Vulnerabilidades, métricas y cálculos en en SCI

Allá por junio de 2015 comentamos las vulnerabilidades relacionadas con Sistemas de Control Industrial y, a día de hoy,  continuamente vemos cómo se notifican cada vez más sea cual sea esta si de índole Software o Hardware. Ningún fabricante está exento, más aún cuando todos ellos no han podido ser diseñados bajo la premisa de ser seguro. Hablo desde el punto de vista de “Security” no “Safety”.

En este sentido uno de los métodos de catalogación es el “Common Vulnerability Scoring System”. Un framework abierto y ampliamente utilizado para estimar el impacto cuantitativo de las vulnerabilidades identificadas. Para ello se establece un conjunto de métricas las cuales se dividen de 3 grandes grupos como son: Base, Temporal y de Entorno, donde cada una de ellas engloba distintas características a considerar, como son el Vector de Ataque, privilegios requeridos, interacción con el usuario, remediación, etc.

Luego una fórmula matemática se encarga de establecer en una franja de 0 a 10, la gravedad de la misma, siendo 10 la más alta.

Actualmente se cuenta con la versión 3.1 la cual introduce algunos cambios con respecto a la versión 3.0.

A continuación, os dejo algunos documentos donde podréis encontrar información detallada con respecto a estas dos últimas versiones.

Documento CVSS 3.0

Documento CVSS 3.1

Calculadora CVSS 3.1

Sin embargo, este estándar se ha hecho con el fin de ser aplicado, principalmente en entornos IT, no para entornos OT. Los cuales, como es sabido, son muy distintos. Las consecuencias e impacto de la explotación de una de ellas podrá tener una repercusión Física. Por tanto, una vez más, debemos de establecer unos criterios acordes a los escenarios a los que nos enfrentamos.

En este sentido nos encontramos con IVSS, Industrial Vulnerability Scoring System. Un método que nos ayudará a establecer un valor teniendo en cuenta aspectos concretos de estos entornos como son impacto en la actividad, daños colaterales, rendimiento y elementos Safety.

Elaborada por Clint Bodungen,  la herramienta está disponible es su sitio Web podéis así como la fórmula empleada que permiten obtener dicho índice.

Hay que tener en cuenta que las vulnerabilidades a la hora de descubrirse se llevan a cabo en entornos controlados de laboratorio, junto con la posible explotación asociada. Por tanto, debemos tener presenta que las consecuencias e impacto dependerá del contexto y actividad donde se lleven a cabo. Un laboratorio nunca nos dará el resultado del entorno real.

Además, por ejemplo, no es lo mismo una fábrica donde produzca bajo estrategias JIT/JIS (Just In Time, Just In Sequence) a otra que lo haga con plazos de entrega de días o semanas donde una parada de 24 horas pueda llegar a ser asumible y no suponga repercusión alguna por disponer de estocaje suficiente. O bien, si de lo que hablamos es afecta a la actividad o la seguridad de los empleados como puede ser dispositivos Safety, robots o PLC de control de proceso.

Descubierta la misma, aun cuando el fabricante libere el parche o la remediación, es muy posible que pase un tiempo “muy considerable” antes de ser aplicada. Todo proceso de cambio debe realizarse forma controlada siguiendo una etapa de test, prueba piloto y finalmente despliegue controlado. No podemos llevar a cabo ninguna acción si no estamos seguros al 110 % de que no existirá incompatibilidad o impacto alguno, que pueda penalizar total o parcialmente los procesos bajo su control. No podemos introducir un riesgo mayor del que pretendemos mitigar con la corrección de una vulnerabilidad.

Esto en el mejor de los casos, ya que no sería la primera vez que se detectan vulnerabilidades sobre componentes o sistemas que no puedan ser actualizados, debiéndose aplicar otras medidas compensatorias como el Virtual Patching o definición de arquitecturas de red con mayor o menor índice de segmentación.

Hasta aquí la entrada de hoy, escueta pero que da lugar a invertir tiempo en lectura y tener contacto con un recurso online que nuevamente, entre otros muchos motivos, nos muestra las diferencia de los entornos IT y OT.

Un saludo!

 

Buscando ICS en la red, ZoomEye

En el día de hoy voy a hablar de una herramienta que si bien el grupo a las que pertenece ya es conocido y reconocido por muchos profesionales del ámbito IT, quizás no lo sea tanto para otros como ingenieros y técnicos de sistemas de control y automatización. Éstos, hasta hace no demasiado mucho tiempo, han estado ajenos a todo lo relacionado con la Ciberseguridad, cosa que ha tenido que cambiar, y cambiará aún, más con la llegada de la tán nombrada Industria. 4.0.

El tipo de herramienta a la que me refiero no es ni más ni menos, que los motores de búsqueda de dispositvos en Internet. Éstos, son buscadores no de páginas o contenido web, que es a lo que estamos acustumbrados, sino equipos como pueden ser servidores, routers, cámaras, y todo aquello que pueda estar expuesto en Internet. Y como no, autómatas, RTUs, HMIs, y cualquier otros sistemas que deban ser accesibles remotamente. A priori muchos podrían pensar que esto es un disparate, y que a nadie se le ocurriría dejar visibles sus equipos así tan alegremente, sin embargo esto es más común de lo que pensamos.

La herramienta por excelencia en este ámbito es Shodan el cual fue creada en el año 2009 por John Matherly quien concibió la idea de buscar sistemas en lugar de páginas en Internet. Si bien uno puede crearse un usuario de froma gratuita, también existe una opción de pago con las que se consiguien mayor cantidad de posibilidades.

