Diseño arquitectónico

El proceso de construcción de un sistema compuesto por hardware, software y comunicaciones de una infraestructura crítica comienza por la selección de un modelo de proceso de diseño. Decidido el modelo de proceso, nos enfrentamos en una etapa temprana, con la elicitación de requerimientos y una etapa de diseño inicial. Esta etapa de diseño inicial debería mirar al sistema con el objetivo de identificar subsistemas y establecer un marco de control y comunicación entre los subsistemas identificados. A esto se denomina DISEÑO ARQUITECTÓNICO.

Autores como Bass y otros señalan al menos tres ventajas de diseñar y documentar explícitamente la arquitectura de un sistema. En realidad ellos hablan de "software" y no de sistema, pero se puede extender esta propuesta y reafirmar estas ventajas, con algunas observaciones:

• Facilitación de la comunicación con los stakeholders;
• Falicitar el análisis del sistema para cumplir con requerimientos críticos como pueden ser el rendimiento, confiabilidad, mantenibilidad y SEGURIDAD.
• Reutilización a gran escala.

Esto último en particular, lleva a que sistemas diferentes para el mismo dominio presenten estilos arquitectónicos semejantes. Digo, aparecen patrones de organización ya reconocidos como una organización cliente-servidor o un arquitectura por capas. Lo cual es una referencia al momento de tomar decisiones de diseño de la arquitectura de la solución.En definitiva, hay que elegir la estructura mas adecuada que permita satisfacer los requerimientos funcionales y no funcionales del sistema.

Resultante de esta etapa del proceso de diseño es un documento que contendrá a nivel sistema, modelos estructurales o estáticos, modelos de procesos o dinámicos, modelos de interfaces, relaciones, etc. Para todos ellos, SysML es el lenguaje a utilizar.

Sería deseable que también la seguridad sea abordada en esta etapa temprana de diseño, para lo cual deberíamos evaluar modelos de amenazas que permitan mapear sobre patrones de seguridad que luego se incorporarán en las decisiones posteriores de diseño de componentes.

Cuando hablamos de todas estas cuestiones aparece como interesante pensar en disponer primero de una arquitectura de referencia (AR), en particular para los Cyber Physical Systems. Y luego en una AR segura. Esto permitiría abordar desde una etapa muy temprana, el problema de diseño seguro de un CPS. Luego esto permitiría escalar al sistema crítico las deciciones de diseño a fin de garantizarle seguridad.

Bass, L., Clements P. (2003). Software Architecture in Practice, 2nd edn. Boston: Addison-Wesley. (Ch 11).-

Veo que no estamos solos

El tema de la ciberseguridad de infraestructuras críticas es también una preocupación de la OEA y entre las noticias que publica su sitio, está un evento que se nos pasó... Un congreso sobre Ciberseguridad en Infraestructuras Críticas celebrado en Buenos Aires, este pasado mes de Octubre, organizado por el Centro de Ciberseguridad Industrial. 

Volviendo al sitio de Seguridad Cibernética de la OEA, en la pestaña de "Documentos", podrán encontrar varios PDF que les ayudarán a gestionar la ciberseguridad en sus lugares de trabajo. Que los disfruten..!!

Guías de NIST y DHS

La Casa Blanca y el "Department of Homeland Security" (DHS) difundieron dos publicaciones independientes sobre ciberseguridad en IoT. Cubren directrices y principios para crear dispositivos IoT con medidas de seguridad incorporadas, así como protocolos recomendados para implementar tales medidas.

La administración de Obama "apresuró" la publicación del NIST, debido a la urgente escalada alrededor de la ciberseguridad de los dispositivos IoT después del mayor ataque de DDoS a infraestructuras de Internet de USA, ocurrido el mes pasado.

 

La ciberseguridad comenzó a ser una preocupación desde los 90 cuando se masificó la conectividad a Internet. Cuando la conectividad llegó a los dispositivos móviles en la década de 2000, se convirtió en un problema aún más grande. Hoy, IoT es el siguiente paso de preocupación, ya que implica un gran número de dispositivos interconectados que están perpetuamente en línea. Esto aumenta significativamente la magnitud del riesgo.

Ambas publicaciones tienen como objetivo guiar las medidas de seguridad en la etapa de diseño y fabricación en lugar de en el nivel de usuario. Lo cual contrasta con las decisiones que suelen tomarse al intentar mejorar la seguridad cuando ya se tiene un producto terminado, lo cual desde el punto de vista conceptual es un error muy caro. 

