Application Security (AS)

AS-01: E-mail Security

Las empresas implementan protecciones de seguridad de correo electrónico como filtrado de
correo no deseado, bloqueo de correo electrónico, redireccionamiento de correo electrónico,
firmas personalizadas de detección de malware, escaneo de archivos adjuntos para virus,
encriptación de correo electrónico, autenticación de correo electrónico, filtrado de contenido y
archivo de correo electrónico .

Email Gateway
El correo electrónico es una de las formas más efectivas de entregar malware. Una vez instalado,
es posible que un adversario se establezca en la red y se dirija a los Endpoints, llegando
finalmente a recursos protegidos como bases de datos, archivos compartidos y correos
electrónicos confidenciales.
Todo el correo electrónico se recibe primero en una puerta de enlace de correo electrónico para
su inspección y posible entrega posteriormente.
Se puede implementar una puerta de enlace de correo electrónico en línea para que todos los
correos se analicen y se determine que sean seguros antes de enviarlos a las bandejas de entrada
de los empleados. También se pueden analizar archivos adjuntos, de forma similar a como un
MPS (Malware Prevention System) ejecutando binarios en un contenedor dedicado. Algunas
versiones de Gateway también pueden analizar y desinfectar cualquier enlace contenido en el
cuerpo del correo.
Dado que el correo electrónico es la forma más popular para que los atacantes instalen malware
en una red, una puerta de enlace de correo electrónico puede considerarse una parte fundamental
del programa de seguridad de la información de una organización. Sin embargo, dada su
complejidad y la dependencia de un administrador de correo electrónico experimentado para
implementarlo y operarlo correctamente, se considera un objetivo de seguridad de nivel 2.

Encriptación de Email
Todos sabemos que los emails que enviamos por el internet sin encriptar pueden ser leídos en el
camino. Desde el punto de vista práctico, es muy difícil encriptar todos nuestros emails, porque
para esto tendríamos que tener la llave publica del destinatario, y son pocas las personas que se
toman el trabajo de generar una llave pública. Por esto, aunque nosotros tengamos la intención
de encriptar nuestros mails, si los demás no cooperan, no funciona. Esto explica por qué casi no
se usa la encriptación de email. En lugar de tratar de encriptar el mail, debemos asegurarnos de
que cuando tengamos que comunicar datos clasificados, lo hagamos por medio de un memo,
encriptarlo, y enviarlo como un adjunto en el email, o a través de un servicio de transmisión
segura de archivos.
Por otro lado, lo que si debemos encriptar es la comunicación entre la computadora y el servidor
de correo, en casos de que se usen redes inalámbricas. Si un usuario está conectado a la red local
vía Ethernet, es poco probable que la comunicación sea interceptada. Sin embargo, si el usuario
se encuentra en un punto de acceso de WIFI público, y se conecta con su cliente de email al
servidor de correo sin encriptar, el username y password de su cuenta será muy fácil de
interceptar. Una táctica común durante pruebas de penetración es sentarse en un café cercano a la
compañía objetivo, conectarse al servicio gratuito de internet inalámbrico, activar un sniffer, y
esperar a que los empleados entren y se conecten. Es por esto que es importante que si se usa un
cliente de email web, nos aseguremos que use HTTPS, y si es un cliente tipo Microsoft Outlook,
este configurado para encriptar la comunicación entre el cliente y el servidor. De igual forma, se
puede utilizar una VPN.

AS-02: Webshell Detection

Las empresas ponen en práctica herramientas de detección webshell para todas las aplicaciones
con el fin de detectar códigos maliciosos y archivos cargados en las aplicaciones.

Ataque Webshell

El webshell es una puerta trasera que permite a los atacantes volver al sitio web del servidor y
ejecutar comandos directamente en el servidor.

