¿Cuáles son las mejores prácticas para mitigar los ataques de día cero?

SDL holístico.

Por definición, no puedes defenderte de un ataque específico que no conoces de antemano.
Sin embargo, si implementó un Ciclo de vida de desarrollo seguro y completo en todas las fases, incluido el Modelado de amenazas adecuado, y mitiga las amenazas (no los ataques), debe ser relativamente bien

La mejor manera de mitigar los exploits de día cero es evitar que los escritores de exploits de día cero escriban exploits de día cero.

La mejor manera de evitar que los escritores de exploits de día cero escriban exploits de día cero es alentarlos a encontrar otras formas de ganar dinero o ganar fama, lo que requeriría que la exfiltración de datos sea menos fácil y menos rentable, además de identificar robos. y el concepto de "hackear" es menos divertido.

Para hacer que la extracción de datos e identificar el robo sea menos fácil / rentable, debemos cambiar el juego, es decir, eliminar los datos de las tarjetas de pago y la identificación emitida por el gobierno, como los números de seguridad social. Es posible que tengamos que cambiar la forma en que usamos nombres y números, especialmente juntos.

Para hacer que el pirateo sea menos divertido, necesitamos hacerlo aburrido e inútil, posiblemente haciendo una actividad más novedosa más emocionante que el pirateo, y de alguna manera hacer que el pirateo sea menos emocionante que, por ejemplo, tejer canastas bajo el agua o contabilidad submarina. p>

Si los métodos anteriores fallan, entonces tal vez sería mejor desalentar el uso criminal de ataques de día cero mediante rehabilitación criminal, encarcelamiento, multas y otras formas de castigo. Sin embargo, para imponer el castigo, primero debemos atrapar a los delincuentes utilizando ataques de día cero. Cierto uso pseudo-criminal de las hazañas de día cero es "por encima de la ley" al igual que el espionaje a nivel nacional (por ejemplo, el personaje ficticio James Bond tiene una "licencia para matar" y quizás hay algunos hackers que tienen "licencias para usar exploits de día cero ").

Suponiendo que eso también falla, entonces debemos hacer que sea demasiado costoso para los escritores de día cero escribir exploits de día cero. Creo que esta es la estrategia que ha adoptado Microsoft con respecto a algunos de sus productos. Esto existe fuera de la SDL, y generalmente implica contramedidas de explotación como DEP, ASLR y el uso de técnicas que se encuentran en herramientas como EMET .

Algunos colaboradores de Linux han tomado esta ruta al inventar ASLR e implementar otros conceptos en sus grsecurity parches del kernel. Sin embargo, ni Microsoft ni los desarrolladores de grsecurity pueden prever exploits no tradicionales, como los basados en aplicaciones web, exploits de kernel, condiciones de carrera y otros defectos esotéricos o de diseño.

Desde el punto de vista tecnológico, es mucho más difícil resolver el problema de explotación de día cero. Esta es la razón por la que principalmente he proporcionado una larga lista de soluciones humanas para el problema de explotación de día cero, que creo que tendrá un mayor impacto. No soy un experto en resolver estos problemas sociales humanos; si lo fuera, estaría usando estos poderes mágicos para combatir el hambre, las enfermedades u otros problemas que son mucho más profundos que las hazañas de día cero.

Tal vez es mejor dejar que las explotaciones de día cero ocurran. No puedes evitar que sean liberados. Una cosa que puede hacer es ayudar a que su organización se convierta en un objetivo menor de las vulnerabilidades de día cero es ejecutarse en una infraestructura que nunca (o muy rara vez) haya sido atacada por vulnerabilidades de día cero, pero esto puede llevar a la seguridad a la oscuridad. Como ejemplo de esta estrategia fallida, AOL utilizó equipos tolerantes a fallas de Stratus, pero esto no evitó que fueran pirateados.

Uno de los métodos más conocidos hasta la fecha es aprovechar los honeypots, el monitoreo de integridad de proceso / kernel / memoria / proceso (por ejemplo, BitLocker con TPM, Tripwire, etc.) y el subterfugio para proporcionar niveles de defensa, y luego seguir con un Una ofensa rápida y despiadada, como la guerra moderna. Nuevamente, esto involucra principalmente trabajar en la capa humana sin una gran cantidad de tecnología pesada. Algunos de estos métodos pueden combinarse utilizando técnicas de inteligencia de negocios, y esto es lo que intentan hacer algunos productos SIEM (y la herramienta SISIM de código abierto OSSIM), pero aún se encuentran en las primeras etapas de madurez y progreso, por lo que no deberían se basaron en ellos mismos, pero formaron parte de una metodología más amplia y un programa de gestión de explotación de día cero.

Si está hablando de Zero Day, ataca contra cualquier aplicación dentro de su red. Sugeriría:

Use el filtro de ingreso en el firewall de la red y también use filtro de egreso para limitar el tráfico que puede salir del sistema. lo que significa que si una máquina se viera afectada por un exploit del Día Cero, con suerte, no podría comunicarse.

El uso de un IDS / IPS para detectar patrones de tráfico inusuales también puede resultar efectivo.

Un punto no mencionado por Avi o Mark es el antiguo mantra de "defensa en profundidad". Puede ser una frase muy trillada, pero con varias capas de seguridad, un atacante necesita usar más de un día cero para obtener acceso, y cada capa puede brindar más oportunidades para detectar el ataque (a través de IDS, etc.) o para responder.

Definitivamente, desarrolle el SDL y use IDS, IPS y otras herramientas, pero cree una arquitectura segura y mejorará su seguridad de manera considerable.

Si te refieres a protegerte de una vulnerabilidad conocida en una aplicación que aún no tiene un parche oficial, aquí hay algunas formas:

• Si es un software de código abierto, generalmente hay parches no oficiales disponibles muy rápidamente. De lo contrario, incluso puede intentar parchearlo si tiene los recursos.

• Las vulnerabilidades a menudo dependen de configuraciones / configuraciones específicas. Pruebe y vea si puede configurar una configuración que no sea vulnerable (es decir, deshabilitar una extensión).

No se me ocurre nada más aparte de los métodos de seguridad habituales que no son específicos de la pregunta.