De todos modos garantizar la seguridad en etapas de diseño y fabricación trae consigo el factor costo, la pregunta más importante es: ¿ pueden los fabricantes de dispositivos estar lo suficientemente incentivados como para que valga la pena gastar tiempo, dinero y esfuerzo en incorporar hardware y software de seguridad en sus dispositivos ? Ver para creer.

Ambas guías <NIST> <DHS> se enfocan en los fundamentos y procesos del ciclo de vida del sistema para la fabricación de dispositivos y proporcionan pautas para incorporar protocolos y mecanismos de seguridad como parte del propio ciclo de vida del producto. La publicación de Homeland Security va un paso más allá y aborda las cuestiones desde el punto de vista del consumidor industrial. 

El objetivo de estas publicaciones es el de iniciar la discusión sobre un conocimiento de alto nivel y evocar un sentido de urgencia en la aplicación de las directrices y principios descritos en ellas. 

La FCC ha dicho que no es probable que promulgue normas obligatorias para la ciberseguridad de IOT, pero con IOT impregnando las áreas críticas de la industra como la producción de energía, la tecnología médica y la infraestructura de transporte, se incrementa el riesgo de que tales sistemas sean comprometidos. Lo sabremos pronto... 

Organismo Regulador de Seguridad en Presas (ORSEP)

En la República Argentina se ha construido más de un centenar de grandes presas y un importante número de presas de menor dimensión. Existen también diques de protección ante crecidas, terraplenes de recrecimiento de cuerpos lagunares, azudes y presas de relave minero o diques de cola.
Si bien, el territorio nacional presenta un alto porcentaje de recursos hídricos aún no explotados, actualmente varios proyectos hidráulicos en desarrollo prevén la construcción y puesta en operación de nuevas presas en los próximos años.

En el año 1999, mediante el decreto 239 del Poder Ejecutivo Nacional se crea el Organismo Regulador de Seguridad de Presas (ORSEP), autoridad de aplicación de los contratos de concesión para la explotación de las 31 obras propiedad del Estado Nacional, como garante del cumplimiento de las obligaciones en la materia por parte de las empresas hidroeléctricas concesionarias.

En función de lo anterior, las presas concesionadas por el Estado Nacional disponen de un marco regulatorio para la seguridad estructural y operativa de sus instalaciones, que procura un tratamiento riguroso y homogéneo en la temática, bajo fiscalización del organismo regulador.

Independientemente de lo mencionado, la mayoría de las presas del país se encuentran bajo las jurisdicciones provinciales, donde la gestión de la seguridad sigue criterios y modalidades diferentes según lo adoptado en cada caso.

El ORSEP tiene como misión fundamental lograr que todas las presas alcancen los más elevados estándares de seguridad, con el fin de proteger a la población y resguardar el patrimonio nacional.

Me pregunto si estará contemplada la ciberseguridad dentro de los estándares referidos a la seguridad de presas y otras obras. Ejemplo: Si se detecta una actividad sospechosa en el perímetro de una presa, a quién se puede reportar el incidente ?

Norma IEC 61508

Después de los accidentes mencionados en la entrada “Conceptos sobre sistemas críticos”, se intentó cuantificar la frecuencia de fallas de los componentes de una planta industrial utilizando las mismas técnicas utilizadas para cuantificar la frecuencia prevista de fallas aplicadas previamente a la disponibilidad de una planta en su totalidad, donde el costo de la falla del equipo era la principal preocupación. La tendencia en los últimos años ha sido una aplicación más rigurosa de estas técnicas en el campo de la evaluación de riesgos junto con la verificación de terceros (auditorías). Estas técnicas incluyen Análisis de Árbol de Fallas, Análisis de Efectos y Modos de Falla, Evaluación de Fallas de Causa Común y otras.

La evaluación del riesgo de las plantas de proceso y otras actividades industriales fue común en los años ochenta, pero la orientación y las normas formales eran raras y algo fragmentadas. Sólo la Sección 6 de la Ley de Salud y Seguridad en el Trabajo de 1974 (Reino Unido) apuntalaba la necesidad de hacer todo lo razonablemente posible para garantizar la seguridad. Sin embargo, después de la catástrofe de Flixborough, una serie de movimientos (incluyendo la directiva de Seveso) condujo a las regulaciones CIMAH (Control of Industrial Major Accident Hazards) en 1984, y su formulario COMAH revisado (Control of Major Accident Hazards) en 1999. La adopción de la “Machinery Directive” por la UE, en 1989, introdujo el requisito de un análisis documentado del riesgo en apoyo del Marcado CE.