Un shell web es un script que se puede cargar en un servidor web para habilitar la administración
remota de la máquina. Los servidores web infectados pueden estar orientados a Internet o
internos a la red, donde el webshell se usa para pivotar más hacia los hosts internos.
Un webshell se puede escribir en cualquier idioma compatible con el servidor web de destino.
Los webshell más comúnmente observados están escritos en idiomas que son ampliamente
compatibles, como PHP y ASP. Los guiones de shell Perl, Ruby, Python y Unix también se usan.
Usando herramientas de reconocimiento de redes, un atacante puede identificar vulnerabilidades
que pueden ser explotadas y resultar en la instalación de un webshell. Por ejemplo, estas
vulnerabilidades pueden existir en sistemas de gestión de contenido (CMS) o software de
servidor web.
Una vez cargado con éxito, un adversario puede usar el shell web para aprovechar otras técnicas
de explotación para escalar privilegios y emitir comandos de forma remota. Estos comandos
están directamente relacionados con el privilegio y la funcionalidad disponibles para el servidor
web y pueden incluir la capacidad de agregar, eliminar y ejecutar archivos, así como la capacidad
de ejecutar comandos de shell, más ejecutables o scripts.

Detección
Debido a la simplicidad potencial y la facilidad de modificación de las cubiertas de la web,
pueden ser difíciles de detectar. Por ejemplo, se sabe que los productos antivirus producen malos
resultados en la detección de webshell.

Los siguientes pueden ser indicadores de que su sistema ha sido infectado por un webshell.
Tenga en cuenta que varios de estos indicadores son comunes a los archivos legítimos. Cualquier
sospechoso de archivos maliciosos debe considerarse en el contexto de otros indicadores y debe
analizarse para determinar si se requiere una inspección o validación adicional.

 Períodos anormales de uso elevado del sitio (debido a la posible actividad de carga y
descarga);
 Archivos con una marca de tiempo inusual (por ejemplo, más reciente que la última
actualización de las aplicaciones web instaladas);
 Archivos sospechosos en ubicaciones accesibles por Internet (raíz web);
 Archivos que contienen referencias a palabras clave sospechosas como cmd.exe o eval;
 Conexiones inesperadas en los registros. Por ejemplo:
 Un tipo de archivo que genera tráfico de red inesperado o anómalo (por ejemplo, un
archivo JPG que realiza solicitudes con parámetros POST);
 Log inicios de sesión sospechosos que se originan desde subredes internas a servidores
DMZ y viceversa.
 Cualquier evidencia de comandos de shell sospechosos, Como el recorrido Del directorio,
por el proceso Del servidor web.

Posible defensa
Para evitar vulnerabilidades de carga de shell, busque en el código de su aplicación las llamadas
a move_uploaded_files () y refuerce cada fragmento de código que use esa función. Recomiendo
crear una hoja de cálculo que enumere todo el código que se puede usar para cargar archivos en
la aplicación para hacer un seguimiento del proceso de fortalecimiento de la aplicación. Las
siguientes defensas se pueden usar para defenderse de vulnerabilidades de carga de shell:
 Requiera autenticación para subir archivos
 Almacenar archivos cargados en una ubicación no accesible desde la web
 No evalúar ni incluir datos cargados
 Codificar los nombres y extensiones de archivos cargados
 Definir tipos válidos de archivos que los usuarios deberían poder cargar.

AS-03: Application Firewalls

Las empresas implementan firewalls de aplicaciones en el modo de detección y cumplimiento
para evitar que los paquetes de datos maliciosos lleguen a todas las aplicaciones.
Se puede usar una aplicación web firewall (WAF) en el perímetro para proteger las aplicaciones
web que miran a Internet. Un WAF es un dispositivo de seguridad que se centra en la capa
superior de la pila de red: capa 7, también conocida como la capa de aplicación. Este tipo de
firewall examina todas las solicitudes que se envían a una aplicación web, así como las
respuestas que devuelve la aplicación. WAF puede bloquear el acceso o la entrada de contenido
malicioso, así como desinfectar los datos para que no causen daños al recibirlos.
Un desafío para implementar un WAF es que este dispositivo primero necesita '' aprender '' el
código de la aplicación web que está protegiendo. Muchos WAF tienen un modo de aprendizaje
que puede implementarse durante algunas semanas o meses al inicio de una implementación.
Mientras se encuentra en el modo de aprendizaje, el WAF observa la actividad de uso de la web y
con el tiempo determina a qué se parece "normal". Esto ayuda a reducir el número de falsos
positivos que informa el WAF. "Normal" es subjetivo porque las aplicaciones se pueden codificar
de muchas maneras pero producen los mismos resultados. Sin aprender, algunas de las opciones
de codificación se considerarían maliciosas para la WAF.

