Source: https://www.scribd.com/doc/139600583/480-Seguridad-Sistemas-SCADA-Mar10
Timestamp: 2016-07-24 13:02:55+00:00

Document:
480 Seguridad Sistemas SCADA Mar10
UploadSign inJoinBooksAudiobooksComicsSheet MusicEditors' Picks BooksHand-picked favorites from our editorsEditors' Picks AudiobooksHand-picked favorites from our editorsEditors' Picks ComicsHand-picked favorites from our editorsEditors' Picks Sheet MusicHand-picked favorites from our editorsTop BooksWhat's trending, bestsellers, award-winners & moreTop AudiobooksWhat's trending, bestsellers, award-winners & moreTop ComicsWhat's trending, bestsellers, award-winners & moreTop Sheet MusicWhat's trending, bestsellers, award-winners & moreCategoriesArts & IdeasBiography & MemoirBusiness & LeadershipChildren'sComputers & TechnologyCooking & FoodCrafts & HobbiesFantasyFiction & LiteratureHappiness & Self-HelpHealth & WellnessHistoryHome & GardenHumorLGBTMystery, Thriller & CrimePolitics & EconomyReferenceReligionRomanceScience & NatureScience FictionSociety & CultureSports & AdventureTravelYoung AdultCategoriesArts & IdeasBiography & MemoirBusiness & LeadershipChildren'sComputers & TechnologyCooking & FoodFantasyFiction & LiteratureHappiness & Self-HelpHealth & WellnessHistoryHome & GardenHumorLGBTMystery, Thriller & CrimePolitics & EconomyReferenceReligionRomanceScience & NatureScience FictionSociety & CultureSports & AdventureTravelYoung AdultCategoriesAdaptationsChildren’sCrime & MysteryFictionHumorMangaNonfictionRomanceSciFi, Fantasy & HorrorSuperheroesYoung AdultPublishersArcanaArchie ComicsBOOM! StudiosDynamiteIDW PublishingKingstone ComicsMarvel ComicsSpace Goat ProductionsTop Cow ComicsValiant ComicsZenescopeDifficultyBeginnerIntermediateAdvancedMixedInstrumentBrassDrums & PercussionGuitar, Bass, and FrettedPianoStringsVocalWoodwindsGenreClassicalCountryFolkJazz & BluesMovies & MusicalsPop & RockReligious & HolidayStandardsWelcome to Scribd! Start your free trial and access books, documents and more.Find out moreSIN CLASIFICARGUÍA DE SEGURIDAD DE LAS TIC (CCN-STIC-480) SEGURIDAD EN SISTEMAS SCADA
CCN-STIC-480 SEGURIDAD EN SISTEMAS SCADA
 Editor y Centro Criptológico Nacional, 2010 NIPO: 076-10-072-4 Tirada: 1000 ejemplares Fecha de Edición: marzo de 2010 LIMITACIÓN DE RESPONSABILIDAD El presente documento se proporciona de acuerdo con los términos en él recogidos, rechazando expresamente cualquier tipo de garantía implícita que se pueda encontrar relacionada. En ningún caso, el Centro Criptológico Nacional puede ser considerado responsable del daño directo, indirecto, fortuito o extraordinario derivado de la utilización de la información y software que se indican incluso cuando se advierta de tal posibilidad. La referencia a cualquier producto comercial específico, proceso o servicio con nombre comercial, marca fabricante, o de otro modo, no constituye ni implica su respaldo comercial. Los puntos de vista y las opiniones de los autores expresadas en este documento no se utilizarán para fines publicitarios ni de respaldo. AVISO LEGAL Quedan rigurosamente prohibidas, sin la autorización escrita del Centro Criptológico Nacional, bajo las sanciones establecidas en las leyes, la reproducción parcial o total de este documento por cualquier medio o procedimiento, comprendidos la reprografía y el tratamiento informático, y la distribución de ejemplares del mismo mediante alquiler o préstamo públicos.