Sin embargo, estas leyes y requisitos no especifican cómo se debe establecer un objetivo de riesgo tolerable para una actividad, ni tampoco abordan los métodos de evaluación de los diseños propuestos ni proporcionan requisitos específicos de seguridad en el diseño.

La necesidad de una orientación más formal se conoce desde hace tiempo, pero hasta mediados de los años 80, las técnicas de evaluación de riesgos tendían a concentrarse en cuantificar la frecuencia y magnitud de las consecuencias derivadas de determinados riesgos. Estos fueron a veces comparados con valores objetivos vagamente definidos, pero, siendo un tema controvertido, tales objetivos (generalmente en la forma de tasas de mortalidad) no eran fácilmente aplicados o publicados.

La Norma de la Unión Europea EN 1050 (Principios de la evaluación del riesgo), en 1996, abarcaba los procesos de evaluación de riesgos, pero ofrecía pocos consejos sobre la reducción del riesgo. Se proporcionaron algunas orientaciones para el control de maquinaria (EN 954-1 véase el capítulo 10) sobre cómo reducir los riesgos asociados a los sistemas de control, pero no se incluyeron específicamente los PLC (programmable logic controllers) que fueron tratados por separado en otros documentos de IEC (International Electrotechnical Commission) y CENELEC (European Committee for Standardization).

Por otro lado, la proliferación de software a partir de los años 80, en particular en los sistemas de control y seguridad en tiempo real, centró la atención en la necesidad de abordar fallas sistemáticas, ya que podrían no necesariamente ser cuantificadas. En otras palabras, mientras que las tasas de fallos de hardware se consideraban una tasa creíble y predecible de confiabilidad, se estuvo de acuerdo en que las tasas de falla de software generalmente no eran predecibles. Se aceptó que era necesario considerar defensas cualitativas contra fallas sistemáticas como una actividad adicional, y separada, a la tarea de predecir la probabilidad de fallas aleatorias del hardware.

En 1989, el HSE (Health and Safety Executive) publicó directivas que fomentaban este doble enfoque para garantizar la seguridad funcional de equipos programables. Esto condujo al trabajo de IEC, durante la década de 1990, que culminó en la norma internacional sobre seguridad funcional IEC 61508. La norma IEC se refiere a la seguridad de los sistemas eléctricos, electrónicos y programables en los que un potencial fallo afectará personas o medio ambiente. Tiene un carácter voluntario, en lugar de legal, al menos para el Reino Unido, pero hay que decir que actualmente ignorarla puede verse como "no hacer todo lo razonablemente practicable" en el sentido de la Ley y un fracaso para demostrar la "diligencia debida". A medida que se extiende el uso de la Norma, se puede argumentar que es cada vez más "practicable" usarlo. La Norma fue revisada y reeditada en 2010.

Conceptos sobre sistemas críticos

No existe sistema socio-técnico que presente riesgo cero. Esto se debe a que ningún elemento físico tiene tasa de falla cero, ningún ser humano está exento de cometer errores y ningún diseño de software puede prever todas las posibilidades operacionales. Luego todos los sistemas fallan. No existen los sistemas sin fallas. 

A pesar de ello, la percepción pública del riesgo, especialmente después de un incidente mayor, a menudo exige el ideal de riesgo cero. Pero, en general, la mayoría de las personas entienden que esto no es practicable, y se pueden consultar valores de riesgo diario de muerte por diversas causas, que están lejos de ser nulos. De este modo, prevalece el sentido común y la noción de reconocer un riesgo tolerable asociado a cualquier actividad humana.

Ahora bien, el grado real de riesgo que se considera tolerable variará de acuerdo con una serie de factores tales como el grado de control que se tiene sobre las circunstancias, el carácter voluntario o involuntario del riesgo o el número de personas en riesgo en cualquier incidente, entre otros factores.

A partir de ello, se ha desarrollado una tecnología de la seguridad en torno a la necesidad de establecer metas de niveles de riesgo tolerables y evaluar si los diseños propuestos cumplen con estos objetivos, ya sean en plantas de proceso, sistemas de transporte, equipos médicos o cualquier otra aplicación. 

 