AS-04: Database Firewalls

Las empresas implementan firewalls en modo detección y ejecución para detener paquetes de
datos SQL maliciosos que llegan a todas las bases de datos.
Un firewall de base de datos es otro tipo de firewall de capa 7 que está ajustado específicamente
para ver la sintaxis relacionada con la base de datos que se envía a una base de datos. Este
dispositivo generalmente se encuentra en frente de una base de datos, por lo que los comandos
enviados a la base de datos se evalúan primero, en ese momento se puede generar una alerta y la
consulta puede bloquearse. Un firewall de base de datos puede evitar que ataques como la
inyección SQL lleguen a su objetivo deseado. Sin embargo, antes de la implementación se
requiere un período de aprendizaje para que el firewall de la base de datos pueda saber qué
consultas legítimas se pueden esperar y no se deben bloquear.
Un firewall de base de datos puede proteger una base de datos que sirve de backend para una
aplicación. Por ejemplo, una aplicación puede tener vulnerabilidades de seguridad como
inyección de SQL, debido a la falta de validación de entrada. Para aplicaciones vulnerables como
esta, se puede usar un firewall de base de datos para proporcionar '' parches virtuales ''. Esto
protegería a la base de datos de recibir declaraciones SQL maliciosas que la aplicación no
bloquea frente a la base de datos.
Un desafío es que las bases de datos de lenguaje de consulta estructurado (SQL) están siendo
usurpadas por NoSQL y otras bases de datos no relacionales, donde la sintaxis es muy diferente.
Sin embargo, cualquier producto valioso de firewall de base de datos debe ser capaz de proteger
las últimas encarnaciones de repositorios de datos. Como la implementación de un firewall de
base de datos requiere a alguien que esté muy familiarizado con las consultas de bases de datos
como estructuradas, esto se considera una solución de seguridad de nivel 3.

AS-05: Forward Proxy and Web Filters

Las empresas implementan proxys y filtros web en modo de cumplimiento para todas las
solicitudes salientes desde servidores internos a Internet.
Un Forward proxy es un sistema intermedio que permite que un navegador se conecte a una red
remota a la que normalmente no tiene acceso. Un proxy directo también se puede usar para
almacenar en caché los datos, reduciendo la carga en las redes entre el proxy directo y el servidor
web remoto.
El Web Filter proporciona una extensa base de datos de categorías de filtrado de bibliotecas,
autenticación de usuarios, implementación de perfiles de tiempo y filtrado de cuotas y
herramientas para adaptar el perfil de filtrado de un usuario para cumplir con la política de uso
de Internet de su organización, basada en los hábitos de uso de Internet del usuario final.

AS-06: Reverse Proxy

