Dominio 3 Diseño de software seguro

Una de las fases más importantes del SDLC es la fase de diseño. Durante esta fase, las
especificaciones de software se traducen en planos arquitectónicos que se pueden codificar
durante la fase de implementación (o codificación) que sigue. Cuando esto sucede, es
necesario que la traducción incluya principios de diseño seguro. También es importante
asegurarse de que los requisitos que garantizan la seguridad del software están diseñados
en el software en la fase de diseño. Si bien escribir código seguro es importante para la
garantía del software, la mayoría de los problemas de seguridad del software se han
atribuido a un diseño inseguro o incompleto. Clases completas de vulnerabilidades que no
son sintácticas o relacionadas con el código, como fallas semánticas o de lógica
empresarial, están relacionadas con problemas de diseño. La evaluación de la superficie de
ataque utilizando modelos de amenazas y el modelado de casos de uso indebido (que se
tratan en el capítulo Requisitos de software seguro), la identificación de controles y la
priorización basada en el riesgo para el negocio son todos procesos esenciales de garantía
de software que deben realizarse durante la fase de diseño del desarrollo de software. En
este capítulo, cubriremos los principios y procesos de diseño seguro, y aprenderemos sobre
diferentes arquitecturas y tecnologías, que se pueden aprovechar para aumentar la
seguridad en el software. Terminaremos este capítulo entendiendo la necesidad y la
importancia de realizar revisiones arquitectónicas del diseño de software desde una
perspectiva de seguridad.

Temas
● Procesos de diseño
○ Evaluación de superficie de ataque
○ Modelado de amenazas
○ Identificación de control
○ Priorización de control
○ Documentación
● Consideraciones de diseño
○ Métodos de cifrado, hash y recuperación
○ Autenticación multifactor y registro
○ Principios de diseño de seguridad
○ Interconectividad
○ Interfaces de gestión de seguridad
○ Gestión de identidad
● Arquitectura
○ Computación distribuida
○ Arquitectura orientada a servicios
○ Aplicaciones de Internet enriquecidas
○ Computación generalizada
○ Integración con arquitecturas existentes
○ Software como servicio
● Tecnologías
 ○ Autenticación y gestión de identidad
○ Gestión de credenciales (por ejemplo, X.509 y SSO)
○ Control de flujo (por ejemplo, proxies, firewalls, middleware)
○ Auditoría (por ejemplo, syslog, IDS e IPS)
○ Protección de datos (por ejemplo, DLP, cifrado y seguridad de la base de
datos)
○ Entorno informático (por ejemplo, lenguajes de programación, virtualización y
sistemas operativos
○ Gestión de derechos digitales (DRM)
○ Integridad (por ejemplo, firma de código)
● Revisión técnica de diseño y arquitectura (por ejemplo, revisión de puntos de interfaz
y diagrama de implementación)

Objetivos
Como CSSLP, se espera que:

● Comprender la necesidad y la importancia de diseñar la seguridad en el software.

● Familiarícese con los principios de diseño seguro y cómo se pueden incorporar al
diseño de software.
● Tener un conocimiento profundo de cómo modelar el software de amenazas.
● Familiarícese con las diferentes arquitecturas de software que existen y los
beneficios y desventajas de seguridad de cada una.
● Comprender la necesidad de tener en cuenta las consideraciones de seguridad de
los datos (tipo, formato), la base de datos, la interfaz y la interconectividad al diseñar
el software.
● Sepa cómo el entorno informático y las tecnologías elegidas pueden tener un
impacto en las decisiones de diseño con respecto a la seguridad.
● Sepa cómo realizar revisiones de diseño y arquitectura con una perspectiva de
seguridad.

Este capítulo cubrirá cada uno de estos objetivos en detalle. Es imperativo que comprenda
completamente los objetivos y esté familiarizado con cómo aplicarlos al software que su
empresa crea o adquiere.

La necesidad de un diseño seguro

El software que está diseñado correctamente mejora la calidad del software. Además de los
aspectos funcionales y de calidad del software, existen otros requisitos que deben tenerse
en cuenta en su diseño. Algunos de estos otros requisitos incluyen requisitos de privacidad,
globalización, localización y seguridad. En el capítulo Conceptos de software seguro,
aprendimos que el software puede cumplir con todos los requisitos de calidad y aún ser
inseguro, lo que justifica la necesidad de diseñar explícitamente el software teniendo en
cuenta la seguridad.
IBM Systems Sciences Institute, en su trabajo de investigación sobre la implementación de
inspecciones de software, determinó que era casi cien veces más caro corregir errores de
seguridad una vez que el software está en producción que cuando se está diseñando. El
tiempo necesario para solucionar los problemas identificados es más corto cuando el
software aún se encuentra en la fase de diseño. Los ahorros de costos son sustanciales ya
que hay una interrupción mínima o nula en las operaciones comerciales. Además de los
beneficios de ahorro de tiempo y costos antes mencionados, existen varios otros beneficios
de diseñar la seguridad al principio del SDLC. Algunos de estos incluyen los siguientes:

● Software resistente y recuperable: la seguridad diseñada en el software reduce la

probabilidad de ataques o errores, lo que asegura la resistencia y la capacidad de
recuperación del software.
● Software de calidad que se puede mantener y que es menos propenso a errores: el
diseño seguro no solo aumenta la resistencia y la capacidad de recuperación del
software, sino que también es menos propenso a errores (accidentales o
intencionales). En este sentido, el diseño seguro está directamente relacionado con
los aspectos de confiabilidad del software. También hace que el software sea de fácil
mantenimiento al tiempo que mejora considerablemente la calidad del software.
● Rediseño mínimo y consistencia: cuando el software se diseña teniendo en cuenta la
seguridad, existe una necesidad mínima de rediseño. El uso de estándares para el
diseño arquitectónico de software también hace que el software sea coherente,
independientemente de quién lo esté desarrollando.
● Defectos de lógica empresarial abordados: Los defectos de lógica empresarial son
aquellos que se caracterizan porque el software funciona según lo diseñado, pero el
diseño en sí hace posible eludir la política de seguridad. Se han observado
comúnmente fallas en la lógica empresarial en la forma en que se diseñan los
mecanismos de recuperación de contraseñas. En los primeros días, cuando las
personas necesitaban recuperar sus contraseñas, se les pedía que respondieran a
un conjunto predefinido de preguntas, para lo cual habían proporcionado respuestas
que se guardaban en sus perfiles en el sistema. Estas preguntas eran fáciles de
adivinar o, a menudo, tenían un conjunto finito de respuestas. No es difícil adivinar el
color favorito de una persona o proporcionar una respuesta del conjunto finito de
colores primarios que existe. El software responde a la entrada del usuario según lo
diseñado, por lo que realmente no hay problemas de confiabilidad. Sin embargo,
debido a que no se consideró cuidadosamente la arquitectura mediante la cual se
diseñó la recuperación de contraseñas, existía la posibilidad de que un atacante
usará la fuerza bruta o eludiera inteligentemente los mecanismos de seguridad. Al
diseñar software teniendo en cuenta la seguridad, se pueden descubrir fallas en la
lógica empresarial y otros problemas de diseño arquitectónico, que es una de las
principales ventajas de diseñar software de forma segura.

Invertir el tiempo por adelantado en el SDLC para diseñar la seguridad en el software

respalda el motivo de seguridad "integrado", en lugar de intentar "atornillarlo" en una etapa
posterior. El método atornillado para implementar la seguridad puede resultar muy costoso,
llevar mucho tiempo y generar software de baja calidad que se caracteriza por ser poco
confiable, inconsistente, no mantenible, propenso a errores y susceptible de ser explotado
por piratas informáticos.
Defectos contra errores

Si bien puede parecer que muchos errores de seguridad están relacionados con una
programación insegura, la mayoría de los errores de seguridad también se basan en la
arquitectura. La línea de demarcación entre cuando un error de seguridad del software se
basa en una arquitectura incorrecta o cuando se debe a una implementación insegura no
siempre es muy clara, ya que el error en sí mismo puede ser el resultado de una falla en la
arquitectura y en la implementación. En la etapa de diseño, dado que no se escribe ningún
código, nos preocupan principalmente los problemas de diseño relacionados con la garantía
del software. En el resto de este capítulo y libro, nos referiremos a los defectos de diseño y
arquitectura que pueden resultar en errores como "fallas" y a las construcciones de
codificación / implementación que pueden causar una brecha en la seguridad como
"errores".

No es tan importante saber qué errores de seguridad constituyen una falla y cuáles un error,
pero es importante comprender que tanto las fallas como los errores deben identificarse y
abordarse de manera adecuada. El modelado de amenazas y las revisiones de diseño de
arquitectura segura, que cubriremos más adelante en este capítulo, son útiles en la
detección de arquitectura (fallas) y problemas de implementación (compras), aunque estos
últimos están determinados principalmente por revisiones de código y ejercicios de prueba
de penetración después de la implementación. Los defectos de la lógica empresarial que se
mencionaron anteriormente son principalmente un problema de diseño. No son fácilmente
detectables al revisar el código. Los escáneres y los sistemas de detección de intrusos
(IDS) no pueden detectarlos, y los firewalls de la capa de aplicación son inútiles en su
protección contra ellos. El descubrimiento de fallas de diseño no sintácticas en las
operaciones lógicas del software es posible gracias a las revisiones de arquitectura y diseño
de seguridad. Las revisiones de arquitectura y diseño de seguridad que utilizan los
resultados de la evaluación de la superficie de ataque, el modelado de amenazas y el
modelado de casos de uso indebido son muy útiles para garantizar que el software no solo
funcione como se espera, sino que no infrinja ninguna política de seguridad al hacerlo. Las
fallas lógicas también se conocen como problemas semánticos. Los defectos son amplias
clases de vulnerabilidades, que a veces también pueden incluir errores de codificación
sintáctica. La validación de entrada insuficiente y la gestión inadecuada de errores y
sesiones son predominantemente defectos arquitectónicos que se manifiestan como errores
de codificación.

Software de arquitectura con conceptos básicos de seguridad

Además de diseñar para la funcionalidad del software, también se debe realizar el diseño
para los principios y principios de seguridad. En el capítulo anterior, aprendimos sobre
varios tipos de requisitos de seguridad. En la fase de diseño, consideraremos cómo se
pueden incorporar estos requisitos en la arquitectura y composición del software. En esta
sección, cubriremos cómo se pueden diseñar los requisitos de seguridad identificados y qué
decisiones de diseño se deben tomar en función de las necesidades comerciales.
Comenzaremos con cómo diseñar el software para abordar los elementos de seguridad
básicos de confidencialidad, integridad, disponibilidad, autenticación, autorización y
auditoría, y luego veremos ejemplos de cómo diseñar los principios de diseño seguro
cubiertos en los Conceptos de software seguro. capítulo.

Diseño de confidencialidad

La protección de la divulgación se puede lograr de varias formas utilizando técnicas

criptográficas y de enmascaramiento. El enmascaramiento, que se trata en el capítulo
Requisitos de software seguro, es útil para proteger la divulgación cuando los datos se
muestran en la pantalla o en formularios impresos; pero para garantizar la confidencialidad
cuando los datos se transmiten o almacenan en almacenes de datos transaccionales o
archivos fuera de línea, se utilizan principalmente técnicas criptográficas. Las técnicas
criptográficas más predominantes incluyen técnicas abiertas como hash y cifrado y técnicas
encubiertas como esteganografía y marca de agua digital como se muestra en la Figura 3.1.
Estas técnicas se introdujeron en el capítulo Requisitos de software seguro y se tratan aquí
con un poco más de detalle con una perspectiva de diseño.

El criptoanálisis es la ciencia de encontrar vulnerabilidades en los mecanismos de

protección criptográfica. Cuando se implementan técnicas de protección criptográfica, el
objetivo principal es asegurar que un atacante con recursos deba hacer un esfuerzo tan
grande para subvertir o evadir los mecanismos de protección que el esfuerzo requerido, en
sí mismo, sirva como disuasivo o imposibilite la subversión o evasión. Este esfuerzo se
denomina factor de trabajo. Es fundamental tener en cuenta el factor de trabajo al elegir una
técnica criptográfica al diseñar el software. El factor de trabajo contra la protección
criptográfica depende exponencialmente del tamaño de la clave. Una clave es una
secuencia de símbolos que controla las operaciones de cifrado y descifrado de un algoritmo
criptográfico. En la práctica, esta suele ser una cadena de bits que se suministra como
parámetro en el algoritmo para cifrar texto sin formato para cifrar texto o para descifrar texto
cifrado para convertirlo en texto sin formato. Es vital que esta clave se mantenga en secreto.

El tamaño de la clave, también conocido como longitud de la clave, es la longitud de la clave

que se utiliza en el algoritmo. Normalmente se mide en bits o bytes. Con el tiempo y la
potencia computacional, casi todos los algoritmos criptográficos pueden romperse, excepto
el pad único, que es el único algoritmo que es demostrablemente irrompible mediante
exhaustivos ataques de fuerza bruta. Sin embargo, esto solo es cierto si la clave utilizada en
el algoritmo es verdaderamente aleatoria y se descarta permanentemente después de su
uso. El tamaño de la clave en un teclado de una sola vez es igual al tamaño del mensaje en
sí y cada bit de clave se usa solo una vez y se descarta.

Además de proteger el secreto de la clave, la administración de claves es extremadamente

crítica. El ciclo de vida de la administración de claves incluye la generación, intercambio,
almacenamiento, rotación, archivo y destrucción de la clave, como se ilustra en la Figura
3.2.

Desde el momento en que se genera la clave hasta el momento en que se elimina por
completo (o se destruye), es necesario protegerla. El mecanismo de intercambio, en sí
mismo, debe ser seguro para que la clave no se revele cuando se comparte la clave.
Cuando la clave se almacena en archivos de configuración o en un módulo de seguridad de
hardware (HSM) como el chip Trusted Platform Modules (TPM) para una mayor seguridad,
debe protegerse mediante mecanismos de control de acceso, seguridad TPM, cifrado y
arranque seguro. mecanismos, que cubriremos en el capítulo Implementación, operaciones,
mantenimiento y eliminación de software.

La rotación (intercambio) de claves implica el vencimiento de la clave actual y la generación,

intercambio y almacenamiento de una nueva clave. Las claves criptográficas deben
intercambiarse periódicamente para frustrar las amenazas internas e inmediatamente
después de la divulgación de la clave. Cuando la clave se rota como parte de un protocolo
de seguridad de rutina, si los datos de los que se realiza una copia de seguridad o se
archivan están en formato cifrado, entonces la clave que se utilizó para cifrar los datos
también debe archivarse. Si la clave se destruye sin ser archivada, la clave correspondiente
para descifrar los datos no estará disponible; que conduzca a una denegación de servicio
(DoS) en caso de que sea necesario recuperar los datos para fines forenses o de
recuperación ante desastres.

Los algoritmos de cifrado son principalmente de dos tipos, simétricos y asimétricos.

Algoritmos simétricos

Los algoritmos simétricos se caracterizan por utilizar una única clave para las operaciones
de cifrado y descifrado que se comparte entre el remitente y el receptor. Esto también se
conoce con otros nombres, como criptografía de clave privada, criptografía de clave
compartida o algoritmo de clave secreta. El remitente y el receptor no necesitan ser
humanos todo el tiempo. En el mundo empresarial actual de la informática, los remitentes y
receptores pueden ser aplicaciones o software dentro o fuera de la empresa.

El principal beneficio de la criptografía de clave simétrica es que es muy rápida y eficiente

para encriptar grandes volúmenes de datos en un corto período de tiempo. Sin embargo,
esta ventaja viene con desafíos importantes que tienen un impacto directo en el diseño del
software. Algunos de los desafíos con la criptografía de clave simétrica incluyen los
siguientes:

● Intercambio y gestión de claves: tanto el originador como el receptor deben tener un

mecanismo para compartir la clave sin comprometer su secreto. Esto a menudo
requiere un mecanismo seguro fuera de banda para intercambiar la información
clave, lo que requiere más esfuerzo y tiempo, además de aumentar potencialmente
el área de superficie de ataque. La entrega de la clave y los datos también deben ser
mutuamente excluyentes.
● Escalabilidad: dado que se debe utilizar una clave única entre cada remitente y
destinatario, el número de claves necesarias para las operaciones criptográficas de
clave simétrica depende exponencialmente del número de usuarios o partes
involucradas en esa transacción segura. Por ejemplo, si Jack quiere enviar un
mensaje a Jill, ambos deben compartir una clave. Si Jill quiere enviar un mensaje a
 John, entonces debe haber una clave diferente que se utilice para que Jill se
comunique con John. Ahora, entre Jack y John, también existe la necesidad de otra
clave, si necesitan comunicarse. Ahora, si agregamos a Jessie a la mezcla, es
necesario tener seis teclas, una para que Jessie se comunique con Jack, una para
que Jessie se comunique con Jill y otra para que Jessie se comunique con John,
además de las tres teclas que son necesarios como se mencionó anteriormente y se
muestran en la Figura 3.3. El cálculo del número de claves se puede representar
matemáticamente como:

Entonces, si hay 10 usuarios / partes involucradas, entonces la cantidad de claves

requeridas es 45 y si hay 100 usuarios / partes involucradas, entonces necesitamos
generar, distribuir y administrar 4950 claves, lo que hace que la criptografía de clave
simétrica no sea muy escalable.

No repudio no abordado: la clave simétrica proporciona protección de

confidencialidad simplemente cifrando y descifrando los datos. No proporciona
prueba de origen o no repudio.

En la Tabla 3.1 se tabulan algunos ejemplos de algoritmos de criptografía de clave simétrica

común junto con su fuerza y ​tamaño de clave admitido. RC2, RC4 y RC5 son otros ejemplos
de algoritmos simétricos que tienen diversos grados de fuerza según los múltiples tamaños
de clave que admiten. Por ejemplo, el algoritmo RC2- 40 se considera un algoritmo débil
mientras que el RC2-128 se considera un algoritmo fuerte.

Algoritmos asimétricos

En la criptografía de clave asimétrica, en lugar de utilizar una única clave para las
operaciones de cifrado y descifrado, se utilizan dos claves que están relacionadas
matemáticamente entre sí. Una de las dos claves debe mantenerse en secreto y se conoce
como clave privada, mientras que la otra clave se revela a cualquier persona con quien se
necesiten comunicaciones y transacciones seguras. La clave que se muestra públicamente
a todos se conoce como clave pública. También es importante que sea computacionalmente
inviable derivar la clave privada de la clave pública. Aunque existe una clave privada y una
clave pública en la criptografía de clave asimétrica, se la conoce comúnmente como
criptografía de clave pública.

Tanto la clave privada como la pública se pueden utilizar para el cifrado y el descifrado. Sin
embargo, si un mensaje está cifrado con una clave pública, solo la clave privada
correspondiente puede descifrar ese mensaje. Lo mismo ocurre cuando un mensaje se cifra
con una clave privada. Ese mensaje solo se puede descifrar mediante la clave pública
correspondiente. Esto hace posible que la criptografía de clave asimétrica proporcione
garantía de confidencialidad y de no repudio.

La confidencialidad se proporciona cuando el remitente utiliza la clave pública del receptor

para cifrar el mensaje y el receptor utiliza la clave privada correspondiente para descifrar el
mensaje, como se ilustra en la Figura 3.4. Por ejemplo, si Jack quiere comunicarse con Jill,
puede cifrar el mensaje de texto sin formato con su clave pública y enviarle el texto cifrado
resultante. Jill puede usar su clave privada que está emparejada con su clave pública y
descifrar el mensaje. Dado que la clave privada de Jill no debe ser conocida por nadie más
que Jill, el mensaje está protegido contra cualquier persona que no sea Jill, garantizando la
confidencialidad. Ahora, si Jill quiere responder a Jack, puede cifrar el mensaje de texto sin
formato que planea enviarle con su clave pública y enviarle el texto cifrado resultante.
Luego, Jack puede descifrar el mensaje de texto cifrado a texto sin formato utilizando su
clave privada, que nuevamente, solo él debería saber.

Además de la protección de la confidencialidad, la criptografía de clave asimétrica también

puede proporcionar una garantía de no repudio. La protección de no repudio también se
conoce como garantía de prueba de origen. Cuando se utiliza la clave privada del remitente
para cifrar el mensaje y el receptor utiliza la clave correspondiente para descifrarlo, como se
ilustra en la Figura 3.5, se proporciona la garantía de la prueba de origen. Dado que el
mensaje sólo puede ser descifrado por la clave pública del remitente, el receptor tiene la
seguridad de que el mensaje se originó en el remitente y fue cifrado por la clave privada
correspondiente del remitente. Para demostrar el no repudio o la prueba de origen,
consideremos el siguiente ejemplo. Jill tiene la clave pública de Jack y recibe un mensaje
encriptado de Jack. Ella puede descifrar ese mensaje usando la clave pública de Jack. Esto
le asegura que el mensaje fue encriptado usando la clave privada de Jack y le da la
confianza de que Jack no puede negar que le envió el mensaje, ya que él es el único que
debería tener conocimiento de su clave privada.

Si Jill quiere enviar un mensaje a Jack y él necesita estar seguro de que nadie más que Jill
le envió el mensaje, Jill puede cifrar el mensaje con su clave privada y Jack usará su clave
pública correspondiente para descifrar el mensaje. Un compromiso en la clave privada de
las partes involucradas puede dar lugar a amenazas de confidencialidad y no repudio. Por
tanto, es de vital importancia proteger el secreto de la clave privada.

Además de la garantía de confidencialidad y no repudio, la criptografía de clave asimétrica

también proporciona control de acceso, autenticación y garantía de integridad. Se
proporciona control de acceso ya que la clave privada está limitada a una persona. En virtud
del no repudio, se valida la identidad del remitente, que admite la autenticación. A menos
que el par de claves público-privado se vea comprometido, los datos no se pueden descifrar
ni modificar, lo que proporciona una garantía de integridad de los datos.

La criptografía de clave asimétrica tiene varias ventajas sobre la criptografía de clave

simétrica. Estos incluyen los siguientes:

● Intercambio y administración de claves: en la criptografía de claves asimétricas, se

alivian los costos generales de tener que intercambiar y almacenar la clave de forma
segura. Las operaciones criptográficas que utilizan claves asimétricas requieren una
identificación, intercambio y gestión de claves de infraestructura de claves públicas
(PKI). PKI utiliza certificados digitales para hacer posible el intercambio de claves y
la automatización de la gestión. Los certificados digitales se tratan en la siguiente
sección.
● Escalabilidad: a diferencia de la criptografía de clave simétrica, donde existe la
necesidad de generar y distribuir de forma segura una clave entre cada parte, en la
criptografía de clave asimétrica, solo se necesitan dos claves por usuario; uno que
es privado y en poder del remitente y el otro que es público y se distribuye a
cualquiera que desee realizar una transacción con el remitente. 100 usuarios
requerirán 200 claves, lo que es mucho más fácil de administrar que las 4.950 claves
necesarias para la criptografía de clave simétrica.
● Aborda el no repudio: también aborda el no repudio al proporcionar al receptor la
garantía de una prueba de origen. El remitente no puede negar el envío del mensaje
cuando el mensaje se ha cifrado con la clave privada del remitente.
Si bien la criptografía de clave asimétrica proporciona muchos beneficios sobre la
criptografía de clave simétrica, también existen ciertos desafíos que prevalecen. La
criptografía de clave pública es computacionalmente intensiva y mucho más lenta que la
encriptación simétrica. Sin embargo, esta es una opción de diseño preferible para entornos
de Internet.

Algunos ejemplos comunes de algoritmos de clave asimétrica incluyen Rivest, Shamir,

Adelman (RSA), El Gamal, Diffie-Hellman (que se usa solo para el intercambio de claves y
no para el cifrado de datos) y Elliptic Curve Cryptosystem (ECC), que es ideal para
dispositivos de hardware pequeños. como tarjetas inteligentes y dispositivos móviles.

Certificados digitales

El estándar de certificado digital actual, reconocido internacionalmente es ITU X.509 versión

3 (X.509 v3), que especifica formatos para la clave pública, el número de serie, el nombre
del propietario del par, un período de validez que indica el rango de fechas desde cuándo y
durante cuánto tiempo será válido el certificado, el identificador del algoritmo asimétrico que
se utilizará, el nombre de la autoridad certificadora (CA) que acredite la propiedad, los
números de versión de la certificación a los que se ajusta el certificado y un conjunto
opcional de extensiones , como se muestra en la Figura 3.6.

Cualquiera puede utilizar los certificados digitales para verificar la autenticidad del
certificado en sí, ya que contiene el certificado digital de la autoridad certificadora.

Los diferentes tipos de certificados digitales que se utilizan predominantemente en la

configuración de Internet incluyen:
 ● Certificados personales
● Certificados de servidor
● Certificados de validación extendida (EV) y
● Certificados de editor de software

Los certificados personales se utilizan para identificar a las personas y autenticarlas en el

servidor. El correo electrónico seguro que utiliza S-Mime utiliza certificados personales.

Los certificados de servidor se utilizan para identificar servidores. Estos se utilizan

principalmente para verificar la identidad del servidor con el cliente y para comunicaciones
seguras y seguridad de la capa de transporte. El protocolo Secure Sockets Layer (SSL)
utiliza certificados de servidor para garantizar la confidencialidad cuando se transmiten
datos.

Los certificados de validación extendida (EV) son para mejorar la confianza del usuario y
reducir las amenazas de ataques de phishing. Con el predominio de la informática en línea,
la necesidad de una mayor garantía de identidad en línea y representación de identidades
en línea en el navegador dio lugar a un tipo especial de certificado X.509. Estos se conocen
como certificados de validación extendida (EV). A diferencia de los certificados
tradicionales, que protegen la información solo entre un remitente y un receptor, los
certificados EV también brindan garantía de que los sitios o servidores remotos a los que los
usuarios se conectan son legítimos. Los certificados EV se someten a una validación más
extensa de la identidad del propietario antes de su emisión e identifican a los propietarios de
los sitios a los que se conectan los usuarios y, por lo tanto, abordan los ataques MITM. La
Figura 3.7 ilustra un ejemplo de un certificado de servidor SSL de validación extendida
digital que proporciona información sobre la CA, su validez e información de huellas
dactilares.

Los certificados de editor de software se utilizan para firmar software que se distribuirá
en Internet. Es importante tener en cuenta que estos certificados no garantizan
necesariamente que el código firmado sea seguro para su ejecución, sino que tienen una
función meramente informativa e informan al usuario del software que el certificado está
firmado por una CA de un editor de software de confianza.

Más adelante en este capítulo, aprenderemos sobre los certificados digitales en el contexto
de la infraestructura de clave pública (PKI) y la infraestructura de gestión de privilegios
(PMI). Se trata en la sección Gestión de certificados en Tecnologías.
Firmas digitales

Los certificados contienen en ellos las firmas digitales de las CA que verificaron y emitieron
los certificados digitales. Una firma digital es distinta de un certificado digital. Es similar a la
firma de un individuo en su función, que es autenticar la identidad del remitente del
mensaje, pero en su formato es electrónico. Las firmas digitales no solo proporcionan
verificación de identidad, sino que también garantizan que los datos o el mensaje no hayan
sido manipulados, ya que la firma digital que se utiliza para firmar el mensaje no puede ser
imitada fácilmente por alguien a menos que se vea comprometida. También proporciona no
repudio.

Hay varias consideraciones de diseño que deben tenerse en cuenta al elegir técnicas
criptográficas. Por lo tanto, es imperativo comprender primero los requisitos comerciales
relacionados con la protección de información confidencial o privada. Cuando se
comprenden estos requisitos, se puede elegir un diseño apropiado que se utilizará para
implementar de forma segura el software. Si hay una necesidad de comunicaciones seguras
en las que nadie más que el remitente y el receptor deben conocer un mensaje oculto, se
puede considerar la esteganografía en el diseño. Si es necesario proteger los derechos de
autor y la propiedad intelectual, las técnicas de marca de agua digital son útiles. Si es
necesario garantizar la confidencialidad de los datos en el procesamiento, tránsito,
almacenamiento y archivos, se pueden utilizar técnicas de cifrado o hash.
Diseño de integridad

La integridad en el diseño asegura que no haya modificaciones no autorizadas del software

o los datos. La integridad del software y los datos se puede lograr utilizando cualquiera de
las siguientes técnicas o una combinación de las técnicas, como Hashing (o funciones
hash), diseño de integridad referencial, bloqueo de recursos y firma de código (cubierto en
el capítulo Implementación segura de software) . Las firmas digitales también brindan
protección contra la alteración de datos o mensajes.

Hashing (Funciones Hash)

Aquí hay un resumen de lo que se introdujo sobre el hash en el capítulo Requisitos de

software seguro: Las funciones hash se utilizan para condensar entradas de longitud
variable en una salida irreversible de tamaño fijo conocida como resumen de mensaje o
valor hash. Al diseñar software, debemos asegurarnos de que se tengan en cuenta todos
los requisitos de integridad que garantizan una protección irreversible, que se proporciona
mediante hash. La figura 3.8 describe los pasos que se toman para verificar la integridad
con hash. John quiere enviar un mensaje privado a Jessie. Pasa el mensaje a través de una
función hash, que genera un valor hash, H1. Envía el resumen del mensaje (datos originales
más valor hash H1) a Jessie. Cuando Jessie recibe el resumen del mensaje, calcula un
valor hash, H2, usando la misma función hash que John usó para generar H1. En este
punto, el valor hash original (H1) se compara con el nuevo valor hash (H2). Si los valores
hash son iguales, entonces el mensaje no se ha alterado cuando se transmitió.

Además de garantizar la integridad de los datos, también es importante asegurarse de que

el diseño de hash esté libre de colisiones. "Libre de colisiones" implica que no es factible
computacionalmente calcular el mismo valor hash en dos entradas diferentes. Los ataques
de cumpleaños se utilizan a menudo para encontrar colisiones en funciones hash. Un
ataque de cumpleaños es un tipo de ataque de fuerza bruta que recibe su nombre de la
probabilidad de que dos o más personas elegidas al azar puedan tener el mismo
cumpleaños. Los diseños de hash seguros garantizan que los ataques de cumpleaños no
sean posibles, lo que significa que un atacante no podrá ingresar dos mensajes y generar el
mismo valor de hash. Salar el hash es un mecanismo que asegura valores de hash libres de
colisiones. Salar el hash también protege contra los ataques de diccionario, que son otro
tipo de ataque de fuerza bruta. Un ataque de diccionario es un intento de frustrar los
mecanismos de protección de seguridad mediante el uso de una lista exhaustiva (como una
lista de palabras de un diccionario).

Los valores de sal son bytes aleatorios que se pueden usar con la función hash para evitar
colisiones y prevenir ataques de diccionario prediseñado. Consideremos lo siguiente: Es
probable que dos usuarios dentro de una gran empresa tengan la misma contraseña. Tanto
John como Jessie tienen la misma contraseña, "tiger123" para iniciar sesión en su cuenta
bancaria. Cuando la contraseña se hash utilizando la misma función hash, debe producir el
mismo valor hash que se muestra en la Figura 3.9. La contraseña, "tiger123" se codifica
mediante la función hash MD5 para generar un valor de hash de tamaño fijo,
"68FAC1CEE85FFE11629781E545400C65".

Aunque los nombres de usuario son diferentes, cuando la contraseña es hash, puede
provocar ataques de suplantación, ya que genera el mismo resultado, donde John puede
iniciar sesión como Jessie o viceversa. Aunque técnicamente, esto no se considera una
colisión hash ya que la entrada es la misma, tales fallas de diseño se pueden mitigar
usando una sal. Al agregar bytes aleatorios (salt) al texto sin formato original antes de
pasarlo a través de la función hash, la salida que se genera para la misma entrada se hace
diferente. Esto mitiga los problemas de seguridad discutidos anteriormente. Se recomienda
utilizar un valor de sal que sea único y aleatorio para cada usuario. Cuando el valor de sal
es "1234ABC" para John y "9876XYZ" para Jessie, la misma contraseña, "tiger123" da
como resultado diferentes valores hash como se muestra en la Figura 3.10.

Las consideraciones de diseño deben tener en cuenta los aspectos de seguridad

relacionados con la generación de la sal, que deben ser únicos para cada usuario y
aleatorios.

Algunas de las funciones hash más comunes son MD2, MD4 y MD5, todas diseñadas por
Ronald Rivest; la familia Secure Hash Algorithms (SHA-0, SHA-1, SHA-y SHA-2) diseñada
por NSA y publicada por NIST para complementar las firmas digitales y HAVAL. La serie de
algoritmos Ronald Rivest MD genera una salida de tamaño fijo de 128 bits y se ha
demostrado que no está completamente libre de colisiones. La familia de funciones hash
SHA-0 y SHA-1 generaron una salida fija de tamaño de 160 bits. La familia SHA-2 de
funciones hash incluye SHA-224 y SHA-256, que generan una salida de tamaño de 256 bits
y SHA-384 y SHA-512 que generan una salida de tamaño de 512 bits. HAVAL se distingue
por ser una función hash que puede producir hashes en longitudes variables (128 bits - 256
bits). HAVAL también es flexible para permitir que los usuarios indiquen el número de
rondas (3-5) que se utilizarán para generar el hash para mayor seguridad. Como regla
general, cuanto mayor sea la longitud de bits del valor hash admitido, mayor será la
protección proporcionada, lo que hace que el factor de trabajo del criptoanálisis sea
significativamente mayor. Por tanto, al diseñar el software, es importante tener en cuenta la
longitud de bits del valor hash que se admite. La Tabla 3.2 tabula las diferentes longitudes
de los valores hash que son compatibles con algunas funciones hash comunes.

Otro aspecto importante al elegir la función hash para su uso dentro del software es
averiguar si la función hash ya se ha roto y se considera inadecuada para su uso. La
función hash MD5 es un ejemplo que el CERT de EE. UU. Del Departamento de Seguridad
Nacional (DHS) considera criptográficamente roto. DHS promueve el cambio a la familia
SHA de funciones hash.

Integridad referencial

El aseguramiento de la integridad de los datos, especialmente en un sistema de

administración de bases de datos relacionales (RDBMS), es posible gracias a la integridad
referencial, que asegura que los datos no se queden en un estado huérfano. La protección
de integridad referencial utiliza claves primarias y claves externas relacionadas en la base
de datos para asegurar la integridad de los datos. Las claves primarias son aquellas
columnas o combinaciones de columnas en una tabla de base de datos, que identifican de
forma única cada fila en una tabla. Cuando la columna o columnas que se definen como la
clave principal de una tabla están vinculadas (referenciadas) en otra tabla, estas columnas
se denominan claves externas en la segunda tabla. Por ejemplo, como se muestra en la
Figura 3.11, la columna Customer_ID en la tabla CUSTOMER es la clave principal porque
identifica de forma única una fila en la tabla.
Figura 3.11 Integridad Referencial

Aunque hay dos usuarios con el mismo nombre y apellido, "John Smith", el Customer_ID es
único y puede identificar la fila correcta en la base de datos. Los clientes también están
vinculados a sus pedidos mediante su Customer_ID, que es la clave externa en la tabla
ORDER. De esta forma, no es necesario duplicar toda la información del cliente en la tabla
de PEDIDO. La eliminación de duplicados en las tablas se realiza mediante un proceso
llamado Normalización, que se trata más adelante en este capítulo. Cuando se necesita
consultar la base de datos para recuperar todos los pedidos del cliente John Smith cuyo
Customer_ID es 1, se devuelven dos pedidos (Order_ID 101 y 103). En este caso, la tabla
principal es la tabla CUSTOMER y la tabla secundaria es la tabla ORDER. Order_ID es la
clave principal en la tabla ORDER, que, a su vez, se establece como la clave externa en la
tabla ORDER_DETAIL. Para conocer los detalles del pedido realizado por el cliente Mary
Johnson cuyo Customer_ID es 3, podemos recuperar los tres productos que solicitó
haciendo referencia a las relaciones de clave principal y clave externa. En este caso,
además de que la tabla CUSTOMER es el padre de la tabla ORDER, la tabla ORDER, en sí
misma, es padre de la tabla secundaria ORDER_DETAIL.

La integridad referencial asegura que los datos no se queden en un estado huérfano. Esto
significa que si el cliente Mary Johnson se elimina de la tabla CUSTOMER en la base de
datos, todos los detalles de su pedido y pedido correspondientes también se eliminan de las
tablas ORDER y ORDER_DETAIL respectivamente. Esto se conoce como eliminaciones en
cascada. Si no lo hace, los registros estarán presentes en las tablas ORDER y
ORDER_DETAILS como huérfanos con una referencia a un cliente que ya no existe en la
tabla CUSTOMER principal. Cuando se diseña la integridad referencial, se puede configurar
para eliminar todos los registros secundarios cuando se elimina el registro principal o para
no permitir la operación de eliminación de un cliente (registro principal) que tiene pedidos
(registros secundarios), a menos que todos los registros secundarios los registros se
eliminan primero. Lo mismo ocurre en el caso de las actualizaciones. Si por alguna
necesidad comercial, se cambia el Customer_ID de Mary Johnson en la tabla principal
(CUSTOMER), todos los registros posteriores en la tabla secundaria (ORDER) también
deben actualizarse para reflejar el cambio. Esto se conoce como actualizaciones en
cascada.

Las decisiones para normalizar datos en valores atómicos (no duplicados) y establecer
claves primarias y claves externas y sus relaciones, actualizaciones y eliminaciones en
cascada, para asegurar la integridad referencial son consideraciones de diseño importantes
que aseguran la integridad de los datos o la información.

Bloqueo de recursos

Además del hash y la integridad referencial, el bloqueo de recursos se puede utilizar para
asegurar la integridad de los datos o la información. Cuando no se permiten dos
operaciones simultáneas en el mismo objeto (digamos un registro en la base de datos),
porque una de las operaciones bloquea ese registro para que no permita cambios en él,
hasta que completa su operación, se denomina bloqueo de recursos. Si bien esto
proporciona garantía de integridad, es fundamental comprender que si la protección de
bloqueo de recursos no está diseñada correctamente, puede provocar posibles
interbloqueos y la posterior denegación de servicio (DoS). El punto muerto es una condición
cuando dos operaciones compiten entre sí para cambiar el estado de un objeto compartido
y cada una está esperando que la otra libere el objeto compartido que está bloqueado.
Al diseñar software, es necesario considerar los mecanismos de protección que garantizan
que los datos o la información no hayan sido alterados de manera no autorizada o por una
persona o proceso no autorizado, y los mecanismos deben incorporarse en la composición
general del software.

Diseño de disponibilidad

Cuando los requisitos de software exigen la necesidad de operaciones comerciales

continuas, el software debe diseñarse cuidadosamente. El resultado del análisis de impacto
empresarial se puede utilizar para determinar cómo diseñar el software para su
disponibilidad. La protección contra la destrucción y DoS se puede lograr mediante la
codificación adecuada del software. Aunque no se escribe ningún código en la fase de
diseño, en la fase de diseño del software se pueden considerar los requisitos de
configuración, como la agrupación de conexiones, el uso de cursores y construcciones de
bucle. Las construcciones de codificación que utilizan cursores incorrectos y un diseño
incorrecto de bucles pueden provocar interbloqueos y DoS. Cuando estas configuraciones y
construcciones se diseñan correctamente, la garantía de disponibilidad aumenta. Las
técnicas de replicación, conmutación por error y escalabilidad también se pueden utilizar
para diseñar el software para su disponibilidad.
Replicación

Es necesario prestar especial atención al software y la replicación de datos para que el MTD
y el RTO estén ambos dentro de niveles aceptables. Un solo punto de falla se caracteriza
por no tener capacidades de redundancia y esto puede afectar indeseablemente a los
usuarios finales cuando ocurre una falla. Al replicar datos, bases de datos y software en
múltiples sistemas informáticos, se hace posible cierto grado de redundancia. Esta
redundancia también ayuda a proporcionar un medio para reducir la carga de trabajo en
cualquier sistema en particular.

La replicación generalmente sigue un esquema de respaldo maestro-esclavo o

primario-secundario en el que hay un nodo maestro o primario y las actualizaciones se
propagan a los esclavos o al nodo secundario ya sea de forma activa o pasiva. La
replicación activa / activa implica que las actualizaciones se realizan en los sistemas
maestro y esclavo al mismo tiempo. En el caso de la replicación activa / pasiva, las
actualizaciones se realizan primero en el nodo maestro y luego se envían los cambios a las
réplicas posteriormente.

Cuando se trata de la replicación de datos, también se deben tener en cuenta

consideraciones especiales para abordar la integridad de los datos, especialmente en los
esquemas de replicación activa / pasiva.

En informática, la conmutación por error se refiere al cambio automático de un software

transaccional activo, servidor, sistema, componente de hardware o red a un sistema en
espera (o redundante). Aunque la conmutación por error se usa como sinónimo de
conmutación, la distinción entre los dos es que la conmutación por error es automática,
mientras que la conmutación es manual y requiere la intervención humana para cambiar las
operaciones del sistema activo al de reserva. Para asegurar una alta disponibilidad
mediante técnicas de conmutación por error, es imperativo que todos los posibles puntos
únicos de falla se aborden en el diseño de la solución de software.

Diseño de escalabilidad

Un concepto relacionado con la disponibilidad es la escalabilidad. En informática, la

escalabilidad es la capacidad del sistema o software para manejar una cantidad de trabajo
creciente (o creciente) sin que se degrade su funcionalidad o rendimiento. Los dos métodos
principales de diseño para la escalabilidad son:

*Escalado vertical (también conocido como escalado)

*Escala horizontal (también conocida como escala horizontal).

Cada copia del software o sistema generalmente se denomina nodo, cuando se habla de
escalabilidad.

El escalado vertical significa que se agregan recursos adicionales al nodo existente.

También se podría actualizar el nodo existente para manejar las crecientes necesidades.
Suele estar relacionado con el hardware. Un ejemplo de ampliación es agregar memoria y
almacenamiento adicionales al servidor de aplicaciones existente o aumentar la
configuración del grupo de conexiones para manejar mayores conexiones a la base de
datos back-end. La agrupación de conexiones es un mecanismo de eficiencia de acceso a
la base de datos. Un grupo de conexiones es el número de conexiones que la base de
datos almacena en caché para su reutilización. Cuando su software necesita admitir una
gran cantidad de usuarios, se debe configurar la cantidad adecuada de grupos de
conexiones. Si el número de grupos de conexiones es bajo en un entorno altamente
transaccional, la base de datos estará sometida a una gran carga de trabajo,
experimentando problemas de rendimiento que posiblemente pueden conducir a la
denegación de servicio. Una vez que se abre una conexión, se puede colocar en el grupo
para que otros usuarios puedan reutilizar esa conexión, en lugar de abrir y cerrar una
conexión para cada usuario. Esto aumentará el rendimiento, pero se deben tener en cuenta
las consideraciones de seguridad y por eso es necesario diseñar el software desde una
perspectiva de seguridad (disponibilidad).

La escala horizontal significa que se agregan nodos más nuevos al nodo existente.
Un ejemplo de escalamiento horizontal sería instalar copias adicionales del mismo software
o agregar un servidor de caché proxy a la implementación existente de servidores web y de
aplicaciones de uno a dos o más. Se recomienda que se determinen los límites de
escalabilidad del hardware y que el software o sistema esté diseñado para escalabilidad en
lugar de capacidad de hardware. Debe tenerse en cuenta que, si bien el almacenamiento en
caché mejora el rendimiento al reducir el número de viajes de ida y vuelta a los servidores
backend, debe diseñarse cuidadosamente para reducir la probabilidad de problemas de
integridad y divulgación de datos. Si los datos confidenciales se almacenan en caché en el
servidor de caché o en el cliente, pueden dar lugar a la divulgación, si no están protegidos
criptográficamente. Si los datos que se modifican se almacenan en caché antes de realizar
el cambio, pueden producirse problemas de integridad de los datos. El diseño de software
seguro también debe determinar y tener en cuenta la configuración de Tiempo de vida (TTL)
para la caché para que la caché no se almacene indefinidamente después de que haya
transcurrido el tiempo de la ventana de caché. La regla general es que cuanto más críticos
sean los datos en caché, menor será el tiempo que se debe configurar para que se retengan
en el caché.

Diseño de autenticación

Al diseñar para la autenticación, es importante considerar la autenticación multifactor y el

inicio de sesión único (SSO), además de determinar el tipo de autenticación que se requiere
según se especifica en la documentación de requisitos. El uso de múltiples factores o el uso
de más de un factor para autenticar un principal (usuario o recurso) proporciona una mayor
seguridad y se recomienda. Por ejemplo, validar y verificar la huella digital de uno (algo que
usted es) junto con un token (algo que tiene) y un código pin (algo que sabe) antes de
otorgar acceso proporciona una defensa más profunda que simplemente usar un nombre de
usuario y contraseña (algo que sabe ). Además, si existe la necesidad de implementar SSO,
en el que la identidad declarada del principal se verifica una vez y las credenciales
verificadas se transmiten a otros sistemas o aplicaciones, generalmente utilizando tokens,
entonces es crucial tener en cuenta en el diseño del software tanto el impacto en el
rendimiento y su seguridad. Si bien SSO simplifica la administración de credenciales y
mejora la experiencia y el rendimiento del usuario porque la credencial del director se
verifica solo una vez, el diseño incorrecto de SSO puede resultar en brechas de seguridad
que tienen consecuencias colosales. Una brecha en cualquier punto del flujo de la
aplicación puede llevar a un compromiso total, similar a perder las llaves del reino. SSO se
trata con más detalle en la sección de tecnología de este capítulo.

Diseño de autorización

Al diseñar para autorización, preste especial atención a su impacto en el desempeño y a los

principios de separación de funciones y privilegio mínimo. También se debe determinar el
tipo de autorización a implementar de acuerdo con los requisitos. ¿Vamos a utilizar roles o
necesitaremos utilizar una autorización basada en recursos, como un subsistema de
confianza con modelo de suplantación y delegación, para gestionar la concesión de
derechos de acceso? Verificar los derechos de acceso cada vez y cada vez, para hacer
cumplir el principio de mediación completa, puede provocar una degradación del
rendimiento y una disminución de la experiencia del usuario. Por otro lado, un diseño que
requiere el almacenamiento en caché de credenciales verificadas que se utilizan para
decisiones de acceso puede convertirse en un talón de Aquiles desde una perspectiva de
seguridad. Cuando se trata de decisiones de compensación de rendimiento versus
seguridad, se recomienda pecar de cauteloso, teniendo en cuenta la seguridad sobre el
rendimiento. Sin embargo, esta decisión debe ser discutida y aprobada por la empresa.

Cuando se utilizan roles para la autorización, el diseño debe garantizar que no haya roles
en conflicto que eludan el principio de separación de funciones. Por ejemplo, un usuario no
puede desempeñar un papel de cajero y también un papel de auditor para una transacción
financiera. Además, las decisiones de diseño son para asegurar que solo el conjunto
mínimo de derechos se otorgue explícitamente al usuario o recurso, lo que respalda el
privilegio mínimo. Por ejemplo, a los usuarios de la cuenta de grupo "Invitado" o "Todos"
solo se les debe permitir derechos de lectura y no se debe permitir ninguna otra operación.

RBAC es predominantemente la forma en que se toman las decisiones de autorización en la

mayoría de las aplicaciones, pero con la incidencia en el número de aplicaciones de
software de computación en la nube como servicio y aplicaciones móviles, las decisiones
autorizadas se diseñan utilizando la gestión de derechos. El diseño para la autorización se
puede lograr mediante la gestión de derechos. La gestión de derechos se trata de un control
de acceso granular. Responde a la pregunta "¿Quién tiene derecho (autorizado o
autorizado) a realizar qué operaciones después de haber sido autenticadas?" Las dos
formas principales en las que se pueden diseñar los derechos en el software son las
siguientes:

Las decisiones de autorización se ejecutan como un servicio compartido que la

aplicación aprovecha para las decisiones de autorización. Este suele ser el caso de la
implementación del control de acceso en aplicaciones de computación en la nube basadas
en servicios.
 Las decisiones de autorización están integradas en cada aplicación o software que
publica la empresa. Este suele ser el caso de las aplicaciones que se ejecutan en sistemas
operativos móviles. La aplicación en sí se ejecuta dentro de una zona de pruebas y su
interacción con el sistema subyacente se realiza mediante la configuración de derechos.

La ventaja de utilizar un servicio de gestión de derechos en lugar de incluirlo en la propia

aplicación es que las decisiones de control de acceso están centralizadas y los cambios en
la política de control de acceso se pueden aplicar de manera uniforme, universal y
automática en todas las aplicaciones. Esto también hace que la aplicación en sí sea menos
compleja y simplifica los desafíos de auditoría y cumplimiento. Sin embargo, la violación del
servicio de administración de derechos deja huérfanos y pone en riesgo a todas las
aplicaciones que aprovechan ese servicio.

Diseño de responsabilidad

Aunque a menudo se pasa por alto, se ha demostrado que el diseño para auditoría es
extremadamente importante en caso de una infracción, principalmente con fines forenses,
por lo que debe tenerse en cuenta en el diseño del software desde el principio. Los datos de
registro deben incluir los aspectos de "quién", "qué", "dónde" y "cuándo" de las operaciones
del software. Como parte del "quién", es importante no olvidar a los actores no humanos,
como los procesos y servicios por lotes o los demonios.

Es aconsejable iniciar sesión de forma predeterminada y aprovechar la funcionalidad de

registro existente dentro del software, especialmente si se trata de software COTS. Dado
que es una práctica recomendada agregar registros y no sobrescribirlos, las restricciones de
capacidad y los requisitos son consideraciones de diseño importantes. Las decisiones de
diseño para retener, archivar y eliminar registros no deben contradecir los requisitos de
retención internos o normativos externos.

Los datos confidenciales nunca deben registrarse en forma de texto sin formato. Digamos
que los requisitos exigen registrar los intentos de autenticación fallidos. Entonces es
importante verificar con la empresa si es necesario registrar la contraseña que se
proporciona cuando falla la autenticación. Si los requisitos exigen explícitamente que se
registre la contraseña después de una autenticación fallida, entonces es importante diseñar
el software para que la contraseña no se registre en texto sin formato. Los usuarios a
menudo escriben mal sus contraseñas y el registro de esta información puede conducir a
una posible violación de la confidencialidad y comprometer la cuenta. Por ejemplo, si el
software está diseñado para registrar la contraseña en texto plano y el usuario Scott cuya
contraseña es "tigre" la escribe mal como "tigwr", alguien que tenga acceso a los registros
puede adivinar fácilmente la contraseña del usuario.

El diseño también debe tener en cuenta los mecanismos de protección del propio tronco; y
el mantenimiento de la cadena de custodia de los troncos garantizará que los troncos sean
admisibles en los tribunales. La validación de la integridad de los registros se puede lograr
mediante el hash de las imágenes de antes y después de los registros y verificando sus
valores de hash. La auditoría junto con otros controles de seguridad, como la autenticación,
puede proporcionar un no repudio. Es preferible diseñar el software para registrar
automáticamente el principal autenticado y la marca de tiempo del sistema, y ​no dejar que lo
defina el usuario, para evitar posibles problemas de integridad. Por ejemplo, utilizando
Request. ServerVariables [LOGON_USER] en una aplicación web IIS o la función del
sistema getDate () incorporada de T-SQL en SQL Server es preferible a pasar un nombre
principal definido por el usuario o una marca de tiempo.

Hemos aprendido cómo diseñar software incorporando elementos de seguridad básicos de

confidencialidad, integridad, disponibilidad, autenticación, autorización y responsabilidad. En
la siguiente sección, aprenderemos sobre la arquitectura de software con principios de
diseño seguro.

Software de arquitectura con principios de diseño

seguro
Algunos de los problemas de diseño comunes e inseguros que se observan en el software
son los siguientes:

*implementación incorrecta de privilegios mínimos,

*el software falla de forma insegura,
*los mecanismos de autenticación se evitan fácilmente,
*seguridad a través de la oscuridad,
*manejo inadecuado de errores, y
*validación de entrada débil.

En la siguiente sección veremos algunos de los principios de diseño pertinentes a la

arquitectura de software seguro. Los siguientes principios se introdujeron y definieron en el
capítulo Conceptos de software seguro. Se revisa aquí como un repaso y se analiza con
más profundidad con ejemplos.

Privilegios mínimos

Aunque el principio de privilegio mínimo es más aplicable a la administración de un sistema,

donde el número de usuarios con acceso a funciones y controles críticos está restringido, el
privilegio mínimo se puede implementar dentro del diseño de software. Cuando se dice que
el software está operando con el mínimo de privilegios, significa que solo se le ha otorgado
explícitamente el nivel mínimo y necesario de derechos de acceso (privilegios) durante un
período mínimo de tiempo para que pueda completar su operación. El objetivo principal del
privilegio mínimo es la contención del daño que puede resultar de una brecha de seguridad
que ocurre accidental o intencionalmente. Algunos de los ejemplos de privilegio mínimo
incluyen la regla de seguridad militar de clasificación de nivel de autorización de "necesidad
de saber", programación modular y cuentas no administrativas.
La regla de seguridad militar de la necesidad de saber limita la divulgación de información
sensible solo a aquellos que han sido autorizados a recibir dicha información, lo que ayuda
a garantizar la confidencialidad. Quienes han sido autorizados pueden determinarse a partir
de las clasificaciones de nivel de autorización que poseen, como Alto secreto, Secreto,
Sensible pero no clasificado, etc. Las mejores prácticas también sugieren que es preferible
tener muchos administradores con acceso limitado a los recursos de seguridad en lugar de
uno. usuario con derechos de "superusuario".

La programación modular es una técnica de diseño de software en la que todo el programa

se divide en subunidades o módulos más pequeños. Cada módulo es discreto con
funcionalidad unitaria y, por lo tanto, se dice que es cohesivo, lo que significa que cada
módulo está diseñado para realizar una y solo una operación lógica. El grado de cohesión
de un módulo indica la fuerza con la que se relacionan las diversas responsabilidades de un
módulo de software. La discreción del módulo aumenta su facilidad de mantenimiento y la
facilidad para determinar y corregir defectos de software. Dado que cada unidad de código
(clase, método, etc.) tiene un único propósito y las operaciones que puede realizar el código
se limitan solo a aquello para lo que está diseñado, la programación modular también se
conoce como el Principio de Responsabilidad Única de Ingeniería de software. Por ejemplo,
la función CalcDiscount () debería tener la responsabilidad única de calcular el descuento
de un producto, mientras que la función CalcSH () debería usarse exclusivamente para
calcular las tarifas de envío y manipulación. Cuando el código no está diseñado de forma
modular, no solo aumenta la superficie de ataque, sino que también dificulta la lectura y la
resolución de problemas del código. Si existe un requisito para restringir el cálculo de
descuentos a un gerente de ventas, no separar esta funcionalidad en su propia función,
como CalcDiscount (), puede conducir potencialmente a un código de ejecución de un
gerente que no es de ventas y que tiene el privilegio de un gerente de ventas. Un aspecto
relacionado con la cohesión es el acoplamiento. El acoplamiento es un reflejo del grado de
dependencia entre módulos; es decir, qué tan dependiente es un módulo de otro. Cuanto
más dependiente es un módulo con respecto a otro, mayor es su grado de acoplamiento, y
los “módulos acoplados libremente” es la condición en la que las interconexiones entre los
módulos no son rígidas o codificadas.

Las buenas prácticas de ingeniería de software aseguran que los módulos de software sean
altamente cohesivos y estén débilmente acoplados al mismo tiempo. Esto significa que las
dependencias entre módulos serán débiles (débilmente acopladas) y cada módulo será
responsable de realizar una función discreta (altamente cohesiva).

Por lo tanto, la programación modular ayuda a implementar el mínimo de privilegios,

además de hacer que el código sea más legible, reutilizable, mantenible y fácil de
solucionar.

El uso de cuentas con capacidades no administrativas también ayuda a implementar el

privilegio mínimo. En lugar de usar la cuenta "sa" o "sysadmin" para acceder y ejecutar
comandos de la base de datos, usar una cuenta de "lector de datos" o "redactor de datos"
es un ejemplo de implementación de privilegios mínimos.
Separación de tareas

Cuando el diseño divide la funcionalidad del software en dos o más condiciones, todas las
cuales deben cumplirse antes de que se pueda completar una operación, se denomina
separación de funciones. El uso de claves divididas para la funcionalidad criptográfica es un
ejemplo de separación de funciones en el software. Se necesitan claves para las
operaciones de cifrado y descifrado. En lugar de almacenar una clave en una única
ubicación, dividir una clave y almacenar las partes en diferentes ubicaciones, con una parte
en el registro del sistema y la otra en un archivo de configuración, proporciona más
seguridad. El diseño del software debe tener en cuenta las ubicaciones para almacenar
claves, así como los mecanismos para protegerlas.

Otro ejemplo de separación de funciones en el desarrollo de software está relacionado con

los roles que desempeñan las personas durante su desarrollo y el entorno en el que se
implementa el software. No se debe permitir que el programador revise su propio código ni
un programador debe tener acceso para implementar código en el entorno de producción.
Cubriremos con más detalle la separación de tareas según el entorno en la sección de
configuración del capítulo Implementación, operaciones, mantenimiento y eliminación de
software.

Cuando se diseña correctamente, la separación de funciones reduce el alcance del daño

que puede causar una persona o un recurso. Cuando se implementa junto con la auditoría,
también puede desalentar el fraude interno, ya que requerirá la colusión entre las partes
para realizar el fraude.

Defensa en profundidad

La superposición de controles de seguridad y salvaguardas de mitigación de riesgos en el

diseño de software incorpora el principio de defensa en profundidad. Esto también se
conoce como defensa en capas. Las razones detrás de este principio son dobles, la primera
de las cuales es que el incumplimiento de una sola vulnerabilidad en el software no resulta
en un compromiso total o total. En otras palabras, la defensa en profundidad es similar a no
poner todos los huevos en una canasta. En segundo lugar, la incorporación de la defensa
de la profundidad en el software puede utilizarse como disuasión para los atacantes
curiosos y no determinados cuando se enfrentan a una medida defensiva sobre otra.

A continuación se enumeran algunos ejemplos de medidas de defensa en profundidad.

Uso de la validación de entrada junto con declaraciones preparadas o

procedimientos almacenados, lo que impide las construcciones de consultas dinámicas
utilizando la entrada del usuario para defenderse de los ataques de inyección.
No permitir la secuencia de comandos activa junto con la codificación de salida y la
validación de entrada o solicitud para defenderse de la secuencia de comandos entre sitios
(XSS).
El uso de zonas de seguridad, que separa los diferentes niveles de acceso según la
zona a la que el software o persona está autorizada a acceder.
Fallo de seguridad

Fail secure es el principio de seguridad que garantiza que el software funcione de manera
confiable cuando se ataca y se recupere rápidamente en un estado normal de negocio y
seguro en caso de falla de diseño o implementación. Su objetivo es mantener la resistencia
(confidencialidad, integridad y disponibilidad) del software estableciendo un estado seguro
de forma predeterminada. La seguridad ante fallos es principalmente una consideración de
diseño de disponibilidad, aunque también proporciona confidencialidad e integridad. Es
compatible con el diseño y los aspectos predeterminados de la iniciativa SD3, lo que implica
que el software o sistema es seguro por diseño, seguro por defecto y seguro por
implementación. En el contexto de la seguridad del software, "a prueba de fallas" se puede
usar indistintamente con "a prueba de fallas", que se observa comúnmente en la seguridad
física.

Algunos ejemplos de diseño seguro contra fallas en software incluyen los siguientes:

● Al usuario se le niega el acceso de forma predeterminada y la cuenta se

bloquea después de que se intenta el número máximo (nivel de recorte) de
intentos de acceso.
● No diseñar el software para ignorar el error y reanudar la siguiente operación.
La funcionalidad On Error Resume Next en lenguajes de script como
VBScript, como se muestra en la Figura 3.12.
● Los errores y las excepciones se manejan explícitamente y los mensajes de
error no son detallados por naturaleza. Esto asegura que la información de
excepción del sistema, junto con el seguimiento de la pila, no se propague a
la estructura interna del software y lance los ataques en consecuencia para
eludir los mecanismos de protección de seguridad o aprovechar las
vulnerabilidades en el software. El diseño de software seguro tendrá en
cuenta el registro del contenido del error en una base de datos de soporte y
el envío de solo un valor de referencia (como el ID de error) al usuario con
instrucciones para ponerse en contacto con el equipo de soporte para
obtener soporte adicional.
Economía de mecanismos

En el dominio de Secure Software Concepts, notamos que uno de los desafíos para la
implementación de la seguridad es el compromiso que ocurre entre la usabilidad del
software y las características de seguridad que deben diseñarse e integrarse. Con la noble
intención de aumentar la usabilidad de los desarrolladores de software a menudo diseñan y
codifican con más funcionalidad de la necesaria. Esta funcionalidad adicional se conoce
comúnmente como "campanas y silbidos". Un buen indicador de qué características del
software son “campanas y silbidos” innecesarios es revisar la matriz de trazabilidad de
requisitos (RTM) que se genera durante la fase de recopilación de requisitos del proyecto de
desarrollo de software. Las características de campanas y silbatos nunca serán parte del
RTM. Si bien dicha funcionalidad adicional puede aumentar la experiencia del usuario y la
usabilidad del software, aumenta la superficie de ataque y es contraria a la economía de los
mecanismos, el principio de diseño seguro, que establece que cuanto más complejo es el
diseño del software, es más probable que exista vulnerabilidades. Un diseño más simple
implica programas fáciles de entender, menor superficie de ataque y menos enlaces débiles.
Con una superficie de ataque reducida, hay menos oportunidades de fallas y cuando
ocurren fallas, el tiempo necesario para comprender y solucionar los problemas también es
menor. Los beneficios adicionales de la economía de mecanismos incluyen la facilidad para
comprender la lógica del programa y los flujos de datos y menos inconsistencias. La
economía del mecanismo en términos simples también se conoce como el principio KISS
(Keep It Simple Stupid) y, en algunos casos, como el principio de complejidad innecesaria.
La programación modular no solo respalda el principio de privilegio mínimo, sino que
también respalda el principio de economía de mecanismos.

Tomadas en cuenta, las siguientes consideraciones apoyan el diseño de software con el

principio de economía de mecanismos en mente:

Debe evitarse la funcionalidad innecesaria o los mecanismos de seguridad

innecesarios. Dado que la aplicación de parches y la configuración de las versiones de
software más recientes son conocidas por las características de seguridad que estaban
deshabilitadas en versiones anteriores, es recomendable ni siquiera diseñar características
innecesarias, en lugar de diseñarlas y dejar las características en un estado deshabilitado.

Esfuércese por la simplicidad. Mantener los mecanismos de seguridad simples

asegura que la implementación no sea parcial, lo que podría resultar en problemas de
compatibilidad. También es importante modelar los datos para que sean simples, de modo
que el código y las rutinas de validación de datos no sean demasiado complejos o
incompletos. El soporte de expresiones regulares complejas para la validación de datos
puede resultar en debilidades de complejidad algorítmica como se indica en la publicación
407 (CWE-407) de Common Weakness Enumeration.

Esfuércese por la facilidad operativa de uso. El inicio de sesión único (SSO) es un

buen ejemplo que ilustra la simplificación de la autenticación de usuario para que el
software sea operativamente fácil de usar.

Mediación completa

En los primeros días de la programación de aplicaciones web, se observó que un cambio en

el valor de un parámetro QueryString mostraría el resultado que estaba vinculado al nuevo
valor sin ninguna validación adicional. Por ejemplo, si Aidan ha iniciado sesión y el
Localizador uniforme de recursos (URL) en la barra de direcciones del navegador muestra
el par de nombre y valor, usuario = aidan, cambiar el valor "aidan" por "reuben" mostraría la
información de reuben sin validar que el El usuario que inició sesión es, de hecho, Reuben.
Si Aidan cambia el valor del parámetro a user = reuben, puede ver la información de
Reuben, lo que podría provocar ataques a la confidencialidad, en los que la información
personal y sensible de Reuben se divulga a Aidan.

Si bien esto no es tan frecuente hoy como solía ser, problemas de diseño similares todavía
son evidentes en el software. No verificar los derechos de acceso cada vez que un sujeto
solicita acceso a objetos viola el principio de mediación completa. La mediación completa es
un principio de seguridad que establece que las solicitudes de acceso deben ser mediadas
cada vez, cada vez, para que la autoridad no se eluda en solicitudes posteriores. Impone
una vista de todo el sistema del control de acceso. Recordar los resultados de la verificación
de autoridad, como se hace cuando las credenciales de autenticación se almacenan en
caché, puede aumentar el rendimiento; sin embargo, el principio de mediación completa
requiere que los resultados de una verificación de autoridad se examinen con escepticismo
y se actualicen sistemáticamente ante el cambio. Por lo tanto, el almacenamiento en caché
puede conducir a un mayor riesgo de seguridad de omisión de autenticación, secuestro de
sesión y ataques de reproducción, y ataques de intermediario (MITM). Por lo tanto, debe
evitarse, si es posible, diseñar el software para que se base únicamente en el
almacenamiento en caché basado en cookies de las credenciales de autenticación del lado
del cliente.

La mediación completa no solo protege contra las amenazas de autenticación y las

amenazas de confidencialidad, sino que también es útil para abordar los aspectos de
integridad del software. No permitir devoluciones de datos del navegador sin la validación
de los derechos de acceso, o verificar que una transacción se encuentra actualmente en un
estado de procesamiento, puede proteger contra la duplicación de datos, evitando
problemas de integridad de datos. Informar simplemente al usuario que no haga clic más de
una vez, como se muestra en la Figura 3.13, no es infalible y, por lo tanto, el diseño debe
incluir la desactivación de los controles del usuario una vez que se inicia una transacción
hasta que se completa la transacción.

El principio de diseño de mediación completo también aborda la falla en la protección de la

vulnerabilidad de ruta alternativa. Para implementar correctamente la mediación completa
en el software, es aconsejable durante la fase de diseño del SDLC identificar todas las
posibles rutas de código que acceden a recursos privilegiados y sensibles. Una vez que se
identifican estas rutas de código privilegiadas, el diseño debe obligar a estas rutas de
código a utilizar una única interfaz que realiza comprobaciones de control de acceso antes
de realizar la operación solicitada. La centralización de la validación de entrada mediante el
uso de una única capa de validación de entrada con una única lista de verificación de
filtrado de entrada para todas las entradas controladas externamente es un ejemplo de
dicho diseño. Alternativamente, se puede considerar el uso de un marco de validación de
entrada externo que valide todas las entradas antes de que sean procesadas por el código
al diseñar el software.

La mediación completa también aumenta la protección contra el eslabón más débil. El

software es tan fuerte como su componente más débil (código, servicio, interfaz o usuario).
También es importante reconocer que cualquier protección que brinden las salvaguardias
técnicas puede resultar inútil si las personas son víctimas de ataques de ingeniería social o
no saben cómo usar el software. El problema es que las personas que son la primera línea
de defensa en la seguridad del software también pueden convertirse en el eslabón más
débil, si no se les informa, capacita y educa en la seguridad del software.

Diseño abierto

El Dr. Auguste Kerckhoff, a quien se le atribuye habernos dado el principio criptográfico de

Kerckhoff, afirma que toda la información sobre el sistema criptográfico es de conocimiento
público excepto la clave, y la seguridad del sistema criptográfico contra los ataques de
criptoanálisis depende del secreto del llave. Un resultado del principio de Kerckhoff es el
principio de diseño abierto, que establece que la implementación de salvaguardas de
seguridad debe ser independiente del diseño en sí, de modo que la revisión del diseño no
comprometa la protección que ofrecen las salvaguardas. Esto es particularmente aplicable
en criptografía, donde los mecanismos de protección están desacoplados de las claves que
se utilizan para las operaciones criptográficas, y los algoritmos utilizados para el cifrado y
descifrado están abiertos y disponibles para que cualquiera pueda revisarlos.

Lo inverso del principio de diseño abierto es la seguridad a través de la oscuridad, lo que

significa que el software emplea mecanismos de protección cuya fuerza depende de la
oscuridad del diseño, tanto que la comprensión del funcionamiento interno de los
mecanismos de protección es todo lo que se necesita. para derrotar los mecanismos de
protección. Un ejemplo clásico de seguridad a través de la oscuridad, que debe evitarse si
es posible, es la codificación rígida y el almacenamiento de información confidencial, como
claves criptográficas o información de cadenas de conexión con nombre de usuario y
contraseñas, código en línea o ejecutables. La ingeniería inversa, el análisis binario de
ejecutables y el análisis en tiempo de ejecución de protocolos pueden revelar estos
secretos. La revisión del código de las máquinas de votación de Diebold reveló que las
contraseñas estaban integradas en el código fuente, la implementación criptográfica era
incorrecta, el diseño permitía a los votantes votar un número ilimitado de veces sin ser
detectados, los privilegios se podían escalar y las personas con información privilegiada
podían cambiar la elección de la boleta electoral de un votante , todo lo cual podría haberse
evitado si el diseño estuviera abierto a la revisión de otros. Otro ejemplo de seguridad a
través de la oscuridad es el uso de campos de formulario ocultos en aplicaciones web, que
ofrece poca o ninguna protección contra la divulgación, ya que pueden procesarse mediante
un cliente modificado.

Por lo tanto, el diseño del software debe tener en cuenta la necesidad de dejar el diseño
abierto pero mantener la implementación de los mecanismos de protección independiente
del diseño. Además, si bien la seguridad a través de la oscuridad puede aumentar el factor
de trabajo que necesita un atacante y proporcionar cierto grado de defensa en profundidad,
no debería ser el mecanismo de seguridad único y principal del software. Se recomienda
aprovechar los estándares de la industria examinados públicamente, probados y probados,
en lugar de desarrollar a medida el propio mecanismo de protección. Por ejemplo, los
algoritmos de cifrado, como el Estándar de cifrado avanzado (AES) y el Estándar de cifrado
de datos triple (3DES), son examinados públicamente y han sido sometidos a análisis,
pruebas y revisiones de seguridad elaborados por la comunidad de seguridad de la
información. El funcionamiento interno de estos algoritmos está abierto a cualquier revisor, y
la revisión pública puede arrojar luz sobre cualquier debilidad potencial. La clave que se
utiliza en la implementación de estos algoritmos probados es lo que debe mantenerse en
secreto.

Algunos de los aspectos fundamentales del principio de diseño abierto son los siguientes:

*La seguridad de su software no debe depender del secreto del diseño.

*Debe evitarse la seguridad a través de la oscuridad.
 *El diseño de los mecanismos de protección debe estar abierto al escrutinio de los
miembros de la comunidad, ya que es mejor para un aliado encontrar una vulnerabilidad o
falla de seguridad que para un atacante.

Mecanismos menos comunes

Los mecanismos menos comunes es el principio de seguridad por el cual los mecanismos
comunes a más de un usuario o proceso están diseñados para no ser compartidos. Dado
que los mecanismos compartidos, especialmente aquellos que involucran variables
compartidas, representan una ruta de información potencial, los mecanismos que son
comunes a más de un usuario y de los que dependen todos los usuarios deben
minimizarse. El diseño debe compartimentar o aislar el código (funciones) por roles de
usuario, ya que esto aumenta la seguridad del software al limitar la exposición. Por ejemplo,
en lugar de tener una función o biblioteca que se comparte entre miembros con roles de
supervisor y no supervisor, se recomienda tener dos funciones distintas, cada una de las
cuales cumple su rol respectivo.

Aceptabilidad psicológica

Uno de los principales desafíos para lograr que los usuarios adopten la seguridad es que
sienten que la seguridad suele ser muy compleja. Con un aumento en los ataques a las
contraseñas, muchas empresas resolvieron implementar reglas de contraseña seguras,
como la necesidad de tener contraseñas alfanuméricas y de mayúsculas y minúsculas que
deben tener una longitud determinada. Además, estas contraseñas complejas a menudo
deben cambiarse periódicamente. Si bien esto redujo la probabilidad de forzar o adivinar
contraseñas, se observó que los usuarios tenían dificultades para recordar contraseñas
complejas. Por lo tanto, anularon el efecto que las fuertes reglas de contraseñas trajeron al
anotar sus contraseñas y pegarlas debajo de sus escritorios y, en algunos casos, incluso en
las pantallas de sus computadoras. Este es un ejemplo de mecanismos de protección de la
seguridad que no eran psicológicamente aceptables y, por lo tanto, no eran efectivos.

La aceptabilidad psicológica es el principio de seguridad que establece que los mecanismos

de seguridad deben diseñarse para maximizar el uso, la adopción y la aplicación
automática.

Un aspecto fundamental del diseño de software con el principio de aceptabilidad psicológica

es que los mecanismos de protección de seguridad:

*son fáciles de usar,

*no afectan la accesibilidad, y
*son transparentes para el usuario.

Los usuarios no deben tener una carga adicional como resultado de la seguridad y los
mecanismos de protección no deben hacer que el acceso al recurso sea más difícil que si
los mecanismos de seguridad no estuvieran presentes. La accesibilidad y la usabilidad no
deben verse obstaculizadas por los mecanismos de seguridad, ya que de lo contrario, los
usuarios optarán por apagar o eludir los mecanismos, neutralizando o anulando cualquier
protección diseñada.

Ejemplos de incorporación del principio de aceptabilidad psicológica en el software incluyen

el diseño del software para notificar al usuario a través de mensajes de error explícitos y
llamadas como se muestra en la Figura 3.14, pantallas de cuadro de mensaje y diálogos de
ayuda e interfaces de usuario intuitivas.

Eslabón más débil

Es posible que haya escuchado el dicho: "Una cadena es tan fuerte como sus eslabones
más débiles". Este principio de seguridad establece que la resistencia de su software contra
los intentos de piratas informáticos dependerá en gran medida de la protección de sus
componentes más débiles, ya sea el código, el servicio o una interfaz. Una avería en el
eslabón más débil resultará en una infracción de seguridad.

Otro enfoque de este concepto relacionado con la seguridad es que "una cadena es tan
débil como sus eslabones más fuertes". Independientemente del enfoque que se adopte, lo
importante es tener en cuenta que al diseñar software, se debe prestar especial atención
para que no haya componentes explotables.

Un concepto relacionado es "Punto único de falla". El software debe diseñarse de manera

que no exista una fuente única de compromiso total. Si bien esto es similar al principio del
vínculo más débil, la diferencia distintiva entre los dos es que el vínculo más débil no tiene
por qué ser necesariamente el resultado de un único punto de falla, sino que podría ser el
resultado de varias fuentes débiles. Por lo general, en la seguridad del software, el eslabón
más débil es un superconjunto de varios puntos únicos de fallas. Cuando el software se
diseña con una defensa en profundidad, se mitigan las amenazas que surgen de los
enlaces más débiles y los puntos únicos de falla.

Aprovechamiento de componentes existentes

La Arquitectura Orientada a Servicios (SOA) prevalece en el entorno informático actual y

uno de los aspectos principales de su popularidad es la capacidad que proporciona para la
comunicación entre plataformas y entornos heterogéneos. Dicha comunicación es posible
porque los protocolos de arquitectura orientada a servicios son comprensibles para
plataformas dispares, y la funcionalidad empresarial se abstrae y expone para el consumo
como interfaces de programación de aplicaciones (API) basadas en contratos. Por ejemplo,
en lugar de que cada institución financiera escriba su propia rutina de conversión de
moneda, puede invocar un contrato de servicio de conversión de moneda común. Esta es la
premisa fundamental del principio de aprovechamiento de los componentes existentes.
Aprovechar los componentes existentes es el principio de seguridad que promueve la
reutilización de los componentes existentes.

Una observación común en las revisiones de códigos de seguridad es que los

desarrolladores intentan escribir sus propios algoritmos criptográficos en lugar de utilizar
estándares criptográficos validados y probados como AES. Estas implementaciones
personalizadas de funcionalidad criptográfica también se determinan a menudo como el
eslabón más débil. Se recomienda aprovechar las funciones y los algoritmos criptográficos
probados y validados.

Desde el punto de vista de la seguridad, es aconsejable diseñar el software para escalar

utilizando una arquitectura de niveles, ya que la funcionalidad del software se puede dividir
en niveles de presentación, negocios y acceso a datos. El uso de una única capa de acceso
a datos (DAL) para mediar en todo el acceso a los almacenes de datos de backend no solo
respalda el principio de aprovechar los componentes existentes, sino que también permite
escalar para admitir varios clientes o si cambia la tecnología de la base de datos. Se
recomiendan los bloques de aplicaciones empresariales sobre las bibliotecas y controles
compartidos de desarrollo personalizado que intentan proporcionar la misma funcionalidad
que los bloques de aplicaciones empresariales.

La reutilización de bibliotecas y componentes comunes probados y comprobados tiene los

siguientes beneficios de seguridad: En primer lugar, la superficie de ataque no aumenta y,
en segundo lugar, no se introducen nuevas vulnerabilidades. Un beneficio complementario
de aprovechar los componentes existentes es una mayor productividad porque aprovechar
los componentes existentes puede reducir significativamente el tiempo de desarrollo.

Equilibrio de los principios del diseño seguro

Es importante reconocer que es posible que no sea posible diseñar para cada uno de estos
principios de seguridad en su totalidad dentro de su software, y que pueden ser necesarias
decisiones de compensación sobre la medida en que estos principios pueden diseñarse.
Por ejemplo, si bien el SSO puede mejorar la experiencia del usuario y aumentar la
aceptabilidad psicológica, contradice el principio de mediación completa, por lo que es
necesaria una decisión comercial para determinar hasta qué punto el SSO está diseñado en
el software o para determinar que ni siquiera es una opción. considerar. Las
consideraciones de diseño de SSO también deben tener en cuenta la necesidad de
garantizar que no haya un solo punto de falla y que se tomen las medidas de mitigación
adecuadas y en profundidad. Además, implementar una mediación completa mediante la
verificación de los derechos y privilegios de acceso, cada vez y siempre, puede tener un
impacto grave en el rendimiento del software. Por lo tanto, este aspecto del diseño debe
considerarse y tenerse en cuenta cuidadosamente, junto con otras estrategias de defensa
en profundidad, para mitigar la vulnerabilidad sin disminuir la experiencia del usuario o la
aceptabilidad psicológica. El principio del mecanismo menos común puede parecer
contradictorio con el principio de aprovechar los componentes existentes, por lo que es
necesario tener en cuenta un diseño cuidadoso para equilibrar los dos, en función de las
necesidades y requisitos comerciales, sin reducir la seguridad del software. Si bien la
aceptabilidad psicológica requeriría que los usuarios sean notificados del error del usuario,
se deben tener consideraciones de diseño cuidadosas para garantizar que los errores y
excepciones se manejen explícitamente y de naturaleza no detallada para que no se revele
la información de configuración interna del sistema. El principio de los mecanismos menos
comunes puede parecer diametralmente opuesto al principio de aprovechar los
componentes existentes, y se puede argumentar que centralizar la funcionalidad en los
componentes comerciales que se pueden reutilizar es análogo a poner todos los huevos en
una canasta, lo cual es cierto. Sin embargo, las estrategias adecuadas de defensa en
profundidad deben tenerse en cuenta en el diseño al elegir aprovechar los componentes
existentes.

Otras consideraciones de diseño

Además de las consideraciones de diseño de seguridad del software central que se trataron
anteriormente, existen otras consideraciones de diseño que deben tenerse en cuenta al
crear software. Estos incluyen los siguientes:

*Diseño de interfaz
*Interconectividad

Cubriremos cada una de estas consideraciones en la siguiente sección.

Diseño de interfaz

Interfaz de usuario

El modelo de seguridad de Clark y Wilson, más comúnmente conocido como el modelo de

triple seguridad de acceso, establece que el acceso de un sujeto a un objeto siempre debe
estar mediado a través de un programa y no debe permitirse el acceso directo sujeto-objeto.
Una interfaz de usuario (UI) entre un usuario y un recurso puede actuar como programa
mediador para respaldar este modelo de seguridad. El diseño de las interfaces de usuario
debe garantizar la protección de la divulgación. El enmascaramiento de información
sensible, como una contraseña o un número de tarjeta de crédito, mostrando asteriscos en
la pantalla, es un ejemplo de una interfaz de usuario segura que garantiza la
confidencialidad. También se puede decir que una vista de base de datos es un ejemplo de
una interfaz de usuario restringida. Sin dar a un usuario interno acceso directo a los objetos
de datos, ya sea en el sistema de archivos o en la base de datos, y sin requerir que el
usuario acceda a los recursos usando una interfaz de usuario, protege contra ataques de
inferencia y ataques directos a la base de datos. Las abstracciones que utilizan interfaces
de usuario también son una buena defensa contra las amenazas internas. La interfaz de
usuario proporciona una capa donde se pueden realizar auditorías de acciones privilegiadas
y críticas para el negocio, lo que aumenta la posibilidad de descubrir amenazas internas y
actividades fraudulentas que podrían comprometer la seguridad del software.

Interfaces de programación de aplicaciones (API)

Una interfaz de programación de aplicaciones (comúnmente conocida por su abreviatura

como API), es el contrato técnico que se publica para la comunicación de un componente
de software con otro o para que el software interactúe con el sistema operativo subyacente.
Las interfaces suelen estar disponibles en una biblioteca y puede incluir especificaciones
para rutinas, estructuras de datos, clases de objetos y variables. Las API permiten la
interoperabilidad del software no solo dentro del mismo ecosistema informático, sino
también en ecosistemas dispares y heterogéneos.

Si estas API no son seguras, pueden permitir a los piratas informáticos explotar el software.
Esto es de particular importancia, especialmente en soluciones de software como servicio
(SaaS) como en el caso de la computación en la nube y en las aplicaciones de redes
sociales. La publicación de las principales amenazas para la computación en la nube de
Cloud Security Alliance (CSA) enumera las interfaces y API inseguras, en segundo lugar,
solo superadas por el abuso y el uso nefasto de los recursos de la computación en la nube.
Los proveedores de servicios en la nube exponen interfaces o API para que sus inquilinos
(clientes / clientes) y socios utilicen y gestionen el aprovisionamiento, la orquestación y la
supervisión. La seguridad de los servicios en la nube está directamente relacionada con la
seguridad de las API que exponen. Los sitios de redes sociales como Facebook y Twitter
también exponen el acceso a su funcionalidad utilizando API y cuando diseña aplicaciones
que aprovechan o interactúan con estas API, es imperativo asegurarse de que estas API no
puedan ser explotadas, poniendo su aplicación en riesgo.

Interfaces de gestión de seguridad (SMI)

Las interfaces de administración de seguridad (SMI) son aquellas interfaces que se utilizan
para configurar y administrar la seguridad del software en sí. Estas son interfaces
administrativas con altos niveles de privilegios. Los SMI se utilizan para tareas de
aprovisionamiento de usuarios, como agregar usuarios, eliminar usuarios, habilitar o
deshabilitar cuentas de usuario, así como otorgar derechos y privilegios a roles, cambiar la
configuración de seguridad, configurar los ajustes del registro de auditoría y pistas de
auditoría, registro de excepciones, etc. Un ejemplo de SMI son las pantallas de
configuración que se utilizan para administrar la configuración de seguridad de un enrutador
doméstico. La Figura 3.15 muestra el SMI para un enrutador doméstico D-Link.
Desde el punto de vista de la seguridad, es fundamental que estas SMI también se modelen
como amenazas y que se diseñe la protección adecuada, ya que estas interfaces
generalmente no se capturan explícitamente en los requisitos. A menudo se observa que
son el eslabón más débil, ya que se pasan por alto cuando se modelan las amenazas al
software.

Las consecuencias de violar una interfaz administrativa suelen ser graves porque el
atacante termina ejecutándose con privilegios elevados. Un compromiso de un SMI puede
llevar a un compromiso total, divulgación y amenazas de alteración y destrucción, además
de permitir que los atacantes los utilicen como puertas traseras para instalar malware
(troyanos, rootkits, spyware, adware, etc.). No solo deben implementarse fuertes controles
de protección para proteger SMI, sino que estos deben ser capturados explícitamente en los
requisitos, ser parte del ejercicio de modelado de amenazas y diseñarse de manera precisa
y segura. Algunos de los controles de protección recomendados para estas interfaces
sensibles y con privilegios elevados son los siguientes:

Evite la conectividad y la administración remotas, lo que requiere que los

administradores inicien sesión localmente.
Implementar la protección de datos en tránsito, utilizando medidas de protección de
seguridad de canal en la capa de transporte (por ejemplo, SSL) o de red (por ejemplo,
IPSec).
Utilice cuentas de privilegios mínimos, RBAC y servicios de administración de
derechos para controlar el acceso y la funcionalidad de las interfaces.
Registre y audite el acceso al SMI.

Interfaz fuera de banda

A veces, cuando la computadora está apagada o en modo de suspensión o hibernación, es

posible que un administrador aún necesite acceder y administrar esa computadora. Aquí es
donde entran en juego las interfaces de administración fuera de banda. Las interfaces de
administración fuera de banda permiten que un administrador se conecte a una
computadora que está en un estado inactivo o apagado. Por lo tanto, a veces se denomina
interfaces de gestión de luces apagadas (LOM). Se establece un canal dedicado con la
computadora que se administra invocando la interfaz de conectividad de acceso remoto
fuera de banda. Estas interfaces están disponibles directamente desde la placa base (en
computadoras de nueva generación) o mediante el uso de una tarjeta de administración
remota que se conecta a la placa base. Por el contrario, las interfaces en banda funcionan
haciendo que un agente de administración se ejecute en la computadora que se administra
y el controlador de administración administra la computadora comunicándose con el agente.
Dado que estas interfaces están diseñadas para ser invocadas de forma remota, es
imperativo asegurarse de que solo el personal y los procesos autorizados puedan acceder a
la tarjeta o interfaz de administración remota e invocar los servicios necesarios.

Interfaces de registro

El registro es un componente crucial de la auditoría y, al diseñar software para auditoría, es

importante considerar tener interfaces que puedan activar o desactivar el registro en
diferentes entornos (por ejemplo, desarrollo, prueba, producción, etc.). Estas interfaces
también deben estar diseñadas para configurar el tipo de eventos que se pueden registrar
(por ejemplo, eventos de aplicaciones, eventos del sistema operativo, errores y
excepciones, etc.) y la verbosidad de los registros (informativos, estado, advertencia, pila
completa, etc.) .). Además, el diseño de interfaces visuales para trazar y representar
gráficamente los datos de registro es útil para discernir patrones y correlacionar amenazas.
También es importante diseñar el control de acceso a estas interfaces de registro para que
ningún usuario no autorizado pueda cambiar los valores de configuración del registro.
Además, como regla general, se recomienda que los registros nunca se sobrescriban y solo
se agreguen, pero esto puede representar un desafío de capacidad y, por lo tanto, la
verbosidad del registro debe planificarse cuidadosamente durante la fase de diseño.
También se recomienda evitar el diseño de interfaces que permitan la eliminación de
registros porque un atacante puede aprovechar dicha funcionalidad y usarla para eliminar
sus acciones de los archivos de registro, en un intento de ocultar su huella, después de
explotar el software.

Interconectividad

En el mundo en el que vivimos hoy en día, rara vez se desarrolla e implementa software en
un silo. La mayoría de las aplicaciones y el software comerciales están altamente
interconectados, lo que crea posibles puertas traseras para los atacantes si se diseñan sin
tener en cuenta la seguridad. El diseño del software debe tener en cuenta la consideración
del diseño para garantizar que el software sea confiable, resistente y recuperable. La
compatibilidad ascendente y descendente del software debe diseñarse explícitamente. Esto
es importante cuando se trata de delegación de confianza, inicio de sesión único (SSO),
autenticación basada en tokens y uso compartido de claves criptográficas entre
aplicaciones. Si una aplicación ascendente tiene datos cifrados utilizando una clave en
particular, debe haber un medio seguro para transferir la clave a las aplicaciones
descendentes que necesitarán descifrar los datos. Cuando se agregan datos o información
de varias fuentes, como es el caso de los Mashups, el diseño del software debe tener en
cuenta la confianza que existe o que debe establecerse entre las entidades interconectadas.
La programación modular con las características de alta cohesión y acoplamiento flexible
ayuda con el diseño de interconectividad, ya que reduce las complejas dependencias entre
los componentes conectados, manteniendo cada entidad lo más discreta y unitaria posible.

La interconectividad no solo se observa en las aplicaciones de software, sino también en los

dispositivos. El aumento en la informática móvil con soporte para traer su propio dispositivo
(BYOD) hacia el que se están moviendo las empresas, combinado con una mayor
conectividad, tanto cableada como inalámbrica, es evidente un aumento en la cantidad de
redes ad hoc. Tradicionalmente, lo que solían ser terminales tontos con funcionalidad
limitada están siendo reemplazados por dispositivos inteligentes que cuentan con mayor
capacidad de procesamiento y funcionalidad. Por lo tanto, es imperativo incluir estos
dispositivos altamente interconectados como parte del perfil de amenaza, especialmente si
está involucrado en el desarrollo de aplicaciones móviles. Aunque la principal amenaza para
la informática basada en dispositivos es que el dispositivo se pierda o sea robado (robo
físico), debe entenderse que la conectividad remota a los dispositivos también puede
conducir a la divulgación de datos. Esto es crucial para mitigar, especialmente cuando se
almacenan datos privados o confidenciales en el cliente. Sin duda, la divulgación de datos
del lado del cliente es el mayor riesgo que enfrentan los consumidores de dispositivos
móviles cuando sus dispositivos se pierden o son robados. En la mayoría de las
aplicaciones móviles, la protección de los datos del cliente se deja en manos de la propia
aplicación y, por lo tanto, las aplicaciones deben diseñarse para evitar almacenar
información confidencial en el entorno aislado de la aplicación. Es posible que los editores y
las API de terceros que brindan servicios criptográficos (cifrado y descifrado) deban
considerarse para garantizar la confidencialidad. Cuando los datos se almacenan en una
ubicación de la red, el dispositivo de almacenamiento conectado a la red (NAS) también
debe protegerse. Solo se deben diseñar conexiones autenticadas y autorizadas al NAS y si
el acceso está diseñado para estar restringido por un rango de IP, se deben tener
consideraciones especiales para las amenazas de suplantación de IP. Además, toda la
conectividad entre el nodo NAS y el dispositivo en sí debe ser segura para mitigar las
amenazas de espionaje y divulgación de Man-inthe-Middle (MITM).

Cuando diseña software pensando en la seguridad, es necesario establecer y completar

ciertos procesos de seguridad. Estos procesos se llevarán a cabo durante las etapas
iniciales del proyecto de desarrollo de software. Estos incluyen la evaluación de la superficie
de ataque, el modelado de amenazas, la identificación y priorización de controles y la
documentación. En esta sección, analizaremos cada uno de estos procesos y
aprenderemos cómo se pueden usar para desarrollar software seguro confiable,
recuperable y resistente a ataques.
Procesos de diseño

Cuando diseña software pensando en la seguridad, es necesario establecer y completar

ciertos procesos de seguridad. Estos procesos se llevarán a cabo durante las etapas
iniciales del proyecto de desarrollo de software. Estos incluyen la evaluación de la superficie
de ataque, el modelado de amenazas, la identificación y priorización de controles y la
documentación. En esta sección, analizaremos cada uno de estos procesos y
aprenderemos cómo se pueden usar para desarrollar software seguro confiable,
recuperable y resistente a ataques.

Evaluación de la superficie de ataque

La superficie de ataque de un software o aplicación es la medida de su exposición de ser

explotado por un agente de amenaza, es decir, debilidades en sus puntos de entrada y
salida que un atacante malintencionado puede aprovechar para su beneficio. Dado que
cada característica accesible del software es un vector de ataque potencial que un intruso
puede aprovechar, la evaluación de la superficie de ataque tiene como objetivo determinar
los puntos de entrada y salida en el software que pueden conducir a la explotación de
debilidades y la manifestación de amenazas. A menudo, la evaluación de la superficie de
ataque se realiza como parte del ejercicio de modelado de amenazas durante la fase de
diseño del SDLC. Cubriremos el modelado de amenazas en una sección posterior. La
determinación de la "capacidad de ataque" del software o la exposición al ataque puede
comenzar en la fase de requisitos del SDLC, cuando los requisitos de seguridad se
determinan mediante la generación de casos de uso indebido y matrices sujeto-objeto.
Durante la fase de diseño, cada caso de mal uso o matriz sujeto-objeto se puede utilizar
como entrada para determinar los puntos de entrada y salida del software que pueden ser
atacados.
La evaluación de la superficie de ataque intenta enumerar la lista de características que un
atacante intentará explotar. A estos puntos de ataque potenciales se les asigna un peso o
sesgo en función de su supuesta gravedad para que los controles puedan identificarse y
priorizarse. En el sistema operativo Windows, abra los puertos, abra los puntos finales y
sockets de la llamada de procedimiento remoto (RPC), abra las canalizaciones con nombre,
los servicios predeterminados y SYSTEM de Windows, los archivos del controlador web
activo (páginas del servidor activo, los archivos de rotación de traducción jerárquica (HTR),
etc. ), Los filtros de la Interfaz de programación de aplicaciones del servidor de Internet
(ISAPI), las páginas web dinámicas, las Listas de control de acceso (ACLS) débiles para
archivos y recursos compartidos, etc., son puntos de entrada y salida atacables. En los
sistemas operativos Linux y * nix, las aplicaciones raíz de setuid y los enlaces simbólicos
son ejemplos de características que pueden ser atacadas.

El término cociente de superficie de ataque relativo (RASQ) fue introducido por el

reconocido autor y director del programa de seguridad cibernética de Microsoft, Michael
Howard, para describir la capacidad de ataque relativa o las oportunidades probables de
ataque contra el software en comparación con una línea de base. La línea de base es un
conjunto fijo de dimensiones. La noción de la métrica RASQ es que, en lugar de centrarnos
en la cantidad de errores a nivel de código o vulnerabilidades a nivel del sistema, debemos
centrarnos en las oportunidades probables de ataque contra el software y apuntar a
disminuir la superficie de ataque mejorando la seguridad del software. productos. Esto es
particularmente importante para el cálculo de productos de envoltura retráctil, como el
sistema operativo Windows, para mostrar mejoras de seguridad en versiones más recientes;
pero lo mismo se puede determinar para las versiones de las aplicaciones comerciales. Con
cada punto de ataque asignado un valor, conocido como sesgo de ataque, según su
gravedad, el RASQ de un producto se puede calcular sumando la superficie de ataque
efectiva para todos los vectores raíz. Un vector raíz es una característica particular del
sistema operativo o software que puede afectar positiva o negativamente la seguridad del
producto. El valor de la superficie de ataque efectiva se define como el producto del número
de superficies de ataque dentro de un vector de ataque raíz y el sesgo de ataque. Por
ejemplo, un servicio que se ejecuta de forma predeterminada bajo la cuenta SYSTEM y
abre un socket al mundo es un candidato de ataque principal, incluso si el software se
implementa con código seguro, en comparación con un escenario en el que las ACLS del
registro son débiles. A cada uno se le asigna un sesgo, como 0,1 para una amenaza baja y
1,0 para una amenaza grave.
Los investigadores Howard, Pincus y Wing, en su artículo titulado "Midiendo las superficies
de ataque relativas", dividen la superficie de ataque en tres dimensiones formales; objetivos
y habilitadores, canales y protocolos, y derechos de acceso.

A continuación se ofrece una breve introducción de estas dimensiones:

● ■■ Los objetivos y los habilitadores son recursos que un atacante puede aprovechar
para crear un ataque contra el software. Un atacante primero determina si un
recurso es un objetivo o un facilitador y, en algunos casos, un objetivo en un ataque
en particular puede ser un facilitador de otro tipo de ataque y viceversa. Los dos
tipos de objetivos y facilitadores son procesos y datos. Los navegadores, los
remitentes de correo y los servidores son ejemplos de habilitadores y destinos de
procesos, mientras que los archivos, directorios y registros son ejemplos de
habilitadores y destinos de datos. Un aspecto de la determinación de la superficie de
ataque es determinar el número de posibles procesos y objetivos de datos y
habilitadores y las oportunidades probables para atacar a cada uno de ellos.
● ■■ Los canales y protocolos son mecanismos que permiten la comunicación entre
dos partes. El medio por el cual un remitente (o un atacante) puede comunicarse con
un receptor (un objetivo) se denomina canal y la regla mediante la cual se
intercambia información se denomina protocolo. Los puntos finales del canal son
procesos. Hay dos tipos de canales, a saber, canales de paso de mensajes y
canales de memoria compartida. Los ejemplos de canales de paso de mensajes
incluyen sockets, conexiones RPC y canalizaciones con nombre que utilizan
protocolos como ftp, http, RPC y streaming para intercambiar información. Los
ejemplos de canales de memoria compartida incluyen archivos, directorios y
registros, que utilizan protocolos de archivos abiertos antes de leer, verificaciones de
control de acceso de concurrencia para objetos compartidos y reglas de integridad
de bloqueo de recursos. Además de determinar el número y la "capacidad de
ataque" de los objetivos y los habilitadores, la determinación de la superficie de
ataque incluye la determinación de los tipos de canal, las instancias de cada tipo de
canal y los protocolos, procesos y derechos de acceso relacionados.
 ● ■■ Los derechos de acceso son los privilegios asociados con cada recurso,
independientemente de si es un objetivo o un habilitador. Estos incluyen derechos de
lectura, escritura y ejecución que se pueden asignar no solo a los datos y los
objetivos del proceso, como archivos, directorios y servidores, sino también a los
canales (que son esencialmente recursos de datos) y puntos finales (recursos del
proceso). La Tabla 3.3 es una tabulación de varios vectores de ataque de raíz a
dimensiones formales.

Dimensiones Vector de Ataque

Objetivos (Procesos) ● Servicios

● Controladores web activos
● Filtros ISAPI activos
● Páginas web dinámicas

Objetivo (Proceso), limitado por derechos ● Servicios que se ejecutan de forma

de acceso predeterminada
● Servicios que se ejecutan como
SYSTEM

Objetivos (datos) ● Directorios virtuales ejecutables

● Cuentas habilitadas

Objetivos (datos), restringidos por derechos ● Cuentas habilitadas en el grupo de

de acceso administración
● Cuenta de invitado habilitada
● ACLS débiles en el sistema de
archivos
● ACL débiles en el registro
● ACL débiles en acciones

Habilitadores (proceso) ● VBScript habilitado

● JScript habilitado
● ActiveX habilitado

Canales ● Sesiones nulas a canalizaciones y

recursos compartidos
Tabla 3.3 - Mapeo de vectores de ataque RASQ en dimensiones

Una explicación completa de la informática RASQ está más allá del alcance de este libro,
pero un CSSLP debe conocer este concepto y sus beneficios. Aunque la puntuación RASQ
puede no ser verdaderamente indicativa de la verdadera exposición de un producto de
software a los ataques o de su estado de seguridad, puede usarse como una medida para
determinar la mejora de la calidad y seguridad del código entre versiones de software. La
idea principal es mejorar la seguridad del software reduciendo la puntuación RASQ en
versiones posteriores. Esto también se puede ampliar dentro del SDLC, en el que la
puntuación RASQ se puede calcular antes y después de la prueba del software y / o antes y
después del despliegue del software para reflejar la mejora en la calidad del código y,
posteriormente, la seguridad. Se recomienda la lectura del artículo de los investigadores
Howard, Pincus y Wing para obtener información adicional sobre RASQ.

Modelado de amenazas

Las amenazas al software son múltiples. Van desde amenazas de divulgación contra la
confidencialidad hasta amenazas de alteración contra la integridad y amenazas de
destrucción contra la disponibilidad, omisión de autenticación, escalada de privilegios,
suplantación, eliminación de archivos de registro, ataques de intermediario, secuestro y
reproducción de sesiones, inyección, scripting, desbordamiento y ataques criptográficos.
Cubriremos los tipos de ataques predominantes con más detalle en el capítulo
Implementación segura de software.

Fuentes / agentes de amenazas

Al igual que las diversas amenazas al software, también existen varias fuentes / agentes de
amenazas. Estos pueden ser humanos o no humanos.

Los agentes de amenazas humanas van desde el usuario ignorante que causa un error
simple de usuario hasta los ciberdelincuentes organizados que pueden orquestar amenazas
infames y desastrosas a la seguridad nacional y corporativa. La Tabla 3.4 tabula los
diversos agentes de amenaza humana para el software en función de su creciente grado de
conocimiento y la extensión del daño que pueden causar.

Los agentes de amenazas no humanos incluyen software malintencionado (Malware) como

virus y gusanos, que son de naturaleza proliferativa; spyware, adware, troyanos y rootkits
que son principalmente de naturaleza sigilosa y ransomware como se muestra en la Figura
3.16.

Los malwares proliferativos, como sugieren sus nombres, tienen como objetivo propagar
sus operaciones maliciosas a otras redes, hosts y aplicaciones que están conectadas a la
víctima. Los virus y gusanos son ejemplos de malware proliferativo. Los virus y gusanos son
las formas más comunes de malware proliferativo.

Tipo de agente de amenaza Descripción

Usuario ignorante El usuario ignorante es el que a menudo es la causa de

un error de usuario simple y no intencional. El error
simple del usuario también se conoce a veces como
error simple o simplemente error del usuario. Combatir
esta fuente de amenaza es simple pero requiere una
inversión de tiempo y esfuerzo. La educación del usuario
 es la mejor defensa contra este tipo de agente de
amenaza. La mera documentación y las guías de ayuda
son medidas insuficientes si no se utilizan
adecuadamente.

Descubridor accidental Un usuario común que se encuentra con un error

funcional en el software y que puede obtener acceso
privilegiado a la información o la funcionalidad. Este
usuario nunca buscó eludir los mecanismos de
protección de seguridad en primer lugar.

Curious Attackerk Un usuario común que nota alguna anomalía en el

funcionamiento del software y decide seguir adelante. A
menudo, un descubridor accidental se convierte en un
atacante curioso.

Script Kiddies Este tipo de agentes de amenaza deben tratarse con

seriedad, simplemente por su prevalencia en la industria.
Son aquellos usuarios comunes que ejecutan scripts de
piratas informáticos contra activos corporativos sin
comprender el impacto y las consecuencias de sus
acciones. La mayoría de los piratas informáticos de élite
de hoy en día fueron un día scripts kiddies. Una prueba
de fuego para identificar el trabajo de un script kiddy es
que a menudo no esconden ni saben cómo ocultar su
huella en el software o los sistemas que han atacado.

Insider Uno de los atacantes más poderosos en la actualidad es

el insider o el enemigo dentro del firewall. Estos son
empleados potencialmente descontentos o miembros del
personal dentro de la empresa que tienen acceso a
información privilegiada. El administrador de la base de
datos con acceso sin restricciones y sin auditar a
información confidencial directamente es una fuente de
amenaza potencial que no debe ignorarse. La
identificación, autenticación, autorización y auditoría
adecuadas de las acciones del usuario son controles
importantes y necesarios que deben implementarse para
disuadir los ataques internos. La auditoría también se
puede utilizar como un control de detectives en los casos
en que se especula con fraudes y ataques internos.

Ciberdelincuentes Son malhechores altamente calificados a los que se les

organizados paga profesionalmente por usar sus habilidades para
frustrar la protección de seguridad del software y los
sistemas, en busca de una alta ganancia financiera. No
solo tienen un conocimiento profundo del desarrollo de
software, sino también de la ingeniería inversa y los
controles de seguridad de la red y el host. Pueden
utilizarse para ataques contra activos corporativos y
también son una amenaza para la seguridad nacional
como ciber terroristas. Los desarrolladores de software
malicioso y los piratas informáticos de amenazas
persistentes avanzadas (APT) generalmente también se
 incluyen en esta categoría.

Tercero / Proveedor Cuando el software se desarrolla fuera del ámbito del

control de la empresa, entonces
lógica maliciosa y código malicioso (código malicioso)
como bombas lógicas y caballos de Troya
puede estar incrustado de forma no intencionada o
intencionada en el código del software, ya que el
software
se mueve a través de la cadena de suministro. Al
subcontratar el desarrollo de software, el extranjero
Se debe determinar el control e influencia de propiedad
(FOCI) del tercero o proveedor
y el adquirente debe realizar la inspección (revisión) del
código antes de la aceptación.
Tabla 3.4 - Fuente / agente de amenaza humana

Los virus funcionan infectando un programa de software o ejecutable y requieren el

programa o el host infectado para sus operaciones maliciosas. Ejemplos de algunos virus
conocidos incluyen el virus Melissa y el virus I Love You.

Un gusano, por otro lado, funciona de manera similar a un virus, pero no necesariamente
requiere que la víctima infectada sobreviva, ya que pueden propagarse e infectar otros
sistemas, redes, hosts o aplicaciones. Los gusanos generalmente no requieren la
interacción humana para propagarse, mientras que los virus generalmente lo hacen.
Algunos ejemplos de gusanos conocidos incluyen el gusano Nimbda, el gusano Sasser, el
gusano SQL Slammer y el gusano Samy.

Figura 3.16 - Tipos de malware

Stealthware incluye la categoría de malware que se programa para intentar obtener el

control del sistema explotando las debilidades del sistema operativo o del software que se
ejecuta en ellos. Permanecen ocultos (en modo sigiloso, y por lo tanto, su clasificación) y
operan subrepticiamente, a menudo sin el conocimiento o consentimiento del sistema o
usuario victimizado. Estos incluyen spyware, adware, troyanos y rootkits.

El Spyware se utiliza para recopilar de forma clandestina información confidencial y privada

y el trabajo de software publicitario redirigiendo a los usuarios a pantallas de marketing
(anuncios) sin el consentimiento del usuario.

En el contexto de la seguridad de la información, los caballos de Troya son software

malicioso que parecen inocuos en su funcionalidad, pero internamente llevan una carga útil
maliciosa que tiene como objetivo eludir los controles de seguridad y explotar el sistema o
software que pretenden comprometer. Los caballos de Troya hacen posible que los piratas
informáticos se conecten de forma remota con la víctima, utilizando canales encubiertos
(puertas traseras) que establecen y dichos caballos de Troya se conocen como troyanos de
puerta trasera o troyanos de acceso remoto (RAT). Una forma de troyano de puerta trasera
es un bot. Un bot generalmente escucha los comandos de un atacante y cuando es parte de
una colección de sistemas comprometidos, se le llama botnet (red de bots). Los troyanos
también se pueden utilizar para instalar registradores de pulsaciones de teclas, otros
programas espía y publicitarios, o se pueden utilizar para robar información, modificar la
configuración y hacer un mal uso de los recursos informáticos.

Los autores Hoglund y Butler en su libro “Rootkits”, definen un rootkit como “un conjunto
(kit) de programas y código que permite a un atacante mantener un acceso indetectable
permanente o consistente a“ root ”, el usuario más poderoso de una computadora. " Sin
embargo, debe reconocerse que intrínsecamente, los rootkits no son una amenaza para la
seguridad y existen varias razones válidas y legítimas para desarrollar este tipo de
tecnología. Estos incluyen el uso de rootkits para fines de resolución de problemas remotos,
situaciones de espionaje y aplicación de la ley autorizadas y consentidas y también
monitorear el comportamiento del usuario. Los rootkits se ejecutan en modo usuario o en
modo kernel. Los usuarios y programas maliciosos generalmente usan rootkits para
modificar el sistema operativo (SO) y se hacen pasar por programas legítimos, como
módulos cargables del kernel (* nix OS) o controladores de dispositivos (sistema operativo
Windows). Dado que se hacen pasar por programas legítimos, son indetectables. Estos
rootkits se pueden usar para instalar registradores de pulsaciones de teclas, modificar
archivos de registro, instalar canales encubiertos y evadir la detección y eliminación.

Los rootkits se utilizan principalmente para control remoto o para escuchas de software.
Los piratas informáticos y el software malintencionado (malware), como el software espía,
intentan explotar las vulnerabilidades del software para instalar rootkits en sistemas sin
parchear ni reforzados. Por lo tanto, es imperativo que la seguridad del software que
creamos o compramos no permita comprometer la computación confiable al convertirse en
víctimas del uso malicioso de rootkits.

Las amenazas combinadas muestran características de dos o más tipos de malware. Un

rootkit podría considerarse una amenaza combinada.

El ransomware incluye la categoría de malware que afecta el concepto de disponibilidad de

seguridad, a diferencia de otros tipos de malware que generalmente apuntan a
comprometer la seguridad del sistema o software. Actúan imponiendo restricciones a la
víctima que infectan y exigen el pago de un rescate para eliminar la restricción.
Históricamente, una técnica popular en el ransomware era que el ransomware encriptaba el
contenido del disco duro del usuario y, hasta que se pagaba un rescate al creador del
malware, el disco duro no se desencriptaba, lo que obligaba a la víctima a sufrir pérdidas
económicas. El ransomware es una de las amenazas más frecuentes en el malware móvil,
ya que tienden a funcionar bloqueando la pantalla en los dispositivos móviles y no eliminan
la restricción hasta que se cumplen las demandas del creador de malware móvil.

Una clase especial de amenaza que aprovecha los agentes de amenazas humanos y no
humanos que prevalecen en la actualidad son las amenazas persistentes avanzadas. Las
amenazas persistentes avanzadas (Advanced Persistent Threats APT) se refieren a
ataques de piratería sofisticados que explotan el software y el sistema durante un largo
período de tiempo y, en su mayor parte, pasan desapercibidos, mientras que el agente de
amenaza (malware) se encuentra en el entorno informático de la víctima. Se dice que son
"avanzados" porque los agentes de amenaza detrás de estos ataques no son los habituales
script kiddies, sino aquellos que tienen una gama completa de técnicas de recopilación de
inteligencia y evasión de intrusiones. Se dice que son "avanzados" porque los agentes de
amenaza detrás de estos ataques no son los habituales script kiddies, sino aquellos que
tienen una gama completa de técnicas de recopilación de inteligencia y evasión de intrusos.
Se dice que son "persistentes" porque los agentes de amenazas tienen como objetivo
mantener el acceso continuo a largo plazo (persistente) al objetivo, en contraste con las
amenazas que operan como exploits rápidos de un solo golpe. Generalmente, las
amenazas de acceso persistente "lento y lento" no se detectan. Recientemente, las APT
han ganado mucha atención de los medios porque estos ataques se han dirigido a
gobiernos, empresas y activistas políticos. Cabe señalar que, si bien las APT aprovechan el
malware para realizar sus ataques, un componente importante de las APT involucra a
operadores humanos altamente capacitados, motivados, bien financiados y organizados.

¿Qué es el modelado de amenazas?

El modelado de amenazas es una técnica de seguridad sistemática, iterativa y
estructurada que no debe pasarse por alto durante la fase de diseño de un proyecto de
desarrollo de software. El modelado de amenazas es extremadamente crucial para
desarrollar software resistente a ataques. Debe realizarse para identificar los objetivos de
seguridad del software, las amenazas al software, las vulnerabilidades en el software que se
está desarrollando. Proporciona al equipo de desarrollo de software el punto de vista de un
atacante o de un usuario hostil, ya que el ejercicio de modelado de amenazas tiene como
objetivo identificar los puntos de entrada y salida que un atacante puede explotar. También
ayuda al equipo a tomar decisiones de diseño e ingeniería al proporcionar información sobre
las áreas en las que se debe priorizar y enfocar la atención, desde un punto de vista de
seguridad. La razón fundamental detrás del modelado de amenazas es la premisa de que, a
menos que uno sea consciente de los medios por los cuales los activos de software pueden
ser atacados y comprometidos, los niveles apropiados de protección (controles de
mitigación) no se pueden determinar y aplicar con precisión. Los activos de software
incluyen los procesos de software, ellos mismos y los datos que recopilan y procesan. Con
la prevalencia actual de ataques contra software o en la capa de aplicación, ningún software
debe considerarse listo para su implementación o codificación hasta que se complete su
modelo de amenazas relevante y se identifiquen las amenazas.

Beneficios
El beneficio principal del modelado de amenazas durante la fase de diseño del proyecto es
que las fallas de diseño se pueden abordar antes de escribir una sola línea de código, lo
que reduce la necesidad de rediseñar y corregir los problemas de seguridad en el código en
un momento posterior. Una vez que se genera un modelo de amenaza, debe visitarse y
actualizarse iterativamente a medida que avanza el proyecto de desarrollo de software. En
la fase de diseño, el desarrollo de modelos de amenazas comienza cuando los equipos de
arquitectura de software identifican las amenazas al software. El equipo de desarrollo puede
utilizar el modelo de amenazas para implementar controles y escribir código seguro. Los
evaluadores pueden usar los modelos de amenazas no solo para generar casos de prueba
de seguridad, sino también para validar los controles que deben estar presentes para
mitigar las amenazas identificadas en los modelos de amenazas. Finalmente, el personal de
operaciones puede utilizar modelos de amenazas para configurar el software de forma
segura, de modo que todos los puntos de entrada y salida tengan los controles de
protección necesarios. De hecho, un modelo de amenazas holístico es aquel que ha
recibido aportaciones de representantes de los equipos de diseño, desarrollo, pruebas y
despliegue y operaciones.

Desafíos
Aunque los beneficios del modelado de amenazas son amplios, el modelado de amenazas
conlleva algunos desafíos, los más comunes de los cuales se detallan a continuación.
Modelado de amenazas:
● Puede ser un proceso que requiere mucho tiempo cuando se realiza correctamente.
● Requiere un SDLC bastante maduro.
● Requiere la capacitación de los empleados para modelar correctamente las
amenazas y abordar las vulnerabilidades.
● A menudo se considera que no es una actividad muy preferencial. Los
desarrolladores prefieren la codificación y el personal de control de calidad prefieren
las pruebas al modelado de amenazas.
● A menudo no está directamente relacionado con las operaciones comerciales y es
difícil mostrar un retorno de la inversión demostrable para los modelos de amenazas.

Prerrequisitos
Antes de profundizar en el proceso de modelado de amenazas, respondamos primero a la
pregunta sobre cuáles son algunos de los requisitos previos para el modelado de
amenazas. Para que los modelos de amenazas sean efectivos dentro de una empresa, es
fundamental cumplir las siguientes condiciones:
● La empresa debe tener políticas y estándares de seguridad de la información
claramente definidos. Sin estos instrumentos de gobierno, la adopción de modelos
de amenazas como parte integral del SDLC dentro de la empresa será un desafío.
 Esto se debe a que, cuando los equipos de negocios y de desarrollo retroceden y
eligen no generar modelos de amenazas debido a los desafíos impuestos por el
triángulo de hierro, la organización de seguridad de la información no tendrá una
base sobre la cual hacer cumplir la necesidad del modelado de amenazas.
● La empresa debe conocer los requisitos normativos y de cumplimiento. Así como las
políticas y estándares de la empresa funcionan como instrumentos de gobernanza
interna, armando a la organización de seguridad de la información para hacer
cumplir el modelado de amenazas como parte del SDLC, los requisitos de
cumplimiento y regulatorios funcionan como mandatos de gobernanza externa que
deben tenerse en cuenta en el diseño de software que aborda la seguridad.
● La empresa debe tener un proceso SDLC maduro y claramente definido. Dado que
la actividad de modelado de amenazas se inicia durante la fase de diseño de un
proyecto de desarrollo de software, es importante que la empresa emplee un
enfoque estructurado para el desarrollo de software. El desarrollo ad hoc producirá
modelos de amenazas ad hoc, incompletos e inconsistentes. Además, dado que el
modelado de amenazas es un proceso iterativo y el modelo de amenazas debe
revisarse durante la fase de desarrollo y prueba del proyecto, esas fases deben
formar parte del ciclo de vida del desarrollo de software.
● La empresa tiene un plan para actuar sobre el modelo de amenazas. Las
vulnerabilidades subyacentes que podrían hacer que las amenazas (identificadas
mediante el ejercicio de modelado de amenazas) se materialicen también deben
identificarse y abordarse adecuadamente. El simple hecho de completar un ejercicio
de modelado de amenazas no sirve para proteger el software que se está
diseñando. Generar un modelo de amenaza y no actuar en consecuencia es como
comprar una máquina de ejercicios y no usarla, sino esperar ponerse en forma y
estar en forma. Es necesario actuar sobre el modelo de amenaza. En este sentido,
es imperativo que la empresa capacite a sus empleados para abordar de manera
adecuada las amenazas y vulnerabilidades identificadas. Los programas de
concientización, capacitación y educación para enseñar a los empleados cómo
modelar el software de amenazas y cómo mitigar las amenazas identificadas son
necesarios y críticos para la efectividad del ejercicio de modelado de amenazas.

¿Qué modelo podemos amenazar?

Dado que los modelos de amenazas requieren la asignación de tiempo y recursos y tienen
un impacto en el ciclo de vida del proyecto, el modelado de amenazas se debe realizar de
forma selectiva, en función del valor del software como activo para la empresa.

Podemos modelar las versiones existentes, próximas, software nuevo y heredado. Es

particularmente importante el software heredado de modelos de amenazas porque la
probabilidad de que el software se desarrolló originalmente teniendo en cuenta los modelos
de amenazas y la seguridad, y teniendo en cuenta las amenazas actuales, es mínima.
Cuando existe la necesidad de modelar el software heredado, se recomienda hacerlo
cuando se esté diseñando la próxima versión del software heredado. También podemos
diseñar interfaces de amenazas (interfaces de programación de aplicaciones, servicios web,
etc.) y componentes de terceros. Cuando los componentes de terceros se modelan como
amenazas, es importante notificar al propietario / editor del software de la actividad y
obtener su aprobación para evitar problemas legales de propiedad intelectual (IP) o
violaciones de los acuerdos de licencia de usuario final (EULA). El software de terceros de
modelado de amenazas suele ser un tipo de prueba de comportamiento o de caja negra, ya
que realizar análisis e inspecciones estructurales mediante componentes COTS de
ingeniería inversa, sin la debida autorización del editor del software, puede tener graves
repercusiones en la violación de la propiedad intelectual.

Proceso
Como CSSLP, es imperativo que uno no solo comprenda los beneficios, los jugadores clave,
los desafíos y los requisitos previos en el desarrollo de un modelo de amenazas, sino que
también debe estar familiarizado con los pasos involucrados en el modelado de amenazas.

Pero antes de profundizar en el proceso de modelado de amenazas, primero debemos

determinar los objetivos de seguridad que debe cumplir el software. En ocasiones, esto se
denomina "Visión de seguridad" del software en la terminología de modelado de amenazas.
Los objetivos de seguridad son los objetivos de alto nivel de la aplicación, que si no se
cumplen tendrán un impacto en los principios de seguridad del software. Estos incluyen los
requisitos que afectan los conceptos básicos de seguridad, como confidencialidad,
integridad, disponibilidad, autenticación, autorización y responsabilidad. Algunos ejemplos
de objetivos de seguridad incluyen:

● Prevención del robo de datos

● Protección de la propiedad intelectual (PI)
● Proporcionar alta disponibilidad
Figura 3.17 - Proceso de modelado de amenazas

Las entradas que se pueden utilizar para identificar los objetivos de seguridad se enumeran
a continuación.
● ■■ Políticas y estándares internos de la empresa
● ■■ Normas, cumplimiento y requisitos de privacidad
● ■■ Requisitos comerciales y funcionales

El proceso de modelado de amenazas se puede dividir en cuatro fases principales, como se

muestra en la Figura 3.17. Estas fases son:

1. Arquitectura de aplicación modelo

2. Identificar amenazas
3. Identificar, priorizar e implementar controles
4. Documentar y validar

Cada fase se divide en actividades más específicas.

Arquitectura de aplicación modelo

Diagramar la aplicación es el proceso de crear una descripción general de la aplicación
identificando los atributos de la aplicación. Este diagrama de la arquitectura de la aplicación
incluye las siguientes actividades.
Identificar la topología física.
La topología física de la aplicación brinda información sobre dónde y cómo se
implementarán las aplicaciones. ¿Será una aplicación solo interna o se implementará en la
Zona Desmilitarizada o estará alojada en la nube?

Identificar la topología lógica.

Esto incluye determinar los niveles lógicos (presentación, negocio, servicio y datos) de la
aplicación.
● ■■ Determine los componentes, servicios, protocolos y puertos que se deben definir,
desarrollar y configurar para la aplicación.
● ■■ Identificar las identidades que se utilizarán en la aplicación y determinar cómo se
diseñará la autenticación en la aplicación.
Los ejemplos incluyen formularios, certificados, tokens, biometría, inicio de sesión único,
multifactor, etc.

Identificar los actores humanos y no humanos del sistema.

Los ejemplos incluyen clientes, agentes de ventas, administradores de sistemas,
administradores de bases de datos, etc.

Identificar elementos de datos.

Los ejemplos incluyen información del producto, información del cliente, etc.

Genere una matriz de control de acceso a datos.

Esto incluye la determinación de los derechos y privilegios que los actores tendrán sobre los
elementos de datos identificados. Los derechos generalmente incluyen privilegios de Crear,
Leer, Actualizar o Eliminar (CRUD). Para cada actor se debe generar la matriz de control de
acceso a datos como se muestra en la Figura 3.18.
● ■■ Identificar las tecnologías que se utilizarán en la construcción de la aplicación.
● ■■ Identificar dependencias externas.
El resultado de esta actividad es una estructura arquitectónica de la aplicación.

Figura 3.18 - Matriz de control de acceso a datos

Identificar amenazas
Un conocimiento profundo de cómo se diseñará el software puede ayudar a descubrir las
amenazas y vulnerabilidades pertinentes. La identificación de amenazas potenciales y
aplicables incluye las siguientes actividades.

Identificar los límites de la confianza

Los límites ayudan a identificar acciones o comportamientos del software permitidos o no
permitidos. Un límite de confianza es el punto en el que cambia el nivel de confianza o el
privilegio. La identificación de los límites de confianza es fundamental para garantizar que
se diseñen los niveles adecuados de protección dentro de cada límite.

Identificar puntos de entrada

Los puntos de entrada son aquellos elementos que toman la entrada del usuario. Cada
punto de entrada puede ser una fuente de amenaza potencial, por lo que todos los puntos
de entrada deben identificarse y protegerse explícitamente. Los puntos de entrada en una
aplicación web pueden incluir cualquier página que reciba información del usuario. Algunos
ejemplos incluyen la página de búsqueda, la página de inicio de sesión, la página de
registro, la página de pago, la página de mantenimiento de la cuenta, etc.

Identificar puntos de salida

Es tan importante identificar los puntos de salida de la aplicación como lo es identificar los
puntos de entrada. Los puntos de salida son aquellos elementos que muestran información
desde dentro del sistema. Los puntos de salida también incluyen procesos que eliminan
datos del sistema. Los puntos de salida pueden ser la fuente de fuga de información y
deben estar igualmente protegidos. Los puntos de salida en una aplicación web incluyen
cualquier página que muestre datos en el cliente del navegador. Algunos ejemplos son la
página de resultados de búsqueda, la página del producto, la página Ver carrito, etc.

Identificar los flujos de datos

Los diagramas de flujo de datos (DFD) y los diagramas de secuencia ayudan a comprender
cómo la aplicación aceptará, procesará y manejará los datos a medida que se distribuyen a
través de diferentes límites de confianza. Es importante reconocer que un DFD no es un
diagrama de flujo, sino una representación gráfica del flujo de datos, los elementos de
almacenamiento de datos de backend y las relaciones entre las fuentes de datos y los
destinos. Los diagramas de flujo de datos utilizan un conjunto estándar de símbolos.

Identificar la funcionalidad privilegiada

Es importante identificar cualquier funcionalidad que permita la elevación de privilegios o se
identifique la ejecución de operaciones privilegiadas. Se identifican todas las funciones de
administrador y las transacciones comerciales críticas.

Presentar a los actores erróneos

La identificación de amenazas comienza con la introducción de actores indebidos; actores
erróneos tanto humanos como no humanos. Algunos ejemplos de malos actores humanos
son un hacker externo, un grupo de hacktivistas, un administrador deshonesto, un
administrador de ventas fraudulento, etc. Los ejemplos de malos actores no humanos
incluyen un proceso interno en ejecución que está realizando cambios no autorizados,
malware, etc.

Determine las amenazas potenciales y aplicables

Durante esta actividad, la intención es identificar las amenazas relevantes que pueden
comprometer los activos. Es importante que los miembros de los equipos de arquitectura,
desarrollo, pruebas y operaciones sean parte de esta actividad, junto con los miembros del
equipo de seguridad.
Las dos formas principales en las que se pueden identificar las amenazas y las
vulnerabilidades son:
■■ Piense como un atacante (lluvia de ideas y uso de árboles de ataque).
■■ Utilice una lista de amenazas categorizadas.

Piense como un atacante (lluvia de ideas y uso de árboles de ataque)

Pensar como un atacante es someter la aplicación a la perspectiva de un usuario hostil. Uno
puede comenzar con una lluvia de ideas sobre posibles vectores de ataque y escenarios de
amenazas usando una pizarra. Si bien la lluvia de ideas es una metodología rápida y
sencilla, no es muy científica y tiene el potencial de identificar amenazas no relevantes y no
identificar amenazas pertinentes. Entonces, otro enfoque es usar un árbol de ataque.
Un árbol de ataque es una estructura jerárquica similar a un árbol, que tiene el objetivo de
un atacante (por ejemplo, obtener privilegios de nivel administrativo, determinar la
composición y configuración de la aplicación, eludir los mecanismos de autenticación, etc.)
o un tipo de ataque (por ejemplo, desbordamiento de búfer, cruce scripts del sitio, etc.) en
su nodo raíz. La figura 3.19 es una ilustración de un árbol de ataque con el objetivo del
atacante en su nodo raíz.

Figura 3.19 - Árbol de ataque: objetivo del atacante en el nodo raíz

La figura 3.20 muestra un árbol de ataque con un vector de ataque en su nodo raíz. Cuando
el nodo raíz es un vector de ataque, el nodo hijo de los nodos raíz es la condición no
mitigada o de vulnerabilidad. El siguiente nodo de nivel (nodo hijo de una condición no
mitigada) suele ser la condición mitigada o un control de salvaguardia que se implementará.
Figura 3.20 - Árbol de ataque: vector de ataque en el nodo raíz

También se pueden utilizar los errores de programación más peligrosos de OWASP Top 10
o CWE / SANS Top 25 como punto de partida para identificar los vectores raíz pertinentes a
su aplicación. Es un método de recopilación e identificación de posibles ataques de forma
estructurada y jerárquica. Es un método utilizado por los profesionales de la seguridad
porque permite que el equipo de modelado de amenazas analice las amenazas con mayor
detalle y profundidad. La estructura en forma de árbol proporciona un desglose descriptivo
de varios ataques que el atacante podría usar para comprometer el activo. La creación de
árboles de ataque para su empresa tiene el beneficio adicional de crear una representación
reutilizable de problemas de seguridad, que se puede usar en múltiples proyectos para
enfocar los esfuerzos de mitigación. Los desarrolladores reciben información sobre los tipos
de ataques que se pueden usar contra su software y luego implementan los controles de
protección adecuados, mientras que los equipos de prueba pueden usar los árboles de
ataque para escribir planes de prueba. Las pruebas aseguran que los controles estén en su
lugar y sean efectivos.

Usar listas de amenazas categorizadas

Además de pensar como un atacante, otra metodología para identificar amenazas es utilizar
una lista categorizada de amenazas. Algunas metodologías, como la metodología NSA IAM,
el modelado de riesgos OCTAVE y Microsoft STRIDE, tienen como parte de su metodología
una lista de tipos o categorías de amenazas que se pueden utilizar para identificar
amenazas. Los errores de programación más peligrosos de OWASP Top 10 y CWE Top 25
también se pueden usar como una lista de amenazas y se puede determinar su
aplicabilidad.
STRIDE es un acrónimo de una categoría de amenazas. El uso de la lista de amenazas de
la categoría STRIDE es un enfoque basado en objetivos para el modelado de amenazas
porque se tienen en cuenta los objetivos del atacante. La Tabla 3.5 describe la categoría de
amenazas STRIDE de Microsoft.

Objetivo Descripción

S Spoofing ¿Puede un atacante hacerse pasar por otro usuario o

identidad?

T Tampering, ¿Se pueden manipular los datos mientras están en

tránsito o en almacenamiento o archivos?
Manipulación

R Repudiation, ¿Puede el atacante (usuario o proceso) negar el

ataque?
Repudio

I Information Disclosure ¿Se puede divulgar información a usuarios no

Divulgación de autorizados?
Información

D Denial of Service ¿Es posible la denegación de servicio?

Denegación de
servicio

E Elevation of Privilege ¿Puede el atacante eludir la implementación de

privilegios mínimos y ejecutar el software con privilegios
Elevación de elevados o administrativos?
privilegios

Tabla 3.5 - Categoría de amenazas STRIDE

Cuando se utiliza una categoría de amenazas, existe un alto grado de probabilidad de que
una amenaza en particular pueda tener correlación cruzada con otras amenazas. Por
ejemplo, la elevación de privilegios puede ser el resultado de la suplantación de identidad
debido a la divulgación de información o simplemente el resultado de la falta de controles de
repudio. En tales casos, se recomienda utilizar su mejor criterio al categorizar las
amenazas. Se puede seleccionar la categoría más relevante o documentar todas las
categorías de amenazas aplicables y clasificarlas de acuerdo con la probabilidad de que la
amenaza se materialice.

Identificar, priorizar e implementar controles

La mera catalogación de una lista de amenazas proporciona poca ayuda a un equipo de
diseño que necesita decidir cómo abordar la amenaza.

Riesgos derivados de amenazas identificadas que deben mitigarse. La mitigación se logra

mediante la implementación de controles. Es aconsejable utilizar controles estándar en
lugar de inventar los suyos propios. Cuando la mitigación no es posible, el riesgo puede
aceptarse si el nivel de riesgo está por debajo de lo que es aceptable para la empresa o si
el software puede rediseñarse para eliminar la amenaza.

El conocimiento de las amenazas y vulnerabilidades es inútil a menos que se identifiquen

los controles adecuados para mitigar las amenazas que pueden explotar las
vulnerabilidades. La identificación de los controles debe ser específica para cada amenaza.
Una amenaza puede mitigarse completamente con un solo control, o puede ser necesaria
una combinación de controles. En los casos en que se necesite más de un control para
mitigar una amenaza, las medidas de defensa en profundidad deben garantizar que los
controles se complementen en lugar de contradecirse entre sí. También es importante
reconocer que los controles (salvaguardas y contramedidas) no eliminan la amenaza, sino
que solo reducen el riesgo general que está asociado con la amenaza.

Dado que es poco probable que abordar todas las amenazas identificadas sea
económicamente viable, es importante abordar las amenazas que plantean el mayor riesgo
primero, antes de abordar aquellas que tienen un impacto mínimo en las operaciones
comerciales. Los rangos de riesgo derivados de la actividad de evaluación de riesgos de
seguridad (SRA) del ejercicio de modelado de amenazas se utilizan para priorizar los
controles que deben implementarse. Los rangos de riesgo cuantitativo generalmente se
clasifican en bandas cualitativas, como Alto, Medio o Bajo, o, según la gravedad de la
amenaza, en Severidad 1, Severidad 2 y Severidad 3. Estas bandas también se conocen
como barras de errores o bandas de errores y no se limitan solo a cuestiones de seguridad.

También hay barras de insectos para mayor privacidad. Las barras de errores ayudan a
priorizar los controles que se implementarán después del diseño.
Hay varias formas de determinar cuantitativa o cualitativamente la clasificación de riesgo de
una amenaza. Estos van desde la metodología heurística Delphi simple, no científica, hasta
una clasificación de riesgo más sólida desde el punto de vista estadístico utilizando la
probabilidad de impacto y el impacto empresarial. Las tres formas comunes de clasificar las
amenazas son:

● ■■ Clasificación Delphi
● ■■ Clasificación promedio
● ■■ Clasificación de probabilidad x impacto (P x I)
Ranking de Delphi
La técnica Delphi de clasificación de riesgos es aquella en la que cada miembro del equipo
de modelado de amenazas hace su mejor estimación sobre el nivel de riesgo de una
amenaza en particular. Durante un ejercicio de clasificación de riesgos de Delphi, se
expresan opiniones individuales sobre el nivel de riesgo de una amenaza particular y las
opiniones expresadas no se cuestionan, sino que se aceptan como se indica. Las personas
identificadas para este ejercicio incluyen tanto a miembros con habilidades a un nivel
experto como a aquellos que no lo son, pero los miembros participantes solo comunican sus
opiniones a un facilitador. Esto es para evitar el dominio de personalidades fuertes que
potencialmente pueden influir en el rango de riesgo de la amenaza. El facilitador debe
proporcionar, de antemano, criterios de clasificación predefinidos (1 - Crítico, 2 - Grave, 3 -
Mínimo) junto con la lista de amenazas identificadas, para garantizar que todos los
miembros utilicen los mismos criterios de clasificación. Los criterios a menudo se basan
simplemente en el impacto potencial de la materialización de la amenaza y el proceso de
clasificación se realiza hasta que existe consenso o confianza en la forma en que se
clasifican las amenazas. Si bien este puede ser un método rápido para determinar el
consenso del potencial de riesgo de una amenaza, es posible que no brinde una imagen
completa del riesgo y debe usarse con moderación y solo junto con otras metodologías de
clasificación de riesgos. Además, los criterios de clasificación de riesgos ambiguos o
indefinidos y los diferentes puntos de vista y antecedentes de los participantes pueden
hacer que los resultados sean diversos y que el proceso en sí sea ineficiente.

Clasificación promedio
Otra metodología para clasificar el riesgo de la amenaza es calcular el promedio de valores
numéricos asignados a las categorías de clasificación de riesgo. Uno de estos marcos de
categorización de clasificación de riesgo es DREADI, que es un acrónimo de Damage
Potential, Reproducibility, Explotabilidad, Usuarios afectados y Discoverability. A cada
categoría se le asigna un rango numérico y se prefiere utilizar un rango más pequeño (como
1 a 3 en lugar de 1 a 10) para que la clasificación sea más definida, las vulnerabilidades
menos ambiguas y las categorías más significativas.

● Daño Potencial: clasifica el daño que se causará cuando se materialice una

amenaza o se explote una vulnerabilidad.
1 = nada
2 = Los datos de los usuarios individuales están comprometidos o afectados
3 = Sistema completo o destrucción de datos
● Reproducibilidad: clasifica la facilidad de poder recrear la amenaza y la frecuencia
de la amenaza que explota la vulnerabilidad subyacente con éxito.
1 = Muy difícil o imposible, incluso para los administradores de la aplicación
2 = Se requieren uno o dos pasos; puede que necesite ser un usuario autorizado
3 = Solo la barra de direcciones en un navegador web es suficiente, sin
autenticación
● Explotabilidad: clasifica el esfuerzo necesario para que se manifieste la amenaza y
las condiciones previas, si las hay, necesarias para materializar la amenaza.
 1 = Conocimientos avanzados de programación y redes, con herramientas de ataque
avanzadas o personalizadas
2 = Existe software malicioso en Internet o una vulnerabilidad se realiza fácilmente
con las herramientas de ataque disponibles
3 = Solo un navegador webVa que va
● Usuarios afectados: clasifica la cantidad de usuarios o instancias instaladas del
software que se verán afectados si la amenaza se materializa.
1 = Ninguno
2 = Algunos usuarios o sistemas, pero no todos
3 = Todos los usuarios
● Capacidad de detección: clasifica la facilidad con la que los investigadores y
atacantes externos descubren la amenaza, si no se abordan.
1 = Muy difícil o imposible; requiere código fuente o acceso administrativo
2 = Puede resolverlo adivinando o monitoreando los rastros de la red
3 = La información está visible en la barra de direcciones del navegador web o en un
formulario

Una vez que se han asignado los valores a cada categoría, se calcula el promedio de esos
valores para dar un número de clasificación de riesgo. Matemáticamente, esto se puede
expresar como se muestra a continuación.

Figura 3.21 - Uso de una clasificación promedio para clasificar varias amenazas de
aplicaciones web.

Figura 3.22 - Clasificación promedio

El rango promedio y la categorización en grupos como Alto, Medio o Bajo se pueden usar
para priorizar los esfuerzos de mitigación.
Clasificación de probabilidad x impacto (P x I)

El cálculo de la gestión de riesgos convencional del riesgo de materialización de una

amenaza o de explotación de una vulnerabilidad se realiza utilizando el producto de la
probabilidad (probabilidad) de ocurrencia y el impacto que la amenaza tendrá en las
operaciones comerciales, si se materializa. Las empresas que utilizan principios de gestión
de riesgos para su gobierno utilizan la fórmula que se muestra a continuación para asignar
una clasificación de riesgo a las amenazas y vulnerabilidades.

Riesgo = Probabilidad de ocurrencia X Impacto Comercial

Esta metodología es relativamente más científica que el Delphi o la metodología de

clasificación promedio. Para la metodología de clasificación de probabilidad-impacto (P x I),
volveremos a tener en cuenta el marco DREAD. La clasificación de riesgo se calculará
utilizando la fórmula que se proporciona a continuación.

Riesgo = Probabilidad de ocurrencia X Impacto comercial

Riesgo = (Rvalue + Evaluar + DIvalue) X (Dvalue + Avalue)

La figura 3.23 es un ejemplo que ilustra el uso de la metodología de clasificación P x I para

clasificar varias amenazas de aplicaciones web.

Figura 3.23 - Clasificación de probabilidad x impacto (P x I)

A partir de este ejemplo, podemos ver que la amenaza Cross-Site Scripting (XSS) y las
amenazas de inyección SQL son de alto riesgo, que deben mitigarse de inmediato, mientras
que las amenazas de reproducción de cookies y secuestro de sesión son de riesgo medio.
Debería haber un plan para mitigarlos lo antes posible. Las amenazas de eliminación de
registros de auditoría y CSRF tienen un rango de riesgo bajo y pueden ser aceptables. Para
priorizar los esfuerzos de estos dos elementos de alto riesgo (inyección SQL y XSS),
podemos usar el rango de riesgo calculado (P x I) o podemos usar la probabilidad de
ocurrencia (P) o el valor del impacto comercial (I). Dado que tanto la inyección SQL como
XSS tienen el mismo valor de impacto comercial de 6, podemos usar el valor de
probabilidad de ocurrencia para priorizar los esfuerzos de mitigación, eligiendo mitigar
primero XSS y luego la inyección SQL, porque el valor de probabilidad de ocurrencia para
XSS es 9, mientras que el valor de probabilidad de ocurrencia para la inyección SQL es 7.
Si bien la metodología Delphi generalmente se enfoca en el riesgo desde un punto de vista
de impacto comercial, la metodología de clasificación promedio, cuando se usa el marco
DREAD, toma en cuenta tanto el impacto comercial (Daño potencial, Usuarios afectados)
como la probabilidad de ocurrencia (Reproducibilidad, Explotabilidad y Descubribilidad); sin
embargo, debido a que se promedian los valores de impacto comercial y probabilidad de
ocurrencia de manera uniforme, el valor del rango de riesgo derivado no da una idea de la
desviación (límites inferior y superior) del promedio. Esto puede conducir a una aplicación
uniforme de los esfuerzos de mitigación a todas las amenazas, por lo que potencialmente se
aplica demasiado esfuerzo de control de mitigación en amenazas que no son realmente
ciertas o muy poco esfuerzo de control de mitigación en amenazas que son serias. La
metodología de clasificación P x I brinda información sobre el riesgo como una medida tanto
de la probabilidad de ocurrencia como del impacto comercial de forma independiente, así
como cuando se consideran en conjunto. Esto permite que el equipo de diseño tenga la
flexibilidad de reducir la probabilidad de que ocurra o aliviar el impacto comercial de forma
independiente o conjunta, una vez que haya utilizado el rango de riesgo P x I para priorizar
dónde enfocar sus esfuerzos de mitigación. Además, la metodología P x I ofrece una
imagen más precisa del riesgo. Tenga en cuenta que en la metodología de clasificación
promedio, a las amenazas de reproducción de cookies y de secuestro de sesiones se les
había asignado un riesgo medio de 2.0. Esto plantea un desafío para el equipo de diseño:
¿qué amenaza se debe considerar mitigar primero? Sin embargo, en la clasificación P x I de
las mismas amenazas, observa que la amenaza de repetición de cookies tiene una
puntuación de riesgo de 24, mientras que la amenaza de secuestro de sesión tiene una
puntuación de riesgo de 21, según la probabilidad de ocurrencia y el impacto comercial.
Esto facilita que el equipo de diseño considere mitigar la amenaza de reproducción de
cookies antes de abordar la amenaza de secuestro de sesión.

Documentar y validar
La importancia de documentar el modelo de amenazas no puede subestimarse porque el
modelado de amenazas es iterativo y, a lo largo del ciclo de vida del proyecto, los controles
de protección para abordar las amenazas identificadas en el modelo de amenazas deben
implementarse, validarse de manera adecuada y el modelo de amenazas en sí. actualizado.

Las amenazas y los controles se pueden documentar en forma de diagrama o en formato

textual. La documentación esquemática proporciona un contexto para las amenazas. La
documentación textual permite una documentación más detallada de cada amenaza. Es
mejor hacer ambas cosas. Documente cada amenaza en forma de diagrama y amplíe los
detalles de la amenaza utilizando una descripción textual.

Al documentar las amenazas, se recomienda utilizar una plantilla para mantener la

coherencia de documentar y comunicar las amenazas. Algunos de los atributos de una
amenaza que deben documentarse incluyen el tipo de amenaza con un identificador único,
la descripción, el objetivo de la amenaza, las técnicas de ataque, el impacto en la seguridad,
la probabilidad o el riesgo de que la amenaza se materialice y, si están disponibles, los
posibles controles. para implementar. La figura 3.24 muestra la documentación textual de un
ataque de inyección.

Figura 3.24 - Documentación de amenazas

La figura 3.25 es una ilustración de la documentación de los controles de identificación para

abordar una amenaza.

Una vez documentadas las amenazas y los controles, y el riesgo residual, se debe realizar
una validación para garantizar lo siguiente:
● ■■ La arquitectura de la aplicación que se modela (diagrama) es precisa y
contextualmente actual (actualizada).
● ■■ Las amenazas se identifican en cada límite de confianza y para el elemento de
datos.
● ■■ Cada amenaza se ha considerado explícitamente y se han identificado y
mapeado los controles para mitigar, aceptar o evitar las amenazas que abordan.
● ■■ Si se acepta la amenaza, el propietario de la empresa debe determinar y aceptar
formalmente el riesgo residual de esa amenaza.
También es importante revisar el modelo de amenazas y re-validarlo, en caso de que
cambien el alcance y los atributos de la aplicación de software.

Arquitecturas
Dado que los objetivos comerciales y la tecnología cambian con el tiempo, es importante
que las arquitecturas de software sean estratégicas, holísticas y seguras. La arquitectura
debe ser estratégica, lo que significa que el diseño del software tiene en cuenta una
perspectiva a largo plazo y aborda más que solo los objetivos tácticos a corto plazo. Esto
reduce la necesidad de rediseñar el software cuando hay cambios en los objetivos
comerciales o en la tecnología. Al diseñar la arquitectura del software para que sea
altamente cohesiva y poco acoplada, el software se puede escalar con un rediseño mínimo
cuando se requieren cambios. La arquitectura también debe ser holística. Esto significa que
el diseño de software no es solo de naturaleza centrada en TI, sino que también incluye las
perspectivas de la empresa y otras partes interesadas. En una economía global, las
consideraciones locales son también una consideración arquitectónica importante. La
arquitectura holística de software también significa que tiene en cuenta no solo los aspectos
de diseño de personas, procesos y tecnología, sino también los aspectos de red, host y
aplicaciones del diseño de software. La seguridad de la implementación en las diferentes
capas del modelo de referencia de interconexión de sistemas abiertos (OSI) de ISO / IEC
7498-1: 1994 es importante para que no exista un vínculo débil entre la capa física y la capa
de aplicación. La Tabla 3.6 ilustra las diferentes capas del modelo de referencia OSI, las
amenazas potenciales en cada capa y qué control de protección o tecnología se puede
aprovechar en cada capa. El uso de IPSec en la capa de red (capa 3), la capa de sockets
seguros (SSL) en la capa de transporte (capa 4) y la gestión de derechos digitales (DRM)
en la capa de presentación (capa 6) aumenta los controles de protección que están
diseñados en la capa de aplicación (capa 7) y esto demuestra dos principios de diseño
seguro: defensa en profundidad y aprovechamiento de los componentes existentes.

Finalmente, la arquitectura de software debe ser no solo estratégica y holística, sino

también segura. Los beneficios de la arquitectura de seguridad empresarial son muchos.
Algunos de ellos se enumeran a continuación. Arquitectura de seguridad empresarial:

● Proporciona protección contra problemas relacionados con la seguridad que pueden

estar relacionados con la arquitectura (fallas) o la implementación (errores) o ambas.
● Hace posible implementar soluciones de seguridad comunes en toda la empresa.
● Promueve la interoperabilidad y facilita la integración de sistemas mientras se
gestiona el riesgo de forma eficaz.
● Permite aprovechar las mejores prácticas líderes en la industria. La Interfaz de
programación de aplicaciones de seguridad empresarial de OWASP (ESAPI) es un
ejemplo de un conjunto de herramientas que se puede aprovechar para administrar
los riesgos de manera uniforme al permitir que los miembros del equipo de
desarrollo de software se protejan contra fallas y errores.
● Facilita a los tomadores de decisiones la toma de decisiones relacionadas con la
seguridad mejores y más rápidas en toda la empresa.
# de Nombre de Descripción de capa Amenazas Controles de
capa capa Protección /
Tecnología

7 Aplicación Describe la Defectos, errores, Firewalls de capa de

estructura, puertas traseras, aplicación, diseño
interpretación y software malicioso, seguro, codificación,
manejo de pruebas,
información despliegue,
mantenimiento,
operaciones y
eliminación.

6 Presentación Describe la Fuga de Enmascaramiento y

presentación de información y otros controles
información, divulgación de criptográficos, RBAC
haciendo contenido y derechos
conversiones de dependientes del
sintaxis como ASCII contenido, controles
/ EBCDIC de protección de
responsabilidad como
"reenvío no
permitido", DRM

5 Sesión Describe el Omisión de Fuertes controles de

protocolo de enlace autenticación, autenticación,
entre aplicaciones identificadores de generación de ID de
(autenticación, inicio sesión débiles y sesión única y
de sesión) adivinables, aleatoria, cifrado en
spoofing, MITM, transmisión y
robo de almacenamiento,
credenciales, niveles de recorte de
divulgación de bloqueo de cuenta
datos, ataques de
fuerza bruta

4 Transporte Describe la Pérdida de Cortafuegos de

transferencia de paquetes, huellas inspección de estado,
datos entre digitales y SSL, monitoreo de
aplicaciones; enumeración de puertos, control de
proporciona control hosts, puertos flujo
de flujo, detección y abiertos
corrección de
errores (por
ejemplo, TCP y
UDP)

3 Red Describe la Suplantación de Cortafuegos de

transferencia de rutas y direcciones filtrado de paquetes,
datos entre redes IP, suplantación de supervisión de ARP /
(por ejemplo, identidad difusión, filtros de
Protocolo de borde de red, IPSec
Internet)
 2 Enlace de Describe la Suplantación de Filtrado MAC,
datos transferencia de direcciones MAC, Firewalls y
datos entre elusión de VLAN, segmentación
máquinas (p. Ej., errores de árbol de (aislamiento) de
Módem RJ11, RJ45 expansión, ataques redes, Autenticación
Ethernet) inalámbricos inalámbrica y cifrado
fuerte

1 Físico Describe el Robo físico, Perímetros y

hardware de red, pérdida de energía, vigilancia bloqueados,
como interfaces de registradores de candados protegidos
red y cables físicos, teclas y otros con PIN y contraseña,
y la forma de interceptores de autenticación
transmitir bits y datos biométrica, blindaje
bytes de datos electromagnético,
(pulsos eléctricos, transmisión y
ondas de radio o almacenamiento
luz). seguros de datos

Tabla 3.6 - Capas de interconexión de sistemas abiertos

Los cambios en la potencia informática del hardware han dado lugar a cambios en las
arquitecturas de software desde la arquitectura centralizada del mainframe a la arquitectura
informática altamente distribuida. Hoy en día, muchas arquitecturas distribuidas, como el
modelo Cliente / Servidor, redes peer-to-peer, arquitectura orientada a servicios (SOA),
aplicaciones de Internet enriquecidas (RIA), computación generalizada, software como
servicio (SaaS), computación en la nube y virtualización. , existen y están en aumento. En la
siguiente sección, analizaremos los diferentes tipos de arquitecturas que prevalecen en la
actualidad y cómo diseñar software para que sea seguro al usar estas arquitecturas.

Arquitectura central - Mainframe

Conocidos coloquialmente como Big Iron, los mainframes son computadoras que son
capaces de procesar datos a granel con gran velocidad de cálculo y eficiencia. La velocidad
se suele medir en millones de instrucciones por segundo (MIPS). En los primeros días del
mainframe, la informática implicaba servidores mainframe estrechamente acoplados y
terminales tontas que eran simplemente interfaces para la funcionalidad que existía en los
servidores back-end de alto procesamiento. Todo el procesamiento, la seguridad y la
protección de datos estaba a cargo del servidor central, que normalmente operaba en una
red cerrada con un número restringido de usuarios.
Además de la mayor velocidad de cómputo, la ingeniería de redundancia para alta
disponibilidad y la conectividad a través de redes IP, la computación de mainframe actual
brinda conectividad remota, lo que permite que decenas de usuarios accedan a los datos y
la funcionalidad del mainframe. Esto es posible gracias a las interfaces de acceso, incluidas
las interfaces web que están disponibles en los mainframes. El mainframe proporciona uno
de los grados más altos de seguridad inherentemente con un Nivel de garantía de
evaluación de 5. Tiene su propia infraestructura de red, que aumenta sus capacidades de
seguridad inherentes y básicas.
Sin embargo, con el aumento de la conectividad, aumenta el potencial de ataque y
disminuye la seguridad proporcionada por la red cerrada y los mecanismos de control de
acceso restringido. Además, uno de los desafíos que surgen es que la cantidad de personas
capacitadas en los procedimientos operativos y la seguridad de los mainframes está
disminuyendo, y las personas se jubilan o se trasladan a plataformas más nuevas. Este es
un tema importante desde el punto de vista de la seguridad porque aquellos que se van son
los que probablemente diseñaron la seguridad de estos mainframes y esta fuga de cerebros
puede dejar los sistemas de mainframe en un estado operacionalmente inseguro.
Para hacer frente a los desafíos de seguridad en la evolución de la arquitectura informática
de mainframe, el cifrado de datos y la protección de tránsito de extremo a extremo son
controles de mitigación de riesgos importantes que se deben implementar. Además, es
importante diseñar en el principio de aceptabilidad psicológica al hacer que la seguridad sea
transparente.

Esto significa que deben evitarse las soluciones que requieren la reescritura de
aplicaciones, lenguaje de control de trabajos (JCL) de mainframe y secuencias de
comandos de infraestructura de red. El problema de la escasez de habilidades debe
abordarse empleando la educación de los usuarios y las iniciativas que hacen lucrativo un
futuro en mainframe, especialmente en relación con su cruce con nuevas aplicaciones y
plataformas abiertas más nuevas como Linux.

Transferencia de estado representacional (REST)

REST, como estilo arquitectónico, se está convirtiendo en el modelo de diseño de servicios

web predominante. REST se puede considerar como una variante de SOA donde los
servicios son realmente recursos (o URI). Es por eso que REST también se conoce
comúnmente como Arquitectura Orientada a Recursos (ROA).

REST es un modelo cliente / servidor, en el que las solicitudes y respuestas se basan en el

estado de transición de los recursos.

Aunque los servicios web se han implementado predominantemente mediante SOAP, REST
también se puede utilizar para implementar servicios web. Un servicio web RESTful se
implementa utilizando los principios REST y la API del Protocolo de transferencia de
hipertexto (HTTP). La forma en que se implementan los servicios web RESTful es como una
colección de recursos y cada servicio web RESTful:

● ■■ Tiene una dirección de recurso única o un URI base (por ejemplo, http://isc2.org/
resources /)
● ■■ Admite el tipo de medio de los datos admitidos por el servicio web (por ejemplo,
XML, JSON, etc.)
● ■■ Utiliza métodos HTTP para sus operaciones (por ejemplo, GET, PUT, POST o
DELETE)
Dado que los servicios web RESTful se ejecutan sobre el protocolo de hipertexto, son
independientes de la plataforma. El servidor puede ser un servidor Windows mientras que el
cliente puede ser una máquina Linux o un dispositivo iOS. También es independiente del
lenguaje de programación.

El beneficio de usar REST para las transiciones cliente / servidor es que promueve un
acoplamiento flexible entre los diferentes servicios, ya que REST no está fuertemente
tipado, a diferencia de SOAP. REST también se diferencia de SOAP por ser menos
hinchado, ya que no requiere un encabezado de mensaje del proveedor de servicios para
sus operaciones, pero esto podría tener mensajes de seguridad ya que la prueba del origen
de la solicitud es difícil de asegurar. REST también es más rápido que SOAP, ya que no
requiere todo el análisis (análisis XML) que SOAP necesita para que funcione. REST
también se enfoca en la legibilidad y usa sustantivos y verbos comunes (por ejemplo, GET,
PUT, POST, DELETE) para sus llamadas a métodos. Aunque hay algunas mejoras en el
rendimiento al usar REST, debe entenderse que REST no ofrece ninguna característica de
seguridad incorporada y debe implementarse con tecnologías de seguridad
complementarias para garantizar operaciones seguras. Por ejemplo, los tokens para
autenticación y SSL (HTTPS) para el cifrado de datos en el cable son necesarios para
incorporar seguridad cuando se utilizan los servicios web RESTful.

Aplicaciones de Internet enriquecidas

Con la naturaleza omnipresente de la Web y la exageración de las redes sociales, es muy

poco probable que no se haya encontrado ya con Rich Internet Applications (RIA). Algunos
ejemplos de RIA en uso en la actualidad son Facebook y Twitter. Las aplicaciones de
Internet enriquecidas traen la riqueza del entorno de escritorio y el software a la Web. Una
conexión en vivo (Protocolo de Internet) a la red y un cliente (navegador, complemento de
navegador o máquina virtual) son a menudo todo lo que se necesita para ejecutar estas
aplicaciones. Algunos de los marcos que se utilizan comúnmente en RIA son AJAX, Abode
Flash / Flex / AIR, Microsoft Silverlight y JavaFX. Con mayores capacidades de
procesamiento del lado del cliente (navegador), la carga de trabajo en el lado del servidor se
reduce, lo que es un beneficio principal de RIA. El aumento de la experiencia y el control del
usuario también son beneficios evidentes.

RIA también tiene algunos mecanismos de control de seguridad inherentes. Estos incluyen
la Política del Mismo Origen (SOP) y la zona de pruebas. El origen de una aplicación web
se puede determinar mediante la información del protocolo (http / https), el nombre de host y
el puerto (80/443). Si dos sitios web tienen el mismo protocolo, nombre de host e
información de puerto, o si las propiedades document.domain de dos recursos web son las
mismas, se puede decir que ambos tienen la misma fuente u origen. El objetivo de SOP es
evitar que un recurso (documento, script, applets, etc.) de una fuente interactúe y manipule
documentos en otra. La mayoría de los navegadores de hoy en día tienen seguridad SOP
incorporada y los clientes de navegador RIA heredan intrínsecamente esta protección. Las
aplicaciones de Internet enriquecidas también se ejecutan dentro de la zona de pruebas de
seguridad del navegador y no pueden acceder a los recursos del sistema, a menos que el
acceso se otorgue explícitamente. Sin embargo, las amenazas de las aplicaciones web,
como los ataques de inyección, los ataques de secuencias de comandos y el malware, son
aplicables a RIA. Con RIA, la superficie de ataque aumenta, lo que incluye al cliente que
puede ser susceptible a amenazas de seguridad. Si se elude la protección de la zona de
pruebas, las máquinas host que no están correctamente parcheadas pueden convertirse en
víctimas de amenazas de seguridad. Esto requiere la necesidad de diseñar explícitamente
mecanismos de protección de seguridad web para RIA. Asegúrese de que las decisiones de
autenticación y control de acceso no dependan de las comprobaciones de verificación del
lado del cliente. El cifrado y la codificación de datos son importantes mecanismos de
protección. Para asegurar la protección de los SOP, el diseño del software debe tener en
cuenta la determinación del origen real (o verdadero) de los datos y servicios y no solo
validar la última referencia como el punto de origen.

Computación omnipresente / ubicua

La definición del diccionario de la palabra "penetrar" es "atravesar" o "difundirse en cada

parte de" y, como su nombre indica, la computación omnipresente se caracteriza porque la
computación se difunde en cada parte del día a día. vivo. Es una tendencia de la
computación distribuida cotidiana que surge de las tecnologías convergentes,
principalmente las tecnologías inalámbricas, Internet y el aumento en el uso de dispositivos
móviles como teléfonos inteligentes, PDA, computadoras portátiles, etc. Se basa en la
premisa de que cualquier dispositivo puede conectarse a una red de otros dispositivos.

Hay dos elementos de la informática generalizada y estos incluyen la computación

generalizada y la comunicación generalizada. La computación generalizada implica que
cualquier dispositivo, aparato o equipo que pueda integrarse con un chip o sensor de
computadora puede conectarse como parte de una red y acceder a servicios desde y a
través de esa red, ya sea una red doméstica, una red de trabajo o una red. en un lugar
público como un aeropuerto, una estación de tren, etc. La comunicación generalizada
implica que los dispositivos de una red generalizada pueden comunicarse entre sí a través
de protocolos alámbricos e inalámbricos, que se pueden encontrar prácticamente en todas
partes en esta era digital.

Uno de los principales objetivos de la informática generalizada es crear un entorno en el que

la conectividad de los dispositivos sea discreta para la vida cotidiana, intuitiva,
perfectamente portátil y disponible en cualquier momento y lugar. Esta es la razón por la
que la computación omnipresente también se conoce como computación ubicua y, en
términos simples, computación cotidiana en todas partes. Los protocolos inalámbricos
eliminan las limitaciones impuestas por la informática cableada físicamente y hacen posible
ese paradigma informático "en todas partes". Bluetooth y ZigBee son ejemplos de dos
protocolos inalámbricos comunes en un entorno informático generalizado. Los teléfonos
inteligentes, los asistentes digitales personales (PDA), las tabletas, los automóviles
inteligentes, las casas inteligentes y los edificios inteligentes son algunos ejemplos de la
informática generalizada.

En la informática generalizada, los dispositivos son capaces de conectarse y desconectarse

de una red en cualquier momento y en cualquier lugar, lo que convierte a este tipo de
informática en un tipo de informática distribuida ad hoc, plug-and-play. La red es de
naturaleza muy heterogénea y puede variar en el número de dispositivos conectados en un
momento dado. Por ejemplo, cuando está en un aeropuerto, su computadora portátil o
teléfono inteligente puede conectarse a la red inalámbrica en el aeropuerto, convirtiéndose
en un nodo en esa red, o su teléfono inteligente puede conectarse a través de Bluetooth a
su automóvil, lo que permite el acceso a su calendario, contactos y archivos de música en
su teléfono inteligente a través de la red del automóvil.

Para maximizar la productividad, las empresas están adoptando iniciativas Bring Your Own
Device (BYOD) y / o Choose Your Device (CYD), pero se debe reconocer que, si bien los
beneficios de la computación generalizada incluyen la capacidad de estar conectados
siempre desde cualquier lugar, desde un Desde el punto de vista de la seguridad, trae
consigo algunos desafíos que requieren atención. Esto es importante porque los empleados
dependen cada vez más de los teléfonos inteligentes y las tabletas para hacer su trabajo.
Los dispositivos que están conectados como parte de una red generalizada no solo son
susceptibles de atacarse a sí mismos, sino que también pueden usarse para orquestar
ataques contra la red a la que están conectados. Es por eso que la mediación completa,
implementada mediante la autenticación de nodo a nodo, debe ser parte del diseño de
autenticación. No se debe permitir que las aplicaciones en el dispositivo se conecten
directamente a la red backend, sino que deben autenticarse en el dispositivo y, a su vez, el
dispositivo debe autenticarse en las aplicaciones internas de la red. Se recomienda usar el
chip Trusted Platform Module (TPM) en el dispositivo en lugar de usar la dirección Media
Access Control (MAC) fácilmente falsificable para la identificación y autenticación del
dispositivo. La gestión de dispositivos móviles (MDM) está ganando mucha atención en la
actualidad, ya que permite establecer políticas que rijan el uso de aplicaciones de terceros
en dispositivos móviles. Al diseñar aplicaciones móviles para la empresa, se recomienda
aprovechar las capacidades de MDM para garantizar la confianza de las partes interesadas.
Los diseñadores de aplicaciones informáticas generalizadas deben estar familiarizados con
los mecanismos y el protocolo de protección de dispositivos móviles de nivel inferior.

Los diseñadores de sistemas ahora también deben diseñar mecanismos de protección

contra amenazas a la seguridad física. Debido al pequeño tamaño de la mayoría de los
dispositivos informáticos móviles, es probable que los roben o los pierdan. Esto significa que
los datos almacenados en el propio dispositivo están protegidos contra amenazas de
divulgación mediante cifrado u otros medios criptográficos. Debido a que un dispositivo se
puede perder o robar, las aplicaciones en el dispositivo deben estar diseñadas para tener
una capacidad de "borrado automático" que se pueda activar en el dispositivo mismo o de
forma remota. Esto significa que los datos del dispositivo se borran por completo cuando el
dispositivo es robado o se cumple una condición para borrar los datos (por ejemplo,
manipulación, autenticación fallida, etc.). La actividad desencadenante más común es la
entrada incorrecta del PIN (Número de identificación personal) más veces que el número
configurado de intentos de autenticación permitidos. El cifrado y la autenticación son de
suma importancia para la protección de datos en dispositivos informáticos omnipresentes.
Se recomienda la autenticación biométrica en lugar de la autenticación basada en PIN, ya
que esto requerirá que un atacante falsifique las características físicas del propietario,
aumentando significativamente su factor de trabajo.
Algunos de los desarrollos en tecnologías que han promovido la popularidad de la
informática generalizada incluyen:

● Redes y comunicaciones inalámbricas

● Identificación por radiofrecuencia (RFID)
● Servicios basados ​en la ubicación (LBS)
● Comunicaciones de campo cercano (NFC)
● Redes de sensores.

Redes y comunicaciones inalámbricas

Las redes y las comunicaciones inalámbricas hacen que sea relativamente más fácil
crear redes informáticas omnipresentes, en comparación con su red cableada
contrapartes. De hecho, se puede argumentar que el supuesto de que el aumento
de red inalámbrica ha tenido un impacto directamente proporcional en el predominio
de redes informáticas omnipresentes.

Configuración de redes inalámbricas y protocolos en los que una parte significativa

de la computación generalizada depende, sin embargo, también son susceptibles a
ataques.

La mayoría de los puntos de acceso inalámbricos están encendidos con la

configuración predeterminada del fabricante, que se puede adivinar fácilmente si no
se transmite como el identificador de conjunto de servicios (SSID). El SSID permite
que otros dispositivos 802.11x se unan a la red. Aunque el encubrimiento SSID,
significa que el SSID no se transmite, no es infalible, aumenta la protección contra el
descubrimiento de dispositivos no autorizados y no configurados previamente a la
red inalámbrica automáticamente. Para que un dispositivo se conecte a la red, debe
conocer el secreto compartido y este secreto compartido, mecanismo de
autenticación ofrece mucha más protección que la autenticación de red abierta.

No solo la configuración de la red inalámbrica es vulnerable, sino también los

protocolos, ellos mismos, pueden ser susceptibles a violaciones de seguridad. El
Equivalente Cableado Privacidad (WEP) utiliza un cifrado de flujo RC4 de 40 bits
para proporcionar protección. Se ha demostrado que es débil y se ha roto
fácilmente. Utilizando se recomienda el acceso protegido Wi-Fi (WPA y WPA2)
sobre WEP en la actualidad entornos informáticos omnipresentes. Los ataques
contra el protocolo Bluetooth son también evidentes, que incluyen Bluesnarfing,
Bluejacking y Bluebugging, para nombrar unos pocos.
Otras vulnerabilidades inalámbricas comúnmente observadas incluyen: espionaje
y análisis de tráfico, la suplantación del Protocolo de resolución de direcciones
(ARP), para la interceptación de mensajes, la divulgación y los ataques MITM, la
inyección de mensajes o eliminación y bloqueo de puntos de acceso inalámbricos
que conducen a DoS.

Identificación por radiofrecuencia (RFID).

RFID es una tecnología inalámbrica que utiliza campos electromagnéticos de

radiofrecuencia. Para transferir datos con fines de identificación y seguimiento
automático. La tecnología funciona principalmente mediante el uso de un objeto que
se conoce comúnmente como Etiqueta RFID. Una etiqueta RFID contiene la
información de identificación y el seguimiento de información en él, que transmite a
un lector. Algunas de estas etiquetas deben estar alimentados por una batería y se
conocen como etiquetas asistidas por batería (BAT) mientras que no requieren
batería externa y se alimentan y leen a distancias cortas utilizando campos
magnéticos. Aunque una etiqueta RFID funciona como un código de barras, no
requiere una línea de visión con el lector y puede estar integrado en el objeto
rastreado, lo que permite su uso en operaciones sigilosas.

La tecnología RFID está ganando rápidamente una gran adopción como la

tecnología informática y la implementación descuidada de la tecnología RFID
pueden conducir a la divulgación de información confidencial sobre los usuarios y
sus ubicaciones. Además, estas etiquetas se pueden clonar, lo que supone una
amenaza de suplantación de identidad, o estar discapacitado y provocar un DoS.
Por tanto, es muy importante identificar e implementar controles de seguridad y
privacidad cuando el software aprovecha RFID tecnología. Además de los controles
clásicos que aseguran la confidencialidad, la integridad y disponibilidad, el software
RFID debe garantizar:

⃞ Anonimato al evitar la identificación no autorizada de usuarios.

⃞ Desvinculabilidad al evitar el rastreo no autorizado de etiquetas y
⃞ Privacidad de la ubicación al evitar el acceso no autorizado al perfil de usuario
datos.
Servicios basados ​en la ubicación (LBS)

La mayoría de las plataformas y dispositivos móviles de hoy en día vienen con el

hardware y software capacidades de geolocalización. La geolocalización permite
determinar la real ubicación geográfica de un objeto. Aunque se puede utilizar la
tecnología RFID para LBS, existen otras tecnologías además de RFID que
proporcionan geolocalización capacidades en software también. Estos incluyen
sistemas de posicionamiento global (GPS), sistemas de información geográfica
(SIG), Sistema de posicionamiento basado en red, ubicación del plano de control y
localización del módulo de abonado global (GSM).

Los fabricantes de dispositivos móviles publican las API de geolocalización que el

software los desarrolladores pueden invocar para aprovechar las capacidades de
geolocalización. Mientras estos proveedores de servicios han estado
promocionando estas características de experiencia de usuario como un
diferenciador, los servicios basados ​en la ubicación pueden traer consigo algunos
problemas graves en cuanto a privacidad y seguridad. Desarrolladores de software
que escriben software que aprovechan las API de geolocalización debe garantizar
que el usuario no solo sea notificado de su potencial rastreado, pero también se
solicitó su consentimiento antes de aprovechar la ubicación funcionalidad de
seguimiento en el software. Además, el software debe ser diseñado para brindar a
los usuarios la opción de desactivar el seguimiento de ubicación como un medio
para proteger su privacidad. De no hacerlo, no solo puede permitir que un atacante
rastrear a un usuario hasta su ubicación física real, pero tener un cumplimiento serio
repercusiones de la violación.

Comunicación de campo cercano (NFC)

NFC es una tecnología de comunicaciones inalámbrica de corto alcance que

permite transacciones de corto alcance o sin contacto (por ejemplo, pago móvil,
emisión de boletos por aire, etc.) al igual que la tecnología RFID, el estándar en el
que se basa. Una NFC dispositivo de transmisión (como un teléfono inteligente),
puede comunicarse con otros NFC dispositivos receptores, cuando están en
contacto cercano o cerca entre sí. Por ejemplo, con solo un toque o señalando, un
usuario puede pagar su boleto de autobús sin tener la necesidad de sacar su
billetera y pasar su tarjeta de crédito, cuando tiene la tarjeta habilitada para NFC en
su persona, o en algunos casos, incluso sin la la propia tarjeta NFC, cuando la
información del usuario se almacena en su NFC habilitado inteligente teléfono. Esto
hace que la transferencia de datos de la aplicación sea relativamente fácil.

Junto con los beneficios de la comodidad del usuario y la transferencia rápida y

sencilla de datos de la aplicación, existen algunos riesgos de seguridad que conlleva
la tecnología NFC que los desarrolladores de software que aprovechan la tecnología
NFC deben tener en cuenta, al diseñar su software.

Estas amenazas incluyen:

■ Interceptación y manipulación de mensajes durante la transmisión

■ Ataques Man-in-the-Middle (MITM)
■ Escuchas clandestinas (por personas cercanas)
■ Cabe señalar que, a diferencia de otras tecnologías inalámbricas de largo alcance,
el gran beneficio de utilizar NFC para las comunicaciones es que reduce
posibilidad de escuchas, porque las transmisiones son
corto alcance (generalmente a centímetros de distancia entre sí).

Para mitigar estos riesgos, el software debe diseñarse para establecer primero un
canal seguro entre los puntos finales de comunicación / transacción y si es factible,
los puntos finales deben ser validados por su autenticidad y confianza antes de
cualquier transmisión.

Redes de sensores

Básicamente, una red de sensores es una colección de varios microordenadores de

detección estaciones (o nodos sensores) que recopilan y transmiten información.
Históricamente, el uso más frecuente de redes de sensores se ha observado en el
monitoreo de los fenómenos del clima, pero recientemente con el aumento de la
informática de sistemas integrados tecnología, dispositivos sensores y nodos ahora
se utilizan para la automatización del hogar (hogares inteligentes), monitoreo del
tráfico terrestre y aéreo y dispositivos médicos, y operaciones de vigilancia militar.
Las capacidades limitadas de almacenamiento de datos y energía en estas
microcomputadoras representan un desafío para la implementación de controles de
seguridad inalámbricos tradicionales. Además, el canal de comunicación en las
redes de sensores no es confiable y no ofrece ninguna garantía de entrega
garantizada. Esto puede conducir a paquetes de contención y conflictos, latencia
cuando los datos viajan a través de múltiples saltos de un nodo sensor a otro y
errores de enrutamiento. Dado que estos dispositivos sensores son de tamaño
pequeño, también son susceptibles de robo físico cuando se dejan desatendidos.

Al diseñar redes de sensores o software que se utiliza en estos dispositivos

sensores, es necesario asegurarse de que la divulgación de datos y las amenazas
de alteración se mitigan, especialmente en situaciones militares. Además, es
importante sincronizar la hora en todos los nodos del nodo sensor para evitar datos
problemas de integridad. Aunque, se observan amenazas a la confidencialidad e
integridad en las redes de sensores, la amenaza más notable para las redes de
sensores está relacionada con la disponibilidad. Es DoS, ya que incluso la simple
interferencia de los nodos del sensor puede generar no están disponibles para las
operaciones. Adquisición de nodos, protocolo de direccionamiento (enrutamiento)
ataques, escuchas clandestinas, análisis de tráfico y suplantación de identidad son
otras amenazas que deben mitigarse en la red de sensores. Una conocida amenaza
de suplantación de identidad observado en las redes de sensores es el ataque Sybil,
donde un dispositivo deshonesto asume diferentes identidades de un nodo sensor
legítimo en la red.

Es necesario un enfoque en capas para la seguridad informática generalizada los

siguientes son algunas de las mejores prácticas comprobadas que se recomiendan
como protección, medidas en un entorno informático generalizado:

■Asegúrese de que las protecciones de seguridad física (puertas cerradas, placas

acceso, etc.) están en su lugar, si corresponde.
■ Cambiar las configuraciones predeterminadas de los dispositivos de punto de
acceso inalámbrico y no transmita información SSID.
■ Cifre los datos mientras están en tránsito usando SSL / TLS y en el dispositivo.
■ Utilice un mecanismo de autenticación de secreto compartido para mantener
dispositivos salten a su red.
■ Utilice la autenticación basada en dispositivos para aplicaciones internas en
red.
■ Utilice la autenticación biométrica para el acceso de los usuarios al dispositivo, si
factible.
■ Desactive o elimine servicios básicos como Telnet y FTP.
■ Tener una capacidad de borrado automático para evitar la divulgación de datos en
caso de que el dispositivo sea robado o perdido.
■ Audite y supervise periódicamente los registros de acceso para determinar
anomalías.

Computación en la nube

La computación en la nube es una de las principales arquitecturas en las que la

mayoría de las aplicaciones se están diseñando hoy. Los servicios en la nube están
en aumento y el software tradicional se observa que está siendo rediseñado para
operar en la nube.

Las tecnologías de computación en la nube hacen posible que las empresas creen
autoservicio medible, bajo demanda, rápidamente elástico, interoperable y portátil
sistemas y aplicaciones de software que tienen amplio acceso y conectividad a un
conjunto de infraestructura y recursos compartidos.

La arquitectura de computación en la nube es una arquitectura de múltiples

inquilinos, lo que significa que más de un consumidor (o inquilino como se les
conoce en la computación en la nube), puede aprovechar el software y los servicios
que están disponibles mediante un servicio en la nube proveedor.

Impulsores y beneficios

El principal impulsor de la mayor adopción de arquitecturas de computación en la

nube es el ahorro de costos. Antes de la adopción de la computación en la nube, las
empresas tenían que comprar hardware y software para proporcionar servicios a
sus propios clientes. Este fue un gasto de capital (CapEx) para la empresa. Ahora
con empresas en la nube, las empresas no tienen que recurrir al gasto inicial de
comprar recursos, sino en su lugar, pueden alquilar (o suscribirse a) servicios
proporcionados por un servicio proveedor. Luego pueden pagar solo por lo que
usan, al igual que un individuo pagaría la electricidad o el agua que utilizan a su
proveedor de servicios públicos. El modelo de "alquiler" o "pago por uso", desplaza
el gasto en los recursos financieros de la empresa libros de CapEx a gastos
operativos (OpEx) que se pueden administrar más efectivamente.
Además del ahorro de costos, la computación en la nube también brinda
interoperabilidad entre sistemas dispares y soporte para múltiples interfaces de
consumidores. Desde el Los recursos en la nube se abstraen como servicios y se
exponen mediante API, cualquier consumidor que puede invocar y cumplir el
contrato de servicio publicado en API puede ser compatible. El soporte de frontend
de múltiples consumidores también se conoce como multi-tenancy.

La computación en la nube también promueve la independencia de los dispositivos,

ya que los consumidores ven la aplicaciones en la nube y, en general, carecen de
información sobre el dispositivo de hardware en el que se ejecuta el servicio). Los
servicios en la nube son portátiles, lo que significa que la carga de trabajo se puede
distribuir entre los distintos recursos de la nube. Ellos pueden ser provistos
dinámicamente proporcionando economías de escala y medidas, lo que significa
que el uso de los servicios proporcionados por un recurso en la nube sea medible.

Con la arquitectura de la computación en la nube ganando cada vez más tracción

Dentro de las empresas, los servicios en la nube se están convirtiendo en un
diferenciador en muchas empresas. Esta diferenciación es posible porque la
computación en la nube reduce costos y tiempo de comercialización:

■ Costo reducido: en lugar de pagar altos costos por los recursos de hardware y
licencias de software, los inquilinos ahora pueden usar servicios en la nube y
aplicaciones bajo demanda y pagan solo por los servicios que utilizan.
■ Reducción del tiempo de comercialización: con el software ya disponible para su
uso como una inversión de servicio, tiempo y recursos (personal) para Desarrollar la
misma funcionalidad en casa se reduce. Esto, junto con menores requisitos de
formación y tiempo de prueba reducido hace es posible que las empresas
comercialicen rápidamente sus productos y servicios.
■ Integridad de las versiones de software: con el software centralizado administrado
y gestionado por el proveedor de servicios, el inquilino es no es responsable de
parches y actualizaciones de versión, asegurando así que las versiones no están
desactualizadas.

Los recursos de hardware y software en la computación en la nube se pueden

aprovisionar utilizando
tres modelos de servicios primarios. Éstos incluyen

■ Infraestructura como servicio (IaaS),

■ Plataforma como servicio (PaaS) y
■ Software como servicio (SaaS).

En IaaS, componentes de infraestructura como equipos de red, almacenamiento,

Los servidores y las máquinas virtuales se proporcionan como servicios y se
gestionan mediante la nube proveedor de servicio. En PaaS, además de los
componentes de infraestructura, la plataforma componentes como sistemas
operativos, middleware y tiempo de ejecución también son prestados como servicios
y gestionados por el proveedor de servicios en la nube. En SaaS, además de
componentes de infraestructura y plataforma, alojamiento de datos y software las
aplicaciones se proporcionan como servicios y son administradas por el proveedor
de servicios en la nube. SaaS está más directamente relacionado con las funciones
de un profesional de seguridad de software y se trata con más detalle aquí.

Tradicionalmente, el software se diseñó y desarrolló para implementarse en el

sistemas cliente que utilizan empaquetadores e instaladores. Tras la instalación, el
software los archivos se alojarán en el sistema cliente. Los parches y
actualizaciones tienen que ser empujados a cada sistema cliente individual en el
que el software fue instalado. También hay un retraso de tiempo entre el momento
en que las características más nuevas del el software se desarrolla y el tiempo que
se pone a disposición de todos los usuarios del software. Este modelo de desarrollo
de software no solo requiere mucho tiempo, sino que también requiere muchos
recursos y costos.

Abordar los desafíos impuestos por el desarrollo de software tradicional e

implementación, el software está diseñado hoy para estar disponible como un
servicio hasta el final usuarios o clientes. En este modelo, los usuarios finales no
son los propietarios del software, pero pagan una regalía o una suscripción por usar
la funcionalidad comercial del software, en su totalidad o en partes. SaaS
generalmente se implementa mediante tecnologías web y la funcionalidad del
software se entrega a través de Internet. Por eso el SaaS El modelo también se
conoce como un modelo de software basado en la web, un modelo bajo demanda, o
un modelo de software alojado. Puede compararse con el modelo cliente / servidor
en el que el procesamiento se realiza en el lado del servidor, con algunas
distinciones. Una distinción es que el software pertenece y es mantenido por el
editor del software y el software está alojado en la infraestructura del proveedor de
servicios en la nube. Usuario final o Los datos del cliente también se almacenan en
el entorno de alojamiento del proveedor de servicios.
La tenencia múltiple en las arquitecturas de computación en la nube hace posible
base de código único para servir a varios inquilinos. Esta función de un código base
que sirve a todos

Requiere que la administración esté centralizada para todos los inquilinos y es

responsabilidad del proveedor de servicios de aplicaciones en la nube para
garantizar que su software sea confiable, resistente, y recuperable. Algunos de los
ejemplos más conocidos de implementaciones de SaaS son Salesforce.com, que es
un servicio en la nube de gestión de relaciones con los clientes solución, Google
Docs y los servicios Hosted Exchange de Microsoft.

Tras una inspección minuciosa de estos tres modelos de servicios en la nube,

encontrará que todos tienen que ver con responsabilidad o control. La mejor manera
de entender IaaS, PaaS y SaaS responde a la pregunta: "¿Quién es responsable de
(o quién tiene el control) y sobre qué " como se muestra en la Figura 3.27.

Tipos
Los cuatro tipos de nube son:

■ Nube pública
■ Nube privada
■ Nube comunitaria
■ Nube híbrida
En una nube pública, los proveedores de servicios en la nube brindan sus servicios
a múltiples inquilinos que no están relacionados. El inquilino tiene poco o ningún
control en la gestión de infraestructura, plataforma o recursos de software y está
completamente a merced de

el proveedor de servicios para garantizar operaciones seguras. Las nubes públicas

tienen el beneficio de costos iniciales reducidos porque solo paga por lo que usa,
fácil de escalar necesidades comerciales crecientes, sin costos de mantenimiento,
pero tiene el riesgo de falta de control ejemplos de esto incluirían el servicio Amazon
Elastic Cloud Compute, Google AppEngine, IBM Blue Cloud, Sun Cloud, etc.

A diferencia de la nube pública, en una nube privada, el proveedor de servicios en la

nube proporciona servicios en la nube para un solo inquilino. Las nubes privadas
suelen ser internas a una empresa y gestionadas por personal de la empresa. Esta
es la razón por la que la nube privada también se conoce como nube interna o
corporativa. El inquilino tiene el máximo control sobre los recursos de computación
en la nube en una nube privada pero puede ser difícil escalar y realizar una
inversión inicial para configurar la nube la infraestructura y las plataformas corren a
cargo del inquilino.

En una nube comunitaria, existe una tenencia múltiple como es el caso de una
nube, pero los inquilinos son entidades relacionadas como en el caso de una nube
privada. En este sentido, una nube comunitaria funciona más o menos como un
"intermedio" nube. Los inquilinos tienen requisitos comunes y las capacidades de
aseguramiento son construidas sobre estos requisitos. Los beneficios y riesgos
tanto del sector público como del privado son evidentes en una nube comunitaria.

Una nube híbrida combina dos o más de los tipos de nubes mencionados
anteriormente. Los controles y mecanismos de garantía se pueden gestionar de
forma más granular. Por ejemplo, la información privada y confidencial se puede
alojar en la nube privada, mientras que los datos relacionados con la industria del
inquilino se pueden alojar y con el servicio de una nube comunitaria. Estos cuatro
tipos de nubes se representan en Figura 3.28.

Características

El NIST define la computación en la nube como un modelo para permitir un acceso

de red conveniente y bajo demanda a un grupo compartido de recursos informáticos
configurables. (Por ejemplo, redes, servidores, almacenamiento, aplicaciones y
servicios) que pueden ser rápidamente provisionados y lanzados con un mínimo
esfuerzo de gestión o proveedor de servicios Interacción. Las cinco características
de la nube son:

1.En demanda auto servicio

2. Amplio acceso a la red
3. Mancomunidad de recursos
4. Elasticidad rápida
5. Servicio medido

Autoservicio bajo demanda: significa que los inquilinos pueden aprovisionar

recursos y aprovechar los servicios proporcionados por el proveedor de servicios en
la nube como y cuando sea necesario con interacción limitada o nula en el servicio
del lado del proveedor.

Amplio acceso a la red: significa que para la computación en la nube, la red la

conectividad a los servicios y aplicaciones en la nube backend está presente con
gran ancho de banda y estos servicios son accesibles a través de una red.

Agrupación de recursos: significa que los servicios de hardware y software

proporcionado por el servicio en la nube proporcionado es en forma de un grupo
compartido de recursos, para que se puedan dar servicio a varios inquilinos.
Elasticidad rápida: significa que los recursos agrupados compartidos se pueden
aprovisionar dinámicamente para un inquilino y eliminado cuando no es ya es
requerido por ese inquilino y reaprovisionado a otro inquilino quién necesita el
servicio en la nube. Servicio medido: significa que los servicios proporcionados por
la nube proveedor de servicios es monitoreado y medido automáticamente para que
al inquilino se le pueda cobrar solo por lo que usa.

Seguridad en la computación en la nube

Las amenazas a la computación en la nube son principalmente de los siguientes

tipos.

■ Divulgación, pérdida y / o permanencia de datos

■ Acceso no autorizado
■ Hombre en el medio y secuestro de tráfico
■ API inseguras y patentadas
■ Interrupciones del servicio
■ Personal malicioso (iniciados)
■ Abuso de la nube
■ Uso nefasto de recursos informáticos / tecnológicos compartidos
■ Debida diligencia insuficiente / Perfil de riesgo desconocido

Divulgación, pérdida y / o permanencia de datos

La principal amenaza en la computación en la nube es la divulgación de datos

alojados en la nube a personas o procesos no autorizados. A diferencia del caso de
las instalaciones informática, donde el propietario y el custodio de los datos suelen
ser personal que pertenecen a la misma empresa, la protección de datos en la nube
es una desafío porque el propietario de los datos es el inquilino mientras que el
custodio de los datos es el proveedor de servicios, que puede o no ser parte de la
misma empresa. Por lo tanto es imperativo verificar y validar la protección de datos
y los controles de acceso que afirma el proveedor de servicios. Si es posible, los
datos sensibles y privados no deben almacenarse en nubes públicas, comunitarias o
híbridas, y cuando lo esté, debería estar protegido criptográficamente. Cuando los
datos están encriptados, almacenamiento adicional será necesario planificar el
espacio y disponer de una gestión de claves. Uno aspecto de la gestión de claves
que es importante al diseñar criptográficos la funcionalidad en la nube es agilidad
criptográfica, asegurando que el algoritmo se puede cambiar fácilmente cuando sea
necesario y que la clave no esté codificada en el API en sí. La agilidad criptográfica
se cubre con más detalle en el software seguro Capítulo de implementación.

Aprendimos anteriormente que algunas de las características clave de los servicios

en la nube son agrupación de recursos y elasticidad rápida. Entonces, cuando un
recurso compartido (por ejemplo, una base de datos servidor) que aloja los datos de
un inquilino se aprovisiona a otro cliente, no es un potencial para la remanencia de
datos y la divulgación de los datos del primer inquilino para el inquilino posterior.
Esto se debe a que las técnicas de eliminación de datos para asegurar la
confidencialidad está limitada en la nube. Los datos de clasificación y etiquetado,
junto con las tecnologías de prevención de pérdida de datos (DLP) pueden ser útiles
para mitigar pérdida / fuga de datos, pero las estrategias de eliminación de datos
son necesarias para proporcionar protección contra amenazas de divulgación. Dado
que el recurso de hardware debe ser reaprovisionado, no se puede recurrir a la
desmagnetización del flujo magnético o destruir los medios de almacenamiento. La
única opción que queda es sobrescribir (formatear) que tiene el potencial de
remanencia de datos y eventual divulgación. La desinfección se cubre con más
detalle en Implementación segura, Operaciones, Capítulo Mantenimiento y
eliminación.

Acceso no autorizado

Junto únicamente a la garantía de confidencialidad, la necesidad de prevenir el

acceso es de suma importancia en la seguridad de la computación en nube. Esto se
convierte en crítico en una nube pública. Los servicios conectados y las aplicaciones
en la nube pueden conducir a resultados no deseados y acceso no autorizado. El
alcance de una brecha de seguridad generalmente no se limita a un solo inquilino,
sino a todos los inquilinos que comparten el mismo conjunto de recursos.

Cuando los datos y los sistemas se alojan en un entorno de nube de alojamiento

compartido, el acceso a los datos debe ser controlado y la privacidad de los datos y
la separación de datos deben ser extremadamente importante. El proveedor de
servicios debe estar obligado a demostrar la implementación de las normas de
China sin conflicto de intereses de Brewer & Nash modelo de pared. Esto significa
que el acceso a los datos de un inquilino no debe ser accesible por personas que
serían consideradas competidores de ese inquilino.

Esto se muestra en la Figura 3.29.

Las listas de control de acceso (ACL) y el fortalecimiento del sistema pueden ayudar
a mitigar amenazas de acceso no autorizado. También es importante tener en
cuenta que si Single Sign Activado (SSO) no se implementa teniendo en cuenta la
seguridad, puede provocar fallos autenticación y acceso no autorizado.

Hombre en el medio y secuestro de tráfico

Cuando la infraestructura, las plataformas y el software no son propiedad ni están

controlados por el propietario de los datos, la detección de cambios no autorizados
en ellos se convierte Más fuerte. Esta es la razón por la que los modelos de
computación en la nube son más atractivos para un atacante que tiene el interés y la
intención de realizar ataques MITM (secuestro).

Para mitigar la posibilidad de MITM, hay reglas de contraseña adecuadas que hacen
cumplir contraseñas seguras y su administración es útil. Las contraseñas seguras
son aquellas que no son susceptibles a ataques de diccionario o aquellas que no
pueden ser adivinadas fácilmente. Gestionar de forma segura las sesiones de
usuario y el cifrado de un extremo a otro de los canales de transporte que utilizan
SSL / TLS o IPSec también ayudan a mitigar MITM ataques que pueden provocar el
secuestro y la repetición de la sesión.
API inseguras y patentadas

Los servicios en la nube resumen y encapsulan la funcionalidad empresarial en un

contrato API basadas en descubrirlos e invocables. Cuando estas API son
inseguras, escanear y los ataques de enumeración, en los que un atacante puede
invocar API restringidas, pueden ser realizados. Algunos ejemplos de API inseguras
incluyen aquellas que usan texto claro autenticación, control de acceso inflexible y
proporcionar supervisión y capacidades de auditoría. Además de determinar la
seguridad de las API, es esencial comprender también la cadena de dependencia
de las API para que la seguridad as API no termine utilizando API inseguras.

Otro aspecto importante a considerar es el uso de productos personalizados, no

estándar, API propietarias del proveedor de servicios en la nube. Esto puede llevar
al proveedor dependencia y encierro. Por eso es importante realizar una devolución
de inversión (ROI) antes de seleccionar un proveedor de servicios en la nube que
requiera utilizar sus API patentadas.

Interrupciones de servicio

Uno de los conceptos centrales de la seguridad de la información es la

disponibilidad y la nube informática tiene un impacto directo en este concepto. En el
contexto de minimizar interrupciones del servicio y disponibilidad ininterrumpida,
mientras que uno puede argumentar que los ataques DoS y Distributed DoS (DDoS)
no tendrán un impacto significativo dado que el procesamiento se distribuye en la
nube, también se podría argumentar que el tiempo de inactividad del servicio en la
nube que está centralizado y utilizado por varios inquilinos puede causar el cierre de
las operaciones comerciales no solo para uno, sino para todos los inquilinos en la
nube. La centralización de los servicios en la nube presenta el potencial de una
punto de falla. También es fundamental reconocer que en este modelo de pago por
uso de informática, la responsabilidad de no prestar servicios a los clientes de los
inquilinos aún recae sobre el inquilino.

Además, un conocimiento profundo del SLA del proveedor de servicios es necesario

por la característica de servicio de medida de la nube. Anteriormente para elegir un
proveedor de servicios en la nube, es importante estimar la capacidad requisitos
para las crecientes necesidades de datos y comprender la redundancia y la
requisitos. Se deben comunicar los requisitos mínimos de tiempo de actividad
explícitamente al proveedor de servicios y acordado por el proveedor de servicios
utilizando un SLA.

Personal malicioso (iniciados)

El anonimato que es evidente en la arquitectura de la computación en la nube, en

comparación a la informática local, desafortunadamente trae consigo cierta latitud y
impunidad que puede inspirar a un infiltrado malintencionado a realizar actividades
nefastas y pasar desapercibido. Gestión de identidad con auditoría para asegurar el
no repudio es útil para detectar actividades de amenazas internas y disuadir a
algunos de realizar sus actos nefastos. Los posibles agentes de amenaza que son
externos o internos al inquilino, así como los iniciados que pertenecen al proveedor
de servicios, deben ser determinados.

En ningún momento se debe desconocer el perfil de riesgo del proveedor de

servicios. En otras palabras, los procesos internos, las tecnologías y las personas
involucradas en el desarrollo del servicio debe ser, en la medida de lo posible,
transparente para el inquilino. Controles administrativos como verificación de
antecedentes y verificación son vitales ya que los proveedores de servicios en la
nube tienden a utilizar terceros para sus necesidades de infraestructura, plataforma
y software. Dado que la probabilidad de realizar personalmente verificaciones de
antecedentes para el personal de cada proveedor de servicios o personal de
terceros asociado es un desafío, antes de la selección de una nube proveedor de
servicios, es aconsejable solicitar la prueba de fiabilidad a terceros pruebas
independientes de las partes o resultados de evaluación de criterios comunes.
Adicionalmente pedir al servicio que demuestre los controles internos sobre los
informes financieros puede ser necesario. La Declaración sobre Normas de
Auditoría (SAS) No. 70, comúnmente lo que se conoce como auditoría SAS 70 se
utiliza generalmente para este propósito. SAS 70 ahora será reemplazado por la
Declaración sobre los estándares para los trabajos de certificación (SSAE) No. 16,
que también se conoce como Informes sobre controles en una organización de
servicios. La Matriz de controles en la nube (CCM) que publica CSA proporciona
principios de seguridad fundamentales para guiar a los proveedores de servicios en
la nube de los controles que necesitan incorporar a sus ofertas de servicios. Se
necesita un enfoque basado en el riesgo para abordar las amenazas y
vulnerabilidades de la nube. También puede ser utilizado por el inquilino para servir
como criterio y marco común al evaluar a los proveedores de servicios.
Educación y capacitación de concienciación tanto del inquilino como del proveedor
de servicios el personal es muy eficaz para garantizar que los recursos de la nube
no se vean comprometidos fácilmente. Habilidades que se buscan para el personal
de desarrollo involucrado en la computación en la nube incluir la negociación del
contrato, la evaluación de riesgos del proveedor, el desarrollo seguro y operaciones
seguras.

Abuso de la nube

El abuso de la nube es el aprovechamiento de la infraestructura y / o servicio de la

nube para hacer algo que no estaba destinado a hacer. Aprovechando la
conectividad que viene con la nube, lanzar un ataque DDoS, propagar malware y
compartir software pirateado con relativa facilidad son algunos ejemplos de abuso
de la nube también aprovechando la potencia informática en la nube, un ataque
puede abusar del recurso en la nube para realizar actividades maliciosas, como
descubrir la clave utilizada para el cifrado mediante un servicio en la nube. Tal
descubrimiento sería relativamente más difícil para realizar utilizando una
computadora estándar aislada. Las empresas deben determinar los escenarios de
casos de uso (comportamiento normal de la nube) para su arquitectura de nube
implementan para que los casos de abuso (comportamiento anómalo y malicioso)
de la nube se pueda identificar y modelar las amenazas.

Uso nefasto de recursos informáticos / tecnológicos compartidos

La publicación "Top Threats to Cloud Computing" y "Notorious Nine" de Cloud

Security Alliance (CSA) se encuentran entre las principales amenazas, la amenaza
de uso nefasto de los recursos informáticos y explotaciones tecnológicas
compartidas. El uso de recursos informáticos incluye craqueo y / o software
malicioso (malware). Las vulnerabilidades de los hipervisores y la explosión de la
nube son ejemplos de problemas tecnológicos que deben abordarse.

El estallido de nubes es el concepto en el que uno tiene que salir de una de la nube
(interna) a una nube pública (externa) para manejar las demandas elevadas y carga
de trabajo, cuando uno se queda sin recursos informáticos. Clientes potenciales en
la nube a nubes híbridas.
Tecnologías de aislamiento en la nube que hacen que el Protocolo de Internet (IP) y
los medios direcciones de control de direcciones (MAC) de infraestructuras de nube
externas en uno se usen en ese estallido de nubes. Esto debe planearse y
diseñarse cuidadosamente para garantizar que la suplantación de IP y MAC no sea
posible. La comunicación entre las nubes externas e internas deben estar seguras y
protegidas. Hardening y el sandboxing de la infraestructura es importante para que
la plataforma y las hazañas sean más difíciles de hacer.

Debida diligencia insuficiente / Perfil de riesgo desconocido

Empresas que se suben al tren de la computación en la nube, únicamente desde el

punto de vista del ahorro de costes, sin tener en cuenta la nube medio ambiente y
los riesgos que conlleva pueden experimentar un impacto perjudicial a su marca y
continuidad de las operaciones comerciales, en caso de incumplimiento. Por lo
tanto, es crucial que las empresas que adoptan la nube hagan lo debido diligencia.
Deben comprender los términos contractuales, incluida la ejecución de esos
términos y cobertura de responsabilidad. En ningún momento el perfil de riesgo de
el proveedor de servicios en la nube sea desconocido, es decir, el proveedor interno
del servicio en la nube Los procesos de trabajo deben ser transparentes para el
inquilino y no ser como un negro. Caja para el inquilino. Un conocimiento profundo
de los proveedores de servicios en la nube implementación y proceso operativo,
conocimiento del personal y seguridad Se requiere metodología de desarrollo para
aplicaciones en la nube, antes de firmar el orden de compra. Además, las técnicas y
procesos mediante los cuales la nube provee al proveedor de servicios se asegurará
de que el inquilino no infrinja ningún cumplimiento. requisito, debe determinarse de
antemano.

Desafíos

La computación en la nube trae con sus beneficios y amenazas, algunos desafíos

que también son pertinentes para la seguridad de la información.

Uno de los principales desafíos con la adopción de la computación en la nube que

ver con la aplicabilidad del gobierno, las regulaciones, el cumplimiento y la
privacidad (GRC + P) en la nube. La incertidumbre en la aplicación de políticas de
seguridad en el el sitio del proveedor de servicios y la incapacidad para respaldar
auditorías de cumplimiento en la nube son consideraciones de seguridad
importantes que deben abordarse. La seguridad y las responsabilidades se
comparten entre el inquilino y el proveedor de servicios, pero con marcos de
gobernanza o regulatorios mínimos o nulos, la responsabilidad recae en la mayoría
parte del lado de los inquilinos. El inquilino es responsable de garantizar que los
niveles adecuados de protección (controles) están en su lugar y funcionando
eficazmente para proteger contra amenazas de computación en la nube. La
recomendación de mejores prácticas incluye el establecimiento contratos
ejecutables con el proveedor de servicios en la nube, evaluando periódicamente la
perfil de riesgo del proveedor, monitoreo continuo y realización de verificación y
actividades de validación para dar fe de las declaraciones de garantía del proveedor
de servicios.

Otro desafío que se evidencia en la nube está relacionado con la ciber forense. los
recopilación de evidencia física del entorno virtual en la nube, utilizando estática y
las herramientas forenses en vivo es un desafío. Esto se debe principalmente a la
rápida elasticidad característica de la nube. Los recursos (por ejemplo, espacio en
disco, memoria, etc.) que se aprovisionan a su empresa hoy pueden ser
provisionados a otra persona inquilina en el futuro, lo que hace inviable conservar
registros de auditoría que son un importante en las investigaciones cibernéticas.

Además, no tener un conocimiento completo de la infraestructura subyacente en el

modelo de servicio IaaS puede hacer que sea extremadamente difícil para un
cyberforensic investigador para recopilar pruebas después de una violación de
seguridad. El contenido y el IDS deben tener en cuenta los registros tanto del
inquilino como del proveedor de servicios al realizar análisis forenses en la nube.
Para manejar la seguridad de manera efectiva incidentes, es necesaria la
visualización de ubicaciones de datos físicos y lógicos.

Además, vale la pena mencionar que, dado que la nube influye tanto el gobierno
como la industria privada, una asociación entre estos dos sectores, pueden ser
necesarios para abordar eficazmente los desafíos y preocupaciones de seguridad
en las nubes.

Es probable que la computación en la nube sea la forma en que se ofrecerán los

servicios de TI en el futuro y si no se dan las consideraciones de seguridad
apropiadas al diseñar arquitecturas y soluciones de computación en la nube, los
beneficios que la computación en la nube trae podría ser rápidamente anulado y ser
perjudicial para la continuidad de operaciones de negocios.
Aplicaciones móviles

Con la prevalencia de las aplicaciones móviles (generalmente denominadas

aplicaciones móviles) en el espacio informático de TI actual, los piratas informáticos
están comenzando a apuntar al espacio móvil y explotar aplicaciones y protocolos
inseguros que operan en dispositivos móviles (por ejemplo, teléfonos inteligentes,
tabletas, etc.). No hay escasez de informes de seguridad que publican que el
panorama de amenazas está cambiando, o ya ha cambiado, para incluir agentes de
amenazas que tienen como objetivo comprometer la seguridad de las aplicaciones
móviles.

En la sección informática generalizada, aprendimos la importancia de seguridad del

dispositivo y amenazas y controles cubiertos que vienen con BYOD e Iniciativas
CYD en empresas. En esta sección, nos centraremos en la aplicación móvil
arquitectura y los riesgos de seguridad que surgen de un diseño, desarrollo inseguro
e implementación de aplicaciones móviles.

Entender la arquitectura de la aplicación móvil y el tipo de datos que procesa la

aplicación móvil, nos permite ser capaces de modelar amenazas móviles
aplicaciones e identificar agentes de amenazas y controles de mitigación apropiados
cuando aplicaciones de desarrollo que se ejecutan en sistemas operativos móviles.

Arquitectura

La mayoría de las aplicaciones móviles se pueden clasificar en dos categorías

principales: delgadas clientes o clientes gruesos. Los clientes habituales son algo
que se conoce como clientes "ricos". Su arquitectura generalmente se puede dividir
en los siguientes componentes - Software de cliente frontend, comunicaciones de
middleware y soporte de backend (o servidor) infraestructura. Los clientes ricos son
aquellos en los que el negocio y los datos de los componentes de la capa se alojan
en el propio dispositivo cliente frontend. Los clientes delgados se caracterizan por
tener sus componentes de capa de datos y de negocio en la infraestructura de
soporte backend.

Las arquitecturas de aplicaciones móviles suelen tener los siguientes componentes

como parte de su diseño.
■ Hardware del cliente (celular, GPS, sensor, pantalla táctil, cámara, etc.)
■ Software de cliente (sistema operativo, tiempo de ejecución de VM, aplicación
móvil, etc.)
■ Interfaces (NFC, RFID, 802.11x, Bluetooth, etc.)
■ Endpoints (tiendas de aplicaciones, sitios web / servicios, corporativos, etc.)
■ Redes de operadores (voz, datos, SMS, etc.)
■ Almacenamiento de datos (local, en la nube, flash, extraíble, etc.) y
■ Transmisión de datos

La figura 3.30 muestra una arquitectura de aplicación genérica para una aplicación
móvil

Tipos

Los diferentes tipos de aplicaciones móviles que se utilizan predominantemente en

la actualidad incluyen:
■ Aplicaciones nativas
■ Aplicaciones basadas en navegador
■ Aplicaciones móviles de Internet enriquecidas
■ Aplicaciones híbridas

Las aplicaciones móviles nativas se caracterizan por estar instaladas en el

dispositivo cliente sí mismo. El código se implementa en el dispositivo cliente.
Generalmente se han limitado a no hay conectividad con la infraestructura de
soporte de backend y, por lo tanto, confían ampliamente en bases de datos locales
para sus necesidades de almacenamiento. Las aplicaciones basadas en el
navegador están basadas en la web Aplicaciones móviles a las que se puede
acceder mediante navegadores (por ejemplo, Safari, Chrome, etc.) que están
instalados en el propio dispositivo cliente. Son similares a las tradicionales
aplicaciones web de escritorio. Las aplicaciones móviles de Internet enriquecidas se
implementan en el cliente dispositivo, pero aprovechan la infraestructura de soporte
de backend ampliamente utilizando tecnologías de la comunicación. Una capa de
servicio que generalmente se implementa mediante SOAP o REST se utiliza para
comunicarse entre la aplicación en el dispositivo y los servicios backend
proporcionados por la infraestructura de soporte móvil. Híbrido aps son como una
mezcla entre aplicaciones nativas y aplicaciones basadas en navegador. La propia
aplicación aloja un navegador y el usuario interactúa con la funcionalidad de la
aplicación a través del navegador alojado dentro de la aplicación nativa.

SO móvil

Un sistema operativo móvil (comúnmente conocido como SO móvil) es el software

que se ejecuta en dispositivos móviles digitales como teléfonos inteligentes, tabletas
y personal asistentes digitales (PDA). Además de estos sistemas operativos
móviles, los dispositivos móviles ejecutan la aplicación diseñada por el arquitecto y
programador móvil. El sistema operativo móvil actual aumenta las funciones de un
sistema operativo de computadora personal con el usuario experiencia (por ejemplo,
pantallas táctiles, reconocimiento de voz, grabadoras de voz, reproductores de
música, cámaras), tecnologías de radio celular (por ejemplo, GSM, LTE, CDMA),
inalámbrica (por ejemplo, WiFi, Bluetooth, NFC) y capacidades de navegación (por
ejemplo, geolocalización, GPS).

Los sistemas operativos móviles más populares son de código cerrado y

propietarios en naturaleza, pero hay algunos como el sistema operativo Android de
Google y el sistema operativo Firefox de los Mozilla que son de código abierto y
populares están bien. Ejemplos de popular cerrado el SO móvil de origen propietario
incluye iOS de Apple, BlackBerry OS de Research In Motion y el sistema operativo
Windows Phone de Microsoft.

Una cobertura completa y completa de cada sistema operativo móvil está más allá
del alcance de este libro. Sin embargo, al diseñar aplicaciones móviles, es
imperativo reconocer que el sistema operativo móvil en el que se ejecutará la
aplicación móvil, puede tener impacto significativo en la seguridad de la propia
aplicación móvil. Es importante comprender y estar familiarizado con las
capacidades y debilidades de seguridad inherentes del sistema operativo móvil para
crear seguridad dentro de la propia aplicación o usar MDM para administrar
aplicaciones de terceros en el dispositivo. Por ejemplo, iOS tiene una función
multitarea conocida como fondo. En segundo plano de iOS, iOS toma una captura
de pantalla de la aplicación antes de minimizar para que se ejecute en segundo
plano, por razones de experiencia del usuario como una animación rápida cuando
se vuelve a activar la aplicación. Sin embargo, cuando esto ocurre, es importante
asegurarse de que ningún dato sensible que se presenta en la pantalla se captura
en la captura de pantalla.

Seguridad en aplicaciones móviles

La aplicabilidad o inaplicabilidad de las amenazas depende directamente de cómo la

aplicación móvil está diseñada. Por ejemplo, a diferencia del caso de una aplicación
móvil de Internet, una aplicación móvil nativa es menos susceptible a ataques que
explotan los protocolos de comunicación. Móvil basado en navegador las
aplicaciones son relativamente más susceptibles a las vulnerabilidades web
tradicionales además de las amenazas que vienen con casos de uso móvil y
debilidades de dispositivos.

Las amenazas a las aplicaciones móviles provienen principalmente de humanos

malintencionados y / o programas maliciosos. Los agentes de amenazas humanas
provienen de una variedad de usuarios, los perfiles van desde los propietarios
descuidados que pierden sus dispositivos móviles hasta el infame ladrón que
pretende robar dispositivos móviles y los datos que contienen.
También se sabe que los usuarios no informados instalan inadvertidamente
aplicaciones en sus dispositivos. Los programas maliciosos van desde malware que
se instala en el dispositivo cliente hasta scripts maliciosos que se ejecutan en los
navegadores operando en dispositivos móviles. Además, programas maliciosos que
impactan protocolos de comunicación y redes de operadores, como mensajes cortos
maliciosos También se observan los servicios (SMS).

Las amenazas a las aplicaciones móviles son principalmente de los siguientes tipos.
■ Divulgación de información
■ Denegación de servicio móvil (DoS) y DoS distribuido
■ Autenticación rota
■ Eludir la autorización
■ Gestión de sesiones inadecuada
■ Inyección del lado del cliente
■ Jailbreak y Sideloading
■ Malware móvil

Divulgación de información

La preocupación de seguridad predominante en las aplicaciones móviles está

relacionada con la divulgación. La información confidencial o privada puede ser
revelada debido a uno o más de los siguientes razones:

Dispositivos perdidos o robados

El tamaño de los dispositivos móviles los hace más propensos a la pérdida y al robo
físico. Esta es una de las principales razones para la divulgación de información.
Cuando es móvil las aplicaciones están diseñadas, es importante diseñar en
capacidades de "borrado remoto" para mitigar las amenazas de divulgación cuando
el dispositivo se pierde o es robado.

Almacenamiento de datos inseguro en bases de datos locales o en la nube

Además del robo del dispositivo en sí, también se roban los datos almacenados en
los dispositivos móviles (almacenamiento local del lado del cliente). Las bases de
datos locales en la mayoría de los sistemas operativos móviles no están tan
maduras como sus contrapartes de escritorio en lo que respecta a las capacidades
de garantía de confidencialidad, como el cifrado.
Las bases de datos en la nube, especialmente en las redes de hospedaje
compartido, son susceptibles a la fuga de datos debido a la falta de separación y
remanencia de datos en los recursos de hardware reaprovisionados. Lo ideal es que
no se almacenen datos confidenciales sin protección de forma local en el cliente o
en bases de datos públicas y, cuando lo estén, no se deben almacenar de forma
indefinida. Además, es importante identificar y proteger los datos confidenciales en
el dispositivo móvil.

Protección insuficiente de la transmisión de datos

Falta de cifrado de extremo a extremo y protección criptográfica de datos en
movimiento entre el dispositivo móvil y la red del operador o entre un dispositivo y
otro, puede conducir a ataques de olfateo y tapping, que se sabe que conducen a la
divulgación de información de aplicaciones móviles. Los datos deben transmitirse
utilizando únicamente canales de comunicación seguros. Ejemplos de comunicación
segura los canales incluyen TLS, SSL e IPSec.

Criptografía rota

La criptografía personalizada y la codificación de claves en el código de la aplicación

móvil son conocidos por conducir al descubrimiento de claves que pueden conducir
al descifrado de texto cifrado. Para mitigar el problema de la criptografía rota, se
recomienda utilizar La plataforma proporcionó API de cifrado en lugar de escribir las
suyas personalizadas. En algunos casos, puede ser necesario aprovechar las API
de cifrado de terceros para abordar debilidades inherentes, como un PIN de cuatro
dígitos, en el cifrado del editor, como como clave vinculada a la contraseña del
dispositivo del usuario. Como parte de la gestión de claves, los contenedores deben
aprovecharse en lugar de grabar la clave en el código de la aplicación.

Fuga de datos del canal lateral

La fuga de datos del canal lateral ocurre cuando los datos confidenciales y privados
provienen de ubicaciones como cachés web, directorios temporales, archivos de
registro, capturas de pantalla, etc.
Divulgada a personas y programas no autorizados. Estas ubicaciones inesperadas y
no comunes se denominan generalmente "canales laterales". Cierta aplicación
acciones como el fondo de iOS en aplicaciones multitarea y acciones humanas
como la ruptura de la cárcel y el registro de pulsaciones de teclas pueden llevar a la
divulgación del canal lateral de información que debe mantenerse en secreto.

Para mitigar las fugas de datos del canal lateral en la aplicación móvil, las cachés
deben estar cifradas y se deben utilizar directivas anti-caché para aplicaciones
basadas en navegador los canales de comunicación deben ser auditados para
asegurar que no haya fugas. La información confidencial, como las credenciales,
nunca debe registrarse. Sensible la información debe eliminarse de las vistas antes
de que la aplicación pase a la antecedentes como parte del proceso de creación de
antecedentes. Además, el registro de pulsaciones de teclas por campo debe estar
deshabilitado. También se recomienda depurar la aplicación móvil para comprender
los archivos que se crean, escriben o modifican cuando se ejecuta la aplicación.
Ingeniería inversa
(Descompilación, depuración, desmontaje)

Al ejecutar la aplicación móvil a través del descompilador, depurador o

desensamblador, información sensible como contraseñas, claves API y arquitectura
interna de la aplicación móvil puede someterse a ingeniería inversa.

Para mitigar las amenazas de ingeniería inversa, el código de la aplicación se puede

ofuscar. Además, no se debe almacenar información confidencial en el binario de la
aplicación y mantener la información de propiedad exclusiva del cliente.

Denegación de servicio móvil (DoS) y DoS distribuido (DDoS)

Las amenazas a la disponibilidad de las aplicaciones móviles parecen ir en aumento

y se ha observado que los dispositivos móviles son relativamente fáciles de usar
como plataformas de lanzamiento para ataques DoS y DDoS móviles. Lanzar
ataques DDoS requiere habilidades técnicas y de programación significativamente
menores que los ataques DDoS tradicionales, como fue evidente en el rediseño de
la herramienta DoS Low Orbit Ion Cannon (LOIC) en un PUP que afectó a la
plataforma Android. Todo lo que se necesitaba en el rediseño de la herramienta
LOIC DoS era una URL web activa LOIC que no requería conocimientos de
programación. También se sabe que los ataques DDoS móviles aprovechan la
funcionalidad de la red del operador, lo que provoca congestión y, finalmente, DoS
en la red del operador. El malware Android.DDoS.1.origin se disfrazó como una
aplicación legítima de Google Play, pero en el backend estableció comunicación con
un servidor controlado por el hacker. Permaneció inactivo, esperando recibir
instrucciones vía SMS.
Cuando el SMS se envió al dispositivo móvil infectado, se identificó la información
de configuración del dispositivo, como el servidor y el puerto, a los que se enviaron
los paquetes, lo que bloqueó la aplicación, inundó el dispositivo y la red, provocando
un DoS.
Uno de los servicios que vienen con las tecnologías de aplicaciones móviles son las
notificaciones automáticas. Todos los principales sistemas operativos móviles tienen
notificaciones automáticas como parte de la tecnología que admiten. Estos
servidores se conocen como servidores de notificaciones push (PNS). Las
notificaciones automáticas se pueden usar para enviar noticias, actualizaciones de
aplicaciones, solicitudes y avisos a los usuarios. Sin embargo, el diseño inadecuado
y la falta de defensa en los controles de profundidad pueden conducir a ataques de
inundación de notificaciones automáticas que afectan el concepto de seguridad de
disponibilidad. Los servicios de notificaciones push también permiten presentar un
mensaje falso al usuario, haciéndoles creer que el malware móvil que se les pide
que instalen es una actualización legítima que se envía al dispositivo.

Autenticación rota

Las credenciales de autenticación en la arquitectura de aplicaciones móviles son

especialmente susceptibles a la divulgación, el robo y la reproducción. El diseño
inseguro y el código inseguro son la causa raíz de los problemas de autenticación
rotos en las aplicaciones móviles. El uso de la autenticación básica, en la que las
credenciales se transmiten en un formato codificado Base-64 fácilmente
decodificable, se observa ampliamente en las arquitecturas móviles que aprovechan
los servicios SOAP. Además, las credenciales, como la contraseña, generalmente
se almacenan en texto no cifrado en el propio dispositivo y se presentan a los
servicios de back-end en cada solicitud. Esto puede dar lugar a la divulgación no
autorizada de información confidencial a cualquiera que tenga acceso al dispositivo.
Además, las aplicaciones móviles que utilizan datos estáticos, como los
identificadores únicos universales (UUID) del dispositivo, la identificación
internacional de equipos móviles (IMEI) o los identificadores de suscriptor, como la
identificación internacional de suscriptor móvil (IMSI), como su único medio de
autenticación, pueden falsificarse fácilmente. IMEI se utiliza para identificar un
dispositivo físico. IMSI se utiliza para identificar una tarjeta del módulo de
identificación del suscriptor (SIM) en el dispositivo.
Si las credenciales se mantienen en el dispositivo del cliente, para mitigar los
problemas de autenticación rota, se recomienda almacenar esas credenciales solo
en forma criptográficamente protegida en almacenes seguros de claves. Otro control
de autenticación seguro es superponer la verificación de autenticación y no
depender de una sola fuente para la autenticación. No utilice datos fáciles de
determinar o falsificados (p. ej., ID de dispositivo/ID de suscripción) como único
autenticador. Además, el diseño de la aplicación no debe evitar exigir que el usuario
se vuelva a autenticar con frecuencia porque es mejor prevenir ahora que
disculparse más tarde, incluso si esto conlleva cierta frustración en nombre del
usuario. Implemente el principio de diseño seguro de mediación completa y
autentique todas las llamadas API a recursos y/o servicios. Nunca ignore las
advertencias de validación de certificados.

Omitir la autorización

Además de la autenticación rota, los problemas de autorización también son

evidentes en aplicaciones móviles. Un exploit común en la autorización incluye el
explotación de los controladores de protocolo URL mediante la creación de una URL
que puede lanzar otras aplicaciones, como correo, teléfono, Skype, texto, mapas,
etc., en el dispositivo sin el permiso explícito del usuario. Los controladores de
protocolo de URL se conocen como esquemas URL en iOS y como intent en la
plataforma Android. La figura 3.31 ilustra cómo engañar a un usuario haciéndole
creer que está llamando al número de un banco para verificar una actualización de
la cuenta, mientras que la URL creada maliciosamente invoca el teléfono aplicación
en un dispositivo iOS para llamar a un número de servicio de citas 900.

La figura 3.32 también hace algo similar, pero en lugar de abrir la aplicación en el
dispositivo y solicitar al usuario que llame al número, se abre la aplicación de Skype
y sin el consentimiento del usuario realiza la llamada al número falso.

Estos ejemplos aprovecharon un vector de correo electrónico para enviar la

información creada con fines malintencionados URL, pero lo mismo se puede
realizar mediante la inyección de iframe HTML en sitios web, a los que los usuarios
desprevenidos pueden navegar, utilizando los navegadores en su dispositivos
móviles. También se sabe que los atacantes eluden la autorización para pago de
cargos nefastos para aplicaciones sin el consentimiento del usuario cuando las
aplicaciones móviles almacenan de forma insegura el titular de la tarjeta y la
información de pago en el propio dispositivo.
Eludir las verificaciones de licencias es otro problema de autorización evidente en
las aplicaciones de dispositivos.

Por tanto, es importante asegurarse de que se soliciten permisos de usuario

explícitos y que la aplicación móvil no está diseñada para tomar decisiones de
seguridad implícitamente confiando en esquemas de URL o código de invocación de
intención. Además, la aplicación debe estar diseñada para verificar modalmente los
permisos en los límites de entrada para hacer cumplir reglas de autorización.
Gestión incorrecta de sesiones

Debido a que las aplicaciones móviles generalmente tienden a operar en entornos

heterogéneos (por ejemplo, redes de empresas privadas, redes públicas, redes de
operadores, etc.), la gestión de tokens, tanto tokens de sesión de usuario como
tokens de autenticación, es un desafío. Los mecanismos comunes mediante los
cuales la mayoría de las aplicaciones móviles administran sesiones son: cookies
HTTP, tokens de autenticación abierta (OAuth) y servicios de autenticación SSO,
que son todos susceptibles a los ataques Man-in-the-Middle (MITM). La prevalencia
de los ataques de interceptación de sesiones ha llevado a la acuñación del término
Man-in-the-Mobile (MITMo). Los ataques MITMo hacen posible que los piratas
informáticos intercepten y reproduzcan tokens de sesión. Dado que a menudo
aprovechan el malware instalado en el dispositivo móvil para interceptar y reproducir
capacidades, MITMo también puede denominarse Malware-In-The-Mobile.

Los canales de comunicación seguros entre dispositivos y entre el dispositivo y los

puntos finales mitigan algunos de los ataques de reproducción y secuestro de
sesiones. Asegúrese de que los tokens (autenticación y sesión) estén protegidos
durante la transmisión. La protección de la propia red del operador y los datos que
se transmiten a través de Wi-Fi y NFC deben estar en su lugar. Los controladores de
tokens de sesión deben configurarse para ejecutarse con niveles mínimos de
privilegios. Las verificaciones de transacciones en lugar de solo la verificación de
contraseñas se pueden usar para aliviar los ataques de MITMo. En un sistema de
verificación de transacciones, el usuario recibirá un código único que deberá
ingresar para continuar con la transacción. Este código único se envía mediante un
canal de transporte fuera de banda (por ejemplo, mensajes de texto SMS) al
dispositivo móvil y está vinculado específicamente a una transacción. De esta
manera, cualquier malware que intente enviar una transacción fallará a menos que
el código único específico de la transacción en el mensaje de texto SMS también
sea interceptado y la transacción esté activa. Además, al igual que en el caso de los
tokens de autenticación, el identificador del dispositivo que se puede determinar o
falsificar fácilmente nunca debe usarse como tokens de sesión. Del mismo modo, se
recomienda el uso de tokens de sesión no persistentes. Al generar tokens de
sesión, se recomienda utilizar una alta entropía en su generación, de modo que
estos tokens no se puedan adivinar fácilmente. Finalmente, asegúrese de que los
tokens de sesión se puedan revocar y abandonar con la misma rapidez,
especialmente en caso de pérdida o robo de un dispositivo.
Inyección del lado del cliente

Una de las principales amenazas para las aplicaciones y dispositivos móviles es la

inyección del lado del cliente. Los ataques de inyección en el lado del cliente no son
exclusivos de las arquitecturas móviles, pero sí ciertamente muy frecuente en las
aplicaciones móviles. Algunos investigadores de seguridad sienten que cuando uno
piensa en proteger las aplicaciones móviles, uno de los primeros ataques que
debería pensar, solo superado por los dispositivos perdidos o robados, es la
inyección en el lado del cliente. Los ataques de inyección en el lado del cliente son
esencialmente ataques de inyección de código que se manifiestan ellos mismos
como Injection Flaws, con una gran diferencia. A diferencia de la inyección defectos
(por ejemplo, inyección SQL, inyección de comandos del sistema operativo,
inyección LDAP, etc.), el código se envía al cliente en lugar de al servidor. Inyección
de código del lado del cliente Los ataques a aplicaciones móviles se pueden
considerar como una variante del Web DOM basado Ataques de Cross-Site
Scripting (XSS), donde el script que se inyecta se refleja de nuevo en el cliente, sin
ser enviado al servidor. Bases de datos que son alojados en el propio dispositivo
(por ejemplo, SQLite) puede verse comprometido a través del lado del cliente
mediante ataques de inyección. El código inyectado no es manejado correctamente
por el móvil app, lo que lleva a la inyección de código. El manejo inadecuado del
código significa que el código inyectado no se desinfecta y se interpreta como un
comando.

Un control de mitigación primario contra los ataques de inyección del lado del cliente
es la entrada validación, es decir, los datos proporcionados por el usuario se
desinfectan y se vuelven inofensivos. Si la arquitectura lo admite, es recomendable
utilizar de forma segura el almacenamiento en la nube sobre las bases de datos del
lado del cliente para los requisitos de almacenamiento, lo que evita ataques de
inyección del lado del cliente en almacenes de datos. La concienciación y la
educación del usuario contribuyen en gran medida a reducir los ataques de
inyección en el lado del cliente porque un usuario que está educado para nunca
confiar en el cliente tiene menos probabilidades de ser víctima de una inyección del
lado del cliente a diferencia de uno que no lo es móvil Los probadores de
aplicaciones deben verificar y validar que todas las entradas a la aplicación estén
desinfectadas y que la salida de la aplicación se codifica en sus formas no
ejecutables. Diseñando la aplicación móvil para aprovechar las bibliotecas del
navegador que brindan desinfección, validación y se recomienda la codificación, ya
que estas bibliotecas se pueden actualizar con una validación más reciente en
reglas y todas las aplicaciones móviles que las utilizan pueden beneficiarse del
cambio, en lugar de tener que realizar cambios en cada aplicación móvil. El uso de
declaraciones preparadas y se recomiendan procedimientos almacenados para
consultar y manipular datos para que el código inyectado no se concatena
dinámicamente para convertirse en parte del sintaxis de consulta. También es
recomendable validar todos los datos que se reciben o envían a aplicaciones de
terceros y para comprobar si hay errores en la interpretación del código en tiempo
de ejecución o exploits.

Jailbreak y Sideloading

Casi todos los sistemas operativos móviles son susceptibles de ser liberados. Un
dispositivo con jailbreak es uno que se manipula y modifica para que pueda instalar
aplicaciones y software que generalmente no está autorizado por el fabricante del
dispositivo de hardware o el operador de telefonía móvil.

El proceso de manipulación del sistema operativo móvil se conoce como Jailbreak

aprovecha las vulnerabilidades de seguridad en el propio sistema operativo móvil. El
jailbreak es aplicable a sistemas operativos móviles patentados de código cerrado.

Por otro lado, la carga lateral se observa en sistemas operativos móviles de código
abierto, predominantemente el sistema operativo Android. La descarga lateral
permite al usuario instalar software en su dispositivo sin pasar por los métodos
oficiales de distribución de aplicaciones como el Android Market. Es un ajuste de
configuración en el sistema operativo Android que el usuario puede configurar, pero
cuando se permite la descarga lateral, tiene ciertos riesgos que ven con él.

Mientras que el jailbreak y la descarga lateral traen consigo algo de libertad, trae
con ello el potencial de riesgos mucho mayores. Los riesgos incluyen:

■ Estabilidad disminuida - Esto puede variar por mala memoria

administración o disminución de la duración de la batería como aplicación con
jailbreak y descarga lateral los desarrolladores generalmente no siguen prácticas de
codificación buenas o seguras.

■ Garantía anulada - La mayoría de los fabricantes de dispositivos móviles no

admite dispositivos con jailbreak y, por lo tanto, el dispositivo debe requerir algunos
reparaciones de hardware, puede que no sea posible.
■ Dispositivo "bloqueado": un dispositivo bloqueado es aquel que se ha fabricado
completamente inutilizable y no restaurable, incluso con recarga y / o reinstalación
de software. Cuando el exploit de jailbreak no es completamente probado, puede
provocar que los dispositivos móviles se bloqueen y el proceso generalmente se
conoce como ladrillo. Los ladrillos impactan la disponibilidad del concepto de
seguridad.
■ Bloqueo: los propietarios de dispositivos con jailbreak no suelen estar autorizados
para acceder a las tiendas de distribución de software oficiales para obtener sus
aplicaciones. En su lugar, tienen que depender de una distribución digital alternativa.
centros/aplicaciones que están instaladas en el dispositivo con jailbreak para
obtener software adicional o recurrir a la descarga lateral. Las aplicaciones de carga
lateral no se someten al riguroso escrutinio y escaneo en busca de malware que se
proporciona en el método de distribución de la aplicación oficial. Cydia es un
ejemplo de una alternativa a la App Store de Apple.

Cuando un dispositivo móvil tiene jailbreak, realmente no hay grado de confianza en

que se puede colocar en el dispositivo y se sabe que los rootkits y el malware no
solo infectar el dispositivo en sí, sino convertirlos en botnets mediante la conexión a
un centro de mando y control e instrucciones de descarga.

Las empresas deben, como parte de la estrategia MDM, prohibir el uso de jailbreak
dispositivos que se conectan e interactúan con la infraestructura de la empresa,
para mitigar el riesgo de que el malware ingrese a la red de la empresa. Si lo haces
tiene la necesidad de hacer jailbreak al dispositivo, entonces es mejor que cambie la
raíz contraseña en el dispositivo con jailbreak para que sea menos explotable por
piratas informáticos.

Malware móvil

Las aplicaciones maliciosas en las tiendas de aplicaciones y los mercados están en

aumento. El desarrollo de malware móvil que compromete las debilidades de NFC,
que bloquea las actualizaciones a dispositivos móviles y extorsionar a las víctimas,
de forma clandestina o coercitiva (ransomware), es cada vez más frecuente.
Desarrollo de telefonía móvil los kits facilitan a los piratas informáticos que ni
siquiera conocen la programación de aplicaciones móviles Desarrollar malware
móvil “hágalo usted mismo” (DIY) y realizar actividades nefastas.
El malware móvil es probablemente el mayor riesgo para los dispositivos con
jailbreak. Aunque la legalidad del jailbreak tiene diferentes opiniones, lo que debe
ser entendido es que los exploits que se pueden utilizar para hacer jailbreak a un
dispositivo también pueden ser utilizado para instalar rootkits y malware en el
dispositivo. El gusano Ikee y el Duh el malware son ejemplos de malware móvil que
infecta dispositivos móviles con jailbreak ejecutándose en la plataforma iOS. Las
aplicaciones troyanas pueden disfrazarse de legítimas las aplicaciones y los
usuarios pueden ser engañados haciéndoles creer que están instalando algo
legítimo e inocuo al instalar malware móvil.

Los dispositivos con jailbreak son particularmente más susceptibles al malware

móvil porque las aplicaciones que están instaladas no pasan por la validación de
seguridad y verificación como las aplicaciones que se colocan en los canales de
distribución oficiales (por ejemplo, Tienda de aplicaciones). Las aplicaciones de
carga lateral que están instaladas en el dispositivo se rastrean como unas que
tienen "fuentes desconocidas" y el software malicioso se puede instalar más
fácilmente a través de carga lateral.

Directrices de desarrollo seguro y principios de diseño

Las pautas de desarrollo seguro de teléfonos inteligentes para desarrolladores de

aplicaciones, publicadas por la Agencia Europea de Seguridad de las Redes y de la
Información (ENISA) proporciona alguna guía prescriptiva para desarrolladores de
aplicaciones móviles. Los puntos principales son enumerados a continuación:

■ Identificar y proteger datos confidenciales en el dispositivo móvil

■ Manejar las credenciales de contraseña de forma segura en el dispositivo
■ Asegúrese de que los datos confidenciales están protegidos en tránsito
■ Implementar la autenticación, autorización y sesión de usuarios
gestión correcta
■ Mantenga seguras las API de backend (servicios) y la plataforma (servidor)
■ Integración segura de datos con aplicaciones y servicios de terceros
■ Preste especial atención a la recopilación y almacenamiento del consentimiento
para
la recopilación y el uso de los datos del usuario.
■ Implementar controles para evitar el acceso no autorizado a pagos
recursos (por ejemplo, billetera, SMS, llamadas telefónicas, etc.)
■ Garantizar la distribución / aprovisionamiento seguro de aplicaciones móviles
■ Verifique cuidadosamente cualquier interpretación del código en tiempo de
ejecución para detectar errores
Una cobertura completa de la guía está más allá del alcance de este libro, pero es
mejor que un CSSLP esté familiarizado con el desarrollo seguro de directrices y
principios de diseño publicados por ENISA junto con OWASP.

Integración con arquitecturas existentes

Hemos discutido diferentes tipos de arquitecturas de software y los pros y los

contras de cada uno. A menos que estemos desarrollando software nuevo, no
empezamos a diseñar toda la solución de nuevo. Nos integramos con la arquitectura
existente cuando existen versiones de software. Esto reduce el reproceso de
manera significativa y apoya el principio de aprovechar los componentes existentes.
Integración con componentes heredados también puede ser la única opción
disponible como medida de ahorro de tiempo o cuando sea pertinente
especificaciones, código fuente y documentación sobre el sistema existente no son
disponible. No es inusual envolver los componentes existentes con una nueva
generación envoltorios. La programación de fachada hace posible dicha integración.
Cuando las arquitecturas más nuevas están integradas con las existentes, es
importante determinar que se mantengan la compatibilidad y la seguridad con
versiones anteriores. Componentes escritos operar de forma segura en una
arquitectura puede disminuir su protección cuando se integra con otro. Por ejemplo,
cuando el nivel de lógica empresarial que realiza el acceso las decisiones de control
en una arquitectura de 3 niveles se abstraen utilizando interfaces de servicios como
parte de una implementación de SOA, las decisiones de autorización que estaban
restringidas al nivel de lógica empresarial ahora se puede descubrir e invocar. Por lo
tanto, es fundamental asegurarse de que la integración de arquitecturas nuevas y
existentes no eludir o reducir los controles o mecanismos de protección de
seguridad y mantiene compatibilidad con versiones anteriores, al tiempo que reduce
el reproceso.

Tecnologías

La seguridad holística, como se mencionó anteriormente, incluye un componente

tecnológico, además de las personas y los componentes del proceso. El principio de
diseño seguro de aprovechar los componentes existentes no se aplica sólo a los
componentes de software, sino también a las tecnologías. Si existe una tecnología
existente que se pueda utilizar para proporcionar funcionalidad empresarial, se
recomienda utilizarlo. Esto no solo reduce el reproceso, pero también tiene
beneficios de seguridad. Las tecnologías probadas se benefician de un mayor
escrutinio de las características de seguridad que las implementaciones
personalizadas. Además, las implementaciones personalizadas potencialmente
pueden aumentar el ataque superficie. En la siguiente sección, cubriremos varias
tecnologías que pueden ser apalancados, sus beneficios de seguridad y cuestiones
a considerar al diseñar software para estar seguro.

Autenticación

El proceso de verificar la autenticidad de un objeto o la identidad de un usuario es

autenticación. Esto se puede hacer mediante tecnologías de autenticación. En el
capítulo conceptos de software seguro, cubrimos las diversas técnicas mediante las
cuales se puede lograr la autenticación. Estos iban desde probar la identidad
utilizando algo que uno sabe (basado en conocimiento), como nombre de usuario y
contraseña / frase de contraseña, para usar algo que uno tiene (basado en
propiedad), como tokens, clave pública certificados, tarjetas inteligentes, etc., para
usar algo en uno (basado en características), como como huellas dactilares
biométricas, patrones de sangre de la retina, contornos del iris, etc. Necesita más de
un factor (conocimiento, propiedad o característica) para la verificación de identidad
aumenta significativamente el factor de trabajo de un atacante y las tecnologías que
pueden admitir la autenticación multifactor sin problemas debe tenerse en cuenta en
el diseño.

La interfaz de proveedor de soporte de seguridad (SSPI) es una implementación de

las RFC 2743 y 2744 de IETF, comúnmente conocidas como Servicio de seguridad
genérico API (GSSAPI). SSPI abstrae las llamadas para autenticarse y los
desarrolladores pueden aprovechar esto, sin necesidad de comprender las
complejidades de esta autenticación protocolo o, peor aún, intentar escribir el suyo
propio. Autenticación personalizada la implementación sobre una base de aplicación
a aplicación está probada no sólo para ser ineficaz, pero también puede introducir
fallas de seguridad y debe evitarse. SSPI admite la interoperabilidad con otras
tecnologías de autenticación proporcionando una interfaz conectable, pero también
incluye por defecto los protocolos para negociar el mejor protocolo de seguridad
(SPNEGO), delegar (Kerberos), transmitir de forma segura (SChannel) y proteja las
credenciales mediante hashes (Digest).
Antes de que los desarrolladores comiencen a escribir código, es importante que el
software los diseñadores tengan en cuenta los diferentes tipos de autenticación y los
protocolos e interfaces utilizadas en cada tipo.

Gestión de identidad

La autenticación y la identificación van de la mano. Sin identificación, no solo no es

posible la autenticación, sino que la responsabilidad es casi imposible de
implementar. La gestión de identidad (IDM) es la combinación de políticas, procesos
y tecnologías para la gestión de información sobre identidades digitales. Estas
identidades digitales pueden ser las de un humano (usuarios) o un no humano (red,
host, aplicación, servicios). Las identidades de usuario son principalmente de dos
tipos: internos (por ejemplo, empleados y contratistas) y externos (por ejemplo,
socios, clientes, y proveedores). IDM responde las preguntas, "¿Quién o qué está
solicitando acceso?" "¿Cómo se autentican?" Y "¿Qué nivel de acceso se puede
otorgar basado en la política de seguridad? "

El ciclo de vida de IDM se trata del aprovisionamiento, la administración y el

desaprovisionamiento de identidades como se ilustra en la Figura 3.33.

El aprovisionamiento de identidades incluye la creación de identidades digitales. En

una empresa que tiene múltiples sistemas, aprovisionar una identidad en cada
sistema puede ser un proceso laborioso, lento e ineficiente si no está automatizado.
La automatización de las identidades de aprovisionamiento se puede lograr
mediante la codificación de negocios procesos, como la contratación y la
incorporación, y esto requiere un diseño cuidadoso. Roles en un sistema de
aprovisionamiento de usuarios hay conjuntos de derechos que abarcan varios
sistemas y aplicaciones. Los privilegios que tienen algún significado en una
aplicación se conocen como
derechos. El aprovisionamiento de usuarios extiende RBAC más allá de las
aplicaciones individuales al consolidar los derechos de aplicaciones o sistemas
individuales en menos negocios roles, facilitando que una empresa administre a sus
usuarios y sus derechos de acceso.

La gestión de identidades incluye el cambio de nombre de identidades, además o

eliminación de roles, los derechos y privilegios asociados con esos roles, los
cambios en las políticas y los requisitos reglamentarios, la auditoría de solicitudes
de acceso no exitosas y sincronización de múltiples identidades para el acceso a
múltiples sistemas. Cuando se cambia el nombre de las identidades, es imperativo
documentar y registrar estos cambios. También es importante mantener las historias
de actividad de las identidades antes de que fueran renombradas y mapear esas
historias a la nueva nombres de identidad para asegurar capacidades de no repudio.

El desaprovisionamiento de identidades incluye control de acceso de terminación

(TAC) procesos que se componen de la notificación de terminación y la
desactivación o eliminación completa de identidades. Las empresas de hoy están
obligadas a proporcionar evidencia auditable de que los controles de acceso están
en su lugar y son efectivos. La sección 404 de SarbanesOxley (SOX) exige que una
revisión anual de la eficacia de se deben realizar controles y esto se aplica a la
gestión de identidad y acceso.

(IAM) también. Los usuarios reciben derechos y privilegios (derechos) con el tiempo,
pero rara vez se revocan estos derechos cuando ya no son necesarios. Una
empresa debe participar en la revisión y aprobación del acceso a los derechos de
identidad y el proceso se conoce como certificación de acceso por razones legales y
de cumplimiento, puede ser necesario mantener una identidad digital incluso
después de que la identidad ya no esté activa, por lo que la desactivación puede ser
la única opción viable. Si este es el caso, el software que maneja el acceso de
terminación debe estar diseñado para permitir "desactivar" solamente y no permitir
verdaderas "eliminaciones" o "completar eliminación". La desactivación también
permite que la identidad permanezca como copia de seguridad en caso de que sea
necesario: sin embargo, esto puede representar una amenaza para la seguridad El
atacante podría reactivar una identidad desactivada y obtener acceso. El desactivar
las identidades se mantienen mejor en un sistema de respaldo o archivado que está
fuera de línea con acceso restringido y auditado.

Algunas de las tecnologías comunes que se utilizan para IDM son las siguientes:

Directorios

Un directorio es el depósito de identidades. Su funcionalidad es similar a la de

páginas Amarillas. Un directorio se utiliza para buscar información sobre usuarios y
otras identidades dentro de un ecosistema informático. La información de identidad
se puede almacenar y mantener en directorios de red o bases de datos y datos de
aplicaciones back-end historias. Cuando el software está diseñado para utilizar la
autenticación integrada, aprovecha directorios de red a los que se accede mediante
Lightweight Directory Access Protocol (LDAP). LDAP reemplazó al protocolo X.500
más complejo y desactualizado.

Los directorios son un requisito fundamental para IDM y se pueden aprovechar para
eliminar los silos de información de identidad mantenidos dentro de cada aplicación.
Algunos de los productos de directorio más populares son el directorio de IBM
(Tivoli), Sun ONE directorio, Oracle Internet Directory (OID), Microsoft Active
Directory, Novell eDirectory, OpenLDAP y Red Hat Directory Server.

Metadirectorios y directorios virtuales

Los roles y los derechos de los usuarios cambian con los cambios comerciales y
cuando la identidad información y privilegios vinculados a ese cambio de identidad,
estos cambios deben ser propagado a los sistemas que utilizan esa identidad.
Propagación y sincronización de los cambios de identidad del sistema de registro a
los sistemas gestionados posible mediante motores conocidos como
metadirectorios. Recursos humanos (RRHH), Cliente los sistemas de gestión de
registros (CRM) y el directorio corporativo son ejemplos de sistema de registro. Los
metadirectorios simplifican la administración de identidades. Reducen desafíos
impuestos por las actualizaciones manuales y se puede aprovechar dentro del
software para automatizar la propagación de cambios y ahorre tiempo. El diseño del
software debe incluir evaluar la seguridad de los conectores y las dependencias
entre la identidad sistemas de origen y sistemas descendentes que utilizan la
identidad. La identidad de Microsoft Lifecycle Management es un ejemplo de
metadirectorio.

Los metadirectorios son como tuberías internas necesarias para centralizar la

identidad cambio y sincronización, pero generalmente no tienen una interfaz que
pueda ser invocada. Este déficit dio lugar a directorios virtuales. En el contexto de
una arquitectura basada en Identity Services, los directorios virtuales proporcionan
un servicio interfaz que puede ser invocada por una aplicación para extraer datos de
identidad y cambiar en afirmaciones que la aplicación pueda comprender. Los
directorios virtuales proporcionan más seguridad que los metadirectorios porque
también funcionan como guardianes y asegurarse de que los datos utilizados están
autorizados y cumplan con la política de seguridad.

Diseñar para aprovechar los procesos y tecnologías de gestión de identidad es

importante porque reduce el riesgo de la siguiente manera:

■ Automatizar, aplicar y hacer cumplir constantemente la identificación,

políticas de seguridad de autenticación y autorización.
■ Desaprovisionar identidades para evitar que persistan más allá de su
tiempo permitido. Esto protege contra un atacante que puede usar la identidad de un
empleado para obtener acceso.
■ Mitigar la posibilidad de que un usuario o una aplicación ganen
acceso no autorizado a recursos privilegiados.
■ Respaldar los requisitos de cumplimiento normativo proporcionando
capacidades de auditoría y generación de informes.
■ Aprovechar la arquitectura de seguridad común en todas las aplicaciones.

Gestión de credenciales

El capítulo Conceptos de software seguro cubrió diferentes tipos de autenticación,

cada uno requiriendo formas específicas de credenciales para verificar y asegurar
que las entidades que el acceso solicitado a los objetos eran realmente quienes
decían ser. La identificación información proporcionada por un usuario o sistema
para validación y verificación se conoce como credenciales o reclamos. Si bien los
nombres de usuario y las contraseñas se encuentran entre el medio más común de
proporcionar información de identificación, autenticación también se puede lograr
utilizando otras formas de credenciales. Tokens, certificados, huellas dactilares,
patrones retinianos son algunos ejemplos de otros tipos de credenciales.

Las credenciales deben administrarse y se puede usar la API de administración de

credenciales para obtener y administrar información de credenciales, como nombres
de usuario y contraseñas. La administración de credenciales abarca su generación,
almacenamiento, sincronización, restablecimiento y revocación.

En esta sección, cubriremos la administración de contraseñas, certificados y

tecnología de inicio de sesión (SSO).

Gestión de contraseñas

Cuando utilice contraseñas para la autenticación, es importante asegurarse de que

las contraseñas que genera automáticamente el sistema son aleatorias y no
secuencial o fácilmente adivinadas. En primer lugar, las contraseñas en blanco no
deben ser permitidas. Cuando los usuarios pueden crear contraseñas, las palabras
del diccionario no deben permitirse como contraseñas porque se pueden descubrir
fácilmente mediante el uso de fuerza bruta técnicas y herramientas para descifrar
contraseñas. Requerir contraseñas alfanuméricas con casos mixtos y caracteres
especiales aumenta la fuerza de las contraseñas.

Las contraseñas nunca deben codificarse en texto claro y almacenarse en línea con
el código o guiones. Cuando se almacenan en una tabla de base de datos o en un
archivo de configuración, el hash proporciona más protección que el cifrado porque
las contraseñas originales no puede ser determinado. Aunque proporcionar un
medio para recordar contraseñas es bueno para la experiencia del usuario, desde el
punto de vista de la seguridad, no se recomienda.

Exigir al usuario que proporcione la contraseña anterior antes de cambiar una

contraseña, mitiga los cambios de contraseña automatizados y los ataques de
fuerza bruta. Cuando las contraseñas se modifican, es necesario asegurarse de que
el cambio se replica y sincroniza dentro de otras aplicaciones que usan la misma
contraseña. Sincronización de contraseña fomenta la autenticación SSO y resuelve
los problemas de gestión de contraseñas en una red empresarial.
Cuando sea necesario recuperar o restablecer contraseñas, se debe prestar
especial atención dado para asegurar que la solicitud de recuperación de
contraseña sea, ante todo, una solicitud, esta garantía se puede obtener mediante el
uso de alguna forma de identificación mecanismo que no se puede eludir fácilmente.
La mayoría no basada en contraseñas Las aplicaciones de autenticación tienen un
mecanismo de preguntas y respuestas para identificar un usuario cuando es
necesario recuperar las contraseñas. Es imperativo para estas preguntas y
respuestas para ser personalizables por el usuario. Preguntas como "¿Cuál es tu
color favorito o "¿Cuál es el apellido de soltera de tu madre?" no proporciones tan
alto una protección al igual que las preguntas que el usuario puede definir y
personalizar.
Las contraseñas deben tener fechas de vencimiento. Permitir que se utilice la misma
contraseña una vez que haya caducado, debería rechazarse. Las contraseñas de un
solo uso (OTP) proporcionan máxima protección porque no se puede reutilizar la
misma contraseña.

Tecnología de protocolo ligero de acceso a directorios (LDAP) que utiliza directorio

los servidores se pueden utilizar para implementar y hacer cumplir las políticas de
contraseñas para administrar contraseñas. Una política de contraseña para todos
los usuarios o una política diferente para cada usuario se puede establecer. Los
servidores de directorio se pueden utilizar para notificar a los usuarios caducidad de
contraseñas y también se pueden utilizar para administrar contraseñas caducadas y
bloqueos de cuentas.

Gestión de certificados

La autenticación también se puede lograr mediante certificados digitales. Hoy se

realiza criptografía asimétrica y autenticación mediante certificados digitales posible
mediante el uso de una infraestructura de clave pública (PKI), como se muestra en
la Figura 3.34.

PKI hace comunicaciones seguras, autenticación y criptografía operaciones tales

como cifrado y descifrado posibles. Es la seguridad Infraestructura que utiliza
conceptos y técnicas de clave pública para proporcionar servicios para
transacciones y comunicaciones seguras de comercio electrónico. PKI gestiona el
generación y distribución de pares de claves públicas / privadas y publica el público
claves como certificados.
PKI consta de los siguientes componentes:

■ Una autoridad de certificación (CA), que es la entidad de confianza que emite el

certificado digital que contiene la clave pública y relacionados información del tema.

■ Una autoridad de registro (RA), que funciona como verificador de la CA antes de

que la CA emita un certificado digital al solicitante.
■ Un sistema de gestión de certificados con directorios en los que los certificados se
pueden retener y con capacidad de revocación para revocar cualquier certificados
cuyas claves privadas han sido comprometidas (divulgadas). La CA publica las
listas de revocación de certificados (CRL) que contienen todos los certificados
revocados por la CA. Las CRL lo hacen posible para retirar un certificado cuya clave
privada ha sido revelada. Para verificar la validez de un certificado, la clave pública
se requiere CA y se realiza una verificación con la CRL de CA. La propia Autoridad
de Certificación necesita tener sus propios certificados. Estos son autofirmados, lo
que significa que los datos del sujeto en el certificados es el mismo que el nombre
de la autoridad que firma y emite los certificados.

La gestión de PKI incluye la creación de pares de claves pública / privada, clave

pública creación de certificado, revocación de clave privada y listado en CRL cuando
la clave privada está comprometida, el almacenamiento y archivo de claves y
certificados, y la destrucción de estos certificados al final de su vida útil. PKI es un
medio para lograr la confianza entre empresas y aplicación de restricciones sobre el
uso de los certificados emitidos.

Además de utilizar PKI para la autenticación, los certificados X.509 hacen Posibles
capacidades de autorización sólidas al proporcionar Privilege Management
Infraestructura (PMI) utilizando certificados de atributos X.509, autoridades de
atributos, puertas de enlace de destino y políticas de autorización como se muestra
en la Figura 3.35.

PMI permite definir privilegios de acceso de usuario en un entorno que

tiene que admitir múltiples aplicaciones y proveedores.

Inicio de sesión único (SSO)

SSO hace posible que los usuarios inicien sesión en un sistema y, después de ser
autenticados, lanzar otras aplicaciones sin tener que proporcionar su información de
identificación otra vez. Es posible almacenar las credenciales de usuario fuera de
una aplicación y reutilizar automáticamente las credenciales validadas en los
sistemas que las soliciten. Sin embargo, el SSO generalmente se implementa junto
con otras tecnologías. Las dos tecnologías comunes que hacen que el intercambio
de información de autenticación son posibles Kerberos y lenguaje de marcado de
afirmación seguro.

Las credenciales en un sistema de autenticación Kerberos se conocen como tickets.

Cuando inicia sesión por primera vez en un sistema implementado con Kerberos y
su contraseña se verifica, se le otorga un ticket maestro, también conocido como
Ticket Concesión Ticket (TGT), por el Ticket Servidor de concesión (TGS). El TGT
actuará como proxy para su cartas credenciales. Cuando necesite acceder a otro
sistema, presente su maestro TGT al servidor Kerberos y obtenga un ticket
específico para ese otro sistema. El segundo ticket se presenta al sistema al que
solicita acceso como una prueba de quién eres. Cuando se verifica su identidad, se
concede acceso al sistema en consecuencia. Todos los tickets se almacenan en lo
que se llama un caché de tickets en el sistema local. El SSO basado en Kerberos se
puede utilizar dentro del mismo dominio en el que las funciones TGS y se emite el
TGT. Por tanto, Kerberos se utiliza principalmente en configuración de intranet. El
SSO basado en Kerberos es más fácil de implementar en una configuración de
intranet que SSO en un entorno de Internet.

Para implementar SSO en un entorno de Internet con varios dominios, se puede

utilizar SAML. SAML permite a los usuarios autenticarse en un dominio y utilizar
recursos en un dominio diferente sin tener que volver a autenticarse. Se utiliza
principalmente en un entorno basado en web para fines de SSO. La especificación
WS-Security recomienda el uso de tokens SAML para autenticación. Los tokens
SAML se pueden usar para intercambiar no solo autenticación información, sino
también datos de autorización, perfiles de usuario y preferencias, etc. Es una opción
preferida. Si bien los tokens SAML son un estándar de facto para hacer decisiones
de autenticación en implementaciones SOA, la autorización a menudo se
implementa como una solución personalizada. El control de acceso extensible de
OASIS el estándar margen de lenguaje (XACML) se puede utilizar para realizar
autorizaciones decisiones y se recomienda.

Un concepto relacionado con SSO es la federación. La Federación extiende SSO a

través de empresas. En un sistema federado, una persona puede iniciar sesión en
un sitio y acceder servicios en otro sitio afiliado sin tener que iniciar sesión cada vez
o restablecer una identidad. Por ejemplo, si utiliza un sitio de viajes en línea para
reservar sus vuelos, su misma identidad se puede utilizar en un sitio afiliado de
vacaciones y excursiones para reservar su paquete de vacaciones sin tener que
crear una cuenta en el sitio de vacaciones o inicie sesión en él. La federación
satisface principalmente la necesidad de un usuario de conveniencia y cuándo se
implementa, la implementación debe hacerse con acuerdos de protección legal
que se puede hacer entre las dos empresas afiliadas.
Hasta que se desarrolló la especificación estándar SAML 2.0, las empresas que se
comprometieron en la federación tuvieron que trabajar con tres protocolos primarios;
es decir, OASIS SAML 1.0, Libertad de Alianza ID-FF 1.1 y 1.2 y Shibboleth. SAML
OASIS se ocupó principalmente de la federación de empresa a empresa, mientras
que Libertad se centró en la federación de empresas a consumidores, y Shibboleth
se centró en la educación instituciones que exigían el anonimato al participar en la
federación. La rápida identidad en línea (FIDO) tiene un doble objetivo. Uno es
abordar la falta de interoperabilidad entre dispositivos de autenticación fuerte y el
otro es para aliviar los problemas que enfrentan los empleados con la creación y
tener que recordar múltiples nombres de usuario y contraseñas. Las alianzas FIDO
con el objetivo de desarrollar una especificación abierta, escalable e interoperable
con menos dependencia de contraseñas para fines de autenticación en línea. La
alianza FIDO propuso la metodología de autenticación es BYOD que está habilitado
para FIDO y lo usa para validar y certificar tokens, que se descubren dinámicamente
en los puntos finales.

SAML 2.0 alivia los desafíos de la complejidad multiprotocolo, haciéndolo posible

implementar la federación más fácilmente. SAML 2.0 hace federación e
interoperabilidad posible con relativa facilidad debido a la necesidad de negociar,
mapear, y traducir protocolos ya no es necesario. También es un estándar abierto
para servicio de inicio de sesión único basado en la web.

Si bien el SSO es difícil de implementar porque se debe establecer la confianza

entre la aplicación que realiza la autenticación y el soporte sistemas que aceptarán
las credenciales autenticadas, se prefiere porque reduce la probabilidad de error
humano. Sin embargo, los beneficios del usuario simplificado la autenticación que
SSO trae consigo debe equilibrarse con lo siguiente preocupaciones sobre la
infraestructura SSO:

■ La capacidad de establecer confianza entre las entidades que participan en la

Arquitectura SSO.
■ La implementación de SSO puede ser un único punto de falla. Si el SSO las
credenciales están expuestas, todos los sistemas en la implementación de SSO son
susceptibles de incumplimiento. En términos sencillos, la pérdida de las
credenciales de SSO es similar a perder la llave de todo el reino.
■ La implementación de SSO puede ser una fuente de denegación de servicio
(DoS). Si el sistema SSO falla, todos los usuarios que dependen del SSO la
implementación no podrá iniciar sesión en sus sistemas, lo que un DoS.
■ El costo de implementación e integración de SSO puede ser excesivo.

Control de flujo

En computación distribuida, controlar el flujo de información entre procesos en dos

sistemas en los que se puede confiar o no, plantea desafíos de seguridad. Varios
problemas de seguridad están relacionados con el flujo de información sensible
(banco información de cuenta, información de salud, números de seguro social,
tarjeta de crédito declaraciones, etc.) almacenadas en una aplicación web en
particular no deben mostrarse en el navegador de un cliente a aquellos que no están
autorizados a ver esa información. La protección contra malware como spyware y
troyanos significa que la red el tráfico que lleva una carga útil maliciosa no puede
ingresar a la red. Por controlando el flujo de información o datos, varias amenazas al
software pueden ser mitigadas y entrega de mensajes válidos garantizada. Hacer
cumplir las políticas de seguridad sobre cómo la información puede fluir hacia y
desde una aplicación, independiente de los mecanismos de protección de seguridad
a nivel de código, puede ser útil para implementar protección de seguridad cuando
no se puede confiar en el código en sí, proxies, middleware y la infraestructura y las
tecnologías de colas se pueden utilizar para controlar la tasa de transmisión de
datos y permitir o no permitir el flujo de información a través límites de confianza.

Cortafuegos y proxies

Los cortafuegos, más específicamente los cortafuegos de capa de red, separan la

red interna de una empresa de la del exterior. También se utilizan para separar
internos subredes unas de otras. El firewall es un ejecutor de la política de
seguridad inspeccionando el perímetro y todo el tráfico que lo atraviesa. Si la red el
tráfico está restringido o no depende de las reglas predefinidas o la política de
seguridad que está configurado en el firewall.

Los diferentes tipos de firewalls que existen son filtrado de paquetes, proxy, con
estado, y firewall de la capa de aplicación. Cada tipo se trata con más detalle en
esta sección.

Filtrado de paquetes

Este tipo de firewall filtra el tráfico de la red en función de la información que

contiene en el encabezado del paquete, como la dirección de origen, la dirección de
destino, los puertos de red, y banderas de protocolo y estado. Los cortafuegos de
filtrado de paquetes no tienen estado, lo que significa que no lleve un registro de la
información estatal. Estos se implementan comúnmente usando listas de control de
acceso (ACL) que son principalmente líneas de reglas basadas en texto que definen
qué paquetes pueden pasar a través del firewall y cuáles deben ser restringidos.
También se conocen como firewalls de primera generación. Estas son
independientes de la aplicación, escalables y de rendimiento más rápido, pero
proporcionan
poca seguridad porque solo miran la información del encabezado de los paquetes.
Debido a que no inspeccionan el contenido (carga útil) de los paquetes, el filtrado de
paquetes los firewalls están indefensos contra las amenazas de malware. Los
cortafuegos de filtrado de paquetes también conocidos como firewalls de primera
generación.

Proxy

Los firewalls proxy actúan como intermediarios entre las redes internas de confianza
y el fuera de los que no son de confianza. Cuando un paquete llega a un firewall
proxy, el firewall termina la conexión desde la fuente y actúa como un proxy para el
destino, inspecciona el paquete para asegurarse de que es seguro antes de
reenviarlo al destino. Cuando el sistema de destino responde, el paquete se envía al
firewall proxy, que volverá a empaquetar el paquete con su propia dirección de
origen y abstraer la dirección del sistema host de destino interno. Los firewalls proxy
también toman decisiones, al igual que los cortafuegos de filtrado de paquetes. Pero
los firewalls proxy, al romper la conexión, no permite la conexión directa entre
personas no confiables y confiables sistemas. Los firewalls proxy también se
conocen como firewalls de segunda generación.

Con estado

Los firewalls con estado o los firewalls de tercera generación tienen la capacidad de
rastrear diálogos manteniendo un estado y un contexto de datos en los paquetes
dentro de una tabla de estado. diferente a cortafuegos proxy, no requieren tantos
recursos y normalmente son transparentes para el usuario.

Capa de aplicación
Debido a que los firewalls sin estado y con estado solo miran el encabezado de un
paquete y no en el contenido de datos (carga útil) contenido dentro de un paquete,
aplicación específica los ataques no serán detectados y pasarán a través de
firewalls sin estado y con estado. Esta es donde los firewalls de capa de aplicación o
los firewalls de capa 7 resultan útiles. Solicitud los firewalls de capa proporcionan
control de flujo al interceptar datos que se originan en el cliente. El tráfico
interceptado se examina en busca de amenazas potencialmente peligrosas que se
pueden ejecutar como comandos. Cuando se sospecha una amenaza, la aplicación
el firewall de capa puede tomar la acción apropiada para contener y terminar el
ataque o redirigirlo a un honeypot para recopilar datos adicionales.

Una de las dos opciones del Requisito 6.6 de PCI Data Security el estándar es tener
un firewall de aplicaciones (web) colocado entre la web aplicación y el punto final del
cliente. La otra opción es realizar la aplicación revisiones de código. Los firewalls de
aplicaciones están empezando a ganar importancia y esta tendencia se espera que
continúe porque los piratas informáticos están apuntando a la capa de aplicación.

Middleware

La mayoría de las soluciones de software actuales se realizan integrando varios

componentes del software, algunos de los cuales pueden ser desarrollados
internamente mientras que otros pueden ser componentes de terceros. Para que
estos componentes funcionen de manera eficiente y de forma segura en concierto,
deben integrarse. Componentes de middleware funcionan como el "pegamento del
software" cuando se trata de integración. Middleware los componentes facilitan la
comunicación y el flujo entre los componentes del software. Si estos componentes
no se diseñan y administran correctamente, se pueden considerar como un único
punto de falla, con el potencial de convertirse en la fuente para un ataque DoS. Por
eso, cuando el middleware es parte del diseño del software, se debe prestar
especial atención al control del flujo de información y comandos en el software.

Infraestructura y tecnología de colas

La infraestructura y la tecnología de las colas son útiles para evitar la congestión de

la red cuando un remitente envía datos más rápido de lo que un receptor puede
procesarlos. Aplicaciones de legado generalmente están diseñadas para ser de un
solo hilo en sus operaciones. Con el aumento en la funcionalidad de cliente
enriquecido y sin un control de flujo adecuado, los mensajes se pueden perder. La
infraestructura y la tecnología de las colas se pueden utilizar para acumular estos
mensajes en el orden correcto para procesar y garantizar la entrega a los
destinatarios previstos. Algunas de las tecnologías de cola más conocidas incluye
Microsoft Message Cola (MSMQ), Oracle Advance Queueing (AQ) e IBM MQ
Series.

Auditoría (registro)

Una de las consideraciones de diseño más importantes es diseñar el software para

que pueda proporcionar evidencia histórica de las acciones del usuario y del
sistema. Auditoría o registro de las interacciones del usuario y del sistema dentro de
una aplicación se puede utilizar como detective significa averiguar quién hizo qué,
dónde, cuándo y, a veces, cómo. Regulación como Sarbanes Oxley (SOX), HIPAA y
PCI DSS requieren que las empresas recopilen y analicen registros de diversas
fuentes como medio para demostrar la debida diligencia y seguridad integral. La
información que se registra debe procesarse para deducir patrones y descubrir
amenazas. Sin embargo, antes de que cualquier procesamiento tome lugar, es una
buena práctica consolidar los registros, después de sincronizar la hora relojes de los
troncos. La sincronización del reloj de tiempo permite correlacionar eventos
registrados en los datos de registro de la aplicación a eventos del mundo real, como
la insignia lectores, cámaras de seguridad y grabaciones de circuito cerrado de
televisión (CCTV), etc. La información de los registros debe protegerse cuando se
almacena y en tránsito sistema los administradores y usuarios de aplicaciones
monitoreadas no deben tener acceso a los registros. Esto es para evitar que alguien
pueda eliminar evidencia de los registros en el caso de fraude o robo. El uso de un
servicio de gestión de registros (LMS) puede aliviar algo de esta preocupación.
Además, sistemas de detección de intrusiones (IDS) e intrusiones Los sistemas de
protección (IPS) se pueden aprovechar para registrar y recuperar la actividad. En
esta sección, cubriremos tecnologías de auditoría, específicamente Registros de
eventos de aplicaciones, Syslog, IDS e IPS.

Registros de eventos de la aplicación

Los datos de eventos de la aplicación pueden proporcionar información valiosa para

detectar vulnerabilidades, comportamiento inusual e inesperado de aplicaciones,
seguridad incidentes y violaciones a la política. También se pueden utilizar para
establecer líneas de base de actuación. En relación con el registro de datos de
infraestructura, en la mayoría de los sistemas de software, el registro de datos de
eventos de la aplicación se encuentra deshabilitado, falta o mal configurado.
Cuando los eventos de la aplicación son parte del diseño del software, se debe
prestar atención para asegurar que la tala sea consistente y conforme según el
estándar de la industria, para que los datos registrados se puedan consumir,
analizar y correlacionar para discernir patrones. Es muy recomendable que toda la
seguridad de los eventos que surgen en la aplicación se registren.

Como mínimo, el registro de eventos de la aplicación debe capturar:

■ Violaciones de seguridad
■ Procesos comerciales críticos, por ejemplo, procesamiento de pedidos, cambio de
contraseña, etc.
■ Métricas de rendimiento, por ejemplo, tiempo de carga, tiempos de espera, etc. y
■ Eventos relacionados con el cumplimiento

Syslog

Cuando los registros deben transferirse a través de una red IP, se puede utilizar el
protocolo syslog. Syslog se utiliza para describir el protocolo, la aplicación que
recibe y envía, así como los registros. El protocolo es un protocolo cliente / servidor
en el que el cliente la aplicación transmite los registros al servidor receptor de
Syslog (comúnmente llamado demonio syslog, denotado como syslogd). Aunque
syslog usa el método sin conexión protocolo de datagramas de usuario (UDP) sin
confirmación de entrega como mecanismo de transporte, syslog puede utilizar la
transmisión orientada a la conexión protocolo de control (TCP) para asegurar o
garantizar la entrega. Entrega de registros confiables asegura que no solo el
receptor recibe correctamente los registros, sino que se reciben en el orden
correcto. Es una parte necesaria de una seguridad completa. solución y se puede
implementar mediante TCP. Se puede aumentar usando servidores de caché, pero
cuando se hace esto, la superficie de ataque incluirá el caché servidores y los
controles técnicos, administrativos y físicos adecuados deben estar en su lugar para
proteger los servidores de caché.

Syslog se puede utilizar en múltiples plataformas y es compatible con muchos

dispositivos, convirtiéndolo en el estándar de facto para el registro y transmisión de
registros de varios dispositivos a un repositorio central donde los registros se
pueden consolidar, integrar, y normalizado para deducir patrones. Syslog está
ganando importancia rápidamente en Plataformas de Microsoft y es la solución de
registro estándar para Unix y Linux plataformas. La publicación especial 800-92 del
NIST proporciona una guía ingeniosa sobre Administración de registros de
seguridad informática y destaca cómo se puede utilizar Syslog para auditoría de
seguridad, también. Sin embargo, Syslog tiene una debilidad de seguridad inherente
a que se debe prestar atención. Los datos que se transmiten mediante Syslog están
en texto sin cifrar, haciéndolo susceptible a ataques de divulgación. Por lo tanto, la
seguridad de la capa de transporte medidas que utilizan envoltorios como
envoltorios SSL o túneles Secure Shell (SSH) debe utilizarse para proporcionar
cifrado para garantizar la confidencialidad. Adicionalmente, es necesaria la
protección de la integridad mediante funciones hash SHA o MD5 para garantizar
que los troncos no sean manipulados o contaminados mientras están en tránsito o
almacenados. Syslog-NG (nueva generación) es una implementación de código
abierto del syslog protocolo.

Sistema de detección de intrusiones (IDS)

Los IDS se pueden utilizar para detectar amenazas potenciales y actividades

sospechosas. IDSes pueden monitorear dispositivos o aplicaciones en la capa de
red (NIDS) o capa de host (HIDS). Filtran el tráfico entrante y saliente y tienen
capacidades de alerta, que notifican a los administradores sobre amenazas
inminentes. Uno de los desafíos importantes con NIDS es que los datos maliciosos
de carga útil cifrados, como es el caso de los virus cifrados, no se pueden
inspeccionar en busca de amenazas y puede evitar la filtración o la detección.

Los IDS no son cortafuegos, pero se pueden utilizar con uno. Los cortafuegos son
los primeros línea de red o defensa del perímetro, pero pueden ser necesarios para
permitir el tráfico para ingresar a través de ciertos puertos como el puerto 80 (http),
443 (https) o 21 (ftp). Aquí es donde los IDS pueden resultar útiles, ya que
proporcionarán protección contra tráfico malicioso y amenazas que atraviesan
firewalls. Además, los IDS son más útiles que los firewalls para detectar amenazas
internas y actividades fraudulentas que se originan dentro de los firewalls.

Los IDS se implementan de una de las siguientes formas:

■ Basado en firmas: similar a cómo el antivirus detecta malware amenazas, los IDS
basados ​en firmas detectan amenazas buscando firmas o patrones que coinciden
con los de amenazas conocidas. La debilidad de este tipo de IDS es que las
amenazas nuevas y desconocidas, cuyas firmas aún no se conocen, o amenazas
polimórficas con el cambio de firmas no será detectado y puede evadir la intrusión
detección. Snort es muy popular y ampliamente utilizado, disponible gratuitamente,
IDS de código abierto basado en firmas para Linux y Windows Sistemas operativos.

■ Basado en anomalías: un IDS basado en anomalías funciona mediante la

supervisión y comparar el tráfico de la red con una línea de base establecida de lo
que se considera un comportamiento "normal". Cualquier desviación del patrón de
comportamiento normal provoca una alerta como una amenaza potencial. La ventaja
de este tipo de IDS es que se puede utilizar para detectar
y descubrir nuevas amenazas. Los IDS basados ​en anomalías suelen también
conocido como IDS de comportamiento.
■ Basado en reglas: un IDS basado en reglas funciona detectando ataques basado
en reglas programadas. Estas reglas a menudo se implementan como
Declaraciones IF-THEN-ELSE.

Cuando se implementa con el registro, se puede utilizar un IDS para proporcionar

capacidades de auditoría.

Sistema de prevención de intrusiones (IPS)

La mayoría de los IDS son pasivos y simplemente monitorean y alertan sobre

amenazas inminentes. Algunos IDS actuales también son reactivos en
funcionamiento y son capaces de realizar una acción o acciones en respuesta a una
amenaza detectada. Cuando estas acciones son de naturaleza preventiva, primero
contienen la amenaza y la previenen de manifestarse, estos IDS se denominan
Prevención de intrusiones Sistemas (IPS). Un IPS proporciona protección proactiva
y es esencialmente un firewall que combina el filtrado a nivel de red y de aplicación.
Algunos ejemplos de las acciones de IPS proactivas incluyen bloquear más tráfico
desde la dirección IP de origen y bloquear la cuenta cuando se detectan amenazas
de fuerza bruta.

Cuando se implementa con el registro, se puede utilizar un IPS para proporcionar

capacidades de auditoría.

Prevención de pérdida de datos (DLP)

El activo más importante de una empresa, solo superado por los activos de su
personal, es datos, y la protección de datos es importante para asegurar su
confidencialidad, integridad y disponibilidad.
La cronología de las filtraciones de datos, los informes de noticias y los requisitos
reglamentarios para proteger los datos reflejan la prevalencia y el crecimiento
continuo del robo de datos que cuestan a las empresas sumas colosales de
remediación y pérdida de marca. Cifrado de datos mitiga la divulgación de datos en
caso de robo físico y dispositivos perimetrales como ya que los firewalls pueden
proporcionar cierto grado de protección al filtrar las amenazas que están destinados
a robar datos e información dentro de la red. Mientras este tipo de filtrado de
entrada puede ser útil para proteger los datos dentro de la red, hace poco para
proteger los datos que salen de la red de la empresa. Aquí es donde la prevención
de pérdidas (DLP) es útil. DLP es la tecnología que proporciona filtración de salida,
lo que significa que evita que los datos salgan de la red. Correos electrónicos con
los archivos adjuntos que contienen información confidencial se encuentran entre
las principales fuentes de pérdida de datos cuando los datos están en movimiento.
Al escribir mal la dirección de correo electrónico del destinatario cuando compartir
información con un cliente, proveedor o socio, uno puede involuntariamente divulgar
información. Un empleado descontento puede copiar datos confidenciales en un
extremo dispositivo de punto (como un disco duro portátil o USB) y sáquelo de la
red.

DLP evita la pérdida de datos al no permitir información clasificada y etiquetado

como sensible para adjuntarlo o copiarlo. El etiquetado es el proceso de etiquetado.
información que se clasifica con su nivel de clasificación apropiado. Esto puede ser
un esfuerzo abrumador para las empresas que tienen una gran cantidad de
información que deben etiquetarse, por lo que el etiquetado requiere planificación y
estrategia, junto con gestión y apoyo empresarial. El propietario de la empresa de
los datos es en última instancia responsable y debe participar activamente, ya sea
directamente o delegando un dato custodio para trabajar con el equipo de TI, de
modo que los datos no solo sean clasificados sino también etiquetado
apropiadamente. DLP trae ambos obligatorios (etiquetado) y seguridad discrecional
(basada en la discreción del propietario) en vigor.

Las implementaciones exitosas de DLP no solo brindan protección tecnológica sino

también la seguridad de que se requieren recursos humanos y elementos de
proceso están en su lugar. La tecnología DLP funciona supervisando los elementos
de datos etiquetados, detectar y prevenir pérdidas y remediar si los datos salen de
la red. Además, la protección de la tecnología DLP también incluye la protección de
la puerta de enlace. como el canal. El control DLP generalmente se aplica en la
puerta de enlace, el punto en el que los datos pueden salir de la red (punto de
escape), en el siguiente nivel lógico desde donde está almacenado. DLP también
incluye la protección de datos cuando está en tránsito y funciona junto con los
mecanismos de seguridad de la capa de transporte (TLS) protegiendo el canal.
Debe reconocerse que protegerse contra la pérdida de datos mediante la aplicación
de DLP la tecnología puede verse frustrada si los usuarios (personas) no son
conscientes y no están educados sobre los mecanismos y el impacto de los datos
confidenciales que salen por la puerta.
DLP también se puede implementar a través de una política de seguridad
corporativa que exige la destrucción de documentos sensibles, impidiendo la
impresión y el almacenamiento de información sensible en dispositivos de
almacenamiento que se pueden sacar de la empresa.

Hemos cubierto las formas en que DLP puede proteger los datos que están en el
centro de salir de la red, pero en el mundo actual, hay un impulso hacia el Software
como modelo de servicio de la informática. En tales situaciones, los datos de la
empresa se almacenan en el exterior en la red de alojamiento compartido del
proveedor de servicios. Cuando esto ocurre, la protección de datos incluye la
prevención de la fuga de datos cuando los datos están en reposo o almacenados,
así como cuando se está orientando hacia y desde el proveedor de SaaS. Se
pueden utilizar mecanismos de protección de control de acceso y protección
criptográfica para evitar la fuga de datos en las implementaciones de SaaS. . SaaS
es una tendencia en maduración y se recomienda que cuando los datos se
almacenan en el exterior, la pared china adecuada existe protección de control de
acceso, basada en los privilegios autorizados del solicitante, para evitar cualquier
conflicto de intereses. La protección de seguridad de la capa de transporte alivia los
datos pérdida mientras los datos están en movimiento entre su empresa y el
proveedor de SaaS.

Virtualización

La virtualización es una tecnología de software que divide un recurso físico (como

un servidor) en varios recursos virtuales llamados máquina virtual (VM). Se abstrae
recursos informáticos y reproduce las características físicas y el comportamiento de
los recursos. La virtualización facilita la consolidación de recursos físicos al tiempo
que simplifica la implementación y la administración. No solo lo físico los recursos
(servidores) se virtualizan, pero el almacenamiento de datos, las redes y las
aplicaciones pueden ser virtualizado, también. Cuando la tecnología de
virtualización aprovecha un único servidor para ejecutar múltiples sistemas
operativos, o múltiples sesiones de un solo sistema operativo, es comúnmente
conocido como virtualización de plataforma.
Las redes de área de almacenamiento (SAN) son un ejemplo de virtualización del
almacenamiento de datos.

La virtualización está ganando mucho terreno en la actualidad y se espera su

adopción para seguir aumentando en los próximos años. Algunos de los populares y
predominantes los productos de virtualización son VMWare, Microsoft Hyper-V y
Xen.
Los beneficios de la virtualización incluyen los siguientes:

■ Consolidación de recursos físicos (servidor) y, por tanto, reducción de costes.

■ Computación verde; potencia y refrigeración reducidas
■ Facilidad de implementación y administración
■ Aislamiento de aplicaciones, datos y plataformas
■ Mayor agilidad para escalar el entorno y los servicios de TI a la empresa.

Aunque la virtualización tiene como objetivo reducir los costos y mejorar la agilidad,
sin la debida consideración de la seguridad, estos objetivos pueden no lograrse y la
seguridad del ecosistema informático general puede debilitarse. Por tanto, es
imperativo determinar la seguridad y la protección de la virtualización antes de
seleccionar productos de virtualización. Por un lado, se puede argumentar que la
virtualización aumenta la seguridad porque las máquinas virtuales están aisladas
unas de otras y dependiente de un solo servidor host, lo que hace posible abordar la
seguridad física infracciones relativamente simples en comparación con tener que
administrar varios servidores independientes. Por otro lado, se puede decir que la
virtualización aumenta el ataque superficie porque el software de virtualización
conocido como el hipervisor, como se muestra en Figura 3.36, que controla y
administra las máquinas virtuales y su acceso a recursos del host, es un software
que podría tener errores de codificación y se ejecuta con derechos de acceso
privilegiado, haciéndolo susceptible a ataques.

Otras preocupaciones de seguridad de la virtualización que requieren atención

incluyen:

■ Implementar todos los controles de seguridad como antivirus, sistema escaneos,

cortafuegos, etc., como se haría en un entorno físico;
■ proteger no solo la VM sino también las imágenes de VM alterado
■ parchear y administrar todos los dispositivos de VM;
■ garantizar la protección contra el jailbreak de una máquina virtual. Se especula
que es posible atacar el hipervisor que controla las VM y evite la protección de
aislamiento que brinda la virtualización. Una vez que el hipervisor está
comprometido, uno puede saltar de (cárcel salir de) una VM a otra;
■ inspeccionar el tráfico entre máquinas virtuales mediante IDS e IPS, que a su vez
pueden Instancias de VM;
■ implementar controles de salvaguardia de defensa en profundidad;
■ controlar la expansión de VM. La expansión de VM es la proliferación incontrolada
de múltiples instancias de VM. Desperdicia recursos y crea sin supervisión
servidores que pueden contener datos confidenciales y hacen que la limpieza de
servidores innecesarios sea extremadamente difícil.

Además, es importante comprender que las tecnologías para administrar VM la

seguridad es todavía inmadura y actualmente está en desarrollo. Uno de esos
desarrollos es la API de seguridad de VM que permite ayudar a los equipos de
desarrollo de software aprovechar la funcionalidad de seguridad y la capacidad de
introspección dentro de la virtualización de productos. Sin embargo, las
consideraciones de rendimiento al utilizar la API de VM deben ser factorizado.

Gestión de derechos digitales (DRM)

¿Alguna vez ha experimentado la situación en la que decidió omitir el "FBI

Pantalla de advertencia antipiratería ”que aparece cuando carga una película en
DVD de la Región 1 y descubrió que no se le permitió hacerlo, como se ilustra en la
Figura 3.37.
Esto se conoce como bloqueo hacia adelante y es una medida de protección de
responsabilidad contra violadores que no pueden alegar ignorancia de las
consecuencias de su violación actuar. En este caso, se trata de infracción de
derechos de autor y protección contra la piratería. El bloqueo hacia adelante es un
ejemplo del uso de tecnología de un mecanismo de protección que se conoce
colectivamente como Gestión de derechos digitales (DRM).

DRM se refiere a una amplia gama de tecnologías y estándares que están dirigidos
en la protección de la propiedad intelectual (PI) y el uso de contenido de obras
digitales utilizando controles tecnológicos. Ley de derechos de autor (cubierta en
detalle en el Software capítulo de aceptación) es un control disuasorio solo contra
alguien que desea hacer una copia de un archivo o recurso protegido (documentos,
archivos de música, películas, etc.). No puede evitar que alguien haga una copia
ilegal. Es por eso que la protección basada en tecnología es necesaria y DRM
ayuda en este esfuerzo. DRM trata de proteger las obras digitales y difiere en su
función de la ley de derechos de autor. Derechos de autor la ley funciona
permitiendo todo lo que no está prohibido. DRM a la inversa opera prohibiendo todo
lo que no está permitido.

DRM no solo proporciona protección contra copias, sino que se puede configurar de
forma granular para proporcionar derechos de uso y garantizar la autenticidad y la
integridad también. Esto es particularmente importante cuando tiene la necesidad de
compartir archivos con un tercero a través de a quien no tiene control, como un
socio comercial o un cliente, pero aún así quiere controlar el uso de los archivos.
DRM proporciona una capa de presentación (capa OSI 6) seguridad no evitando
que un usuario no autorizado vea el archivo, sino impidiendo que la parte receptora
copie, imprima o comparta el archivo, incluso aunque se le permitirá abrirlo y verlo.
Una de las formas más comunes de el uso compartido de archivos está restringido
al vincular el archivo a un identificador de hardware único alguna propiedad de
hardware que no esté duplicada en otros sistemas. Esto significa que aunque el
archivo se pueda copiar, sigue siendo inutilizable en un sistema o por un usuario no
autorizado. Este tipo de mecanismo de protección es evidente en la música
comprada en la tienda iTunes. Música comprada en iTunes Store está autorizada
para usarse en una computadora y cuando se copia a otra, no funciona a menos
que se cuente con la autorización adecuada de la nueva computadora concedida.
DRM también asegura la autenticidad e integridad del contenido de un archivo,
porque proporciona la capacidad de controlar de forma granular el uso de un
archivo.

Las tres entidades centrales de una arquitectura DRM incluyen usuarios, contenido
y derechos. La implementación de DRM es posible gracias a las relaciones que
existen entre estas tres entidades centrales. Los usuarios pueden crear y / o utilizar
contenido y están concedido derechos sobre el contenido. La entidad usuaria puede
ser cualquiera; privilegiado o no privilegiado, empleado o no, socio comercial,
proveedor, cliente, etc. No es necesario que sea humano, ya que un sistema puede
participar en una implementación de DRM las entidades de contenido se refiere al
recurso protegido, como un archivo de música, un documento, o una película. La
entidad de derechos expresa permisos, restricciones y obligaciones que la entidad
de usuario tiene sobre la entidad de contenido. La expresión de derechos se hace
posible mediante el lenguaje formal, conocido como lenguaje de expresión de
derechos (REL).

Algunos Entre los ejemplos de REL se incluyen los siguientes:

■Open Digital Rights Language (ODRL): un lenguaje abierto y generalizado

estándar en desarrollo que expresa derechos usando XML.
■ Lenguaje de marcado de derechos extensible (XrML): otro lenguaje generalizado
REL que es más abstracto que ODRL. XrML es más un metalenguaje que se puede
utilizar para desarrollar otros REL.
■ Requisitos de publicación de metadatos estándar de la industria (PRISM): a
diferencia de ODRL y XrML, PRISM se puede utilizar para expresar derechos
específicos de una tarea y se utiliza para la distribución de medios impresos
contenido como periódicos y revistas. Esto se usa principalmente en un entorno de
empresa a empresa (B2B) donde las entidades comerciales tienen una relación
contractual y la parte REL de PRISM es utilizado para hacer cumplir la protección de
los derechos de autor.
Debe reconocerse que un REL expresa derechos, pero no tiene capacidad para
hacer valer los derechos. Por lo tanto, es fundamental para un arquitecto de
software diseñar un mecanismo de protección, ya sean datos proporcionados por el
usuario o propiedad de hardware, para restringir u otorgar derechos de uso. Toda la
solución DRM debe verse desde un punto de vista de seguridad para garantizar que
no haya ningún eslabón débil que pueda eludir la protección que proporciona DRM.

Si bien DRM ofrece muchos beneficios relacionados con la protección de la

propiedad intelectual, con algunos desafíos también. Algunos de los desafíos
comunes se enumeran a continuación:

■ Usar una propiedad de hardware como parte de la expresión de derechos

generalmente proporciona más seguridad y se recomienda. Sin embargo, dado que
la vida media del hardware no supera los dos años, vincular los mecanismos de
protección a una propiedad del hardware puede resultar en denegación de servicio
cuando se reemplaza el hardware. Vincular derechos de uso excesivo de contenido
a una persona alivia esta preocupación, pero es importante para garantizar que no
se pueda falsificar la identidad del individuo.
■ Usar datos personales para identificar de forma única a una persona como parte
de la solución DRM podría generar algunos problemas de privacidad. El Sony CD de
música rootkit es un ejemplo de diseño inadecuado que provocó a la empresa
perder la confianza del cliente, sufrir varias demandas colectivas, y recordar sus
productos.
■ DRM no solo prohíbe la copia ilegal, sino que también restringe y prohíbe copia
legal (copias de seguridad legítimas), lo que afecta a Fair Utilizar.

Cuando diseñe soluciones DRM, debe tener en cuenta tanto sus beneficios,
desafíos y consideraciones de seguridad deben estar a la vanguardia.

Computación confiable

En el capítulo de software seguro, cubrimos ciertos conceptos de computación

confiable como TCB, Trusted Boundary y Reference Monitor. En esta sección, se
centrará en algunas tecnologías informáticas fiables que se pueden utilizar para
asegurar confiar. Estas tecnologías incluyen la firma de código (cubierto en Secure
Software capítulo), Trusted Platform Modules (TPM) y tecnologías anti-malware.
Módulo de plataforma confiable (TPM)

Desarrollado por Trusted Computing Group (TCG), cuya misión es desarrollar y

admitir especificaciones industriales abiertas para una informática confiable en
múltiples tipos de plataforma, el TPM es una especificación utilizada en
computadoras personales y otras sistemas para garantizar la protección contra la
divulgación de información confidencial o privada así como la implementación de la
propia especificación. La implementación de la especificación, actualmente en la
versión 1.2, es un microcontrolador comúnmente referido como el chip TPM
generalmente adherido a la placa base (hardware).

Aunque el TPM en sí no controla qué software se ejecuta, el TPM proporciona

generación y almacenamiento a prueba de manipulaciones de claves criptográficas
que se pueden se utiliza para crear y almacenar credenciales de identidad (usuario
o plataforma) para la autenticación propósitos. Se puede usar un chip TPM para
identificar de forma única un dispositivo de hardware y proporcionar autenticación de
dispositivos basada en hardware. Puede ser complementario a las tarjetas
inteligentes y la biometría y, en ese sentido, facilita un fuerte multifactor
autenticación y permite la verdadera autenticación de la máquina y el usuario al
requerir la presentación de datos de autorización antes de divulgar información
sensible o privada información.

Los sistemas TPM ofrecen seguridad y protección mejoradas y agregadas contra

ataque de software externo o robo físico porque tienen en cuenta aspectos de
seguridad basados ​en hardware además de las capacidades de seguridad
proporcionadas por software. Sin embargo, debe entenderse que las claves y la
información confidencial almacenados en el chip TPM siguen siendo vulnerables a
la divulgación si el software que está solicitando esta información para su
procesamiento no está diseñado de forma segura, como ha sido demostrado en el
ataque del canal lateral de arranque en frío. Esto acentúa aún más el hecho de que
la seguridad del software es fundamental para garantizar una informática confiable.
El TPM puede también ser aprovechado por los desarrolladores de software para
aumentar la seguridad en el software que escribir utilizando la especificación de la
interfaz Trusted Software Stack (TSS) de TCG. El TCG también publica la
especificación Trusted Server (para la seguridad del servidor), Arquitectura de
Trusted Network Connect (para la seguridad de la red) y Mobile Trusted Module
(para seguridad informática móvil).
Los ataques de canal lateral, incluido el ataque de arranque en frío, se cubrirán en el
Capítulo de implementación, operaciones, mantenimiento y eliminación de software
en este libro.

Anti-malware

La confiabilidad, que es una composición de la confiabilidad, seguridad y privacidad

de un sistema o software, es cuestionada por malware y potencialmente programas
/ software no deseados (PUP/S). La economía del ciberdelito es una propuesta
lucrativa para los desarrolladores de malware y esto ha aumentado el número de los
ataques de malware que se observan en la industria de la tecnología de la
información.

Para abordar con éxito los problemas comerciales y de seguridad causados ​por
malware, es necesario un programa holístico de múltiples frentes. Esto incluye:

■ la implementación de motor anti-malware (tecnología),

■ un equipo (personas) de investigación antimalware capacitado
■ un mecanismo de actualización (proceso)

Vital para la estrategia anti-malware es el motor anti-malware del lado del cliente.
Este motor es el software necesario para detectar, contener y eliminar el malware
que intenta comprometer un sistema. Las funciones principales de este motor
anti-malware son:

■ escaneo
■ detección
■ cuarentena
■ eliminar y
■ restaurar

El primer paso en los motores anti-malware es escanear el sistema. Exploración

ayuda a monitorear diferentes ubicaciones en el sistema, incluidos los discos duros,
memoria, registro de configuración, etc. que el malware pretende infectar. Cuando el
sistema se escanea, es esencial asegurarse de que el alto nivel de rendimiento no
sea impactado adversamente.
La detección de malware se logra principalmente mediante dos técnicas. La primera
es hacer una comparación de patrones con lo que se conoce como lista de
definiciones. Al comparar con la lista de definiciones, el motor anti-malware detecta
y determina si el programa que intenta ejecutar es un PUP / S (malware) o no. La
lista de definiciones contiene los patrones (también conocidos como huellas
digitales) de malware conocido. Ciertos tipos de malware (por ejemplo, rootkits en
modo kernel) requieren analistas expertos y pueden requerir la asistencia de
expertos en la materia (PYME) en el equipo de investigación anti-malware. La
segunda técnica es analizar el comportamiento del malware (heurístico) y
correlacionar los comportamientos de malware conocidos. La heurística en el
contexto del anti-malware es el conjunto de reglas que son necesarias para
categorizar el malware.

El último paso en el motor anti-malware es manejar cualquier malware identificado.

para que la infección esté en cuarentena (contenida), el malware se elimina
(erradicado) y el sistema o software restaurado (recuperado) antes de la infección.
Es importante tener en cuenta que al poner en cuarentena o eliminar un rootkit, el
motor anti-malware no puede confiar en las llamadas API de los sistemas
operativos. Tunelización Las firmas hacen posible que el motor detecte
inconsistencias que indiquen que el sistema operativo está alterado. Te ayudan a
eludir las modificaciones de rootkit.

Además del motor anti-malware, es fundamental contar con un equipo de

investigación de antimalware capacitado, cuyo objetivo principal es investigar el
malware detectado por el motor anti-malware. Dado que muchos programas
maliciosos vienen empaquetados, están comprimidos, ofuscados para evitar el
análisis estático y algunos incluso cifrados para ocultar su funcionalidad interna, el
equipo debe estar bien versado en la realización análisis de malware, que incluye
desempaquetar, desofuscar, descifrar y revertir ingeniería del malware. El análisis
estático inspecciona las instrucciones del malware para identificar y contrarrestar las
técnicas que se utilizan en su ofuscación. Algunos los tipos de malware, como los
polimórficos, no son adecuados para el análisis estático, porque cada vez que se
ejecuta, el malware cambia a sí mismo (huellas dactilares y / o comportamiento). En
tales situaciones, el análisis dinámico, que examina el malware comportamiento
emulando el malware en una máquina virtual.

Luego hacen las recomendaciones necesarias para actualizar la lista de definiciones

con las últimas huellas dactilares que determinan a partir de su análisis.
Por último, es necesario actualizar la lista de definiciones de malware, no de forma
ad hoc manera pero mediante un proceso formalizado. Generalmente no es
suficiente simplemente eliminar el malware ya que sus interacciones pueden
provocar efectos secundarios.

Se recomienda incorporar el proceso de actualización de huellas dactilares de

malware como parte integral del proceso de actualización de la infraestructura
existente, de modo que no impactar la productividad del usuario.

Las tecnologías anti-malware también deberían permitir al equipo de operaciones de

seguridad, información sobre el estado de seguridad del ecosistema informático. En
la protección de acceso, en el que se analiza el archivo antes de abrirlo, combinado
con tiempo real son necesarias las protecciones que controlan decenas de controles
de seguridad.

Seguridad de la base de datos

Tan importante como el diseño de datos para la seguridad es el diseño de la base

de datos para la confiabilidad, resiliencia y recuperabilidad del software que
depende de la datos almacenados en la base de datos. La protección no solo es
esencial cuando los datos están en tránsito, pero también cuando está en reposo,
en almacenamiento y archivos. Usando un biológico analogía, se puede llamar
corazón a la base de datos que está conectada a la red de la empresa, y una brecha
en esta capa podría resultar desastrosa para la vida y continuidad del negocio. Las
regulaciones como HIPAA y GLBA imponen requisitos para proteger la información
de identificación personal (PII) cuando se almacenan, y la negligencia intencional
puede dar lugar a la imposición de multas, el encarcelamiento de los oficiales de la
corporación y supervisión regulatoria. La capa de aplicación parece ser el conducto
de ataques contra los datos almacenados en bases de datos o almacenes de datos,
como es evidente con muchos ataques de inyección, como Structured Query
Language (SQL) Inyección y ataques de inyección de Protocolo ligero de acceso a
directorios (LDAP), cubierto con más detalle en el capítulo Implementación segura
de software. Utilizando tales ataques, un atacante puede robar, manipular o destruir
datos.

Las consideraciones de diseño de seguridad de la base de datos son de vital

importancia porque tienen un impacto en la confidencialidad, integridad y
disponibilidad de los datos. Un tipo de ataque contra la confidencialidad de los datos
es el ataque de inferencia.
Un ataque de inferencia es aquel que se caracteriza por un atacante que obtiene
información sobre la base de datos de piezas presumiblemente ocultas y triviales de
información utilizando técnicas de minería de datos, sin acceder directamente al
base de datos. Es difícil protegerse contra un ataque de inferencia, porque lo trivial
El atacante puede obtener legítimamente información. Los ataques suelen ir de la
mano de los ataques de agregación. Un ataque de agregación es uno donde la
información en diferentes niveles de clasificación de seguridad, que son
principalmente no sensibles de forma aislada, terminan convirtiéndose en
información sensible cuando se ensambla como un todo. Un ejemplo bien conocido
de agregación es la combinación de coordenadas longitudinales y latitudinales junto
con información de suministros y entrega para reconstruir y recoger posibles
ubicaciones del ejército. Individualmente, las coordenadas longitudinales y
latitudinales generalmente no son sensibles. Tampoco lo es la información de
suministros y entrega. Pero cuando estos se agregan dos piezas de información, la
agregación puede revelar información sensible información a través de inferencia.
Por lo tanto, las consultas de bases de datos que solicitan y la información no
sensible de varias tablas dentro de la base de datos debe ser cuidadosamente
diseñada para ser examinada, monitoreada y auditada.

Polyinstantiation, cifrado de bases de datos, normalización y disparadores y Las

vistas son importantes, las consideraciones de diseño de protección relativas a la
activos de la base de datos.

Polyinstantiation

Un enfoque de seguridad de base de datos bien conocido para tratar los problemas
de inferencia y la agregación es Polyinstantiation. Polyinstantiation significa que
existen varias instancias (o versiones) de la información de la base de datos, de
modo que lo que se ve por un usuario depende de la autorización de seguridad o los
atributos del nivel de clasificación del usuario solicitante. Por ejemplo, muchas
instancias del teléfono del presidente el número se mantiene en diferentes niveles
de clasificación y solo los usuarios con se permitirá autorización secreta para ver el
número de teléfono del presidente de la país, mientras que aquellos que no tienen
autorización reciben un número de teléfono genérico para ver. Polyinstantiation
aborda los ataques de inferencia al permitir un medio para ocultar información
mediante etiquetas de clasificación. Aborda la agregación al permitir los medios para
etiquetar diferentes agregaciones de datos por separado.
Cifrado de base de datos

Las defensas perimetrales, como los firewalls, ofrecen poca o ninguna protección a
las datos de agentes de amenazas internos, que tienen los medios y la oportunidad
de acceder y explotar datos almacenados en bases de datos. La amenaza para las
bases de datos no solo proviene de piratas informáticos externos, sino también de
personas internas que desean comprometer los datos, los datos que son
esencialmente las joyas de la corona de una empresa. De hecho, mientras externo
los ataques pueden verse en las noticias, muchos ataques internos a menudo no se
publican, a pesar de que son igualmente, si no más, devastadores para una
empresa. La persona enterada de las amenazas a las bases de datos merecen
especial atención, especialmente las de personas descontentas. empleados en una
economía de despidos. Sin los controles de seguridad de la base de datos
adecuados, dejar a una empresa sin vigilancia y que depende únicamente del
motivo de una persona con información privilegiada, que ya tiene los medios y la
oportunidad.

El cifrado de datos en reposo es un mecanismo de control preventivo que puede

proporcionar fuerte protección contra la divulgación y alteración de datos, pero es
importante para garantizar que, junto con el cifrado de la base de datos, la
autenticación y existen mecanismos de protección de control de acceso para
asegurar la clave que se utiliza para el cifrado. Tener uno sin el otro equivale a
cerrar la puerta y dejar la llave debajo del felpudo, y esto realmente proporciona
poca protección. Por lo tanto, es necesaria una estrategia de cifrado de base de
datos adecuada para implementar seguridad de la base de datos adecuadamente.
Esta estrategia debe incluir cifrado, acceso control, auditoría de seguridad y registro
de operaciones de base de datos de privilegios y eventos y planificación de
capacidad.

El cifrado no solo tiene un impacto en el rendimiento, sino también en el tamaño de

los datos. Si los campos de la base de datos que están indexados se cifran, luego
las consultas de búsqueda y las búsquedas llevarán mucho más tiempo,
degradando el rendimiento. Adicionalmente, la mayoría de los algoritmos de cifrado
generan tamaños de bloque fijos y rellenan los datos de entrada para coincidir con
el tamaño de salida. Esto significa que los datos de entrada de menor tamaño se
rellenarán y almacenados con un tamaño mayor y el diseño de la base de datos
debe tener esto en cuenta cuenta para evitar problemas de relleno y truncamiento.
Para transformar texto cifrado binario a datos de tipo carácter donde la codificación
se utiliza con cifrado, el tamaño de los datos es aumentado en aproximadamente un
tercio de su tamaño original, y esto debe tenerse en cuenta en diseño, también.

Algunos de los factores importantes que deben tenerse en cuenta cuando se

determina la estrategia de cifrado de la base de datos se enumeran a continuación.
Estos incluyen, pero no se limitan a lo siguiente:

■ Dónde deben cifrarse los datos: en su punto de origen en el

aplicación o en la base de datos donde reside?
■ ¿Cuál debería ser el nivel mínimo de clasificación de datos antes
garantiza protección mediante cifrado?
■ ¿La base de datos está diseñada para manejar tamaños de datos mediante
encriptación?
■ ¿Está la empresa consciente del impacto en el rendimiento de implementar
cifrado y es el compromiso entre rendimiento y seguridad
dentro de los umbrales aceptables para el negocio?
■ ¿Dónde se almacenarán las claves utilizadas para las operaciones de
criptografía?
■ ¿Qué medidas de autenticación y control de acceso serán
implementado para proteger la clave que se utilizará para el cifrado y
descifrado?
■ ¿Están controladas y controladas las personas que tienen acceso a la base de
datos?
monitoreado?
■ ¿Existen políticas de seguridad vigentes para implementar auditorías de
seguridad?
y registro de eventos en la capa de la base de datos para detectar información
privilegiada
amenazas y actividades fraudulentas?
■ Si hay una violación de la base de datos, ¿hay algún incidente?
plan de manejo para contener el daño y responder a la
¿incidente?

El cifrado de la base de datos se puede lograr de dos formas. Estos son

■ Usando el cifrado nativo del Sistema de administración de bases de datos (DBMS)

■ Aprovechar los recursos criptográficos externos a la base de datos.
En el cifrado DBMS nativo, las operaciones criptográficas, incluida la clave el
almacenamiento y la gestión se gestionan dentro de la propia base de datos.
Criptográfico las operaciones son transparentes para la capa de aplicación y este
tipo de cifrado es comúnmente conocido como Cifrado transparente de base de
datos (TDE). El primario el beneficio de este enfoque es que el impacto en la
aplicación es mínimo pero puede haber un impacto sustancial en el rendimiento.
Cuando el cifrado DBMS nativo se utilizan capacidades, el rendimiento y la fuerza
del algoritmo. Debe tenerse en cuenta la flexibilidad para elegir qué datos se pueden
cifrar un punto de vista de seguridad, el principal inconveniente de usar cifrado
DBMS nativo es la debilidad inherente que existe en el almacenamiento de la clave
de cifrado dentro el propio DBMS. La protección de esta clave dependerá
principalmente de la fuerza de los mecanismos de protección de control de acceso
DBMS, pero los usuarios que han el acceso a los datos cifrados probablemente
tendrá derechos de acceso al cifrado almacenamiento de claves, también. Cuando
los recursos criptográficos externos a la base de datos se aprovechan, las
operaciones criptográficas y el almacenamiento y la gestión de claves son
descargados a servidores e infraestructura criptográfica externos. De una seguridad
punto de vista, arquitecturas de base de datos que separan el procesamiento de
cifrado y la clave se recomiendan y prefieren la administración, ya que dicha
arquitectura aumenta el factor de trabajo necesario para el atacante. La separación
de los datos cifrados de las claves de cifrado aportan un beneficio de seguridad
significativo. Cuando estas llaves son almacenadas en módulos de seguridad de
hardware (HSM), aumentan la protección de seguridad sustancialmente y hacen
necesario que el atacante tenga acceso físico para comprometer las claves.
Además, aprovechando la infraestructura externa y los servidores para operaciones
criptográficas alejan la sobrecarga computacional del DBMS, aumentando
significativamente el rendimiento. Los principales inconvenientes de este enfoque
son la necesidad de modificar o cambiar aplicaciones, monitorear y administrar otros
servidores y la sobrecarga de comunicaciones.

Cada enfoque tiene sus propias ventajas y desventajas y al elegir el enfoque de

cifrado de la base de datos, es importante hacerlo solo después de comprender los
pros y los contras de cada enfoque, las necesidades comerciales, requisitos y
estrategia de seguridad de la base de datos.
Normalización

La mantenibilidad y seguridad de una base de datos son directamente

proporcionales a su organización de datos. Los datos redundantes en las bases de
datos no solo desperdician el almacenamiento, sino también implica la necesidad de
mantenimiento redundante, así como la posibilidad de inconsistencias en los
registros de la base de datos. Por ejemplo, si los datos se mantienen en múltiples
ubicaciones (tablas) en la base de datos, los cambios a los datos deben realizarse
en todas las ubicaciones que contienen los mismos datos. El cambio en el precio de
un producto es mucho más fácil de implementar si el precio del producto se
mantiene solo dentro del tabla de productos. Mantener la información del producto
en más de una tabla en el base de datos requerirá implementar cambios a la
información relacionada con el producto en cada mesa. Esto no solo puede ser un
problema de mantenimiento, sino también, si las actualizaciones no se aplican de
manera uniforme en todas las tablas que contienen información de productos,
pueden producirse inconsistencias que conduzcan a la pérdida de la integridad de
los datos.

La normalización es una técnica formal que se puede utilizar para organizar datos
que se elimine la redundancia y la inconsistencia. La organización de los datos está
basada en ciertas reglas y cada regla se conoce como una "forma normal". Existen
principalmente tres reglas de normalización o organización de datos. El diseño de la
base de datos es se dice que está en la forma normal que corresponde al número
de reglas del diseño cumple con. Se sabe que un diseño de base de datos que
cumple con una regla en la primera forma normal, anotada como 1NF Se sabe que
un diseño con dos reglas en la segunda forma normal, anotada como 2NF, y una
con cumplimiento de las tres Se sabe que las reglas están en tercera forma normal,
anotadas como 3NF. Cuarto (4NF) y También existe la Quinta Forma Normal (5NF)
de diseño de bases de datos, pero rara vez se implementa prácticamente.

Primera forma normal (1NF) exige que no haya campos repetidos o grupos de
campos dentro de una tabla. Esto significa que los datos relacionados se almacenan
por separado. Esto también se conoce informalmente como la regla de “No se
permiten grupos repetidos”. Cuando la información del producto se mantiene para
cada registro de cliente por separado en lugar de repetirse dentro de una tabla, se
dice que cumple con 1NF.

La segunda forma normal (2NF) exige que se eliminen los datos duplicados. UN
La tabla en 2NF debe estar primero en 1NF. Esto también se conoce informalmente
como la regla "Eliminar datos redundantes". La eliminación de registros duplicados
en cada La tabla aborda la inconsistencia de los datos y, posteriormente, los
problemas de integridad de los datos 2NF significa que los conjuntos de valores que
se aplican a varios registros se almacenan en tablas y relacionadas usando una
relación de clave primaria (PK) y clave externa (FK).

En la tabla anterior, Product_Code no depende del Customer_ID PK, por lo que,

para cumplir con 2NF, deben almacenarse por separado y asociado mediante una
tabla.

Las tablas 3.9 y 3.10 son ejemplos de tablas que están en 2NF.
La tercera forma normal (3NF) es una extensión lógica de la 2NF y para una tabla
para estar en 3NF, primero debe estar en 2NF. 3NF exige que los datos no
dependen de la PK de identificación única de esa tabla se eliminan y mantenidos en
tablas propias. Esto también se conoce informalmente como el Regla “Eliminar
datos duplicados no dependientes de claves”. Dado que Sales_Rep_ID no depende
de Customer_ID en la tabla CUSTOMER, para que la tabla Estar en 3NF, los datos
sobre los representantes de ventas deben mantenerse en su propia tabla.

de problemas de inconsistencia. La normalización también produce beneficios de

seguridad. Datos integridad, que asegura que los datos no solo sean consistentes
sino también precisos, se puede lograr mediante la normalización. Además, los
permisos para la base de datos las operaciones se pueden otorgar a un nivel más
granular por tabla y limitado a los usuarios, cuando los datos se organizan en forma
normal. Integridad de datos en el contexto de normalización es la garantía de datos
consistentes y precisos dentro de una base de datos.

También debe reconocerse que si bien la seguridad y el mantenimiento de la base

de datos los beneficios de la normalización son dignos de mención, hay un
inconveniente principal para la normalización, que es un rendimiento degradado.
Cuando datos que no están organizados en una forma normalizada, el impacto en el
rendimiento depende principalmente en el tiempo que se tarda en leer los datos de
una sola tabla, pero cuando la base de datos los registros están normalizados, es
necesario unir varias tablas para datos solicitados. Para aumentar el rendimiento,
una decisión consciente puede ser necesaria para desnormalizar una base de datos
normalizada. La desnormalización es el proceso de disminuir la forma normal de
una tabla de base de datos modificando su estructura para permitir datos
redundantes de manera controlada. Una base de datos desnormalizada no es lo
mismo que una base de datos que nunca se ha normalizado. Sin embargo cuando
los datos están desnormalizados, es de vital importancia tener un control externo y
mecanismos de protección que aseguren la coherencia, precisión e integridad de los
datos. La alternativa preferida a la desnormalización de datos en reposo es
implementar vistas de base de datos.

Disparadores

Un disparador de base de datos es un tipo especial de procedimiento que se ejecuta

automáticamente ante la ocurrencia de ciertas condiciones dentro de la base de
datos. Se diferencia de un procedimiento regular en su forma de invocación.
Procedimientos regulares almacenados y declaraciones preparadas se activan
explícitamente para que las ejecute un usuario, una aplicación, o, en algunos casos,
incluso por un disparador en sí. Un gatillo, por otro lado, se dispara para ejecutar
implícitamente por la base de datos cuando ocurre el evento desencadenante.
Eventos que disparan Los desencadenantes pueden ser uno o más de los
siguientes tipos:

■ Declaraciones de lenguaje de manipulación de datos (DML) que modifican

datos, como INSERT, UPDATE y DELETE.
■ Declaraciones de lenguaje de definición de datos (DDL) que se pueden utilizar
para
realizar tareas administrativas en la base de datos, como auditorías
y regular las operaciones de la base de datos.
■ Eventos de error (OnError).
■ Eventos del sistema, como Inicio, Apagado, Reinicio, etc.
■ Eventos de usuario, como inicio de sesión, cierre de sesión, etc.

Los disparadores son útiles no solo para complementar las capacidades de bases
de datos existentes pero también pueden resultar muy útiles para automatizar y
mejorar la protección de la seguridad mecanismos. Los disparadores se pueden
utilizar para:

■ Hacer cumplir reglas comerciales complejas, como restringir las alteraciones

base de datos durante el horario no comercial o computación automática
las tarifas de envío internacional cuando la tasa de conversión de moneda
cambios.
■ Evite transacciones no válidas.
■ Asegurar operaciones de integridad referencial.
■ Proporcionar auditoría y registro de eventos automatizados y transparentes
capacidades. Si una transacción comercial crítica que requiere auditoría
se realiza, se pueden usar activadores DML para registrar la transacción
junto con los campos de auditoría pertinentes en la base de datos.
■ Hacer cumplir los privilegios y derechos de seguridad complejos.
■ Sincronizar datos en tablas y bases de datos replicadas, asegurando
la exactitud e integridad de los datos.

Aunque los beneficios funcionales y de seguridad del uso de activadores son

muchos, los disparadores deben diseñarse con precaución. Implementación
excesiva de disparadores puede causar una lógica de aplicación demasiado
compleja, lo que dificulta el software mantener además de aumentar la superficie de
ataque potencial. Además, dado que desencadenan los eventos desencadenantes,
no pueden realizar confirmaciones ni reversiones operaciones y disparadores mal
construidos pueden causar mutaciones en la tabla y los datos, impactando la
precisión y la integridad. Además, cuando se dispara en cascada, que se
caracterizan por que los disparadores invocan otros disparadores, se utilizan,
interdependencias aumentan, lo que dificulta la resolución de problemas y el
mantenimiento.

Puntos de vista

Una vista de base de datos es una presentación personalizada de datos que pueden
guardarse en una o tablas más físicas (tablas base) u otra vista, en sí. Una vista es
el resultado de una consulta y es similar a una tabla virtual o consulta almacenada.
Se dice que una vista es virtual porque a diferencia de las tablas base que
proporcionan datos a la vista, la vista en sí es no tiene asignado ningún espacio de
almacenamiento en la base de datos física. El único espacio que es asignado es el
espacio necesario para contener la consulta almacenada. Porque los datos en un
vista no se almacena físicamente, una vista se construye dinámicamente cuando la
consulta para generar la vista se ejecuta. Al igual que en una mesa base, DML
CRUD (crear, leer, actualizar y eliminar) operaciones para insertar, ver, modificar o
eliminar datos, con algunas restricciones, se puede realizar en vistas. Pero debe
entenderse que las operaciones realizadas en la vista afectan las tablas base que
sirven los datos por lo que deben tenerse en cuenta las mismas restricciones de
integridad de datos cuando lidiar con las opiniones.

Dado que las vistas se construyen dinámicamente, los datos que se presentan se
pueden personalizar para los usuarios en función de sus derechos y privilegios. Esto
hace posible que protección contra la divulgación de modo que solo aquellos que
tengan la autorización para ver ciertos tipos de datos tienen permitido ver esos tipos
de datos, y que no se les permite ver ningún otro dato. Las vistas no solo brindan
confidencialidad seguridad, también apoyan el principio de "necesidad de saber".
Restringir el acceso a conjuntos predeterminados de filas o columnas de una tabla
aumenta el nivel de seguridad de la base de datos. La figura 3.38 es un ejemplo de
una vista que resulta de unir el Tablas de CATEGORÍA, PRODUCTO y PEDIDO.

Las vistas también se pueden utilizar para abstraer la estructura interna de la base
de datos, ocultando la fuente de datos y la complejidad de las uniones. Una vista de
combinación se define como una que sintetiza la presentación de datos uniendo
varias tablas base o vistas. Las estructuras, relaciones y restricciones internas de la
tabla están protegidas y ocultas al usuario final. Incluso un usuario final que no tiene
conocimiento de cómo realizar uniones puede utilizar una vista para seleccionar
información de varios objetos de la base de datos. Además, se puede cambiar el
nombre de las columnas resultantes de una vista para ocultar la convención de
nomenclatura de bases de datos que un atacante puede utilizar para su beneficio al
realizar el reconocimiento. Las vistas también se pueden utilizar para ahorrar
consultas. Las consultas que realizan cálculos extensos son buenos candidatos
para guardarse como vistas para que se puedan realizar repetidamente sin tener
que reconstruir la consulta cada vez.

Gestión de privilegios

En el contexto de una base de datos, un privilegio es el derecho (o permiso) para

realizar una operación de la base de datos, como seleccionar (leer) registros,
actualizar o alterar (escribir) registros o esquematizar, ejecutar, agregar (crear)
usuario, o eliminar registros, etc.
Los permisos se otorgan a los usuarios, procesos y objetos de la base de datos para
realizar estas operaciones. Los permisos se pueden otorgar a un usuario
explícitamente o a un rol, para al que pertenece el usuario. Un ejemplo de un
usuario que obtiene privilegios directamente es cuando el usuario Paul puede
insertar o actualizar la tabla "Libro" en la base de datos. Un ejemplo de
administración de privilegios basada en roles es cuando los usuarios Paul y Johnson
ambos tienen permiso para actualizar la tabla "Libro" porque pertenecen al rol de
“Autor”.

Por lo general, no es aconsejable otorgar (asignar) privilegios a un usuario

directamente. Se prefieren los roles para la gestión de privilegios, ya que facilita la
gestión de permisos asignados a los usuarios. Dentro de una base de datos, cada
rol debe ser único y diferente de los nombres de inicio de sesión (usuario) y
cualquier otro nombre de función. En la mayoría de las bases de datos sistemas de
gestión (DBMS), los roles no están contenidos en el esquema. Esta permite eliminar
a un usuario que crea un rol sin ningún impacto en el papel en sí.

Cuando se utilizan roles para administrar permisos, el software debe estar diseñado
teniendo en cuenta principios de seguridad como el privilegio mínimo y la
separación de funciones. Un ejemplo de implementación de privilegios mínimos
dentro de la base de datos es el uso de El rol de "lector de datos" o "redactor de
datos" en lugar del rol de propietario de la base de datos ("dbo"). Un Un ejemplo de
separación de funciones dentro de la base de datos es que el usuario Johnson es
no forma parte de la función de "Autor" y "Aprobador".

Entorno del lenguaje de programación antes de escribir una sola línea de código, es
fundamental determinar la programación lenguaje que se utilizará para implementar
el diseño, porque una programación el lenguaje puede traer consigo riesgos
inherentes o beneficios de seguridad. En empresas con un nivel inicial de madurez
de capacidad, los desarrolladores tienden a elegir el lenguaje de programación con
el que están más familiarizados o uno que es popular y nuevo. Está es mejor
asegurarse de que el lenguaje de programación elegido sea uno que forme parte de
la tecnología o el estándar de codificación de la empresa, de modo que el software
producido puede ser soportado y mantenido universalmente.

Elegir el lenguaje de programación apropiado es un diseño importante a considerar.

Puede ser necesario un lenguaje de programación de código no administrado
cuando la ejecución debe ser rápida y la asignación de memoria debe ser
explícitamente revisado. Sin embargo, es importante reconocer que tales grados de
control total también puede llevar a un compromiso total cuando se produce una
violación de seguridad, por lo que se debe prestar atención al elegir una
programación de código no administrado. Una estrategia para obtener los beneficios
de ambos lenguajes de programación de código administrados y no administrados
es codificar el software en un lenguaje de código administrado y llame al código no
administrado usando envoltorios solo cuando necesario, con mecanismos de
protección de defensa en profundidad implementados al mismo tiempo.

También debe entenderse que si bien los lenguajes de programación de código

administrado son menos propensos a errores causados ​por la ignorancia de los
desarrolladores y / o la seguridad problemas, no es una panacea para las amenazas
y vulnerabilidades de seguridad. Sin tener en consideración si uno elige un lenguaje
de programación de código administrado o no administrado, los mecanismos de
protección de seguridad deben diseñarse cuidadosa y explícitamente.

Mientras que los mecanismos de protección como cifrado, hash y enmascaramiento

ayuda con la garantía de confidencialidad, el tipo de datos, el formato, el rango y la
longitud son importantes consideraciones de diseño, cuya falta puede conducir
potencialmente a violaciones de la integridad.

Los lenguajes de programación tienen lo que se conoce como datos primitivos o

integrados. Algunos ejemplos comunes de tipos de datos primitivos son Carácter
(carácter, char), entero (entero, int, corto, largo, byte), números de coma flotante
(doble, float, real) y booleano (verdadero o falso). Algunos lenguajes de
programación también permiten programadores para definir su propio tipo de datos,
que no se recomienda desde un punto de vista de la seguridad, porque
potencialmente aumenta la superficie de ataque. Por el contrario, Los lenguajes de
programación fuertemente tipados no permiten al programador definir sus propios
tipos de datos para modelar objetos reales y esto es preferible de una seguridad
punto de vista, ya que no permite al programador aumentar la superficie de ataque.

El conjunto de valores y las operaciones permitidas en ese conjunto de valores se

definen por el tipo de datos. Por ejemplo, una variable que se define como un tipo
de datos entero se le puede asignar un número entero pero nunca una fracción. Los
enteros pueden estar firmados o no firmados. Los enteros sin signo son aquellos
que solo permiten valores positivos mientras los enteros con signo permiten valores
tanto positivos como negativos. La Tabla 3.13 describe el tamaño y rangos de
valores que dependen del tipo de datos enteros.
La razón por la que el tipo de datos es una consideración de diseño importante es
porque no solo es importante comprender los límites que se pueden almacenar en la
memoria para una variable definida como un tipo de datos en particular, pero
también es vital conocer

operaciones permitidas en un tipo de datos. No comprender el tipo de datos

permitido las operaciones pueden generar discrepancias en las conversiones y
errores de conversión o de conversión que podría resultar perjudicial para el estado
seguro del software.

Cuando un tipo de datos numéricos se convierte de un tipo de datos a otro, puede

ser una conversión de ampliación (también conocida como expansión) o una
reducción conversión (también conocida como truncamiento). Las conversiones de
ampliación son aquellas en las que el tipo de datos se convierte de un tipo que es
de un tamaño y rango más pequeños a uno que es de mayor tamaño y rango. Un
ejemplo de conversión de ampliación sería convertir un "int" en un "largo". La tabla
3.14 ilustra la ampliación de las conversiones sin la pérdida de los datos.
No todas las conversiones de ampliación ocurren sin la posible pérdida de datos. En
algunos casos, no solo es evidente la pérdida de datos, sino que también hay una
pérdida de precisión. Por ejemplo, convertir de un tipo de datos Int64 o singular a
datos dobles el tipo puede provocar una pérdida de precisión.

Una conversión estrecha, por otro lado, puede conducir a la pérdida de información.
Un ejemplo de conversión de restricción es convertir un tipo de datos Decimal en un
Tipo de datos entero. Esto puede causar potencialmente el truncamiento de la
pérdida de datos si el valor almacenado en el tipo de datos Integer es mayor que su
rango permitido. Por ejemplo, cambiar el tipo de datos de la variable, "Precio
Unitario", que contiene el valor, $19,99, de un tipo de datos decimal a un tipo de
datos Integer resultará en almacenar $19 solo, ignorar los valores después del
decimal y causar problemas de integridad de los datos. Incorrecto la transmisión o
conversión puede resultar en excepciones de desbordamiento o pérdida de datos.
Longitud de entrada y validación de rango usando expresión regular (RegEx) y
longitud máxima (longitud máxima), junto con la protección de gestión de
excepciones controles, deben diseñarse para aliviar estos problemas.

Los dos tipos principales de lenguajes de programación en el mundo actual se

pueden clasificar en lenguajes de código administrados o no administrados.
Ejemplos comunes de no administrado el código es C / C ++ mientras que Java y
todos los lenguajes de programación .NET, que incluyen C # y VB. Net son ejemplos
de lenguajes de programación de código administrado.

Los lenguajes de programación de código no administrados son aquellos que tienen

la siguientes características:

■ La ejecución del código no es administrada por ninguna ejecución en tiempo de

ejecución entorno, pero es ejecutado directamente por el sistema operativo. Esta
hace que la ejecución sea relativamente más rápida.
■ Está compilado en código nativo, que se ejecutará solo en el procesador.
arquitectura (X86 o X64) con la que se compila.
■ La asignación de memoria no se administra y los punteros en la memoria Las
direcciones se pueden controlar directamente, lo que hace que estas lenguajes de
programación más susceptibles a desbordamientos de búfer y formatear las
vulnerabilidades de las cadenas que pueden conducir a código arbitrario ejecución
anulando punteros de memoria.
■ Requiere que los desarrolladores escriban rutinas para manejar la asignación de
memoria, comprobar los límites de la matriz, manejar conversiones de tipos de
datos explícitamente, forzar recolección de basura, etc., lo que lo hace necesario
para los desarrolladores tener más habilidades de programación y capacidades
técnicas.

Los lenguajes de programación de código administrado, por otro lado, tienen la

siguientes características:

■ La ejecución del código no la realiza el sistema operativo directamente, sino en

su lugar, es mediante un entorno de ejecución administrado. Desde la ejecución es
administrado por el entorno de ejecución, seguridad y no seguridad servicios como
administración de memoria, manejo de excepciones, límites control, recolección de
basura y control de seguridad de tipo se pueden aprovechar del entorno de
ejecución y los controles de seguridad pueden ser afirmado antes de que se ejecute
el código. Estos servicios adicionales pueden hacer que el código se ejecute
considerablemente más lento que el mismo código escrito en un lenguaje de
programación de código no administrado.
■ No se compila directamente en código nativo, sino que se compila en un lenguaje
intermedio común (CIL) y / o código de bytes antes de la creación del ejecutable.
Cuando se ejecuta el ejecutable, el la compilación Just-in-Time (JIT) transforma el
CIL en nativo código que la computadora entenderá. Esto permite la plataforma
independencia, ya que el compilador JIT maneja la compilación del CIL o bytecode
en código nativo que es arquitectura de procesador específico.
■ Dado que la asignación de memoria la administra el entorno de ejecución,
se mitigan los desbordamientos de búfer y las vulnerabilidades de cadenas de
formato importantemente.
■ El tiempo para desarrollar software es relativamente más corto ya que la mayor
parte de la memoria gestión, manejo de excepciones, verificación de límites, basura
la recopilación y la verificación de seguridad de tipo son manejadas
automáticamente por el entorno de ejecución.

Lenguaje común del tipo de ejecución (CLR)

El entorno de tiempo de ejecución administrado en. NET Framework es el Lenguaje

común del tiempo de ejecución (CLR). Es la implementación de Microsoft estándar
común de infraestructura de lenguaje (CLI). Es esencialmente una máquina virtual
que es parte de. Net Framework. Funciona convirtiendo el programador código
fuente en un lenguaje intermedio común (CIL). Esto alivia la restricción impuesta a
los programadores para elegir un idioma particular para codificar su software.
Siempre que el código se compile en un formato CIL, CLR puede procesar, ese
lenguaje se puede utilizar para la programación.

Luego, durante la ejecución del programa, el compilador Justo a Tiempo (JIT) de

CLR transforma el CIL en instrucciones de máquina para su ejecución por parte del
procesador. El CLR también proporciona otros servicios como gestión de memoria,
seguridad de tipos, seguridad de acceso al código, recolección de basura y manejo
de excepciones (todos los cuales son cubierto con más detalle en el capítulo
Implementación segura de software).

El CLR de. Net Framework tiene su propio modelo de ejecución de seguridad

separado que complementa la seguridad que brinda el sistema operativo en el que
se está corriendo. A diferencia de la seguridad tradicional basada en el principal
(usuario) impuesta por sistema operativo, el CLR tiene la capacidad de hacer
cumplir un modelo de seguridad que está basado en políticas. Esto generalmente se
conoce como seguridad de acceso al código (cubierto en más detalles en el capítulo
Implementación segura de software). Funciona calculando permisos y pruebas
basadas en los atributos del código (como URL, sitio, directorio de aplicaciones,
Zona, Nombre seguro, Editor, Hash, etc.) en lugar de simplemente hacer cumplir la
decisión de seguridad en función de quién es el usuario.

La cobertura del CLR es un detalle explícito que está más allá del alcance de este
libro, pero es recomendable que esté familiarizado con los mecanismos de
aplicación de la seguridad del CLR, si está comprometido con el desarrollo de
software utilizando. Net marco de referencia.

Máquina virtual Java (JVM)

En Java, el entorno de ejecución administrado también se conoce como Java tiempo

de ejecución Medio Ambiente (JRE). Uno de los componentes principales del JRE
es Java Máquina virtual (JVM). Además de la JVM, las clases de paquetes Java
(como math, lang, util, etc.) y algunas bibliotecas en tiempo de ejecución conforman
el JRE. Es la JVM que carga y ejecuta programas Java y aporta a Java,
independencia de plataforma, movilidad y seguridad.

La JVM es una implementación de la especificación de máquina Java, que ha

definido en él, algunos de los aspectos importantes de la seguridad del JRE. Estas
incluir la
■ formato de archivo Java Class,
■ Conjunto de instrucciones y lenguaje Java Bytecode,
■ Cargador de clases,
■ Verificador de código de bytes
■ Administrador de seguridad de Java (JSM)
■ Recolector de basura.

El archivo Java Class (.class) define el formato en el que se almacenan las clases
Java y se accede de forma independiente a la plataforma. La seguridad de la JVM
exigir que los archivos .class desarrollados por el programador estén en el archivo
formato clase. El lenguaje Java Bytecode incluye en él los conjuntos de
instrucciones necesarios para realizar operaciones de máquina de bajo nivel, como
valores push y pop en y desde la pila, manipulando los registros de la CPU y
realizando operaciones aritméticas y lógicas operaciones. El cargador de clases es
un objeto de tiempo de ejecución de Java que se utiliza para cargar Java clases en
la JVM. Comprueba para asegurarse de que la clase cargada no esté falsificada o
redefinido por un atacante. Solo después de que estos controles sean exitosos, el
cargador carga la clase en la JVM, después de lo cual la JVM llama al Bytecode
verificador. Podría decirse que Bytecode Verifier es el componente más importante
de la JVM desde un punto de vista de coherencia de tipos. El verificador de
Bytecode comprueba ver si los archivos .class están en el formato de archivo de
clase y verifica dos veces para asegurarse que no hay instrucciones maliciosas en
el código que comprometan las reglas de seguridad de tipos en Java. Se puede
considerar como el guardián de la JSM. Si las comprobaciones de coherencia del
tipo de Bytecode son correctas, el Bytecode se compila Just-in-Time (JIT) para
ejecutar. Si alguna de las instrucciones del código intenta llamar el sistema operativo
nativo, fuera del límite de la zona de pruebas de la aplicación, luego, el JSM
monitorea estas llamadas y media el acceso, permitiendo o denegando acceso,
basado en la política de seguridad configurada. Durante la ejecución del programa
Java, los objetos se instalan y se destruyen en la memoria. Cuando los objetos se
destruyen en la memoria, es necesario recuperar ese espacio de memoria. Aquí es
donde el recolector de basura de la JVM entra en juego, recuperando objetos
inalcanzables en memoria.

La cobertura de la JVM es un detalle explícito que está más allá del alcance de este
libro, pero es recomendable que esté familiarizado con los mecanismos de
aplicación de la seguridad de la JVM, si está comprometido con el desarrollo de
software utilizando Java lenguaje de programación.
Conmutadores del compilador

Protección basada en compilador, como el modificador de marca / GS y StackGuard

la tecnología ayuda en la protección contra la corrupción de la memoria y mitiga el
búfer se desborda al evitar la ejecución de código malicioso y que no es de
confianza los el conmutador de seguridad del compilador común (indicador / GS) y
la técnica (StackGuard) discutido en esta sección a continuación.

Cuando se utiliza el indicador / GS en compiladores que lo admiten, el ejecutable

que se compila tiene la capacidad de detectar y mitigar los desbordamientos de
búfer de la devolución puntero de dirección que se almacena en la memoria de pila.
Cuando el código se compiló con la bandera / GS encendida se ejecuta, antes de la
ejecución de las funciones que el compilador considera susceptible a ataques de
desbordamiento de búfer, el espacio se asigna en la pila antes de la dirección del
remitente. En la entrada de la función, el espacio asignado es cargado con una
cookie de seguridad que se calcula después de la carga de la función. Al salir de la
función, se invoca una función auxiliar que verifica que la seguridad el valor de la
cookie no se altera, lo que ocurre cuando el espacio de memoria de la pila es
sobrescrito, lo que indica un desbordamiento. Si el valor de la cookie de seguridad
en función se determina que la salida es diferente de lo que era cuando se ingresó
la función, entonces el proceso simplemente terminará para evitar más
consecuencias.

StackGuard es una técnica de compilación que proporciona integridad de puntero de

código control y protección de la dirección de retorno en una función para que no
sea alterada. Se implementa como un pequeño parche del compilador GNU gcc y
funciona para detectar y derrotar ataques de desbordamiento de memoria de pila.
StackGuard funciona mediante colocar un valor conocido (denominado canary o
palabra canary) antes de la devolución dirección en la pila de modo que si se
produce un desbordamiento del búfer, los primeros datos que se corromperá es el
canario. Cuando la función sale, el código se ejecuta para moverse la dirección de
retorno a su siguiente ubicación de instrucción (también conocida como el
desmontaje código) comprueba para asegurarse de que la palabra canary no se
modifica antes de saltar a la siguiente dirección de retorno. Sin embargo, se sabe
que los atacantes forjaron un canario incorporando la palabra canaria en su hazaña
de desbordamiento; para prevenir esta falsificación, StackGuard utiliza dos métodos
para evitar la falsificación. Estos incluyen el uso ya sea un canario terminador o un
canario aleatorio. Se hace un canario terminator de símbolos de terminación
comunes para funciones de biblioteca de cadenas estándar de C como 0 (nulo), CR,
LF (retorno de carro, salto de línea) y -1 (Fin de archivo o EOF) y cuando el atacante
especifica estos símbolos comunes en su desbordamiento como parte de su código
de explotación (shellcode o payload), las funciones terminar inmediatamente. Un
canario aleatorio es un número aleatorio de 32 bits que se establece en la entrada
de la función (al inicio del programa) y se mantiene solo durante el período de
tiempo de esa llamada de función o ejecución del programa. Cada vez que se inicia
el programa, un nuevo se establece una palabra canaria aleatoria y esto hace que la
predictibilidad y la falsificación de la palabra canaria por un atacante casi imposible.

Sistemas operativos

En el capítulo de conceptos de software seguro, cubrimos un concepto de

computación confiable conocido como protección de anillo que puede ser aplicado
por el propio sistema operativo para implementar la garantía de software. En esta
sección, nos centraremos en las tecnologías que se pueden aprovechar del sistema
operativo para brindar una confianza justificada de que el software es seguro. Las
tecnologías de sistemas operativos que se pueden utilizar para implementar la
garantía de software incluyen la aleatorización del diseño del espacio de direcciones
(ASLR), la Prevención de ejecución de datos (DEP) o la Protección del espacio
encapsulado (ESP) y la seguridad de acceso al código (CAS). CAS evita que el
código de fuentes no confiables o de origen desconocido tenga permisos de tiempo
de ejecución para realizar operaciones privilegiadas. CAS también protege el código
de fuentes confiables de comprometer la seguridad de manera inadvertida o
intencional. Se trata con más detalle en el capítulo de implementación segura de
software.

Aleatorización del diseño del espacio de direcciones (ASLR)

Para que la mayoría de las vulnerabilidades de memoria y el malware tengan éxito,

el atacante debe poder identificar y determinar con precisión la dirección de
memoria donde se cargará un proceso o función específicos. Debido al principio de
localidad (temporal principalmente), se observó que los procesos y funciones se
cargan en el mismo ubicaciones de memoria en cada ejecución. Esto facilitó a los
atacantes descubrir la ubicación de la memoria y explotar el proceso o la función
indicando su carga útil explotar código la dirección de memoria del proceso o
función que deseaban explotar. La aleatorización del diseño del espacio de
direcciones (ASLR) es una técnica que se puede utilizar para proteger contra el
descubrimiento de la ubicación de la memoria.
Una biblioteca de vínculos dinámicos o ejecutable (dll) se puede cargar en
cualquiera de las 256 ubicaciones de memoria, lo que significa que con ASLR
activado, el atacante tiene 1 en 256 posibilidades de descubrir exactamente la
dirección de memoria del proceso o función que desean explotar. Protección ASLR
está disponible en los sistemas operativos Windows y Linux y se utiliza a menudo en
junto con otras técnicas de protección de memoria como la ejecución de datos y
prevención (DEP) o Protección de espacio ejecutable (ESP).

Prevención de ejecución de datos (DEP) / Protección de espacio

ejecutable (ESP)

La Prevención de ejecución de datos (DEP), como su nombre lo indica, protege los

sistemas informáticos al monitorear los programas de software para que no accedan
y manipulen la memoria de manera insegura. También se conoce como protección
No-Execute (NX) porque marca los segmentos de datos (generalmente inyectados
como parte de un desbordamiento de búfer) como No-Execute que un software
vulnerable procesará de otro modo como instrucciones ejecutables. Si el programa
de software intenta ejecutar el código desde la memoria de una manera no
aprobada, el DEP terminará el proceso y cerrará el programa. Executable Space
Protection (ESP) es el equivalente en Unix o Linux del DEP de Windows. DEP se
puede implementar como tecnología basada en hardware o como tecnología basada
en software.

Sistemas embebidos

Una definición genérica de un sistema integrado es que es un sistema informático.

que es un componente de una máquina o sistema más grande. Suelen estar
presentes como parte de todo el sistema y están asignados para realizar
operaciones específicas. La especificidad de sus operaciones a menudo aumenta el
sistema integrado confiabilidad sobre un sistema general de usos múltiples. Los
sistemas integrados pueden responder y se rigen por eventos en tiempo real.
Suelen ser dispositivos independientes pero no necesitan serlo. Algunos ejemplos
de dispositivos de sistemas integrados van desde los electrodomésticos comunes,
semáforos, reproductores de mp3, relojes, celulares, teléfonos y asistentes digitales
personales (PDA) para aplicaciones industriales altamente sensibles sistemas de
control (ICS). Los ICS son sistemas controlados por computadora que tienen
software en ejecución (incrustado) en ellos que se utiliza para monitorear y controlar
los procesos industriales.
Las instrucciones del programa que están escritas para sistemas integrados son
conocido como firmware y generalmente se almacenan en chips de solo lectura o
memoria flash papas fritas. Si el firmware se almacena en un chip de solo lectura, el
sistema integrado el microcontrolador o procesador de señal digital (DSP) no es
programable por el usuario final. Solo se espera que en el futuro, el desarrollo de
sistemas integrados los proyectos centrarán su atención en aumentar la seguridad
del firmware y de los propios dispositivos. La gestión de la memoria en los sistemas
integrados es fundamental.

Esto se debe a que la memoria de los sistemas integrados suele contener tanto los
datos y también el firmware del producto. Es importante aprovechar un sistema a
prueba de manipulaciones sensoriales que puede detectar y alertar cuando la
memoria está dañada o alterada. El ISO 15408 (Criterio Común) estándar y los
múltiples niveles independientes del estándar de seguridad (MILS) son dos
estándares reconocidos que se pueden aprovechar para seguridad de los sistemas
integrados. La arquitectura MILS permite crear un código de aplicación verificado,
siempre invocado y a prueba de manipulaciones con funciones de seguridad que
frustran los intentos de un atacante.

La mayoría de los ataques a sistemas integrados son principalmente ataques de

divulgación y por lo que es esencial que el dispositivo integrado que almacena o
muestra información sensible y la información privada cuente con controles de
seguridad y diseño de productos para asegurar confidencialidad. Hoy en día, con
dispositivos integrados como PDA que manejan datos personales y corporativos, es
fundamental asegurarse de que el dispositivo PDA admita e implementa un
esquema de cifrado y / o DRM de capa de red o transporte proteger para proteger la
información confidencial y protegida por derechos de autor que se transmite a,
almacenados y mostrados en estos dispositivos. Una técnica de software que se
utiliza en dispositivos hoy para garantizar que no se divulgue información privada y
confidencial es implementar la funcionalidad de borrado automático en el software.
De esta manera, cuando el no proporciona las credenciales necesarias para
acceder a los datos del dispositivo y no se número de intentos ha sido reemplazado,
el software ejecutará una función de autodestrucción que borra todos los datos del
dispositivo. Además de la divulgación de amenazas, los sistemas integrados
también se enfrentan a una plétora de otros ataques. El pequeño tamaño y la
portabilidad a menudo los convierten en el objetivo de los ataques de canal lateral
(radiación, análisis de potencia, etc.) y ataques de inyección de fallas. Esto exige la
necesidad de proteger los circuitos internos de los dispositivos con controles físicos
de disuasión como sellos (epoxis), recubrimientos de conformación y cintas que
deben romperse antes de que el dispositivo se pueda abrir. El software que se
ejecuta en estos sistemas se puede utilizado para señalar actividades físicas de
violación o manipulación. Otra técnica que los diseñadores de productos emplean
para disuadir el reconocimiento y la ingeniería inversa de la dispositivo en sí es que
ocultan señales críticas en las capas internas de la placa.

Otro aspecto importante de muchos sistemas integrados destacados en la

actualidad es el sistema operativo abierto que se ejecuta en los dispositivos.
Microsoft Windows CE (hasta cierto punto) y las aplicaciones de iPhone de Apple
son excelentes ejemplos de sistemas operativos que permiten a terceros desarrollar
aplicaciones de software que puede ejecutarse en estos dispositivos. Cuando se
permiten aplicaciones y software de terceros para ejecutarse en estos dispositivos
del sistema integrado, es necesario garantizar que el entorno de ejecución se
proporciona al propietario del dispositivo. El tercero las aplicaciones deben estar
aisladas de otras aplicaciones que se ejecutan en el dispositivo y no debe tener
acceso a los datos confidenciales y privados del propietario almacenados en el
dispositivo.

Todos los controles de seguridad que son aplicables en la informática generalizada

son también aplicables a sistemas integrados. Esto significa que antes de que se
permita a los usuarios para utilizar el dispositivo seguro del sistema integrado,
primero deben verificar su identidad y estar autenticado. Se recomienda la
autenticación multifactor para aumentar la seguridad. Además, el chip TPM en el
dispositivo se puede utilizar para nodo a nodo autenticación y prever el
almacenamiento de claves y secretos a prueba de manipulaciones.

Con los cambios en las tecnologías y el aumento en el uso y dependencia de los

sistemas integrados para las actividades del día a día, los atacantes han sido visto
apuntando a los sistemas integrados para comprometer la seguridad del dispositivo
o el sistema host del que forma parte el sistema integrado. Los agentes de amenaza
de los sistemas integrados suelen ser más sofisticados y hábiles que el promedio.
Esto es particularmente cierto en los ataques que se han observado contra sistemas
de control de supervisión y adquisición de datos (SCADA) que es un tipo de ICS. La
mayor sofisticación de los atacantes está obligando a los defensores a ser
igualmente calificados para abordar las amenazas de seguridad del sistema
integrado. Sistemas SCADA se han implementado para monitorear y controlar
procesos físicos como el transporte de petróleo y gas, distribución de electricidad y
agua, semáforos como así como instalaciones militares, lo que hace que los
sistemas SCADA sean un objetivo principal para hackers.
Los sistemas SCADA que se pensaba que eran seguros han demostrado lo
contrario. Las dos razones principales de tal sensación de seguridad placebo son
porque en los primeros días, cuando se implementaron los sistemas SCADA, las
tecnologías utilizadas en su el diseño y la implementación eran en su mayoría de
naturaleza patentada. El propietario de protocolos e interfaces promovieron la
seguridad a través de la noción de oscuridad que dio lugar a una falsa sensación de
seguridad. En segundo lugar, estos sistemas estaban protegidos físicamente y
desconectados. Hoy, con la adopción de estándares abiertos y estandarizados
soluciones, estos sistemas se están convirtiendo en objetivos de los atacantes.
Además, el conectividad que ha sido provocada por la proliferación de Internet
también es un catalizador en la oleada de ataques que se están observando contra
SCADA sistemas que se han puesto en línea.

Además, estos sistemas no se diseñaron originalmente teniendo en cuenta la

seguridad y mecanismos básicos de protección como autenticación y autorización,
para estos sistemas es débil, si es que está presente. La amenaza predominante
para los sistemas SCADA hoy es la amenaza del acceso no autorizado al software
de control integrado en estos sistemas. Las amenazas pueden ser causadas
accidental o intencionalmente por humanos o maliciosamente por malware como
gusanos y caballos de Troya. Porque en la mayoría de sistemas SCADA, el
protocolo de control de paquetes es rudimentario o inexistente, cualquiera puede
enviar un paquete al dispositivo SCADA y controlarlo. Ataques al software que se
ejecutan en sistemas SCADA tienden a ser de tipo desbordamiento o inyección.
Finalmente, infracciones físicas a los sistemas SCADA por parte de personas
internas elude toda la protección que dispositivos perimetrales de red, como
firewalls, proporciona. Esto exige la necesidad para autenticación y autorización de
extremo a extremo al implementar SCADA sistemas.

Revisión de arquitectura y diseño seguro

Una vez que se completa el diseño del software, antes de salir de la fase de diseño
y entrar fase de desarrollo, es importante realizar una revisión del diseño del
software y arquitectura. Esto es para asegurar que el diseño cumpla con los
requisitos. No solo debe revisarse la aplicación para determinar su funcionalidad,
pero debe revisarse por su seguridad, también. Esto hace posible validar el diseño
de seguridad. antes de escribir el código, lo que brinda la oportunidad de identificar
y corregir cualquier vulnerabilidades de seguridad por adelantado, minimizando la
necesidad de reingeniería en un futuro fase. La revisión debe tener en cuenta las
políticas de seguridad y el objetivo entorno donde se implementará el software.
Además, la revisión debe ser cobertura holística, teniendo en cuenta la red y las
protecciones a nivel de host que son estar en su lugar para que las salvaguardas no
se contradigan y minimicen la protección que brindan. Se debe prestar especial
atención al diseño de seguridad, principios y conceptos básicos de seguridad de la
aplicación para garantizar la confidencialidad, integridad y disponibilidad de los
datos y del propio software. Adicionalmente, se debe realizar un análisis capa por
capa y nivel por nivel de la arquitectura para que exista una defensa en profundidad.