A principios de los 70, las personas vinculadas a la industria de procesos se dieron cuenta de que, con plantas cada vez más grandes y complejas, que implicaban mayores inventarios de material peligroso, la práctica de aprender por errores (si es que lo hacían) ya no era aceptable. Se desarrollaron métodos para identificar y cuantificar las consecuencias de las fallas. Se desarrollaron en gran medida para ayudar en el proceso de toma de decisiones al desarrollar o modificar la planta. Las presiones externas para identificar y cuantificar el riesgo vendrían después.

A mediados de esa década ya existía preocupación por la falta de controles formales para regular esas actividades, lo que podría dar lugar a incidentes que tuvieran un impacto importante en la salud y la seguridad del público en general.

El incidente de Flixborough en junio de 1974, que resultó en 28 muertes, centró la atención del público británico y de los medios de comunicación en esta área de la tecnología. Muchos otros acontecimientos, como el de Seveso (Italia) en 1976 hasta el desastre de Piper Alpha y los incidentes ferroviarios más recientes de Paddington (y otros), han mantenido vivo ese interés y han dado lugar a la publicación de directrices y también a legislación en el Reino Unido. Luego veremos que esto generó estándares internacionales para el desarrollo de sistemas críticos.

Mes de la Seguridad y Resiliencia de Infraestructuras Críticas

Las infraestructuras críticas de una nación proporcionan servicios esenciales que sustentan la sociedad y sostienen su estilo de vida. Reconocemos a las infraestructuras críticas en la energía que usamos en nuestros hogares y negocios, en el agua que bebemos, en los sistemas de transporte que nos llevan de un lugar a otro, en los servicios de emergencia y hospitales de nuestras comunidades, en las granjas donde crece nuestra comida. Tiendas en las que compramos, y en los sistemas de Internet y comunicaciones en los que confiamos para mantenernos en contacto con amigos y familiares. La seguridad y la resiliencia de toda esta infraestructura crítica es vital no sólo para la confianza pública, sino también para la seguridad, prosperidad y bienestar de una nación. Al menos así lo ve el Homland Security de USA <aquí>

Los Cyber Physical Systems requieren seguridad

Un Cyber Physical System requiere de seguridad, en términos muy concretos, tal cual lo describe el mapa conceptual de [1]. Se habla de Resiliencia, Privacidad, resistencia a Ataques Maliciosos y Detección de Intrusión.

Técnicamente, la RESILIENCIA es la capacidad de un material de absorber energía cuando se deforma. En el contexto de un CPS, se refiere a la capacidad del sistema para seguir funcionando satisfactoriamente frente a entradas inesperadas, fallas de subsistemas o condiciones ambientales o entradas que están fuera del rango de operación específico. Tolerancia a fallas, detección de fallas y adaptación son todas técnicas que promueven la resiliencia.

En cuando a la PRIVACIDAD, en el contexto de la CPS, se refiere al problema de proteger la información de los seres humanos del acceso no autorizado de otros seres humanos o máquinas.

En cuanto a ATAQUES MALICIOSOS, todos los sistemas informáticos en red enfrentan el riesgo de ataques maliciosos. A medida que las redes que conforman los CPS se vuelven más abiertas, también se vuelven vulnerables. Pero incluso con las redes cerradas, separadas por un "vacío" de las redes abiertas, todavía existen riesgos debido a la confianza incompleta en  proveedores y debido a la posibilidad de la introducción accidental de código malicioso. Los problemas particulares incluyen:

• back doors;
• denial of service attacks;
• trojan horses;
• viruses.

El término DETECCIÓN DE INTRUSIÓN, se refiere a la necesidad de considerar intrusiones físicas y cibernéticas. Las tecnologías que pueden ser llevadas a cabo incluyen:

• Desde el punto de vista del embebido: detección y seguimiento de su movimiento, detección de presencia humana, reconocimiento facial; y
• Desde el punto de vista temporal: habilitar la detección de anomalías temporales lo cual puede revelar intrusión.

 [1]. http://cyberphysicalsystems.org/; consultado en  Octubre 2015.-

Cyber Physical Systems