Las empresas implementan proxys inverso para enmascarar la red interna de todos los usuarios
de Internet.
Un Reverse Proxy es un sistema de servidor web que es capaz de servir a páginas web de otros
servidores web, además de páginas web en disco o generadas dinámicamente por CGI, haciendo
que estas páginas parezcan originadas en el proxy inverso. Cuando se configura con el módulo
mod_cache, el proxy inverso puede actuar como un caché para los servidores web de back-end
más lentos. El proxy inverso también puede habilitar estrategias avanzadas de URL y técnicas de
administración, permitiendo que las páginas web servidas usando diferentes sistemas de
servidores web o arquitecturas coexistan dentro del mismo espacio de URL. Los sistemas de
proxy inverso también son ideales para implementar sitios web de registro centralizados con
muchos o diversos servidores de sitio web. Se pueden construir sistemas complejos de servidores
web de varios niveles usando un frontend mod_proxy y cualquier número de servidores web
back-end".
AS-07: Data Leakage Protection (DLP)
La fuga de datos es una preocupación importante para las organizaciones empresariales en este
mundo cada vez más conectado en red en estos días. La divulgación no autorizada puede tener
graves consecuencias para una organización tanto a corto como a largo plazo. Los riesgos
incluyen la pérdida de clientes y la confianza de las partes interesadas, el deterioro de la imagen
de marca, el aterrizaje en demandas no deseadas y, en general, la pérdida de buena voluntad y
participación de mercado en la industria. Para evitar que todas estas actividades no deseadas y
desagradables sucedan, se necesita un esfuerzo organizado para controlar el flujo de información
dentro y fuera de la organización. Aquí está nuestro intento de desmitificar la jerga que rodea los
procedimientos DLP que le ayudará a elegir y aplicar la mejor opción adecuada para su propio
negocio.
La prevención de fugas de datos es la categoría de soluciones que ayuda a una organización a
aplicar controles para evitar la fuga accidental o maliciosa no deseada de información sensible a
entidades no autorizadas dentro o fuera de la organización. Aquí la información confidencial
puede referirse a documentos de procesos internos de la organización, planes comerciales
estratégicos, propiedad intelectual, estados financieros, políticas de seguridad, diagramas de red,
planos, etc.

AS-08: Secure Application and Database Software Development

Secure Application
Después de que se escribe una aplicación, se implementa en un entorno de algún tipo, donde
permanece durante un período prolongado de tiempo con solo sus características originales para
defenderse de cualquier amenaza, error o uso indebido que encuentre. Un agente malicioso en el
entorno, por otro lado, tiene el mismo período de tiempo prolongado para observar la aplicación
y adaptar sus técnicas de ataque hasta que algo funcione. En este punto, podría suceder cualquier
cantidad de cosas indeseables. Por ejemplo, podría haber una brecha, podría haber una
divulgación de vulnerabilidad, el malware que explota la vulnerabilidad podría ser liberado, o la
técnica de explotación podría venderse al mejor postor.
La mayoría de estas cosas indeseables finalmente conducen a clientes que no están contentos con
sus proveedores de software, independientemente de si los clientes estaban dispuestos o no a
pagar por la seguridad antes de que ocurriera el incidente. Por esa razón, la seguridad es cada vez
más importante para las organizaciones que producen software, y crear seguridad en el software
por adelantado es más fácil (y más barato) que esperar hasta que el software ya esté en el campo
y luego proporcionar actualizaciones de seguridad.
Si bien el entorno de despliegue puede ayudar a proteger la aplicación hasta cierto punto, cada
aplicación debe ser lo suficientemente segura como para protegerse de cualquier ataque
significativo que el entorno de despliegue no pueda evitar, por el tiempo suficiente para que el
operador observe y responda a los ataques en curso. Este capítulo describe técnicas para
desarrollar aplicaciones que son lo suficientemente seguras para su uso previsto, durante el ciclo
de desarrollo, para ahorrar tiempo y dinero en el futuro.

AS-09: Software Code Vulnerability Analysis

Las empresas implementan herramientas de análisis de vulnerabilidad de código de software
(es decir, escáner de vulnerabilidad de aplicación y revisor de código).

Source Code Security Analysis

El análisis del código fuente generalmente se llama análisis estático del código fuente también.
El análisis del código fuente se clasifica en dos tipos principales:

Tecnología para detectar código que rompe las reglas de codificación

Una tecnología para ver si hay violaciones a las reglas de codificación. Su objetivo es garantizar
la calidad del código, como la fiabilidad, facilidad de mantenimiento, versatilidad y eficiencia.

Tecnología para detectar vulnerabilidad

Una tecnología para ver si algunas vulnerabilidades se integran involuntariamente en el código
fuente en el proceso de desarrollo. Es una evaluación de seguridad para garantizar la calidad de
la seguridad del código fuente (análisis de seguridad del código fuente).