tashatuvango - Fotolia
5 lecciones de ciberseguridad de la brecha de SolarWinds
Las simulaciones de ataques de ransomware, el acceso a los registros empresariales y el código del software de pruebas de penetración se encuentran entre las mejores prácticas que sugieren los profesionales de la ciberseguridad tras la violación de SolarWinds.
Los equipos forenses todavía están investigando cómo los piratas informáticos pudieron explotar el sistema de parches de SolarWinds para atacar numerosas organizaciones comerciales y gubernamentales de alto perfil, incluidos Microsoft y el Departamento de Justicia de EE.UU., así como otros clientes del proveedor de software de monitoreo de seguridad. Al mismo tiempo, los expertos de una variedad de proveedores de servicios de seguridad, incluidos los que ofrecen pruebas de penetración, escaneo de vulnerabilidades y revisiones de códigos de software, aconsejan a las empresas que actúen ahora para reforzar su propia seguridad empresarial.
"Incluso si no tienen un producto de SolarWinds, ahora es el momento de averiguar si podría ser pirateado de una manera similar", dijo Scott Burchell, gerente senior del grupo adversario en Secureworks, un proveedor de servicios de pruebas de seguridad y recomendación de remediaciones.
La violación de SolarWinds se reveló por primera vez a fines de 2020, aunque es posible que los ataques hayan comenzado en 2019, y ahora incluye el descubrimiento de dos puertas traseras creadas por malware. El primero, llamado Sunburst, se ha relacionado con numerosas infecciones de la cadena de suministro y ataques de estado-nación, y el segundo, llamado Supernova, no es un ataque a la cadena de suministro, sino más bien un malware que requirió la explotación de una vulnerabilidad en el programa de software Orion recientemente parcheado por SolarWinds. El gobierno de EE.UU. y los expertos en ciberseguridad aún están descubriendo el daño causado por las dos infecciones.
Los proveedores de servicios de seguridad sugieren la siguiente lista de cinco lecciones aprendidas para ayudar a las organizaciones a evitar o detectar un hack de tipo SolarWinds. Estas mejores prácticas también reducen el "ruido de las amenazas" en toda la empresa, lo que permite que una empresa identifique y maneje rápidamente comportamientos sospechosos.
-
Simular un ataque de ransomware
Los ataques de ransomware son una gran preocupación para las empresas de todos los tamaños, pero pocas empresas saben exactamente lo fácil que es lanzar uno en su propia red. El servicio de simulación de ransomware de Secureworks utiliza un dispositivo remoto en un segmento de usuarios para simular un compromiso en la red, por ejemplo, una vulnerabilidad de la cadena de suministro como lo que sucedió con SolarWinds. "A partir de ahí, buscamos ver a qué podemos acceder, ¿podemos movernos lateralmente para depositar cargas útiles de ransomware? Como adversarios, vemos qué tan lejos podemos llegar en la red", dijo Burchell.
La empresa toma nota de los parches faltantes y las vías no seguras que son vulnerables a un depósito de carga útil. Simultáneamente, Secureworks mide la capacidad de la empresa para detectar y responder al compromiso. "Pedimos a los equipos internos que se evalúen a sí mismos y compartan con nosotros las cosas que no vieron o no respondieron", agregó Burchell, y agregó que las redes inalámbricas para invitados son uno de los vectores de ataque que más se pasan por alto.
-
Probar el software de sus proveedores en busca de vulnerabilidades
Si bien las empresas pueden solicitar que un tercero valide el software de un proveedor para marcar una casilla de requisito de cumplimiento, Seemant "Sam" Sehgal, fundador y director ejecutivo del proveedor de plataforma de pruebas de penetración como servicio BreachLock Inc., dijo que las propias empresas deberían asumir la responsabilidad por la integridad del software que traen a la red. "Si usted, como empresa, no está observando lo que está introduciendo en términos de código de software o aplicaciones de proveedores de servicios, se está volviendo vulnerable a un ataque como SolarWinds", dijo Sehgal. Las evaluaciones de seguridad para todas las compras de software y SaaS deben centralizarse para que las aplicaciones puedan probarse y validarse correctamente. "Si el departamento de una empresa ubicado en otro país utiliza un determinado software que interactúa con la red, es necesario que lo sepa".
Las revisiones de código automatizadas, incluso si son impulsadas por inteligencia artificial, tienen sus limitaciones porque no siempre pueden detectar "incógnitas desconocidas", según Sehgal. Por ejemplo, el ataque SolarWinds se basó en una inyección de código que parecía legítima en el código de secuencia. Una revisión manual habría investigado cómo el código llamaba a otras máquinas, incluido a quién se llamaba y de dónde procedían las actualizaciones. Si se detectaran anomalías, un revisor habría solicitado la ingeniería inversa del software para rastrear el código infractor. Sin estas pruebas aumentadas por humanos, "si se materializa una ciberamenaza, se cae en el anzuelo porque faltaba un paso", dijo Sehgal. "Ese paso, un enfoque híbrido en el que los controles de seguridad automatizados se complementan con una prueba de penetración dirigida por humanos (pen testing), podría haber detectado potencialmente la vulnerabilidad y limitado el daño".
-
No confiar en los desarrolladores internos para probar el software desarrollado internamente
Los desarrolladores no deberían tener la última palabra sobre la seguridad de su código. No son expertos en seguridad y podrían ser los que insertaron código malicioso, intencionalmente o no, según Nabil Hannan, director administrativo del proveedor de pruebas de penetración NetSPI. "Para descubrir un problema tipo SolarWinds, se debe pensar de manera diferente a lo que haría un desarrollador sobre lo que está buscando, incluido quién tiene acceso a sus sistemas", dijo. "¿Cómo puede un desarrollador determinar la verdadera intención de otro desarrollador de poner código en el sistema y cómo se comportará? No puede".
Hannan recomendó formar un grupo de ejecutivos y gerentes senior de confianza para trabajar con una empresa de pruebas externa. Cuando los desarrolladores terminan con sus revisiones o actualizaciones completas, el grupo lo envía a los probadores para buscar códigos maliciosos y amenazas internas. "Examinamos el código fuente y los binarios, analizamos los ejecutables y comparamos lo que está publicado con lo que está en el código fuente", dijo. Los probadores buscan puertas traseras, bombas de tiempo, caballos de Troya y patrones de firma. "Si hay diferencias, informaremos al grupo de manera discreta y trabajaremos con ellos para mitigar los problemas". Hannan dijo que tener esta práctica y estos controles en su lugar es útil cuando hay una reorganización administrativa, un desarrollador descontento se va o una fusión o adquisición está a punto de tener lugar.
4. Asegurarse de tener registros y poder acceder a ellos
"Los clientes llaman y dicen: 'Tuvimos una infracción', y nosotros les decimos: 'Permítanos ver sus registros'", dijo Brad Herring, vicepresidente de desarrollo comercial de la empresa de pruebas de penetración Raxis. "Ahí es cuando se dan cuenta de que no tienen registros". Herring dijo que esto sucede con empresas de todos los tamaños y en todas las industrias.
Incluso si tienen registros, Herring dijo que a menudo no los guardan más allá de los 15 o 30 días, lo que no sería adecuado para hacer una investigación sobre el impacto de un ataque como el de SolarWinds. "Queremos que puedan compartir registros de firewall, registros de estaciones de trabajo, registros del servidor, registros del sistema de detección/prevención de intrusiones... básicamente cualquier registro de la empresa que muestre tráfico entrante/saliente". De lo contrario, dijo, los evaluadores no pueden decir que todos los parches, cierres de servicios y otros esfuerzos de remediación funcionaron. "Lo peor es cuando los clientes dicen que su proveedor de servicios administrados tiene los registros, solo para descubrir que no los tienen, y nunca verificaron que los tuvieran. El ataque SolarWinds ha sido una experiencia reveladora para ellos", dijo Herring.
-
Exigir a los proveedores que realicen evaluaciones continuas de seguridad y riesgos de su software, no solo evaluaciones puntuales
Una de las desventajas de un enfoque de seguridad con casillas de verificación es que los proveedores pueden mostrar una evaluación en un momento determinado que refleja una postura de seguridad sólida, pero no ofrece una imagen completa. "Se obtiene una evaluación al comienzo del contrato, y luego hay años de nada", dijo Alex Rice, fundador y director de tecnología de HackerOne, una firma de recompensas por vulnerabilidades y errores. "Ni siquiera se puede establecer una relación con los equipos de respuesta del proveedor. De hecho, para muchas empresas, esta fue su primera interacción con el equipo de respuesta de SolarWinds".
Rice cree que las empresas deben exigir evaluaciones continuas de seguridad y riesgos de sus proveedores cuando firman sus contratos iniciales y posteriores. Muchos proveedores de software dudan en divulgar esa información porque "hay pocos incentivos para ser transparentes", dijo Rice. "Cuanto más revele, más en riesgo puede estar un acuerdo". HackerOne ofrece a sus clientes información sobre todos los incidentes de seguridad que ha tenido o descubierto desde 2012. "Mientras que otros proveedores dicen: 'No tenemos ninguna vulnerabilidad o tiempo de inactividad', nosotros les damos incluso nuestros cuasi accidentes", dijo. "Esto permite que nuestros clientes estén informados".
Rice considera inaceptable que no haya total transparencia sobre lo que sucedió con SolarWinds e insta a la industria a realizar cambios para abordar esta necesidad en el futuro. "Los clientes necesitan saber dónde existe el problema en sus otros proveedores y cómo planean evitar que vuelva a suceder", dijo. "La gente está tratando de responder al hack, pero lo está haciendo a ciegas". Tener la ventaja de un requisito de evaluaciones de seguridad continuas alentaría a que saliera más información.
A medida que se implementan estas lecciones aprendidas, las empresas deben tratar de reducir el estigma que rodea al uso de servicios de seguridad externos, como revisiones de código, pruebas de penetración y análisis de vulnerabilidades, según Herring de Raxis. "Los líderes empresariales deben ayudarnos a acabar con el estigma de que estas empresas buscan conseguir equipos de desarrolladores y de TI. No se trata de aprobar/reprobar ni de meter a nadie en problemas. Estamos aquí para arrojar luz, ayudar a encontrar vulnerabilidades y mitigarlas y reducir el riesgo de una organización", dijo.