Un “Cyber Physical Systems” (CPS) [1] es una integración de sistemas computacionales embebidos, redes de datos y procesos físicos. Los sistemas embebidos junto a las redes monitorean y controlan los procesos físicos mediante lazos de realimentación afectando su cómputo y viceversa. Si bien se basan fuertemente en sistemas embebidos, su principal misión no es el cómputo en sí mismo sino sostener el funcionamiento del sistema físico que componen. Los CPS forman parte de la dinámica de los procesos físicos integrando software y redes en una abstracción que demanda técnicas de modelado, diseño y análisis específicos [2].

El término surgió en algún momento del año 2006, cuando fue utilizado por Helen Gill en la "National Science Foundation" (USA). Si bien estamos familiarizados con el término ciberespacio y podemos estar tentados a asociar los CPS con él, la raíz del término CPS es más antiguo.  Es más preciso asociarlo al término cibernética . Que a su vez fue aportado por Norbert Wiener, un matemático americano que ayudó al desarrollo de la teoría de los sistemas de control.

[1]. http://cyberphysicalsystems.org/; consultado en  Octubre 2015.-
[2]. Lee Seshia A.; “Introduction to Embeddes Systems A Cyber-Physical Systems Approach”; Second Edition; 2015.-

Legislación Argentina

Argentina, 15 años después, elabora algunas ideas y crea el ICIC, o Programa Nacional de Infraestructuras Críticas de Información y Ciberseguridad <consultar>.
Creado mediante la Resolución JGM Nº 580/2011, tiene como finalidad impulsar la creación y adopción de un marco regulatorio específico que propicie la identificación y protección de las infraestructuras estratégicas y críticas del Sector Público Nacional, los organismos interjurisdiccionales y las organizaciones civiles y del sector privado que así lo requieran, y la colaboración de los mencionados sectores con miras al desarrollo de estrategias y estructuras adecuadas para un accionar coordinado hacia la implementación de las pertinentes tecnologías, entre otras acciones.
Lo primero que me pregunto es si es posible dejar librado a los sectores privados, la colaboración de forma voluntaria en la protección de infraestructuras que potencialmente pondrían en riesgo la gobernabilidad de la Nación.

Sectores con infraestructuras críticas

Revisando la primera legislación propuesta por Bill Clinton, la siguiente reflexión que nos hacemos es: bien, vemos que se mencionan sectores de la sociedad que realizan ciertas actividades que estarían confiando en insfraestructuras que son críticas o conformarían infraestructuras críticas.

¿ Habrá alguna clasificación de esos sectores ?

Despúes de todo han pasado 20 años. Esto es algo que lo deberían haber resuelto. Efectivamente, el Departamento de Seguridad Nacional de los Estados Unidos, conocido como "Homeland Security" ha propuesto algunas definiciones que nos ayudarán a poner un manto de luz sobre nuestra reflexión. 

Se puede consultar los sectores definidos por el "Homeland Security" <aquí>.

¿ Qué son las infraestructuras críticas ?

Es una muy buena pregunta. Muchas veces uno recorre el territorio ciudadano, provincial o nacional y encuentra determinadas construcciones que están expuestas.
Expuestas a intenciones de individuos o grupos que podrían poner en riesgo la vida de las personas a las cuales sirven esas construcciones. Hay una primera legislación en USA, propiciada por William J. Clinton en el año 1996. La "Ejecutive Order 13010" dice que "Ciertas infraestructuras nacionales son tan vitales que su incapacidad o destrucción tendría un impacto debilitante en la defensa o la seguridad económica de los Estados Unidos. Estas infraestructuras críticas incluyen telecomunicaciones, sistemas de energía eléctrica, almacenamiento y transporte de gas y petróleo, banca y finanzas, transporte, sistemas de suministro de agua, servicios de emergencia (incluyendo servicios médicos, policiales, de bomberos y rescate) y continuidad del gobierno. Las amenazas a estas infraestructuras críticas se dividen en dos categorías: amenazas físicas a los bienes tangibles (amenazas físicas) y amenazas de ataques electrónicos, de radiofrecuencia o informáticos sobre los componentes de información o comunicaciones que controlan las infraestructuras críticas ( "amenazas cibernéticas" "). Dado que muchas de estas infraestructuras críticas son propiedad y son operadas por el sector privado, es esencial que el gobierno y el sector privado trabajen juntos para desarrollar una estrategia para protegerlos y asegurar su funcionamiento continuo." Es un buen punto para comenzar a responder algunas preguntas sobre este tema.