El uso masivo de las tecnologías de la información y las telecomunicaciones (TIC), en todos los ámbitos de la sociedad, ha creado un nuevo espacio, el ciberespacio, donde se producirán conflictos y agresiones, y donde existen ciberamenazas que atentarán contra la seguridad nacional, el estado de derecho, la prosperidad económica, el estado de bienestar y el normal funcionamiento de la sociedad y de las administraciones públicas. La Ley 11/2002, de 6 de mayo, reguladora del Centro Nacional de Inteligencia, encomienda al Centro Nacional de Inteligencia el ejercicio de las funciones relativas a la seguridad de las tecnologías de la información en su artículo 4.e), y de protección de la información clasificada en su artículo 4.f), a la vez que confiere a su Secretario de Estado Director la responsabilidad de dirigir el Centro Criptológico Nacional en su artículo 9.2.f). Partiendo del conocimiento y la experiencia del CNI sobre amenazas y vulnerabilidades en materia de riesgos emergentes, el Centro realiza, a través de su Centro Criptológico Nacional, regulado por el Real Decreto 421/2004, de 12 de marzo, diversas actividades directamente relacionadas con la seguridad de las TIC, orientadas a la formación de personal experto, a la aplicación de políticas y procedimientos de seguridad, y al empleo de tecnologías de seguridad adecuadas. Una de las funciones más destacables del Centro Criptológico Nacional es la de elaborar y difundir normas, instrucciones, guías y recomendaciones para garantizar la seguridad de los sistemas de las tecnologías de la información y las comunicaciones de la Administración, materializada en la existencia de la serie de documentos CCN-STIC. Disponer de un marco de referencia que establezca las condiciones necesarias de confianza en el uso de los medios electrónicos es, además, uno de los principios que establece la ley 11/2007, de 22 de junio, de acceso electrónico de los ciudadanos a los servicios públicos, en su artículo 42.2 sobre el Esquema Nacional de Seguridad (ENS). Precisamente el Real Decreto 3/2010 de 8 de Enero de desarrollo del Esquema Nacional de Seguridad fija los principios básicos y requisitos mínimos así como las medidas de protección a implantar en los sistemas de la Administración, y promueve la elaboración y difusión de guías de seguridad de las tecnologías de la información y las comunicaciones por parte de CCN para facilitar un mejor cumplimiento de dichos requisitos mínimos. En definitiva, la serie de documentos CCN-STIC se elabora para dar cumplimiento a los cometidos del Centro Criptológico Nacional y a lo reflejado en el Esquema Nacional de Seguridad, conscientes de la importancia que tiene el establecimiento de un marco de referencia en esta materia que sirva de apoyo para que el personal de la Administración lleve a cabo su difícil, y en ocasiones, ingrata tarea de proporcionar seguridad a los sistemas de las TIC bajo su responsabilidad. Marzo de 2010
Félix Sanz Roldán Secretario de Estado Director del Centro Criptológico Nacional
Centro Criptológico Nacional ii
1. INTRODUCCIÓN.......................................................................................................................5 2. OBJETO.......................................................................................................................................5 3. ALCANCE ...................................................................................................................................6 4. INTRODUCCIÓN A LA SEGURIDAD EN SISTEMAS SCADA.........................................6 4.1. RIESGOS DE LOS SISTEMAS SCADA................................................................................6 5. SEGURIDAD EN SISTEMAS SCADA ....................................................................................8 5.1. EMPRESA................................................................................................................................8
5.1.1.1. 5.1.1.2. 5.1.1.3. 5.1.1.4. 5.1.1.5. 5.1.1.6. 5.1.1.7.
GESTIÓN DEL RIESGO .................................................................................................................... 8
ANÁLISIS DEL RIESGO .........................................................................................................................8 LA HERRAMIENTA PILAR .................................................................................................................10 GRUPO DE CONTROL DE LA SEGURIDAD EN SCADA ................................................................11 ARQUITECTURA DE SEGURIDAD ....................................................................................................12 CONTRAMEDIDAS...............................................................................................................................13 EQUIPO DE RESPUESTA DE SEGURIDAD SCADA ........................................................................14 REVISIONES CONTINUAS ..................................................................................................................15
5.1.2.1. 5.1.2.2. 5.1.2.3. 5.1.2.4.
POLÍTICAS, NORMAS Y MANUALES ............................................................................................. 16
ÁMBITO .................................................................................................................................................16 DEFINICIÓN Y REVISIÓN ...................................................................................................................16 APLICACIÓN .........................................................................................................................................17 PLANES DE RESPUESTA.....................................................................................................................18
5.1.4.1. 5.1.4.2. 5.1.4.3. 5.1.4.4.
AUDITORÍAS ................................................................................................................................ 19 GESTIÓN DE PROYECTOS EN SCADA ................................................................................... 19
FASES PREVIAS....................................................................................................................................19 REALIZACIÓN ......................................................................................................................................20 REQUISITOS DE FINALIZACIÓN.......................................................................................................21 OTROS ASPECTOS ...............................................................................................................................22
EMPRESAS EXTERNAS ................................................................................................................. 22
5.1.5.1. PROVEEDORES.....................................................................................................................................23 5.1.5.2. EMPRESAS DE SOPORTE....................................................................................................................24 5.1.5.3. CADENA DE SUMINISTRO .................................................................................................................25
5.2. RECURSOS HUMANOS ......................................................................................................25
5.2.2.1. 5.2.2.2. 5.2.2.3. 5.2.2.4.
CONTRATACIÓN........................................................................................................................... 25 FORMACIÓN ................................................................................................................................. 26
OBJETIVO DE LA FORMACIÓN.........................................................................................................26 PLAN DE FORMACIÓN........................................................................................................................26 MÉTODOS DE FORMACIÓN...............................................................................................................27 PLANES DE RESPUESTA.....................................................................................................................28
RELACIONES INTERDEPARTAMENTALES ........................................................................ 28 BAJA ............................................................................................................................................ 29
5.2.3. 5.2.4. 5.3.1. 5.3.2. 5.3.3. 5.3.4. 5.3.5. 5.3.6.
5.3. SISTEMAS.............................................................................................................................30
GESTIÓN DE ACTIVOS .................................................................................................................. 30 SEGURIDAD FÍSICA ...................................................................................................................... 31 SEGURIDAD PERIMETRAL ............................................................................................................ 32 SECURIZACIÓN ............................................................................................................................ 33 MONITORIZACIÓN ....................................................................................................................... 35 PROCEDIMIENTOS DE RECUPERACIÓN ......................................................................................... 37
5.3.3.1. ACCESOS REMOTOS ...........................................................................................................................33 5.3.4.1. PARCHEADOS.......................................................................................................................................34
5.3.6.1. ANÁLISIS FORENSE ............................................................................................................................38
6. SOFTWARE SCADA ...............................................................................................................39
Centro Criptológico Nacional iii
...................................43 B............40 A................................. REFERENCIAS .................1........1.......................29]) ...43
FIGURA 1: XPLOIT EN EN SOFTWARE REALWIN ([REF................................. 39
ANEXO A.............. 7 FIGURA 2: ORIGEN DE ATAQUES SCADA ..1................41 ANEXO B........................1.............................................. GLOSARIO DE TÉRMINOS Y ABREVIATURAS ..........17]) ........... 20 FIGURA 4: ESQUEMA DE RESPUESTA DE SEGURIDAD EN EL CONTROL DE PROCESOS .. EMPRESAS DESARROLLADORAS DE SOFTWARE SCADA ......................................................... GLOSARIO DE SIGLAS....................................................43 B............ GLOSARIO DE TÉRMINOS ............................................................................................... 8 FIGURA 3: SEGURIDAD EN EL CICLO DE VIDA DEL DESARROLLO ([REF..........SIN CLASIFICAR
OTRAS HERRAMIENTAS ..................................................2.........................
de automatización industrial y sistemas relacionados con la seguridad física o industrial. refinerías. Los datos se procesan para determinar si los valores están dentro de los niveles de tolerancia y.
5. Así lo ve la Unión Europea en varias resoluciones ([Ref. los RTU o PLC que manejan los dispositivos. técnicos o no. de Control Distribuido (DCS). y como punto único de fallo. nucleares. Control y Adquisición de Datos. ([Ref.
.. Por lo tanto. que tienen un papel en la seguridad de los sistemas SCADA..
2. de ser necesario. Su seguridad trasciende el ámbito de la empresa y requiere del asesoramiento y el control de organismos superiores. consolas desde donde los operadores monitorizan y controlan los diferentes equipos y un servidor histórico de bases de datos que almacena en disco toda la información que recibe y maneja el servidor central. centralizado. y un fallo de estos puede ocasionar que no se detecten malos funcionamientos que produzcan graves pérdidas económicas. OBJETO
7. cuando no un peligro para la seguridad de los empleados o desastres medioambientales. o granja de servidores. Los sistemas de control de procesos son críticos en muchas industrias. tomar medidas correctivas para mantener la estabilidad y el control. Toda la producción depende de unos pocos sistemas. de control de procesos. gas centrales generadoras de electricidad: térmicas. 9.21])..SIN CLASIFICAR
1.22]) Estas infraestructuras suelen estar localizadas en • • • • 4. puertos o aeropuertos. Control y Adquisición de DAtos (SCADA).. estableciendo los ámbitos en los que intervienen y presentando los mecanismos adecuados para que su actuación sea efectiva. etc. hidroeléctricas. Describir las técnicas necesarias para analizar los riegos derivados de dichos sistemas.
2. en muchos casos para todo un país y su entorno.
3. distribución y control de electricidad.
6. Enumerar todos los elementos. comprenden todas aquellas soluciones de aplicación que recogen medidas y datos operativos de equipos de control locales y remotos. la seguridad de estos sistemas debe ser una materia de máxima prioridad. Un fallo en una Infraestructura Crítica supone un perjuicio para toda la sociedad. etc. La seguridad de los sistemas SCADA es especialmente relevante en el ámbito de las Infraestructuras Críticas. Presentar la problemática planteada por los sistemas SCADA y sus vulnerabilidades. su impacto y la necesidad imperativa de controlar su seguridad.20]) adoptadas por la administración española ([Ref. sistemas industriales: químicas. 8.22]) La arquitectura básica comprende un servidor.. [Ref. de Supervisión. INTRODUCCIÓN
1. En este documento se utiliza el término SCADA para referirse a todo sistema de control industrial. ([Ref. Los sistemas SCADA o sistemas de Supervisión. sistemas de transportes: metro.19]. agua.. trenes.
Gracias a ello. INTRODUCCIÓN A LA SEGURIDAD EN SISTEMAS SCADA
3. Con el fin de abaratar costes y acelerar el desarrollo de nuevos sistemas y la implantación de mejoras. como Microsoft Windows. no constituye ni implica su respaldo comercial. De ese modo se consigue centrar los esfuerzos en la funcionalidad buscada. o de otro modo. Su diseño se centraba en la funcionalidad. ahora los proveedores dan soporte remoto a través de enlaces telefónicos o de conexiones a Internet. 4. Esta guía es de aplicación a todos los sistemas SCADA. está orientada a cualquier organismo. la presente guía deberá ser actualizada convenientemente con los nuevos productos. Debido a la evolución del mercado. Los sistemas SCADA fueron diseñados antes del surgimiento de Internet. gusanos. ALCANCE
11. Además. referenciando los documentos donde se puede encontrar más información de cada una de ellas. o centralizar el control de instalaciones diversas.1. Fueron pensados para ser sistemas aislados y no conectados en red. navegadores Web y las conexiones inalámbricas. En la misma línea evolutiva. proceso o servicio con nombre comercial. virus y hackers). Utilizaban tecnologías propietarias y poco probadas fuera de ambientes controlados. 12. utilizando como base tecnologías ampliamente probadas y fiables.SIN CLASIFICAR
10. TCP/IP. marca fabricante. institución. Los módems rara vez están sujetos a los comprobaciones de
. Al aumentar las redes de SCADA y su conectividad entre redes. Aunque cobra especial importancia en las Industrias que trabajen con Infraestructuras Críticas. la fiabilidad y la seguridad física. los sistemas SCADA hacen cada vez más uso de tecnologías estándar. 13. industria o empresa que cuente con sistemas SCADA. los sistemas SCADA han aumentado su conectividad a interconectarse con otros sistemas..23]). en limitar el acceso. Presentar algunas soluciones técnicas ante determinadas amenazas. 18. Tradicionalmente carecen de dispositivos de seguridad como cortafuegos. 15. La referencia a cualquier producto comercial específico. tendencias y amenazas que aparezcan y los avances en seguridad que se produzcan. RIESGOS DE LOS SISTEMAS SCADA 17. los riesgos de amenazas electrónicas para los sistemas de SCADA continúan intensificándose.
4. mecanismos de cifrado o software antivirus ([Ref. ahora es posible utilizar sistemas SCADA distribuidos. A pesar de los beneficios derivados de este desarrollo. Los puntos de vista y las opiniones de los autores expresadas en este documento no se utilizarán para fines publicitarios ni de respaldo. integrar los resultados del control de procesos en los sistemas administrativos y mejorar el rendimiento no sólo de la producción de toda la empresa. 16. y gracias al tremendo avance de las comunicaciones y la conectividad de los últimos años. el aumento de la conectividad los ha expuesto a nuevas amenazas para las que no están preparados (ej.. Esta filosofía producía sistemas no preparados para ataques externos.
Aumenta su vulnerabilidad y el rango de posibles atacantes.
Figura 1: Xploit en en software RealWin ([Ref. Por tanto. Un ataque a un sistema no crítico. por ejemplo: ⇒ denegación del servicio ⇒ pérdida de la integridad de los datos ⇒ pérdida de confidencialidad de los datos ⇒ pérdida de reputación
Centro Criptológico Nacional 7
. 21. Los sistemas SCADA se vuelven vulnerables a ataques comunes y a malware ampliamente disponible desarrollado para otras plataformas. como es la red de un proveedor. complejidad. puede suponer de puerta de entrada de virus o ser usado para realizar ataques indirectos.29]). Este tipo de software y hardware a menudo no se adapta a la singularidad.. En Internet es posible encontrar demostraciones de ataques sobre sistemas SCADA comerciales ([Ref. Los efectos de un ataque electrónico en los sistemas SCADA pueden incluir. Muchas medidas estándar de protección de la seguridad en TI utilizadas normalmente en estas tecnologías no han sido adaptadas al entorno SCADA.. El software comercial y el hardware de propósito general se está usando para sustituir el propietario de los sistemas SCADA. 19. las medidas de seguridad disponibles para proteger los sistemas de control y mantener el entorno seguro pueden ser insuficientes.SIN CLASIFICAR
seguridad. los requerimientos de tiempo real y seguridad del entorno SCADA. Hay consecuencias potencialmente serias en el caso en el que se explotaran estas vulnerabilidades.29])
La importancia de los sistemas SCADA debe ser asumida por los cargos con más responsabilidad e incorporada en todas las decisiones que tomen. Se puede considerar que la seguridad SCADA no es algo a tener en cuenta en España al no tratarse de un objetivo prioritario. implicar a todos los ámbitos..1. 5. 5. Una definición útil consiste en expresar el riesgo en función de la probabilidad de que se produzca ese riesgo y el impacto que tendría lugar si ese riesgo se produjera.1. EMPRESA 24. 5. Se puede encontrar más información útil sobre este tema en el documento “CCN-STIC403 Gestión de incidentes de seguridad” ([Ref. probablemente fracasará.27]) reveló que España era origen de una parte importante de estos escaneos.1. un reciente estudio de Team Cymru rastreando escaneos de puertos sobre servicios conocidos de SCADA ([Ref.1. Esto es especialmente importante en el caso de los sistemas SCADA. desde aquellos que abarcan toda la empresa hasta las decisiones técnicas. que probablemente fueron hechos desde ordenadores personales infectados. En cambio.2]). GESTIÓN DEL RIESGO
26. 25. Toda gestión de la seguridad debe ser promovida desde las etapas superiores o directivas. como tal.1..1. la seguridad de los sistemas SCADA debe ser una prioridad y. De otro modo.
Figura 2: Origen de ataques SCADA
5. Todo ejercicio en torno a la seguridad debe comenzar por comprender el riesgo que se corre.SIN CLASIFICAR
⇒ impacto en las condiciones de trabajo 22. SEGURIDAD EN SISTEMAS SCADA
. Como elemento único de fallo del que depende tan fuertemente la producción. ANÁLISIS DEL RIESGO
virus. ([Ref. 29. bots.. Las fuentes de amenazas o atacantes potenciales (conscientes o inconscientes) incluyen (pero no se limitan a): • • • • • • • • • • • Hackers y delincuentes Malware de propagación automática (gusanos. 30. siempre que se cumplan una serie de requisitos formales en SCADA que garanticen una coherencia y un endurecimiento de dichas medidas. 28. acceder a Internet) Inteligencia corporativa Contratistas Servicios de inteligencia extranjeros Crimen organizado Terroristas Manifestantes y activistas (ej.) Atacantes internos Personal descontento Personal realizando acciones no autorizadas (ej. Desde el CCN se recomienda utilizar la metodología Magerit ([Ref. Es importante conocer las amenazas y sus motivaciones para poder responder ante ellas.12]). troyanos. amenazas. phising. pro-derechos de los animales)
32. medioambientales. políticos. impactos.25]). Las posibles amenazas incluyen entre otras: • • • • • Denegación de servicio Ataques dirigidos Incidentes accidentales Accesos y controles no autorizados Código malicioso o no autorizado instalado en las máquinas (gusanos. Para identificar las vulnerabilidades deben partirse del catálogo de activos (ver apartado 120). vulnerabilidades. spam. En general. etc. cualquier medida técnica de seguridad que se pueda aplicar en TI puede ser utilizada en SCADA y viceversa.. El Instituto Nacional de Administración Pública suele convocar acciones formativas en el empleo de esa metodología y esta herramienta en sus distintas modalidades en colaboración con el Centro Criptológico Nacional.. bots. La metodología Magerit se basa en los siguientes elementos: activos. etc. riesgos y salvaguardas. elaborado por el Consejo Superior de la Administración electrónica y de obligado cumplimiento para todos los órganos de la Administración Española y la herramienta PILAR que desarrolla bibliotecas específicas para infraestructuras críticas.
31. 33.).SIN CLASIFICAR
Otra define el riesgo total como la suma de todos los riesgos individuales de las amenazas identificadas.
2.SIN CLASIFICAR
34.4]).. El término atractivo. el término no es relevante en este caso. cualquier sistema vulnerable está en peligro.es ([Ref.1. La mayoría de los gusanos infectan de manera indiscriminada y.. 5. como la infección de un gusano. En consecuencia. LA HERRAMIENTA PILAR
39. 38. pero ha de considerarse alto para toda aquella empresa que trabaje o forme parte de la Infraestructura Crítica Nacional (ICN). A partir del análisis propone:
Centro Criptológico Nacional 10
. consultar el Catálogo de Infraestructuras Críticas Nacionales en http://www. Gestión de activos. integridad.. Para más información acerca de lo que puede considerarse ICN. por tanto. El atractivo de un blanco depende de la fuente de amenaza. falsos negativos o falsos positivos Pérdida de integridad de los datos capturados o almacenados Pérdida de confidencialidad
35.. 40. 37. La Herramienta Pilar analiza los siguientes aspectos: confidencialidad.Para identificar los activos se deben estudiar y evaluar al menos los siguientes elementos (consultar la guía CCN-STIC-470 Herramienta PILAR [Ref.24]).6] para más información): • • • • • • • • • • • • • • • Infraestructura Sistemas operativos y firmware Aplicaciones y software usado Conexiones de red Accesos remotos Procesos y procedimientos Gestión de empleados Gestión de subcontratas y proveedores Pérdida de una o varias máquinas o reducción de su funcionalidad Pérdida de disponibilidad (denegación de servicio) Pérdida de conectividad Cambios de configuración Funcionamiento incorrecto. El atractivo o interés que un sistema puede suscitar en un atacante potencial es un factor importante que puede modificar el riesgo. Se pueden encontrar consejos útiles sobre este tema en la guía “CCN-STIC-410 Análisis de riesgos en sistemas de la Administración” ([Ref.1. disponibilidad. Existen múltiples herramientas y metodologías que permiten realizar un análisis de riesgos (ver por ejemplo [Ref.21]). autenticidad y trazabilidad. Debe intentarse que el impacto posible de cualquier amenaza sea asumible:
36.cnpices. puede no ser aplicable a ciertos riesgos. Desde el CCN se recomienda utilizar la Herramienta de Análisis de Riesgos PILAR. pero sí en muchos otros.
proporcionará orientación sobre nuevas fuentes de amenazas. Ingeniería: en caso de que sea un grupo distinto al de SCADA se puede necesitar orientación práctica sobre el funcionamiento de la empresa. en la pagina web del CCN-CERT ([Ref. recursos disponibles (materiales.3. Equilibrar la política y las estrategias de seguridad con otros factores: necesidades de la empresa. orientada a PYMES y a la Administración Local. los resultados y el entorno existente..1]) o poniéndose en contacto directamente con éste. Para mantener el conocimiento actualizado una buena técnica es establecer un grupo de control de la seguridad en SCADA que revise periódicamente las políticas y normas. 42. Existe una versión sencilla. su ejecución. 5. impactos y contramedidas (salvaguardas). requisitos legales.1.SIN CLASIFICAR
salvaguardas (o contra medidas) normas de seguridad procedimientos de seguridad elementos de respaldo (back up) planes de recuperación de desastres
41. técnicos y humanos). riesgos.1. Recursos humanos: orientación clave para garantizar la coherencia y el cumplimiento de las condiciones de trabajo necesarias. 44. Examinar los factores de riesgo identificados Seleccionar las medidas apropiadas de reducción de riesgos. Seguridad: proporciona una perspectiva de conocimiento. Este grupo no buscará soluciones técnicas.
. llamada PILAR Basic. SCADA: proporciona representación y capacidades de los sistemas de control de procesos. Tecnologías de la información: en caso de que se trate de un grupo distinto de ingeniería y de SCADA.. amenazas.. GRUPO DE CONTROL DE LA SEGURIDAD EN SCADA
43. puede ser uno o varios altos directivos. En dicho grupo deben estar representados al menos los siguientes grupos: • • • • • Gestión: proporciona una perspectiva de lo que el negocio necesita. vulnerabilidades. Puede encontrar más información sobre esta herramienta en su manual ([Ref.18]): • • • • Controlar el programa de seguridad en SCADA: activos. identificación de activos críticos y el nivel de exposición existente. El conocimiento y control del riesgo y de las variables de las que depende es una tarea continua porque están continuamente evolucionando.10]). experiencia e integración en seguridad física y de la información. pues su trabajo será a un nivel superior. Sus responsabilidades principales son (se pueden encontrar más en [Ref.
○ Asegurar que todos los ingenieros. Se realizará teniendo en cuenta las recomendaciones del análisis de riesgos. Para cada riesgo hay tres tipos de acciones disponibles: • • • Aplicar medidas de reducción de riesgos (o medidas de mejora de la seguridad): el resto de esta sección trata la selección de estas medidas con más detalle. se debe aceptar por la dirección y debe registrarse en un registro de riesgos. Aplicar un plan de continuidad: este tema se trata en el módulo “Establecer capacidades de respuesta” y se puede localizar en el Apéndice A. Suele relacionarse con el coste para tener una mejor capacidad de evaluación.
46. Al adoptar medidas de reducción de riesgos. 5. Integrar los requisitos de condiciones de trabajo en la seguridad en SCADA. usuarios y administradores son conscientes de la seguridad e implementan los procesos y procedimientos de forma segura. normas y procesos actualizados con las amenazas actuales. Es importante comprender las prioridades y los activos de la empresa antes de elaborar un plan. debe garantizarse que las medidas han sido desplegadas conforme al diseño de la arquitectura de seguridad. Tratar como riesgo residual (no tomar ninguna acción): en caso de que se decida tratar un riesgo como residual.1. ○ Vigilar que se incluyen las pruebas de integración y despliegue y garantizar que las medidas se han aplicado correctamente. 48. hay una serie de factores a tener en cuenta: • •
49.4.SIN CLASIFICAR
Desarrollar los procedimientos asociados que apoyen a las medidas de reducción de riesgos. El coste La eficacia de la medida. ARQUITECTURA DE SEGURIDAD
Definir y delegar en su caso las responsabilidades.1. ○ Asegurar que el riesgo derivado de colaboradores es gestionado. ○ Garantizar una capacidad respuesta adecuada para reaccionar ante los cambios en las amenazas a la seguridad.
Monitorizar e informar del estado de la seguridad en el SCADA. Mantener la política. a menudo el esfuerzo se centra en incluirlos en las actividades del día a día. Gestionar el plan de concienciación y formación en SCADA. Cabe señalar que no se trata sólo de escribir y publicar estos procedimientos. ○ Una vez finalizados los proyectos y los cambios. Pero el objetivo fundamental de este grupo es ayudar a elaborar una Arquitectura de Seguridad. manteniendo un control de proyectos y cambios.
5. tecnologías certificadas y recomendaciones de la industria. Como mínimo deben incluir: • • Procedimientos de cómo informar sobre los incidentes Proceso para invocar el plan de respuesta
.1. aplicar los parches. Las medidas de seguridad pueden necesitar algún tiempo para ser implementadas (ej. La dificultad de implementación de la medida. aislar el sistema.SIN CLASIFICAR
El modelo de negocio: la necesidad de seguridad (muy alta en el caso de ICN). Procesos y procedimientos para monitorizar. las necesidades legislativas. evaluar y poner en marcha las respuestas a los incidentes y alertas de seguridad.5. Los planes de respuesta son a menudo bastante amplios y deben estar redactados de acuerdo al modelo operativo elegido. Considerar la posibilidad de medidas cautelares simples y de bajo coste que puedan proporcionar alguna protección a corto plazo.
50.1. la implementación de otras medidas de seguridad mayores pueden implicar la implantación de un nuevo sistema o la creación de nuevas prácticas o procedimientos de trabajo. Procedimientos de comunicación y revisión de todos los incidentes de seguridad. rediseñar la red e implementar el cortafuegos). debido a los cambios en entorno operativo del control de procesos que se ha discutido. Una parte esencial de cualquier estrategia de seguridad es. El mantenimiento. ensayo y pruebas de todos los planes de seguridad. el Retorno de la Inversión en Seguridad (RIS). Actualización de las políticas y estándares con las lecciones aprendidas. Algunas medidas de seguridad necesitan poco tiempo porque implican pequeños cambios en la configuración de los sistemas existentes o modificaciones menores en prácticas de trabajo existentes. teniendo en consideración estándares.
54. Entre las posibles respuestas se pueden incluir: aumentar la vigilancia. Las contramedidas mínimas que se deben garantizar son: • • • • • Un Equipo de Respuesta ante incidentes de Seguridad SCADA para responder a los incidentes de seguridad. Sin embargo. Las organizaciones que se dedican al control de procesos ya tendrán preparados planes de recuperación de desastres (PRC) y de continuidad de negocio (PCN). reconocer que el riesgo residual seguirá existiendo y tendrá que ser gestionado junto con la capacidad de identificar y responder a cualquier otro cambio en las amenazas. CONTRAMEDIDAS
51. La soluciones existentes. Sin embargo. 53. por tanto. 52. o movilizar el ERSCP. Los adecuados planes de respuesta a incidentes y de continuidad del negocio para todos los sistemas de control de procesos. Un sistema de alerta temprana que notifique al personal encargado de los incidentes y alertas de seguridad. estos planes a menudo son insuficientes para responder ante la amenaza de ataques electrónicos.
. El ERS debe participar en cada una de las etapas del proceso de monitorización de una situación.4. ya sea a tiempo parcial o completo. etc.1. Oficina de contacto con los medios. proveedores. Sus miembros deben de proceder de varias fuentes. Un Equipo de Respuesta de Seguridad SCADA (ERS) es un elemento fundamental de la capacidad de respuesta de una organización y proporciona las bases para la monitorización.). Gestión del negocio.6) ○ Una definición clara de cómo identificar cada escenario ○ Un plan de acción claro en el caso de identificar un escenario
Un ruta clara de escalado y los requisitos de autorización necesarios para la escalada Listas de herramientas de apoyo disponibles Información de contacto (incluyendo organismos tanto internos como externos.6. Operaciones. incluyendo: • • • • • • • • • Equipo de control de procesos. análisis y respuesta eficaz a alertas e incidentes. Equipo de seguridad empresarial. sistemas y activos críticos.
Los criterios que deben cumplirse para cerrar los incidentes.1. cuerpos policiales. sus suplentes. SCADA y automatización. Es un requisito fundamental que las personas con las capacidades y conocimientos adecuados están involucradas en el ERS. con representantes de distintas áreas. y los detalles de contacto 24x7. Un plan de comunicación claro ○ Cómo comunicar ○ Qué comunicar ○ A quién comunicar ○ Cuándo comunicar y con qué frecuencia
• 5. Centros. Procedimientos predefinidos a los posibles escenarios previamente identificados (ver sección 3. EQUIPO DE RESPUESTA DE SEGURIDAD SCADA
55. Seguridad TI. Reguladores internos. funciones y responsabilidades. Infraestructura TI. empresas.SIN CLASIFICAR
Detalles del personal del equipo de respuesta. 56. analizando cualquier cambio en la amenaza e iniciando las respuestas apropiadas.
59. Revisar y mantener actualizados los planes existentes a raíz de cualquier cambio en la amenaza. al menos anualmente y con mayor frecuencia para sistemas críticos o de alto riesgo. • • • • • • • Criticidad y riesgo de sistema.SIN CLASIFICAR
57. notificaciones de parches.7. o una combinación de ambos. Para evitarlo. Fusiones y adquisiciones. y datos de la red y de los sistemas de monitorización del rendimiento. ○ Monitorizar: recoger información de seguridad de dentro y fuera de la organización.
. Proponer cambios al grupo de gestión de la seguridad en SCADA. o las lecciones aprendidas durante un ejercicio o tras un incidente. hay que definir “disparadores” que pongan en marcha el proceso de actualización cuando sea necesario. ○ Responder: responder en base al tipo y categoría de la amenaza y el riesgo asociado para la organización. Según el tamaño y las necesidades de la empresa. pero suelen incluir: • Cambios en: ○ Nivel de amenaza. la estructura organizativa.1. o una red de ERS locales. Por ello. obsoleto e inservible. Cumplimiento de las garantías necesarias. • • • Ejecutar los planes de respuesta y continuidad existentes. Cambios en un sistema. ○ Tolerancia al riesgo. puede haber un ERS centralizado.1. Revisar regularmente los riesgos residuales. ○ Analizar: categorizar la información recibida de varias fuentes en diferentes niveles y tipos de amenaza potencial. Nuevos proyectos. como un Centro de Coordinación (CC). REVISIONES CONTINUAS
• • 5. Entre sus responsabilidades. El estudio del riesgo suele ser un proceso muy largo y que necesita información de muchas fuentes. Tiempo transcurrido (revisiones periódicas). están: • Garantizar que se cumple el plan de alerta temprana. el sistema. en los requisitos de protección. como alertas. 58. Ensayar y probar periódicamente los planes existentes. amenazas. filtrando los datos apropiados que necesitan una respuesta. infecciones de virus. Tales factores desencadenantes pueden variar . Circunstancias políticas. es fácil que quede desactualizado.
POLÍTICAS. 5. Planes de respuesta (que deben reflejar con exactitud los sistemas y procesos existentes. 62. Las políticas y normas de seguridad en SCADA pueden estar combinadas o ser independientes de las políticas de seguridad generales.1. Están influenciadas por la legislación. Se adaptan a cambios de escenario y suelen revisarse con frecuencia media. Programa de seguridad SCADA. Se trata generalmente de los documentos más detallados y sólo se centran en una aplicación específica. como la forma de configurar un modelo de cortafuegos de acuerdo a la norma / IT de rango superior. Las políticas y las normas son el mecanismo mediante el cual una organización puede comunicar a todos los niveles el objetivo buscado de protección de la seguridad en SCADA. 5. Estructura jerárquica y responsabilidades. El mínimo detalle que debería incluirse en un documento de política es:
. entran en poco detalle y sufren pocas modificaciones a lo largo del tiempo. Una revisión del análisis de riesgo suele desencadenar una serie de cambios en los siguientes elementos de la empresa: • • • • 5. sin el problema de complicar innecesariamente la normativa de nivrel superior. de la dependencia entre ámbitos y de la disponibilidad de recursos. Las guías proporcionan los detalles adicionales para asegurar que las normas e instrucciones técnicas se plasman apropiadamente en soluciones prácticas para entornos específicos. Proporcionan una interpretación organizativa coherente para lograr la calidad deseada de la política definida. la tecnología y las necesidades.2.2. Las políticas las definen los grupos directivos y gestores. Tienen aplicación amplia.SIN CLASIFICAR
Incidente/s importante/s
60. DEFINICIÓN Y REVISIÓN
66. 63. NORMAS Y GUÍAS ÁMBITO
61. Las políticas de seguridad en SCADA son el resultado directo de la gestión del riesgo.1.2. el mantenimiento y la eliminación de componentes en los sistemas SCADA. Están en continua evolución y adaptación.1. actualizándolo para hacer frente a los nuevos riesgos. Definen la creación. las de seguridad en TI y las de seguridad en la producción. 64. Las normas / instrucciones técnicas (IT) son la aplicación práctica de las políticas. normalmente a través del Grupo de control de la seguridad en SCADA.2. Definen los límites dentro de los que se pueden tomar medidas. y cómo se debe alcanzar. 65. La decisión de combinarlas o separarlas dependerá del tamaño y la estructura de la empresa. Inventario.1.
5. El detalle que debería incluirse en una norma es: • • • • • • • La política a la que se aplica la norma. y puede ser un mecanismo para actualizar o corregir donde no se alcancen los objetivos deseados. sino también la vigilancia de su cumplimiento.3. y que las soluciones coherentes se están aplicando en toda la organización. aunque es conveniente que se supervisen.2. APLICACIÓN
69. normalmente a través del Grupo de control de la seguridad en SCADA. Esta vigilancia proporciona una información muy importante para poner de relieve las dificultades de la política y las normas. con esta calidad” a qué o a quién se aplica la política: “el objetivo o los límites de la política” quién es propietario de la política: “quién la publicará y actualizará” qué significa la actualización de la política: “cuando debería revisarse la política” los criterios y procesos de excepción: “cuando no es aplicable la política”.
68.1. Su contenido dependerá del ámbito.SIN CLASIFICAR
la declaración política de intenciones: “los controles deben estar en su lugar. Las guías las elabora cada grupo para aplicar las normas / IT recibidas y no deben ser aprobados. cómo se aplica a las personas.
67. los procesos y la tecnología?" A qué o quiénes se aplica la norma: “el objetivo o los límites de las normas” quién es propietario de la norma: “quién la publicará y actualizará” qué significa la actualización de la norma: “cuando debería revisarse la norma” los criterios y procesos de excepción: “cuando no es aplicable la norma”. El cumplimiento de las políticas y normas: • • Garantizará que los sistemas SCADA están protegidos al nivel acordado de riesgo del negocio Asegurará que se evita la duplicidad innecesaria de esfuerzos. “que política o políticas" La audiencia o lectores: “el nivel de detalle” La definición y aplicación de la norma: “¿qué es esto. ha de vigilarse los siguientes aspectos: • • ¿Es la información suministrada suficiente (ni demasiada ni escasa) para el público objetivo en cada ámbito? ¿Quién es el responsable de la difusión y aplicación de las políticas y normas en cada nivel?
. Para garantizar una buena aplicación de las políticas y normas.
70. No sólo es necesaria la existencia de políticas y normas adecuadas. Las normas / instrucciones técnicas pueden ser elaboradas con la ayuda de grupos internos de especialistas o con la ayuda de terceros. pero deben ser siempre aprobadas por los grupos directivos y gestores.
Un plan de comunicación claro ○ Cómo comunicar ○ Qué comunicar ○ A quién comunicar ○ Cuándo comunicar y con qué frecuencia • Los criterios que deben cumplirse para cerrar los incidentes.4. procesos de excepción) Usar pruebas de penetración o escaneados de vulnerabilidad (con precaución). Sin embargo como mínimo deben incluir: • • • • • Procedimientos de cómo informar sobre los incidentes Proceso para invocar el plan de respuesta Detalles del personal del equipo de respuesta.
. proveedores. cuerpos policiales. y los detalles de contacto 24x7. usuarios y administradores de los sistemas. Las actividades típicas de vigilancia del cumplimiento incluyen: • • • • 5. Centros.SIN CLASIFICAR
¿Quién es el responsable de recopilar los datos sobre los resultados de seguridad en SCADA? Esta pregunta debe tener en cuenta el siguiente apartado de auditoría. Entrevistar a los propietarios. por ejemplo para evaluar la concienciación. Examinar la documentación como prueba del proceso que lleva a cabo (ej. Usar herramientas automáticas o listas de verificación basadas en las normas – instrucciones técnicas aplicables.). PLANES DE RESPUESTA
71.6) ○ Una definición clara de cómo identificar cada escenario ○ Un plan de acción claro en el caso de identificar un escenario • • • • Un procedimiento claro de escalado y los requisitos de autorización necesarios para la escalada del incidente Listas de herramientas de apoyo disponibles Información de contacto (incluyendo organismos tanto internos como externos. control de cambios.. sus suplentes. Procedimientos predefinidos a los posibles escenarios previamente identificados (ver sección 3. sistemas y activos críticos. Los planes de respuesta de seguridad SCADA son a menudo bastante amplios y deben estar redactados de acuerdo al modelo operativo elegido.1.4. empresas. funciones y responsabilidades. etc.2.
1..28]). 74. Se puede encontrar más información sobre auditorias en los documentos referenciados en el ANEXO A. estos no han sido comprometidos. con visibilidad de futuro de todas las etapas de implantación.1. Algunos ejemplos son la implantación. muchos proyectos cuyo ámbito no sea el control de procesos pueden tener impacto en los sistemas SCADA y en su seguridad. En cambio. El 8 de abril de 2009. explotación y baja del proyecto.1. Es recomendable nombrar un ingeniero de seguridad que se encargue de garantizar que la seguridad está convenientemente tratada en los requisitos. Las revisiones o auditorias son importantes para poder detectar y corregir a tiempo vulnerabilidades en la seguridad de los sistemas SCADA. el Wall Street Journal publicó la noticia de que la red eléctrica de EE. Estos proyectos deben ser controlados estrechamente. Cualquier proyecto que pueda afecta a la seguridad en sistemas SCADA debe incorporar los requisitos de seguridad adecuados desde sus primeras etapas. con la asistencia de un especialista en seguridad SCADA Revisión interna: un examen interno por un departamento asociado que no es responsable Auditoria interna: llevada a cabo por el departamento interno de auditoria de la organización Auditoria externa: llevada a cabo por una organización externa Control externo: una revisión de las principales vulnerabilidades específicas de la industria llevada a cabo por una organización externa. actualización o cambio de sistemas SCADA o TI. no se había producido ninguna pérdida de servicio ni de información.1. FASES PREVIAS
78.UU.4. 5. 77. Los sistemas SCADA suelen instalarse con la expectativa de una larga vida útil y unos cambios mínimos durante su vida. En ocasiones se tiene la falsa impresión de que por que no se haya detectado ningún fallo de seguridad en los sistemas..SIN CLASIFICAR
5. Referencias ([Ref. El cumplimiento de estos requisitos se debe asegurar en todo el ciclo vida del proyecto.
75.18]) 5. Las intrusiones se habían limitado a preparar puertas traseras para accesos posteriores. 79. Sin embargo. GESTIÓN DE PROYECTOS EN SCADA
73. Estas auditorias se pueden realizar de diferentes maneras: • • • • • • Auto-evaluación: una evaluación llevada a cabo por el departamento responsable Auto-evaluación asistida: una evaluación llevada a cabo por el departamento. Algunas sugerencias son:
Centro Criptológico Nacional 19
. cambios en los procedimientos. el desarrollo de información sobre la gestión de sistemas y la introducción de nuevas conexiones. había sido comprometida por organizaciones extranjeras ([Ref.4.3. el análisis y la arquitectura del proyecto. Cualquier nuevo sistema en un centro de nueva creación debería incluir requisitos de seguridad en los procesos de diseño y construcción desde la primera etapa.
etc. es fuente de problemas en fases posteriores y el coste de solucionarlos es mayor que el coste de invertir el tiempo suficiente en las primeras etapas para garantizar que el proyecto está bien definido.)
80.SIN CLASIFICAR
Revisiones de seguridad del diseño Revisiones de la seguridad del código Rutinas de mantenimiento Administración y monitorización de los elementos de seguridad (cortafuegos. incluyendo ([Ref.4. La seguridad es una parte importante en todo el ciclo de vida del proyecto. 5. La no inclusión. pero tiene más importancia en las primeras etapas.. continuidad y de pérdida de visión Aislamiento del sistema Garantía continuada Documentación actualizada del sistema Plan de sustitución y baja del sistema (destrucción de datos.2. La vigilancia de la seguridad debe realizarse a través de una serie de pruebas para confirmar la seguridad del sistema resultante y para garantizar que se podrán gestionar las vulnerabilidades en el futuro.17])
82. El siguiente diagrama muestra cómo los asuntos de seguridad deben considerarse en todo el ciclo de vida del desarrollo.1. Los requisitos de seguridad no deben ser considerados distintos a cualquier otro requisito funcional.17]):
Centro Criptológico Nacional 20
. antivirus) Pruebas de entrega Procedimientos de parcheado y control de cambios Planes de respuesta. REALIZACIÓN
81.. por el motivo que sea.
Políticas y normas Garantía
Especificación del sistema Soluciones estándar Integrar sistemas de seguridad en los procesos operativos
Comprender el riesgo de negocio (nivel de proyecto)
Medidas necesarias de seguridad Deficiencias
Comprender el riesgo de negocio (nivel de proyecto) Pruebas de garantía
Figura 3: Seguridad en el ciclo de vida del desarrollo ([Ref.
o antes de pasar el sistema a producción en el caso de proyectos internos. han de probarse al menos los siguientes elementos: o Configuración de seguridad o Escaneado de vulnerabilidades en todo el sistema o Pruebas de penetración o Pruebas de las reglas del cortafuegos o Pruebas de recuperación de fallos/desastres o Pruebas de copias de seguridad o Pruebas de parcheados (actualizaciones de seguridad) o Pruebas de actualización del antivirus o Pruebas de acceso remoto o Garantía de protección del sistema
Pruebas de puesta en servicio: Finalmente. una vez llegado al entorno productivo. Pruebas de sistemas integrados: los elementos integrados que se incorporen a un proyecto.
83. 84.3. deben ser probados independientemente.1. Los requisitos de seguridad. REQUISITOS DE FINALIZACIÓN
5. Los requisitos para aceptar la entrega de un proyecto externo o la finalización de uno interno deben estar estipulados desde la primera fase o. serán difíciles de exigir. como el resto de requisitos. deben estar igualmente contemplados. sobre los que no se tenga control en su funcionalidad y vulnerabilidades. en caso contrario. es importante repetir todas las pruebas anteriores. pero antes de comenzar a prestar servicio.4.SIN CLASIFICAR
Pruebas de unidad: comprobación de que cada elemento independiente cumple los requisitos de seguridad acordados. Es importante que junto con el sistema se documenten una serie de procedimientos operativos que garanticen que la seguridad podrá ser mantenida durante toda la vida del sistema: • • • • • • • Vigilancia de los registros del sistema Rutinas de mantenimiento Administración y monitorización de los cortafuegos Despliegue y garantía de los antivirus Planes de respuesta y continuidad Procedimientos de control de cambios Pruebas de fallo
. Pruebas en desarrollo: en el caso de proyectos externos o compra de sistemas completos. garantizando que cualquier fallo en su funcionamiento va a tener un impacto mínimo en el resto del sistema.
puede que no sea suficiente para un análisis profundo en etapas posteriores. sean en serie. entre otras: • • • • • • Proveedores y fabricantes Desarrolladores e implantadores Empresas de soporte Acuerdos de servicio Subcontratistas Consumidores / receptores de servicio
88. en la operación.1. Cualquier nueva información debe ser añadida al inventario para mantenerlo actualizado. Este aspecto se trata en el apartado siguiente. será difícil de mantener. considerando las siguientes cuestiones:
Centro Criptológico Nacional 22
. al menos: • • • Empresas externas que tienen relación con los sistemas SCADA.4. Si se registra muy poca información.SIN CLASIFICAR
• • • • • • • 5. Y su acción no debe comprometer la seguridad del sistema. 5. El inventario de terceros se elabora a partir del inventario de sistemas SCADA (descrito en 119).. Estas empresas pueden participar en la implementación. por módem. Entre las empresas externas con las que se colabora se pueden encontrar.
Procesos de parcheado (actualizaciones de seguridad) Aislamiento del sistema Procedimientos de pérdida de visión Garantía continuada (véase la guía "CCN-STIC-480B Comprender el riesgo del negocio" [Ref.4. VPN o a través de otras redes o Internet. especialmente cuando dichos recursos pertenezcan a empresas subcontratadas.1. Si se registra demasiada. Ha de considerarse muy detalladamente la gestión de los recursos humanos implicados en los proyectos realizados. En el ciclo de vida de todo sistema de cierta complejidad es inevitable que intervengan empresas externas. EMPRESAS EXTERNAS
86.5. Conexiones que dichas empresas realizan a los sistemas SCADA. en el soporte o en otros aspectos. Empleados de la empresa externa acreditados para formar parte de la relación. El inventario de terceros debe contener. 89. Se recomienda elaborar un inventario de terceros que contenga información sobre todas las empresas externas.12]) Confirmación de todo el software en los discos duros y el firmware Documentación actualizada del sistema Resultados de las pruebas de aceptación en fábrica y de puesta en servicio OTROS ASPECTOS
90. 87.
Empresas de soporte Cadena logística (suministro) PROVEEDORES Compartición de información sobre los sistemas. Acuerdos de nivel de servicio adecuados: Asegurarse de que los niveles de servicio están claramente definidos en el contrato y son adecuados a las necesidades de la organización. o Divulgación de vulnerabilidades: Es importante que los descubrimientos actuales y futuros de vulnerabilidades sean comunicados por el proveedor al dueño del sistema para que puedan adoptarse las medidas oportunas. • Acreditación de proveedores: Introducir los requisitos de seguridad en el control de proceso en la selección y acreditación del proveedor es una herramienta muy poderosa para garantizar que la cultura y el enfoque de seguridad deseados forman
93. es importante incluir cláusulas que ayuden a mantener la seguridad y a gestionar el riesgo.
92. especialmente sobre los sistemas SCADA.SIN CLASIFICAR
¿Quién es el proveedor del sistema? ¿Quién proporciona soporte? ¿Cómo es el soporte proporcionado? ¿Qué nivel de acuerdos de servicio existe? ¿Qué subcontratistas están involucrados?
91. Gran parte de esta tarea es llevada a cabo por los departamentos legales o de adquisiciones. Derecho a auditar: Incluir cláusulas que garanticen el derecho a auditar o revisar los servicios sistemas y locales de terceros.1.5. pero es importante garantizar que los contratos incluyen los siguientes compromisos: • Acuerdo de no divulgación: La empresa externa puede tener acceso a información sensible sobre la organización y sus sistemas. Controles de antecedentes/controles de seguridad interna: La organización debe pedir garantías a los proveedores de que sus empleados que trabajan en áreas sensibles se han sometido a los pertinentes controles de seguridad (habilitaciones o garantías personales de seguridad) antes de ser empleados o contratados. algunos tipos de colaboradores tienen consideraciones específicas que se listan a continuación: • • • 5. • Proveedores. y es esencial que ésta no se explote ni utilice sin el permiso de la organización propietaria de la información.1. Deben incluirse al menos las siguientes cláusulas específicas de seguridad en SCADA:
. Pero además. incluyendo: o Especificaciones técnicas de los sistemas provistos: Las organizaciones deben incitar a los proveedores a detallar los puertos y protocolos utilizan. A la hora de acordar una relación con una empresa externa. Esto es especialmente importante en el caso de proveedores y subcontratistas.
Dado que la organización tendrá requisitos relativamente específicos. Revisiones de seguridad: Deben realizarse revisiones regulares de seguridad con el proveedor para tratar cuestiones de seguridad extraordinarias. Control del personal: El personal de soporte de terceros debe tener un nivel apropiado de concienciación en seguridad. • Pruebas de seguridad / certificación de seguridad: Las organizaciones deben incitar a los proveedores para que lleven a cabo pruebas de seguridad – certificaciones de seguridad (contra el estandar Common Criteria) de sus productos para identificar y eliminar vulnerabilidades de seguridad.1. y para discutir el cumplimiento de la política de seguridad. Las organizaciones deben obtener garantías de los proveedores y vendedores de que los dispositivos de control de bajo nivel han sido debidamente analizados para identificar qué puertos y servicios se usan y si existen vulnerabilidades conocidas. Las organizaciones deben exigir a los proveedores que lleven a cabo pruebas o certificaciones de seguridad sobre los sistemas de control y sus componentes (tales como PLC) para garantizar que están libres de vulnerabilidades de seguridad. es un incentivo para estar en la lista de proveedores acreditados. ya que puede ser una buena fuente de negocio. La lista resultante de proveedores puede ahorrar tiempo y dinero a la organización reduciendo la duplicidad y previendo garantías de los posibles proveedores. Asistencia en la securización del sistema: La mayoría de los sistemas y equipos de control de procesos vienen de fábrica bastante desprotegidos (configurados por defecto). Deben incluirse al menos las siguientes cláusulas específicas de seguridad en SCADA: • Cláusula de aceptación de cambios: cualquier nueva tecnología introducida en un sistema SCADA debe estar autorizada. Requisitos de seguridad para nuevos proyectos: Cuando se planean proyectos de nuevos procesos o nuevos sistemas es esencial que la seguridad se incluya desde el principio en las discusiones contractuales. especialmente si participan nuevos proveedores.2. Se debe pedir a los proveedores que proporcionen toda la información sobre la securización de los sistemas en un documento específico. y solo deben utilizarse con la autorización previa de la organización y tras acreditarse el servicio por el procedimiento aprobado. los planes de mejora. Acuerdos de nivel de servicio adecuados: Asegurarse de que los niveles de servicio están claramente definidos en el contrato y son adecuados a las necesidades de la organización. Desde la perspectiva de los proveedores.SIN CLASIFICAR
parte de las decisiones tomadas. lo que significa que pueden ser usadas todas sus funcionalidades.
94. en cuyo caso son también proveedores y deben incluir las cláusulas específicas.5. La adición de dispositivos como módems o routers para permitir el soporte remoto o fuera de horario es un riesgo potencial. EMPRESAS DE SOPORTE
5. Algunas empresas de soporte prestan éste después de proveer un sistema. No todo el mundo necesita ser un experto
. 95. es importante que las funcionalidades no usadas estén desactivadas para evitar riesgos innecesarios.
Cualquier información confidencial de los clientes que se guarde en dependencias remotas debe estar debidamente protegida. tanto física como electrónicamente. CADENA DE SUMINISTRO Cláusula de responsabilidad: Allí donde los sistemas o conexiones superan los límites de la organización. y una investigación más o menos exhaustiva. de procedimiento y operacional en seguridad adecuada para llevar a cabo su función con seguridad. •
96.5. Además los empleados que trabajan en este soporte se han sometido a los pertinentes controles de seguridad (habilitaciones o garantías personales de seguridad) y esta debidamente formado. Los sistemas desde los que se conectan los proveedores también deben ser seguros. Deben incluirse al menos las siguientes cláusulas específicas de seguridad en SCADA:
5. Esto se puede lograr por medio de controles iniciales y periódicos de seguridad. se habla de toda persona. Esta concienciación debe estar adaptada a la empresa para la que se hace el soporte.SIN CLASIFICAR
en seguridad. También es necesario implementar los procedimientos necesarios para garantizar que los nuevos usuarios de cualquier entorno reciben las cuentas correspondientes. 98.1.3. los
. De poco sirve tener un sistema seguro si los encargados de mantenerlo no están preparados o predispuestos para la tarea. es necesario asegurarse de que se trata de una persona en el que se puede confiar. Es recomendable una investigación de antecedentes en el caso de personal para entornos críticos. RECURSOS HUMANOS 97. • Garantía de soporte remoto: La conexión remota debe ser segura y existe un procedimiento que fija cuando se realiza. La mayor parte de los incidentes de seguridad se producen por causa del factor humano. Cuando se habla de recursos humanos.
5. se deben acordar convenios claros de responsabilidad en seguridad del proveedor.1. Antes de contratar a un empleado que por su trabajo vaya a tener acceso operativo o administrativo al entorno SCADA. 100. Las organizaciones se deben asegurar del cumplimiento de estos requisitos a través de las visitas o auditorias pertinentes. que tenga relación con los sistemas SCADA. contratada o no por la empresa. Contratación Formación Relaciones interdepartamentales Baja CONTRATACIÓN
99. Deben cuidarse los siguientes aspectos: • • • • 5.2. pero todos deben tener la concienciación técnica.2. Estos procesos estan definidos en las habilitaciones / garantías personales de seguridad.
normas e instrucciones técnicas vigentes. 5. Elevar el perfil de la seguridad en el control de procesos Facilitar la concienciación mediante mensajes utilizando la jerarquía de gestión y los canales de comunicación de ésta Garantizar un presupuesto adecuado para el programa de concienciación Entender que algún riesgo residual seguirá existiendo Eliminación las barreras internas entre recursos. tal vez mediante el uso de una breve encuesta o sondeo. La formación no debe centrarse en los puestos técnicos sino abarcar todos los puestos que tengan alguna relación con SCADA en todos los escalafones de la jerarquía. Este conocimiento debe ser utilizado como base para los temas de concienciación. Procedimientos establecidos. La formación debe adaptarse a las necesidades de cada público objetivo. PLAN DE FORMACIÓN
104. 105.2.2. pero no debe centrarse sólo en ese punto. Un paso evidente pero a menudo pasado por alto es evaluar lo que ya se sabe.2. • • • • OBJETIVO DE LA FORMACIÓN Concienciación general en la seguridad SCADA Establecer un lenguaje compartido que permita una comunicación fluida Comprender los distintos entornos operativos Transferir entre áreas los conocimientos necesarios para que todo el personal aplique y cumpla con medidas adecuadas de seguridad.
102..2.2. La formación del personal implicado en la producción o en los sistemas SCADA es importante porque permite aumentar su capacidad de respuesta ante incidentes. Los siguientes elementos deberían ser comprendidos a todos los niveles: • • • Políticas.15]):
103. 5. FORMACIÓN
101. La formación debe perseguir los siguientes objetivos ([Ref.2.SIN CLASIFICAR
niveles de autorización y capacitación necesarias en materia de seguridad cuando se unan a un equipo SCADA. Actualizaciones de los documentos existentes ○ Políticas y normas ○ Orientación de proveedores
. Algunos de los principales beneficios de la participación de los altos directivos son: • • • • • 5.2.1.
108. Ejemplos de fallos de seguridad SCADA y sus efectos.2. ○ Formación de seguridad específica para los sistemas de un proveedor 5. • Para profesionales de TI: ○ Explicación y comprensión del ámbito SCADA.2.
106. el beneficio empresarial) ○ Los requisitos para un programa de seguridad. incluyendo el perfil de riesgo mejorado tras los incidentes (ej. De los cursos de seguridad TI disponibles. deben cubrirse al menos los siguientes aspectos específicos para cada uno de los grupos siguientes: • Para órganos directivos: ○ Una visión general del perfil de riesgo de la empresa (incluyendo el impacto de las amenazas potenciales. Talleres: específicos o multidisciplinares. Sin embargo. Qué debe vigilar cada uno y cómo debe responder. encontrar cuál proporcionará un nivel adecuado de comprensión puede ser proceso difícil y largo. Boletines de seguridad: en papel o por correo electrónico. Los métodos de formación más comunes son: • • • • • • Cursos externos: realizados por proveedores o por profesionales de la seguridad. es poco probable que se oferte todo lo que se necesita y es probable que sea necesaria una mezcla de métodos de entrega. Además. lo que supone un valor añadido para la organización.3. las principales actividades..SIN CLASIFICAR
Respuesta a incidentes: responsabilidades de cada actor. ○ Los beneficios de mejorar la seguridad del control de sistemas. Cursos internos: se ocupan de temas específicos de organización y puede poner en contexto los conocimientos adquiridos externamente Conferencias: presenciales o remotas. • Para profesionales SCADA: ○ Explicación y comprensión de seguridad en TI. recursos y costes ○ El Retorno de la Inversión en Seguridad (RIS). de los incidentes y las vulnerabilidades). ○ Conocimiento de la arquitectura y conexiones entre equipos.
. Pueden incluir certificaciones. MÉTODOS DE FORMACIÓN
107. Repositorio centralizado de conocimientos sobre la seguridad en SCADA. El análisis de las necesidades de formación es de gran ayuda en este ámbito y seleccionar cursos organizados por organizaciones profesionales reconocidas garantizará que se cumplan las necesidades de formación. permitiendo estos últimos que se apliquen una amplia gama de experiencias y conocimientos a un problema. ○ Conocimiento de la arquitectura y conexiones entre equipos.
Campañas con carteles. A pesar de una planificación cuidadosa. industriales.
Sitios Web y emisiones por Internet (webcast): dependen de la motivación de los individuos. 112. La colaboración entre los grupos de SCADA y de TI comienzan en el grupo de control de la seguridad SCADA.3. Deben modificarse a raíz de cualquier cambio en la amenaza.4. Dicha colaboración ha de forjarse desde el respeto y la comprensión de los intereses mutuos y potenciarse desde la escala administrativa.
. Tener una representación de SCADA en el equipo de seguridad de TI de la organización. Algunos mecanismos para potenciar dicha colaboración son ([Ref. etc.SIN CLASIFICAR
• • • • • 5. donde otros departamentos de la empresa están también representados y debe comenzar a forjarse el compromiso entre ambos. Los sistemas SCADA suelen ser punto de confluencia de diferentes áreas de conocimiento. Inclusión de temas de seguridad en las agendas de las reuniones. Las lecciones aprendidas durante un ejercicio o después de que se produzca un incidente también deben incorporarse en los planes. 113. es frecuente descubrir que los planes y el personal se comportan de forma diferente en situaciones de la vida real.15]): • • • • • • • • Representación TI en el Equipo de Respuesta de Seguridad SCADA (ERS) o empleo de un único equipo multidisciplinar. RELACIONES INTERDEPARTAMENTALES
111.2. 110.2.2. pero pueden ser útiles como parte de almacenes de conocimientos. PLANES DE RESPUESTA
109. Videos y DVD. Establecer un sistema de tutoría. en los requisitos de protección. Equipos de proyecto combinados. Todo el personal debe prepararse para la ejecución de planes que deben probarse periódicamente para garantizar que se llevan a cabo como fueron diseñados. Trabajo compartido: Formación cruzada del personal de TI y de SCADA. en el propio sistema o en la estructura organizativa. La operatividad de los sistemas controlados (energéticos.) suele ser muy diferente a la de los sistemas que se utilizan para el control (TI). Reuniones periódicas para discutir los desarrollos y el progreso de la seguridad. Ampliar las listas de distribución e incluir los correspondientes contactos de TI.. cubriendo cada uno los trabajos de los otros. Llamadas telefónicas. Los planes deben ser revisados al menos anualmente y con mayor frecuencia para sistemas críticos o de alto riesgo. Invitar a representantes de TI a las reuniones de control de cambios en SCADA. 5.
Implementar los procedimientos para garantizar que la información y la documentación confidencial son recuperadas. Acceso a una base más amplia de capaciddes técnicas en control de procesos.2. Esto puede producirse por: • • • Cambio de roles y responsabilidades Baja de personal Finalización de relaciones con externos (proveedores. Una oportunidad para compartir las mejores prácticas de cada departamento. pero especialmente importantes en la seguridad SCADA: • • • • • • • • Aumento de la transferencia de conocimientos. contratistas. se desactivan las cuentas y se cambian las contraseñas cuando ya no sea necesario un acceso al entorno SCADA. Es necesario que existan los procedimientos necesarios que garanticen la comunicación fluida entre distintos departamentos para que se tenga conocimiento inmediato cada vez que se produce una baja y se puedan activar los mecanismos correspondientes.)
117. Acceso a una base más amplia de capacidades técnicas en seguridad. a SCADA. Los grupos de TI pueden proporcionar y facilitar varios servicios a otros departamentos de la organización y.
. por supuesto. Las ventajas de un aumento de las relaciones interdepartamentales son muchas en cualquier ámbito. Herramientas antivirus Administración y monitorización de cortafuegos y otros dispositivos de defensa perimetral Monitorización de los sistemas y las redes Gestión de acceso remoto a los sistemas Respuesta a incidentes y alertas Formación y concienciación en seguridad Gestión continua del aseguramiento BAJA
116. ya sea directamente (con ajustes mínimos) o modificando la configuración del entorno de control de procesos.4. etc. Mejor comprensión de las medidas de seguridad aplicadas.SIN CLASIFICAR
114. Soluciones de seguridad a menor coste por ser compartidas Prácticas de trabajo más eficaces Mayor velocidad en la ejecución de proyectos
115. Ejemplos de servicios / mecanismos que pueden ser proporcionados por TI son: • • • • • • • 5. Desarrollando de una estrecha relación pueden identificarse soluciones de TI que se puedan utilizar en el entorno SCADA.
documentar y tener bajo control de cambios todos los aspectos de los sistemas para garantizar su seguridad.SIN CLASIFICAR
5. 119. SISTEMAS 118. pero esa seguridad desaparece rápidamente al no haber medidas que permitan mantenerla. lo que se puede hacer respondiendo a las siguientes preguntas: • • Segregación: ¿Están adecuadamente separadas las redes SCADA de las redes de administración y de otras redes externas (Internet). hardware y software.3. En este documento. Como la seguridad debe ser una preocupación constante. por los medios apropiados? Monitorización y detección: ¿Está el cortafuegos y los dispositivos de protección de perímetro de SCADA registrados y revisados? ¿Se monitoriza la actividad de los usuarios/sistemas? ¿Se monitorizan los logs de los antivirus y de otros dispositivos del sistema. anualmente) Copias de seguridad: procedimientos de copia de seguridad y restauración. El inventario es un bloque fundamental para construir el marco de seguridad En el caso de SCADA es importante capturar. GESTIÓN DE ACTIVOS
121.? Parcheado – actualizaciones de seguridad: ¿Con qué velocidad se aplican los parches? ¿De dónde se reciben? ¿Están parchadas todas las máquinas? Protección antivirus: ¿Con qué velocidad se realizan las actualizaciones? ¿Cuáles son el método y la frecuencia de escaneado? Planes de respuesta: ¿Se revisan y actualizan los manuales regularmente? (ej. 5. debe dedicarse la atención necesaria a los aspectos relacionados con la gestión de la empresa y los recursos humanos que se han tratado en los apartados anteriores. los sistemas se tratan en último lugar porque la experiencia ha demostrado que enfocar los esfuerzos en ellos obtiene un pico de seguridad puntual en el momento del esfuerzo. sistemas y activos que existen. siempre que se cumplan una serie de requisitos formales en SCADA que garanticen una coherencia y un endurecimiento de dichas medidas. etc.1. En general. Es importante garantizar una serie de aspectos básicos relacionados con los sistemas SCADA. Toda gestión de activos debe comenzar con un inventario detallado y actualizado de éstos. El inventario de sistemas SCADA debe incluir localizaciones. centros. La mayoría de los análisis de seguridad en entornos tecnológicos empiezan por recomendar acciones relacionadas con los sistemas. 122.
120. cualquier medida técnica de seguridad que se pueda aplicar en TI puede ser utilizada en SCADA y viceversa.3. especificando de cada uno: • • • situación geográfica papel importancia en la cadena de producción
. identificar el alcance de los sistemas y la identidad de todas las interfaces. su configuración y sus tecnologías.
Deben estar protegidas física y lógicamente los siguientes elementos: • •
. estos inventarios deben protegerse. Equipos de control y SCADA Instalaciones de suministro a dichos equipos (eléctrico o de otro tipo)
127. El acceso a estos inventarios debe limitarse al mínimo número de personas que necesiten acceder a esta información. que no esté disponible para las personas con acceso autorizado. dependencias) y lógico (inicio de sesión informática) debe cumplir al menos los siguientes requisitos: • • • • Acceso personalizado. organizaciones de apoyo (TI. En sistemas sensibles es obligatorio que todo producto y sistema tenga soporte. Si el acceso electrónico no autorizado es un riesgo. SCADA. ya sea por medios automáticos o modificando los procedimientos adecuados para garantizar que queden registrados todos los cambios que se realicen en los activos. El acceso a los sistemas SCADA y a la información que genera debe estar reducido al mínimo. 124.SIN CLASIFICAR
puntos críticos de seguridad pertenencia o no al Catálogo de Infraestructuras Críticas Nacionales responsable único designado gestor proveedor/es de soporte (interno o externo). etc. Vigilancia/monitorización (cámaras de video. Registro automático de de accesos autorizados.) de las actividades realizadas en las dependencias más sensibles. Es importante realizar una auditoria y una evaluación formal del inventario de los sistemas SCADA. que puede ser muy útil para un atacante. Los inventarios son una fuente de información sensible.) interacciones y dependencias. haciendo especial hincapié en los accesos remotos proyectos en curso problemas conocidos condiciones de trabajo especiales o implicaciones legales.
123. En consecuencia. Sólo deben tener acceso aquellas personas con la autorización de seguridad adecuada. El control del acceso físico (salas. registro. edificios. colaboradores remotos o locales. 126. Acceso autorizado y supervisado de personal de terceros que deban acceder por requerimientos técnicos.3. Se puede consultar al CCN acerca de unas directrices básicas. Los inventarios son muy difíciles de generar y mantener actualizados. el acceso físico no autorizado debe ser algo totalmente impensable. Existen muchas guías acerca del control físico.2. SEGURIDAD FÍSICA
125. Además debe mantenerse actualizado. 5. etc.
el uso de tecnologías TI. una SCADA y otra de trabajo. hay intentar utilizar servicios y soluciones ya disponibles. El control de las conexiones con otros sistemas ha de estar controlado y monitorizado. Este escenario no es siempre posible por. etc. En caso de que se necesiten para el normal funcionamiento de la empresa. Algunos servicios no deberían estar disponibles nunca desde los sistemas SCADA. 130. navegación Web y redes inalámbricas.3. es necesario recordar los aspectos desarrollados en el apartado “5.
132. A la hora de seleccionar al personal con acceso autorizado. corren el riesgo de ser comprometidos o infectados. usando cortafuegos y herramientas de monitorización de tráfico. Siempre que sea posible. no obstante se recomienda hacer uso de los siguientes elementos: • • • Cortafuegos y otros dispositivos de protección de perímetro Servidores de autenticación con comunicaciones cifradas Zona desmilitarizada o el sistema de protección de perímetro que se determine del análisis de riesgos de la interconexión de diferentes redes donde estén situados aquellos servicios que sirvan de enlace. SEGURIDAD PERIMETRAL
129.9]). evitando el acceso directo a los servidores SCADA. análisis. guías. entre otros motivos. La selección de las medidas de seguridad debería basarse en el análisis de riesgo correspondiente.1. 131. el sistema esta aislado. la monitorización centralizada de dependencias separadas geográficamente. es recomendable la coexistencia de dos redes separadas.
128. Al estar conectados a otros sistemas. Contratación”.. Algunos de estos servicios pueden ser proporcionados por el grupo de TI: • • • Administración y monitorización de cortafuegos y de otros dispositivos de protección de perímetro Monitorización de los sistemas y las redes Supervisión del acceso remoto
. 5. como correo electrónico.3. Sistemas de detección de intrusiones (IDS). el uso generalizado de Internet y la necesidad de soporte remoto de terceros. como la verificación de los antecedentes en el caso de acceso a entornos sensibles.2. En la herramienta PILAR existe un conjunto completo de salvaguardas.SIN CLASIFICAR
Almacenamiento de datos obtenidos por SCADA Documentación relacionada con SCADA: Informes. ([Ref. como las proporcionadas por el departamento TI. Las soluciones pueden necesitar ser adaptadas al entorno operativo de los sistemas de control. resultados de auditorías. Aplicar a estos sistemas medidas de protección como cortafuegos u otros dispositivos de protección de perímetro es un elemento importante de defensa. 133. El escenario ideal en un entorno SCADA es aquel en el que no existe ninguna conexión con ningún otro sistema. es decir. No tiene sentido invertir en una medida de seguridad fuerte y costosa para un riesgo o impacto mínimo cuando la inversión podría ser mejor aprovechada en otros lugares.
.3. La norma específica la comunicación de datos en tiempo real entre dispositivos de diferentes fabricantes. Se puede encontrar más información sobre este tema en el documento “CCN-STIC-416 Seguridad en VPN” ([Ref. es decir disponer de varios mecanismos de seguridad.3. SECURIZACIÓN
5.1.. En estos casos han de garantizarse una serie de medidas mínimas de seguridad. entre las que se encuentran: • • Acceso controlado y seguro a través de VPN. monitorización o centralización. Administración y monitorización de los servidores y de los equipos de administración. aunque poco deseables. Los accesos remotos desde sistemas ajenos a la organización.3]) y “CCN-STIC-432 Seguridad perimetral-IDS” ([Ref.8]). Empresas Externas”.5. Siempre que sea posible. 138. considerar la subcontrata a terceros.
140. Administración y monitorización de las redes y las comunicaciones. 136. ACCESOS REMOTOS
139. Depender sólo de una capa de defensa fuerte no se considera una buena práctica para la protección de los sistemas de control de procesos y se recomienda un modelo multicapa de “defensa en profundidad”. Controlar el acceso de la subcontrata. 33
..5]). 5. 137. Ejemplos de los posibles servicios externos son: • • • • Administración y monitorización de los cortafuegos y de otros dispositivos. Securización y control de los sistemas remotos desde los que se accede.
La definición de Wikipedia de OPC-OLE (Object-Linking and Embedding) para el control de procesos.4. Además de controlar los accesos físicos y electrónicos a los sistemas.3. que puedan realizar las tareas requeridas teniendo el mínimo acceso a la información y los procesos SCADA. Se puede encontrar más información en el apartado “5.1. Administración y monitorización de las infraestructuras.
135.. Cuando los servicios antes mencionados no estén disponibles en la empresa. ha de garantizarse que éstos han sido desplegados de un modo seguro y tienen el menor número de vulnerabilidades posible. Se puede encontrar más ayuda en las guías “CCN-STIC-408 Seguridad perimetralcortafuegos” ([Ref.SIN CLASIFICAR
Respuesta a incidentes y alertas Eliminación de conexiones no utilizadas
134. Usar protocolos que no sean firewall-friendly (por ejemplo OPC1) implica que las regla de los cortafuegos no pueden ser configuradas en detalle. pueden ser necesarios por motivos de soporte.5]). utilizar protocolos de comunicación firewall-friendly. Además existen requisitos para estos accesos en el documento “CCN-STIC-302 Interconexión entre sistemas” ([Ref.
altas y bajas. al tratarse de entornos sensibles. hay intentar utilizar servicios y soluciones de seguridad ya disponibles. Estas reticencias se pueden solucionar con una serie de sencillas precauciones: • Política de parcheado. es muy posible que no se actualicen. Un sistema que no está totalmente actualizado.SIN CLASIFICAR
141. existe el riesgo de que el parche pueda causar un funcionamiento incorrecto de un sistema. • • • • • • • • • Eliminación de todo software y servicio que no sea necesario. Si una organización no se plantea de manera consciente que debe actualizar sus sistemas. Las pautas a seguir deben reflejarse en documentos de seguridad que formarán parte de los procedimientos utilizados por el personal implicado en SCADA. es un sistema vulnerable. Monitorización del acceso remoto Respuesta a incidentes y alertas Gestión continua de la seguridad Copias de seguridad y restauración Parches o actualizaciones de seguridad
142. Las soluciones pueden necesitar ser adaptadas al entorno operativo de los sistemas de control. Siempre que sea posible. por lo que corren el riesgo de ser comprometidos o infectados.1. Una política de parcheado y actualización de los sistemas aprobada por la dirección debe contemplar: ○ Horarios: En SCADA puede haber sistemas 24x7 sin soporte. Suele ser frecuente que los proveedores desarrollen parches para resolver vulnerabilidades conocidas. pueden aparecer reticencias a realizar el parcheado por temor a lo que pueda ocurrir ([Ref. como las proporcionadas por el departamento TI. Por otro lado. compatibilidad y reinicios no programados. 144.4.26]). aumentando la seguridad. o se actualicen sólo las cosas que sean automáticas. La aplicación de parches no está libre de riesgos. que no mantiene sus antivirus al día y sus aplicaciones no están exentas de fallos conocidos. La mayoría de los sistemas de control actuales se basan en las tecnologías TI estándar. PARCHEADOS
145. Mejora de la configuración de los sistemas existentes Antivirus y otras herramientas de detección de código dañino Controles de acceso: cuentas y contraseñas.3. las actualizaciones automáticas si no se controlan pueden dar lugar a problemas de funcionamiento. 146. 5. E incluso en este último caso. Empleo de mecanismos de autenticación fuerte. En todo momento debe actualizarse el Inventario de los Sistemas SCADA para reflejar el estado de los sistemas. y también para ellos debe existir una política de parches. hay que considerar al menos la siguiente lista de comprobación para verificar su completitud. 143. Una vez se ha identificado una arquitectura de seguridad objetivo. Esto facilitará su despliegue y su mantenimiento.
¿quién esta al tanto de que no aparezca una nueva vulnerabilidad en la BBDD Oracle o PostreSQL? ¿O en el plugin de foros instalado en el portal? Es importante concertar alertas automáticas de los proveedores. y que estas alertas no sea sólo recibidas y almacenadas. Siempre que sea posible. deben intentar definirse sistemas son menos críticos en un entorno similar. o existencia de entornos de preproducción. ○ Pruebas previas ○ Procedimiento habitual. De nuevo. Y no sólo de los proveedores de los sistemas a parchear sino de los de todos los sistemas que puedan sufrir efectos colaterales: sistemas que comparten información. sino incorporadas en la monitorización. Algunas posibles soluciones son: ○ Reemplazarlos o actualizarlos ○ Aislarlos físicamente ○ Reducir sus vulnerabilidades mediante protecciones adicionales (ej.SIN CLASIFICAR
○ Personal. En estos casos. Soporte de proveedores. esta actualización debe realizarse automáticamente y a partir de los datos de monitorización. Cuando sea posible. También se puede suscribir a boletines de vulnerabilidades como los del CCN-CERT. ○ Ventana de prueba: tiempo durante el que se mantienen los mecanismos necesarios para ejecutar la regresión. ○ Procedimiento de emergencia. aplicaciones instaladas en la misma máquina.autorizado a la instalación ○ Herramientas a utilizar. los sistemas deben estar diseñados para facilitar el parcheo.
147. MONITORIZACIÓN
148. ○ Procedimiento de regresión en el caso de un fallo derivado de un parcheo. • Alerta por parches. Los actualizadores automáticos. detrás un cortafuegos configurado adecuadamente) ○ Protegerlos con sistemas de prevención de intrusos 5. por ejemplo servidores en cluster para garantizar la alta disponibilidad. como los de Microsoft. es necesario mantener el inventario de los sistemas y su estado actualizado. sino que debe recoger información de cualquier fuente interna y externa donde se pueda
. Inventario de sistemas actualizado. En caso de no existir (lo que debería ser obligatorio en entornos sensibles como SCADA). pero no cubren todo el software.5. ○ Orden de parcheado.3. es necesario intentar que cualquier vulnerabilidad que contengan tenga el menor impacto posible. La monitorización no debe limitarse al estado de los sistemas y las comunicaciones.. En el caso de sistemas que no puedan ser parcheados. cada vez están mas implantados. Entornos de alta disponibilidad y de preproducción. etc.
Hay un número de fuentes típicas internas y externas que son por lo general importantes para la mayoría de organizaciones. La monitorización debe adaptarse a las amenazas aplicables a los sistemas relevantes.
Notificación de alertas e incidentes
Monitorizar Analizar Responder
Alerta Incidente
Algo debe hacerse Gestión coordinada del incidente
Información de los sistemas de monitorización. lo que requerirá un gran esfuerzo de recursos. Eventos
Grupos de control de procesos
Figura 4: Esquema de respuesta de seguridad en el control de procesos
149. malware y notificaciones de vulnerabilidades. y recoger los datos suficientes para que las alertas o incidentes importantes no sean ignorados.SIN CLASIFICAR
dar cualquier evento relevante como alertas de seguridad. Se necesita un equilibrio entre intentar procesar toda la información disponible. Esto se puede hacer cruzando las alertas de seguridad con el inventario de sistemas de control de procesos. Algunos ejemplos son: • Fuentes internas: ○ Sistemas de monitorización de cortafuegos y otros dispositivos de protección de perímetro ○ Sistemas de detección de intrusos ○ Sistemas de monitorización de la red y los sistemas ○ Informes de código dañino activo (virus y malware) ○ Informes de fallos de sistema ○ Informes del servicio de atención al usuario ○ Informes de vulnerabilidades para las tecnologías en uso
Centro Criptológico Nacional 36
3. sistemas y activos críticos. 5. y los detalles de contacto 24x7. estableciendo la prioridad de cada tipo de riesgo. Procedimientos predefinidos a los posibles escenarios previamente identificados (ver sección 3. Actualmente proporciona: i.. 153.6. por ejemplo CCN-CERT.30]) ○ US-CERT ([Ref. sus suplentes. Centros. Es necesario que todas estas fuentes sean procesadas e incorporadas en el plan de alerta temprana que desencadene los correspondientes procedimientos de recuperación.1]) ○ Fabricantes de hardware ○ Proveedores de software de control de sistemas y aplicaciones ○ Proveedores de sistemas operativos ○ Empresas de antivirus ○ Organizaciones externas de monitorización de seguridad (ej. Informes de código dañino activo (virus y malware) ii.. PROCEDIMIENTOS DE RECUPERACIÓN
152.4.6) ○ Una definición clara de cómo identificar cada escenario ○ Un plan de acción claro en el caso de identificar un escenario
Centro Criptológico Nacional 37
.. funciones y responsabilidades. Informes de vulnerabilidades específicas para SCADA ○ Equipos de Seguridad y Atención a Incidentes (CSIRT) ([Ref.31]) ○ Intercambios de información con el CCN-CERT ([Ref. Deben cubrir todos los casos conocidos. Disponibilidad de copias de seguridad y procedimientos de restauración. Los planes de respuesta de seguridad en el control de procesos son a menudo bastante amplios. Como mínimo deben incluir: • • • • • • Procedimientos de cómo informar sobre los incidentes Proceso para invocar el plan de respuesta Detalles del personal del equipo de respuesta. monitorización subcontratada de cortafuegos e IDS) ○ Medios de comunicación técnicos ○ Grupos de noticias ○ Foros de seguridad ○ Agencias policiales
151.SIN CLASIFICAR
Fuentes externas: ○ Informes de equipos de respuesta ante incidentes.
proveedores. habrá pocas posibilidades de que el criminal pueda ser perseguido y llevado ante la justicia. el riesgo conocido aumenta pues.6. Se puede contactar con el Servicio de Atención al Usuario del CCN-CERT a través de su página web ([Ref. por ejemplo anónima) con en CNPIC y el CCN. lo que generalmente implica reconstruirlo o restaurarlo desde copias de seguridad. Cualquier organización que ha experimentado incidentes de seguridad en el control de proceso debería compartir esa información (de manera adecuada. la decisión clave es si mantener cualquier pista (y posiblemente retrasar la restauración de las operaciones) o restablecer las operaciones al coste de no poder perseguir a los criminales. aun resolviendo la vulnerabilidad. se pueden restablecer las operaciones mientras las máquinas afectadas son puestas en cuarentena para su posterior análisis. Por desgracia. Toda información será tratada como clasificada. Cuando un sistema se ha visto comprometido (ej. existe una amenaza conocida que no ha sido neutralizada.
154. 156. y en caso necesario. Listas de herramientas de apoyo disponibles Prioridades de análisis forense..
Centro Criptológico Nacional 38
. 157. Un plan de comunicación claro ○ Cómo comunicar ○ Qué comunicar ○ A quién comunicar ○ Cuándo comunicar y con qué frecuencia
Los criterios que deben cumplirse para cerrar los incidentes. Información de contacto (incluyendo organismos tanto internos como externos. esto generalmente implica que cualquier pista o rastro auditable dejado por el atacante será destruido y. para lo que se puede utilizar la clave pública del certificado disponible en dicha página Web en la sección “Contacto”. convenientemente sanitizada para borrar los datos que pudieran identificar a individuos u organizaciones. Si teniendo los medios se decide no realizar ningún análisis por seguridad. etc).SIN CLASIFICAR
Un procedimiento de escalado y los requisitos de autorización necesarios para éste.3. por tanto. cuerpos policiales. Compartir la información de incidentes puede permitir que otros organismos complementen la investigación. malware o un hacker). que se eviten incidentes similares en otras organizaciones y que se desarrolle un conocimiento mejor de los riesgos a los que enfrentan los sistemas de control.1]). a menudo se presenta la difícil decisión de restaurar el sistema o mantenerlo en cuarentena para realizar una investigación más a fondo. Se puede encontrar más información útil sobre este tema en el documento “CCN-STIC403 Gestión de incidentes de seguridad” ([Ref.1. ANÁLISIS FORENSE
155. empresas. La información sensible no debe enviarse sin cifrar.2]). para incorporarla en su asesoramiento genérico de seguridad. 5. Si hay sistemas repartidos o redundantes. En esta situación. Normalmente hay una necesidad urgente de restaurar el sistema a un estado operativo tan pronto como sea posible...
de Automata ([Ref.37]) Wonderware HMI/SCADA ([Ref.
. A la hora de seleccionar un software es recomendable comprobar las certificaciones existentes y garantizar el nivel de soporte adecuado. póngase en contacto directo con el CCN-CERT.41]) PcVue Software SCADA ([Ref.34]) Lauer ([Ref. 162.33]) ABB Group ([Ref... Consulte las guías de la serie 400 del CCN-STIC y especialmente “CCN-STIC-430 Herramientas de seguridad” ([Ref..36]) eXpert Manager.. OTRAS HERRAMIENTAS
161.44])
159... El CCN.46]).43]) Control Maestro y Wizcon Supervisor. 160. entre las que cabe destacar las siguientes: • • • • • • • • • • • • Digital Bond ([Ref. Para cualquier duda o asesoramiento...38]) CitectHMI y CitectSCADA ([Ref.42]) Jako Scada ([Ref. Algunos proveedores de hardware tienen productos específicos de SCADA (como WinMSG de Piciorgros [Ref.. Estos productos suelen tener funcionalidades específicas pero son más difíciles de integrar en una monitorización centralizada.40]) WinMachLite. Ninguna elección es garantía absoluta de seguridad.35]) Indusoft Web Studio ([Ref..SIN CLASIFICAR
6. SOFTWARE SCADA
158. como organismo de certificación.1. de Satec ([Ref.. En el mercado existen numerosas empresas y herramientas centradas en el entorno SCADA..39]) MiSCADA ([Ref.6]). puede asesorar en la decisión: 6.1... de Elutions ([Ref.
Programa europeo para la protección de infraestructuras críticas Comisión de la Unisón Europea.6] [Ref..eu/scadplus/leg/es/lvb/l33259..cni.9] [Ref.htm COM/2006/786 .4 CCN-STIC-480A Seguridad en el control de procesos y SCADA Guía de buenas prácticas CCN-STIC-480B Seguridad en el control de procesos y SCADA Guía 1: Comprender el riesgo del negocio CCN-STIC-480C Seguridad en el control de procesos y SCADA Guía 2: Implementar una arquitectura segura CCN-STIC-480D Seguridad en el control de procesos y SCADA Guía 3: Establecer capacidades de respuesta CCN-STIC-480E Seguridad en el control de procesos y SCADA Guía 4: Mejorar la concienciación y las habilidades CCN-STIC-480F Seguridad en el control de procesos y SCADA Guía 5: Gestionar el riesgo de terceros CCN-STIC-480G Seguridad en el control de procesos y SCADA Guía 6: Afrontar proyectos CCN-STIC-480H Seguridad en el control de procesos y SCADA Guía 7: Establecer una dirección permanente COM/2004/0702 .Protección de las infraestructuras críticas en la lucha contra el terrorismo Comisión de la Unisón Europea.3] [Ref.4] [Ref..1] [Ref..eu/scadplus/leg/es/lvb/l33260...19]
Portal de CCN-CERT https://www...ccn-cert..16] [Ref.5] [Ref.14] [Ref..2] [Ref.7] [Ref.13] [Ref...20]
[Ref.12] [Ref.es CCN-STIC-403 Gestión de incidentes de seguridad CCN-STIC-408 Seguridad perimetral – cortafuegos CCN-STIC-410 Análisis de riesgos en sistemas de la Administración CCN-STIC-416 Seguridad en VPN CCN-STIC-430 Herramientas de Seguridad CCN-STIC-431 Herramientas de Análisis de Vulnerabilidades CCN-STIC-432 Seguridad perimetral-IDS CCN-STIC-435 Herramientas de monitorización de tráfico CCN-STIC-470 Manual Herramienta de Análisis de Riesgos Pilar 4.15] [Ref.10] [Ref.17] [Ref. junio 2004. adoptada el 20/10/2004 http://europa..11] [Ref.. 12/12/2006 http://europa.htm Catálogo Nacional de Infraestructuras Críticas
[Ref..18] [Ref...8] [Ref.21]
[Ref...SIN CLASIFICAR
ANEXO A...
Ministerio de la Presidencia http://www.com
Centro Criptológico Nacional 41
..pdf Steven S...satec-global.es/
www. 10/01/2007 www.gov/control systems/
[Ref.wonderware.com/2009/05/una-de-espias-y-un-trabajo-interesante.es/2009/05/29/los-enemigos-de-los-parches/ Una de espías y un trabajo interesante S21Sec http://blog.abb.36] Indusoft – Tools for automation
www..ar-tools...com MAGERIT v.com
[Ref. Metodología de Análisis y Gestión de Riesgos de los Sistemas de Información Consejo Superior de Administración Electrónica.28]
[Ref.s21sec..com
[Ref.lauer-hmi.csi.digitalbond.37] Satec Powerful Solutions
www.htm Los enemigos de los parches http://www.com
[Ref. penetrated by spies Wall Street Journal http://online...31] US Cert [Ref.24] [Ref.35] Lauer
www.33] Digital Bond
www.php?op=display&id=521 Entorno de Análisis de Riesgos http://www.22] SEGURIDAD EN SISTEMAS SCADA
Sugerencias para Mejorar la Seguridad en SCADA S21Sec.csirt.26] [Ref.25]
[Ref.1.com/article/SB123914805204099085..com/?p=281 Equipos de Seguridad y Atencion a Incidentes (CSIRTs) españoles http://www.de
[Ref.34] The ABB Group
www.com/texts..us-cert.es/csi/pg5m20..48bits..30]
[Ref.s21sec.S. The SCADA Security Challenge: The Race Is On: http://www.38] Invensis Wolderware
www.html Electric Gris in U.infosecwriters.SIN CLASIFICAR
CCN-STIC-480 [Ref. Da" Demostración de un exploit sobre un sistema SCADA Blog 48 bits http://blog..wsj..23] [Ref.securityartwork.27]
[Ref.indusoft. Smith.map...29]
[Ref.32]
CCN-STIC-302 Interconexión de sistemas clasificados
A.html "Ska! Ska!.com/descargas/scada. 2..com
[Ref.. EMPRESAS DESARROLLADORAS DE SOFTWARE SCADA
..SIN CLASIFICAR
CCN-STIC-480 [Ref.41] Automata
www.44] Elutions
[Ref..com
[Ref.automataweb..com
[Ref.com
[Ref.40] Iskra Mis
www.elutions..piciorgros.43] Janus Software
www.dotvision.46] Piciorgros
www.45] Dotvision
www.47] CNPIC
http://www.42] ARC Informatique
[Ref.arcinfo..com.39] Citect Real Time Intelligence by Schneider Electric SEGURIDAD EN SISTEMAS SCADA
www.citect.es
...iskra-mis.com
[Ref.si
[Ref..cnpic-es.ejanus.ar
PLC UTR CD USB VPN
. Software o firmware que intenta llevar a cabo procesos no autorizados que pueden tener un impacto en la integridad. Para un equivalente español. Programmable Logic Controller Controlador Lógico Programable. confidencialidad o disponibilidad de un sistema informático. contactar con el CCN.1. GLOSARIO DE TÉRMINOS Y ABREVIATURAS
B. Unidad de Terminal Remota Compact Disk Universal Serial Bus Virtual Private Network. GLOSARIO DE TÉRMINOS
Amenaza Malware Evento que puede desencadenar un incidente en la Organización. GLOSARIO DE SIGLAS
CCN CPNI CSIRTUK ERSCP INC SCADA SCD TI CSIRTUK Centro Criptológico Nacional Centro para la Protección de la Infraestructura Nacional de Reino Unido Combined Security Incident Response Team – United Kingdom Equipo de Respuesta de Seguridad en Control de Procesos Infraestructura Nacional Crítica Sistema de Control Supervisor y Adquisición de Datos Sistemas de Control Distribuido Tecnología de la Información Combined Security Incident Response Team – United Kingdom Departamento dentro del CPNI que engloba el CERN gubernamental. produciendo daños materiales o pérdidas inmateriales en sus activos.SIN CLASIFICAR
ANEXO B.2.
More From This UserReporte_Operartivo Producción DEPARTAMENTO Mensual-MARZO-2013Datos de Los PozosSan Alberto SAL-16Procedimiento Seguro de Trabajo Del Soldador Al ArcoPARARRAYOLevantamiento Artificial Cedip1-RDO-24_07_2014RdoRdoMamáCL 1. ExperienciasBiocomercioSostenibleFANIntro Ducci OnTarea 1 FloresListado de TesisProyecto de GradoTarea composiciones paisesAhorar._PETROLEO_1-2013Funciones Secretaria de HcParcial Terminacion de PozosLevantamiento Artificial CedipMARCHA ANALÍTICAAPLICACIÓN DE LA MSA PARA ANIONESGlycol InjectionCullender SmithPrimera Exposicion
480 Seguridad Sistemas SCADA Mar10 by José Alberto Flores Murillo21 viewsEmbedDownloadRead on Scribd mobile: iPhone, iPad and Android.Copyright: Attribution Non-Commercial (BY-NC)List price: $0.00Download as PDF, TXT or read online from ScribdFlag for inappropriate contentMore informationShow less
RelatedISO_27001_v011by mfrayssinetISO27001by Santiago Suarez Codenasistema escadaby Anahi LeonAutómatas Programables y Sistemas de Automatización. Parte 1by SergioISO 27001 Checklistby Jhon Hegel GutierrezNorma. NTC-ISO-IEC 27001.pdfby alixtrivImplantacion Del ISO 27001 2005by Henry Mitchell Taype CruzadoUNE-ISO(IEC_27002=2009by crow25027005by nanyta_scadaby untecs2007ISO 27001by 'Edson Llanos LlacaDiseño sistema SCADAby agrovadoEvaluacion Iso 27001 Checklistby Guillermo Arturo HurtadoUNIT-ISO-IEC 27001-2013_(ES)by Julio SalasISO27001_2013by vidalsnDomotica Con s7-200by Alejandro Alejandro Pablo Alberto1 SSC Auditores Internos ISO 27001 Rev 1by ruko10Monografico ISO 27001 ISOToolsby Emma FonsecaTesis Especializacion en Scada _MFGby gil_joh1309TESIS SCADAby cjns0001Automatizacion Upsby Miguel CuyaLabview Deshidratación mediante autómata programable. by dirizabalIso 17799by CapLinuxCartel SCADA PDF.pdfby ConjuntoLASierraFriaZacatecasISO 27001by AmtMoralesDesarrollo de Un Sistema de Control Avanzado de La Presin Del Vapor en Una Caldera de Tubos de Fuegoby Christian AlbertoISO 27001 Gestion de Riesgosby Fher5_5Tesis Ing Matto 2006by kalovireSimilar to 480 Seguridad Sistemas SCADA Mar10ISO_27001_v011ISO27001sistema escadaAutómatas Programables y Sistemas de Automatización. Parte 1ISO 27001 ChecklistNorma. NTC-ISO-IEC 27001.pdfImplantacion Del ISO 27001 2005UNE-ISO(IEC_27002=200927005scadaISO 27001Diseño sistema SCADAEvaluacion Iso 27001 ChecklistUNIT-ISO-IEC 27001-2013_(ES)ISO27001_2013Domotica Con s7-2001 SSC Auditores Internos ISO 27001 Rev 1Monografico ISO 27001 ISOToolsTesis Especializacion en Scada _MFGTESIS SCADAAutomatizacion UpsLabview Deshidratación mediante autómata programable. Iso 17799Cartel SCADA PDF.pdfISO 27001Desarrollo de Un Sistema de Control Avanzado de La Presin Del Vapor en Una Caldera de Tubos de FuegoISO 27001 Gestion de RiesgosTesis Ing Matto 200625036594-NORMA-ISO27001Sistema Scada

References: artículo 4
 artículo 4
 artículo 9
 Real Decreto 
 artículo 42
 Real Decreto