Por ejemplo, si efectuamos una búsqueda de equipos con el puerto TCP 102 abierto, tendríamos un resultado como sigue:

Destacar por ejemplo cómo aparte de autómatas también nos identifica dispositivos «Conpot», el Honeypot del que hablaba en estas dos entradas Parte I y Parte II.

Otro ejemplo es Censys. Misma idea, con misma funcionalidad.

Por ejemplo si buscásemos relacionado con «Phoenix Contact» tenemos lo siguiente:

Resulta preocupante no tanto que esta información esté disponible,  sino el uso que se le pueda dar,  y sobre todo quién lo haga. Es decir, si estos datos son accesibles, quizás existan otros que no lo sean y quien esté detrás del sitio disponga de ellos, reservándose el hecho de hacerlos públicos. Si vemos lo que vemos es porque «alguien», nos deja,  alguien tiene el control y la capacidad de decidir «esto si,  esto no». A partir de ahi,  según sus intereses,  dejarnos hacer tal o cual cosa  bien gratis o «pasando por caja».

Tras esta reflexión,  llegamos a la herramienta en cuestión, ZoomEye. La misma tiene origen chino, y esto casi siempre asusta un poco. Aunque, en mi opinión, aqui todos se «miran» se «sonríen» entre ellos. La utilidad es la misma que las anteriores y, al igual que en Shodan, encontramos un apartado específico a ICS desde dónde hacer de una manera predefinida búsquedas relacionadas con protocolos o productos específicos de algunos fabricantes.

En la siguiente imagen se puede ver seleccionando el producto S7-300 (PLC) de Siemens.

También dispone de una vista («Vision») donde podremos la ubicación geográfica de los equipos localizados.

De igual modo se cuenta con un apartado «Docs» donde podremos ver el significado de mensajes, filtros, errores y demás información. Aqui dejo, por ejemplo, los filtros de búsqueda:

A esto habría que sumar un último punto. Como estamos acostumbrados los sistemas poseen contraseñas por defecto o «hardcodeadas» que muchos responsables o adminsitradores pensando en viejas ideas de «Quién tendrá interés», «A mi no me va a pasar», «que probabilidad hay de que eso me pase a mi» y bla bla bla.; no las cambian o no puedan hacerlo. Lo cierto es que investigadores del grupo «SCADA StrangeLove» hace unos meses publicaron una lista con las contraseñas por defecto de muchos fabricantes y que puede ser accedida y descargada desde Github en el siguiente enlace. Por tanto dada la capacidad de estas herramientas y la información ya disponible para autenticación en sistemas; obliga necesariamente a tomar medidas ya que puede quién lo utilice no con buenas intenciones. Y cuando digo «quien» hablo de grupos terroristas, Agencias de Inteligencia, delincuentes, inconscientes, o cualquier otro que pueda no ir con buenas intenciones.

En cualquier caso resulta necesario que cualqueir equipo de esta naturaleza que deba ser accedido desde el exterior, cuente con un sistemas que eviten la exposición directa, y a su vez, establezcan unos controles de acceso, autenticacióin y cifrado de las comunicaciones. La solución más adecuada reside son las VPN, disponiendo ya de productos concretos para entornos industriales. Os dejo unos ejemplos:

Fortinet

Endian

Netgate

Como decía, los Sistemas de Control Industrial en muchas ocasiones deben ser accesibles remotamente para tareas de soporte, mantenimiento o incluso el propio funcionamiento.  Imaginar por ejemplo un parque de aerogeneradores eólicos sobre los cuales se desee monitorizar los MWatts producidos. Como compenderéis no puede ir un técnci con un Range Rover e ir apuntando uno por uno… Sin embargo, éstos pueden ser no sólo detectados sino además accedidos si no se han tomado medidas tán básicas como cambiar las contraseñas por defecto. siempre que se pueda. No obstante, esta medida no puede tomarse del todo efectiva ya que éstos pueden implementar versiones de protocolos vulnerables y que junto con la condición de una difícil actualización, continúan de una forma u otra, en la misma sitación. Esto es, vulnerables y además expuestos. Es por ello que deben establecerse otro tipo controles como la creación de VPNs mediante NGFW, con motores AV, IDS/IPS, Control de Aplicación, capacidad de hacer DPI junto con los procolos industriales utilizados y declinar en ellos el acceso controlado y con unas medidas de seguridad aceptables.

Esto esto es todo, nos vemos en la próxima!!

Reputación IP.

El pasado mes de marzo asistí, un año más, al Congreso de Seguridad Rooted Con que se celebra anualmente en Madrid. Aparte de invitaros a que acudáis a él y que lo difundáis, quisiera que viereis uno de los vídeos que me parece muy interesante. Entendámonos, interesantes y muy buenos, son todos pero en esta ocasión hablaremos de uno en concreto.

Guillermo Grande y Alberot Ortega, miembros de Alienvault, hicieron una presentación sobre  la creación de un sistema de reputación IP. Dicho a groso modo esto es, catalogar una IP o dominio en función de su comportamiento, es decir si el sitio aloja malware, si desde allí se envía spam, se realizan escaneos, etc. y tomar a continuación, alguna medida sobre ellos configurando nuestros dispositivos de seguridad de red.

La verdad que poco más voy a decir ya que, qué mejor que ellos para contar cómo se recolecta la información, se procesa, se selecciona y se aplica. Os dejo entonces tanto el video como el enlace:

Link:

http://labs.alienvault.com/labs/index.php/projects/open-source-ip-reputation-portal/

Espero que os guste,

Seguiremos informando.