SCADA del gasoducto de Seguridad

API estándar de 1164 Tercera

edición, ???? 20XX
2 S API ORMA 1164

Prefacio

Esta norma de seguridad SCADA proporciona orientación a los operadores de sistemas de petróleo y líquidos de gasoductos para la gestión de la
integridad y la seguridad del sistema SCADA. El uso de este documento no se limita a los ductos regulados en el Título 49 CFR 195.1, sino que debe
considerarse como una lista de las mejores prácticas que han de emplearse en la revisión y elaboración de normas para un sistema SCADA. Este
documento incorpora las API
Directrices de seguridad para la industria del petróleo. Esta guía está diseñada específicamente para proporcionar a los operadores con una descripción
de las prácticas de la industria en materia de seguridad SCADA, y para proporcionar el marco necesario para el desarrollo de las prácticas de seguridad
de sonido dentro de cada empresa del operador. Es importante que los operarios comprenden los riesgos y la vulnerabilidad del sistema al revisar el
sistema SCADA para posibles mejoras en el sistema.

Nada de lo contenido en cualquier publicación API debe ser interpretado como una concesión de la derecha, por implicación o de otra manera, para la
fabricación, venta o uso de cualquier método, aparato o producto cubierto por la patente de letras. Ni debe cualquier cosa contenida en la publicación se
interpretará como asegurar que nadie de la responsabilidad por infracción de patentes de invención.

Será: El término “deberá” se usa en la presente norma para indicar aquellas prácticas que son obligatorios.

En caso de que: El término “debería” se utiliza en esta norma para indicar:

- esas prácticas para los que se requiere el juicio de ingeniería;

- aquellas prácticas que son preferidos, pero para los cuales los operadores pueden determinar que prácticas alternativas son igualmente o más
eficaz.

Puede: El término “puede” se utiliza en esta norma para indicar un estado de posibilidad o capacidad

Que: El término “puede” se utiliza en esta norma para indicar un curso de acción permisible dentro de los límites de la norma

Este documento ha sido preparado bajo los procedimientos de normalización de la API que garanticen la notificación y la participación adecuada en
el proceso de desarrollo y se designa como un estándar API. Las cuestiones relativas a la interpretación del contenido de esta publicación o
comentarios y preguntas relativas a los procedimientos bajo los cuales se desarrolló deben ser dirigidas por escrito al Director de Normas del
Instituto Americano del Petróleo, 1220 L Street, NW, Washington, DC 20005. Las solicitudes esta publicación de autorización para reproducir o
traducir la totalidad o parte del material publicado en este documento también deben dirigirse al director.

En general, las normas API son examinados y revisados, reafirmó, o retiradas al menos cada cinco años. Una extensión de una sola vez de hasta
dos años se puede añadir a este ciclo de revisión. Estado de la publicación se puede determinar desde el Departamento, teléfono (202) 682-8000
normas API. Un catálogo de publicaciones y materiales de API es publicado anualmente por la API, 1220 L Street, NW, Washington, DC 20005.

revisiones sugeridas están invitados y deben ser enviadas al Departamento de Normas, API, 1220 L Street, NW, Washington, DC 20005,
standards@api.org.
Contenido

1 Ámbito ................................................. .................................................. ...................................... 5

1.1 Antecedentes de la Industria Sistema SCADA ............................................. ............................................... 5

1.2 Propósito y objetivos .............................................. .................................................. .............. 5

1.3 Funciones y responsabilidades .............................................. .................................................. ........... 6

2 Definiciones y Acrónimos .............................................. .................................................. ........... 6

2.1 Definiciones ................................................ .................................................. ............................... 6

2.2 Acrónimos ................................................ .................................................. .............................. dieciséis

3 Sistema de Gestión ............................................... .................................................. ............... 17

3.1 Plan de Seguridad ............................................... .................................................. ........................... 17

3.2 Personal ................................................ .................................................. ............................... 18

3.3 Políticas de Seguridad ............................................... .................................................. ....................... 18

3.4 Riesgos y Evaluación de la vulnerabilidad ............................................. ............................................... 18

3.5 nuevo o de reemplazo Diseño de seguridad del sistema ........................................... ................................. 20

3.6 Plan de Continuidad de Negocio (BCP) ........................................... .................................................. ..... 20

3.7 Plan de Respuesta a Incidentes (IRP) ........................................... .................................................. ........ 21

3,8 de inventario de activos / Categorización / Seguimiento ........................................... .......................................... 21

3.9 Gestión del Cambio ............................................... .................................................. ............... 21

3.10 del sistema operativo y actualizaciones de la aplicación ............................................ ................................... 22

3.11 Contratación ................................................ .................................................. .......................... 25

4 Seguridad Física ............................................... .................................................. ...................... 25

5 Sistema de control de acceso ............................................... .................................................. ....................... 26

5.1 Acceso restringido ................................................ .................................................. .......................... 26

5.2 Control de acceso lógico a los sistemas de control y redes de control ......................................... ........ 26

5.3 Cuentas de usuario ............................................... .................................................. ................................ 26

5.4 Las cuentas del sistema operativo .............................................. .................................................. ............ 27

5.5 Cuentas SCADA ................................................ .................................................. ............................ 27

5.6 Contraseña Controla ................................................ .................................................. ........................ 27

5.7 Multi-factor de autenticación ............................................. .................................................. ............. 28

5.8 La biometría ................................................. .................................................. .................................... 28

5.9 Servicios Para Personas no requiere ............................................. .................................................. ....... 29

5.10 Herramientas del sistema operativo .............................................. .................................................. .................. 30

Página 3 de 73
4 S API ORMA 1164

5.11 Dispositivo de Acceso ............................................... .................................................. ................................. 30

5.12 Administración de Personal ............................................... .................................................. .............. 31

6.1 ................................................. confidencial .................................................. .................................. 31

6.2 Restringida ................................................. .................................................. ..................................... 32

6.3 Solo para uso interno ............................................... .................................................. ........................... 32

6.4 ................................................. pública .................................................. ............................................ 32

7.1 Diseño de Redes ............................................... .................................................. .............................. 33

7.1.1 Interconectado Negocios y Redes SCADA ............................................. ............................ 33

7.1.2 Puntos de demarcación de comunicación ............................................... ........................................... 33

7.1.3 Los cortafuegos ................................................. .................................................. ................................... 33

7.1.4 Zona desmilitarizada (DMZ) ............................................. .................................................. ............ 33

7.1.5 Con base dual Computadoras .............................................. .................................................. ............. 34

7.1.6 Defensa en profundidad ............................................... .................................................. ....................... 35

7.1.7 Gestión de cortafuegos ................................................ .................................................. ............... 36

7.1.8 La virtualización ................................................. .................................................. ............................ 36

7.1.8.1 Permisos .............................................. .................................................. ................................. 37

7.1.8.2 Hypervisor y Máquinas Virtuales Servicios .......................................... ......................................... 37

7.1.8.3 Redes .............................................. .................................................. .................................. 37

7.1.8.4 Asignación de Recursos ............................................. .................................................. ..................... 38

7.2 Gestión de Red ............................................... .................................................. ................... 38

 SCADA del gasoducto de Seguridad

1 Alcance

Este documento está estructurado de manera que el cuerpo principal proporciona la visión de alto nivel de las prácticas de seguridad integrales. Los
anexos proporcionan más información y orientación técnica. Revisando el cuerpo principal de este documento y siguiendo las orientaciones expuestas
en los Anexos ayuda a crear operaciones intrínsecamente seguras. La aplicación de esta norma, para avanzar en el control de supervisión y
adquisición de datos de seguridad cibernética (SCADA), no es un proceso sencillo o un evento de una sola vez, sino un proceso continuo. El proceso
global podría tomar años para implementar correctamente dependiendo de la complejidad del sistema SCADA. Además, el proceso de forma óptima se
inició como parte de un proyecto de actualización SCADA o utilizar este estándar para el “diseño en” la seguridad como un elemento del nuevo
sistema.

1.1 Antecedentes de la Industria Sistema SCADA

sistemas SCADA se utilizan para controlar y el equipo de control distribuidas a lo largo instalaciones de producción y tuberías. Los sistemas SCADA
típicamente tienen un ciclo de vida largo. Actualización de todos los componentes de un sistema SCADA puede ser un proceso largo y difícil de lograr
sin necesidad de interrumpir la funcionalidad SCADA.

Históricamente, los sistemas SCADA utilizan hardware y software propietario y se comunican a través de canales de comunicación separados
dedicados a los protocolos de comunicación de propiedad. Dado que estos sistemas fueron aisladas de otras redes, el diseño del sistema hincapié
en la mejora de las comunicaciones entre los dispositivos, no garantizar la seguridad de las comunicaciones entre dispositivos.

Las presiones de los clientes de los proveedores de SCADA los obligaron a proporcionar una arquitectura más abierta para facilitar la interconexión de
componentes SCADA, así como la competencia económica ha llevado al uso de Comercial Fuera de la tecnología (COTS), como incrustado interfaces
basadas en Ethernet, Web o PC. Estas características se añaden con frecuencia a los equipos existentes sin modificación del sistema para proporcionar
seguridad adicional. Hoy en día, muchos dispositivos de campo han incrustado servidores Web con poca o ninguna seguridad disponibles. Con el ciclo de vida
prolongado de los sistemas SCADA, es probable que el equipo va a estar todavía en servicio después de soporte por los extremos de los proveedores y
exploits son bien conocidos.

Ahora que los sistemas SCADA tienen interfaces COTS, también es posible conectar a otras redes, como la red de negocios corporativos de
contabilidad, mantenimiento y supervisión de rendimiento. Si bien esto proporciona la empresa que opera una ventaja también tiene el potencial de
exponer a los sistemas SCADA a vulnerabilidades comunes a la red de negocios corporativos, así como el acceso a fuentes externas que
pretendan daño o alteración.

La evolución de los sistemas SCADA, consideraciones políticas, y la escalada de riesgo para la seguridad cibernética suponen un aumento global de las
necesidades propietarios de gasoductos para operar de forma segura su infraestructura.

1.2 Proposito y objetivos

El objetivo de un operador es el control de la tubería de tal manera que no hay efectos adversos sobre los empleados, el medio ambiente, el público
o los clientes como resultado de acciones por parte del operador o por otras partes. Este programa de seguridad SCADA proporciona un medio
para mejorar la seguridad de la operación SCADA del gasoducto por:

- el análisis de las vulnerabilidades del sistema SCADA que pueden ser explotados por entidades no autorizadas,

- una lista de los procesos que se utilizan para identificar y analizar las vulnerabilidades del sistema SCADA a los ataques no autorizados,

Página 5 de 73
6 S API ORMA 1164

- proporcionar una lista exhaustiva de las prácticas para endurecer la arquitectura de núcleo,

- proporcionar ejemplos de las mejores prácticas de la industria.

1.3 Funciones y responsabilidades

la alta dirección del operario deberá implementar un programa de seguridad SCADA para su organización que identifica la rendición de cuentas de
todos los aspectos de la seguridad SCADA en todos los niveles de la organización. El alcance del programa de seguridad SCADA debe incluir la
organización del operador, socios de negocios, vendedores y proveedores externos de productos y servicios SCADA para el sistema SCADA. El
programa de seguridad SCADA debe documentar el plan de seguridad SCADA, identificar las funciones y responsabilidades de los profesionales
de la seguridad y los profesionales que implementan políticas y procedimientos, y proveer a la coordinación de los esfuerzos de seguridad en el
dominio SCADA con las actividades de seguridad cibernética de toda la organización. Estas líneas de comunicaciones deben ser documentados y
ejercidos para garantizar que son eficaces y eficientes.

El programa de seguridad SCADA debe ser diseñado y comunicada de manera que todo el personal que tienen un impacto real o potencial en la
seguridad del sistema SCADA están plenamente informados de sus roles y responsabilidades de seguridad, y recibir una formación adecuada para
completar sus tareas de forma segura. El programa de seguridad SCADA debe estar diseñado para garantizar la aplicación continua de la organización de
las mejores prácticas de la industria de la seguridad cibernética y el cumplimiento de todas las normas pertinentes.

El programa de seguridad SCADA debe incluir y definir las funciones de personal y responsabilidades asociadas con la coordinación, la
comunicación y la rendición de cuentas de seguridad de la información en y entre los sistemas de control y redes empresariales.

2 Definiciones y Acrónimos

2.1 Definiciones

A los efectos de esta norma se aplican las siguientes definiciones.

2.1.1
lista de control de acceso ACL

Una lista de permisos unidos a un objeto. La lista especifica quién o qué se le permite acceder al objeto y se permite que operaciones a realizar
sobre el objeto.

2.1.2 trampilla de
puerta trasera

Una manera documentada o indocumentada de acceder a un programa, servicio en línea, o un sistema informático completo; escrito por el
programador que crea el código del programa.

2.1.3
biometría
El estudio de los métodos para la identificación exclusiva de los seres humanos en base a uno o más intrínsecas rasgos físicos o de comportamiento.

2.1.4
computación en la nube

La práctica de utilizar una red de servidores remotos alojados en Internet para almacenar, gestionar y procesar los datos, en lugar de un servidor
local o un ordenador personal.
2.1.5
confidencial
La clasificación se aplica a la información confidencial de la empresa que requiere de estrictas medidas de seguridad / estricta para protegerlo de la divulgación no
autorizada, modificación o destrucción.

NINGUNO no autorizado divulgación, modificación o destrucción podrían tener efectos deletéreos. La información confidencial que requiere un alto que la
garantía normal de exactitud e integridad (véase la Sección 6 para más detalles).

2.1.6
acceso controlado
Acceso en la que los recursos de un área o sistema está limitado a personal autorizado, usuarios, programas, procesos, u otros sistemas, y se les
niega a todos los demás.

2.1.7
centro de datos

Una instalación utilizada en los sistemas informáticos casa y componentes asociados, tales como las telecomunicaciones y sistemas de almacenamiento que
generalmente incluyen sistemas de alimentación redundantes, conexiones de comunicación de datos, los controles ambientales, y dispositivos de seguridad.

2.1.8
DBMS sistema de gestión de base de datos

Los programas informáticos diseñados con el propósito de la gestión de bases de datos basadas en una variedad de modelos de datos.

2.1.9
Consecuencias
La cantidad de pérdida o daño que se puede esperar de una amenaza de tener éxito.

2.1.10
defensa en profundidad

Una mejor práctica en múltiples capas y tipos de estrategias de defensa se implementan en todo el sistema SCADA, que deberá dirigir al
personal, tecnología y operaciones en todo el ciclo de vida del sistema.

2.1.11
zona desmilitarizada DMZ

Una DMZ es una zona intermedia entre el acceso de confianza y redes no seguras, proporcionando monitoreados y controlados y transferencia de
datos (véase la Figura 5).

2.1.12
ADN ácido desoxirribonucleico

Un ácido nucleico que contiene las instrucciones genéticas utilizadas en el desarrollo y el funcionamiento de todos los organismos vivos conocidos.

2.1.13
sistema de nombres de dominio

Asociados diferentes informaciones mediante nombres de dominio mediante la traducción de los nombres de host del ordenador legible en direcciones IP.

2.1.14
equipo de base dual
Un equipo que tiene interfaces de red conectados a múltiples redes o dominios de seguridad.

Nota Esto no es lo mismo que dos tarjetas de interfaz de red utilizados para la redundancia.

Página 7 de 73
8 S API ORMA 1164

2.1.15
Dynamic Host Configuration Protocol DHCP

Un protocolo utilizado por los dispositivos de red para obtener los parámetros necesarios para el funcionamiento en una red IP.

2.1.16
eliminados
Para deshacerse de, o después de haber eliminado, una amenaza.

2.1.17
seguridad mejorada
La seguridad por encima del nivel normal aceptado, incluyendo, pero no limitado a, fuerte o de múltiples factores de autenticación, cifrado, control de
acceso multinivel incluyendo el acceso físico y biometría.

2.1.18
extranet
Una extranet puede ser visto como una parte de la intranet de una empresa que se extiende a usuarios fuera de la empresa. También se ha descrito
como un “estado de ánimo”, en la que el Internet es percibida como una manera de hacer negocios con otras empresas, así como para vender productos
a los clientes.

2.1.19
instalación
Una planta, edificio, estructura, o complejo de forma contigua situada en el mismo sitio, que se define por un solo perímetro geográfico (por lo
general determinada por una valla u otra barrera que rodea y limita el acceso no controlada), y utilizados por el operador o sus contratistas para el
desempeño de trabajar bajo la jurisdicción del operador.

NINGUNO El término “instalación” incluye la tierra (suelo), las aguas superficiales y aguas subterráneas contenida dentro de su perímetro geográfico.

2.1.20
protocolo de transferencia de archivos

FTP

Un estándar de Internet para la transferencia de archivos a través de Internet.

programas y utilidades FTP NOTA se utilizan para cargar y descargar páginas web, gráficos y otros archivos desde un disco duro a un servidor remoto que
permite el acceso FTP.

2.1.21
cortafuegos
Un conjunto de programas que residen en un servidor de puerta de enlace que protege los recursos de una red interna.

NOTA Un cortafuegos examina cada paquete de red para determinar si se transmita hacia su destino. Un servidor de seguridad a menudo se instala en un aparato
especialmente designado que está separado del resto de la red de modo que ninguna solicitud entrante puede obtener directamente en los recursos de la red privada.
Como mínimo, una mejor recomendación práctica es la inspección de estado de paquetes o profunda.

2.1.22
huésped de la máquina

La máquina virtual que opera en el ordenador central en una aplicación virtualizada.

2.1.23
máquina host
El hardware real, donde residen los sistemas virtuales

2.1.24
interfaz hombre-máquina HMI
Un terminal de computadora normalmente asociada con un terminal gráfico que permite la interacción entre las personas y dispositivos finales.

2.1.25
hipervisor
El software que crea una máquina virtual en un sistema de hardware anfitrión. También se conoce como el administrador de máquinas virtuales.

2.1.26
IRP plan de respuesta a incidentes

Un plan que identifica y documenta los procedimientos que se utilizan para detectar, responder y minimizar el impacto de un incidente de seguridad
cibernética.

2.1.27
propietario de información

La persona responsable de la clasificación, el mantenimiento y la seguridad de los datos específicos.

2.1.28
mensajería instantánea IM

Un sistema de mensajería en tiempo real utilizado para el intercambio de datos e información entre dos o más personas a través de Internet o de una intranet
corporativa.

2.1.29
interna
La información que es accesible a todos los empleados y contratistas, mientras que la prestación de servicios al operador. Para los operadores utilizan solamente (véase
la Sección 6 para más detalles).

2.1.30
Internet Control Message Protocol ICMP

Una extensión a la IP definida por la RFC 792. ICMP soporta paquetes que contienen error, control y mensajes informativos.

NOTA El comando PING, por ejemplo, utiliza ICMP para probar una conexión a Internet.

2.1.31
protocolo de Internet IP

Un protocolo de capa de red en la suite de IP y se encapsula en un protocolo de capa de enlace de datos tales como ethernet.

2.1.32
Internet proveedor de servicios ISP

Una empresa que principalmente ofrece el acceso de sus clientes a la Internet.

2.1.33
intranet
El término genérico para un conjunto de redes informáticas privadas dentro de las políticas establecidas de una organización.

NOTA Intranets generalmente usan tecnologías de red estándar, como Ethernet, TCP / IP, navegadores y servidores web.

Página 9 de 73
10 S API ORMA 1164

2.1.34
IDPS sistemas de detección y prevención de intrusiones

Una referencia más general a las funciones de un IDS e IPS, y refleja el estado de evolución de estas tecnologías a medida que se fusionan en
una sola familia de productos.

2.1.35
sistema de detección de intrusos IDS

Un tipo de gestión de la seguridad para los ordenadores y redes. Un IDS recoge y analiza información de diversas áreas dentro de un dispositivo o
una red para identificar posibles fallos de seguridad, incluyendo las intrusiones y mal uso.

2.1.36
sistema de prevención de intrusiones IPS

Es compatible con la capacidad de recibir datos del sensor IDS o un escáner y luego aplicar procesos analíticos e información para derivar
conclusiones acerca de las intrusiones, y ejecutar una respuesta adecuada. productos que cumplan el IPS también proporcionan la capacidad
para protegerse a sí mismos y sus datos asociados del acceso o modificación no autorizada y para asegurar la responsabilidad de las acciones
autorizadas.

2.1.37
seguridad IP
IPsec
Un conjunto de protocolos desarrollados por el Grupo de Trabajo de Ingeniería de Internet (IETF) para apoyar el intercambio seguro de paquetes en la capa IP.
IPsec se ha utilizado ampliamente para implementar VPNs.

NOTA IPsec soporta dos modos de encriptación; transporte y túnel.

- El modo de transporte encripta solamente la parte de datos (carga útil) de cada paquete, pero deja la cabecera sin tocar.

- El modo túnel es más seguro y cifra tanto la cabecera y la carga útil. En el lado receptor, un dispositivo de IPsec compatible
descifra cada paquete.

2.1.38
escolta informado
Una persona que esté familiarizado con el trabajo que se lleva a cabo por una persona no compensado. Esta persona debe tener un sólido
conocimiento de los riesgos involucrados en el trabajo a realizar. Este individuo monitores se realiza el trabajo.

2.1.39
la capa dos (2) Protocolo de túnel L2TP

Una extensión al protocolo PPP que permite a los ISP para operar VPNs.

2.1.40
red de área local LAN

Un grupo de ordenadores y otros dispositivos dispersa sobre un área relativamente limitada y conectado por un enlace de comunicaciones que
permite a cualquier dispositivo para interactuar con cualquier otro en la red.

2.1.41
red lógica
La red SCADA y la red de negocios comparten la misma infraestructura y libremente datos de la ruta entre los dos.

2.1.42
monitoreo
El acto de observar, llevando a cabo la vigilancia y / o grabar la presencia de individuos con el fin de mantener y mejorar los estándares de
seguridad y de procedimiento; incluyendo el acto de la detección y medición de las condiciones anormales.

2.1.43
Instituto Nacional de Estándares y Tecnología NIST

Una agencia federal que la tecnología se desarrolla y promueve la medición, los estándares y la tecnología.

2.1.44
red del sistema de archivos NFS

Un protocolo que permite a un usuario en un equipo cliente para acceder a archivos a través de una red.

2.1.45
protocolo de transferencia de noticias de la red NNTP

Un uso protocolo de aplicación de Internet principalmente para la lectura y la publicación de artículos de Usenet, así como la transferencia de noticias entre los servidores de
noticias.

2.1.46
operador
Una persona que posee u opera instalaciones de tuberías.

NOTA A los efectos de este documento, los términos “operador de canalización” y “operador” son sinónimos.

2.1.47
punto a punto protocolo PPP

Un protocolo de enlace de datos utiliza comúnmente para establecer una conexión directa entre dos nodos.

2.1.48
política
Un documento que describe los requisitos o reglas específicas que deberán cumplir.

NOTA En el ámbito de seguridad de la información / red, las políticas son generalmente punto específico-, para una sola zona. Por ejemplo, un “uso
aceptable” política cubriría las normas y reglamentos para el uso adecuado de las instalaciones de computación.

Página 11 de 73
12 S API ORMA 1164

2.1.49
procedimiento
Una secuencia documentada de actividades, pasos, decisiones o procesos, que cuando lleva a cabo en la secuencia proporcionada produce el
resultado descrito.

2.1.50
red de control de proceso PCN

Una red utiliza para transmitir instrucciones y datos entre los sistemas SCADA de control y unidades de medida y.

2.1.51
controlador lógico programable PLC

Una computadora digital que se utiliza para la automatización de procesos industriales.

2.1.52
pública
La clasificación se aplica a la información que es de naturaleza general y se puede compartir con todas las personas de conciencia y no se requiere para
satisfacer las tareas o puestos de trabajo (véase la Sección 6 para más detalles).

2.1.53
RAS servicios de acceso remoto

Cualquier combinación de hardware y software que permite el acceso remoto a las herramientas y la información que reside normalmente en una
red de dispositivos SCADA.

2.1.54
unidad terminal remota RTU

Un dispositivo remoto típicamente utiliza para recopilar de estado, alarmas y lecturas remotas analógicas para su transmisión al sistema SCADA y
transferir los controles del sistema SCADA a un dispositivo de campo.

2.1.55
restringido
Clasificación se aplica a información de la compañía no sensibles restringido a los que tienen necesidad legítima para el acceso.

NOTA revelación no autorizada, modificación o destrucción podrían tener un impacto adverso. Esta información es para uso solamente dentro de
la compañía y en algunos casos dentro de las organizaciones afiliadas, como socios de negocios de la empresa (véase la Sección 6 para más
detalles).

02/01/56
riesgo

La probabilidad de que ocurra un evento multiplicada por la gravedad del caso. La más probable que ocurra un evento, y más graves son
los resultados de ese evento que se produzca mayor es el riesgo será.

2.1.57
Evaluación de riesgos
Una evaluación de los procesos para cuestiones de seguridad y vigilancia que presentan riesgos para la continuidad de las operaciones seguras y fiables.

2.1.58
aplicaciones basadas en roles
Aplicaciones que contienen múltiples capas de funcionalidad. Los usuarios autorizados se les concede acceso mínimo necesario para las diversas capas
basadas en la función de trabajo.
2.1.59
proveedor SCADA
entidad comercial o el operador que desarrolla y mantiene el software y / o hardware del sistema SCADA.

2.1.60
SSH shell seguro

Un conjunto de comandos y protocolos que utiliza certificados digitales para la autenticación de servidor y el cliente, así como para encriptar las comunicaciones
para garantizar la seguridad.

01.02.61
Secure Sockets Layer SSL

protocolo criptográfico que proporciona comunicaciones seguras en un entorno informático de red para cosas tales como la navegación web, correo electrónico, fax por
Internet, mensajería instantánea y otras transferencias de datos.

2.1.62
dominios de seguridad / zonas de seguridad
Una o más redes aisladas de otra red (s) por un cortafuegos.

01.02.63
La información de seguridad y gestión de eventos SIEM

Software, aplicaciones o servicios que proporciona análisis en tiempo real de alertas de seguridad generados por el hardware y las aplicaciones de red
gestionados.

2.1.64
plan de seguridad
Un conjunto de políticas, procedimientos o requisitos operativos, patrocinado por la administración, que describen un enfoque multifacético de los
problemas de seguridad y eventos relacionados.

NOTA Este enfoque podría incluir evaluaciones, árboles de decisión, mecanismos de protección, las respuestas y la recuperación, los niveles de seguridad
operativa y activos críticos identificados. Un plan de seguridad normalmente considera personas, procesos y tecnología.

01.02.65
comunicación serial
El proceso de envío de datos un bit a la vez, de forma secuencial, sobre un canal de comunicación o bus de ordenador.

NOTA estándares comunes de comunicación serial de interfaz eléctrica incluyen EIA / TIA 232, 422 y 485.

01.02.66
protocolo simple de gestión de red SNMP

Un protocolo TCP / IP estándar para la gestión de red utilizado por los administradores de red para supervisar y las tasas de disponibilidad,
rendimiento y error de la red mapa.

NOTA Para trabajar con SNMP, dispositivos de red utilizan un sistema de archivos distribuido llama la MIB. Todos los dispositivos compatibles con SNMP contienen una MIB que
suministra los atributos pertinentes de un dispositivo. Algunos atributos son fijos o “hard coded” en la MIB, mientras que otros son valores dinámicos calculados por el software de
agente que se ejecuta en el dispositivo.

Página 13 de 73
14 S API ORMA 1164

2.1.67
contraseñas seguras
Una combinación de letras mayúsculas y minúsculas, números y símbolos especiales en un orden no predecible.

01.02.68
superusuario hacer
SUDO
Una utilidad para sistemas basados ​en UNIX que proporciona una solución eficiente para dar a usuarios específicos permiso para utilizar comandos
específicos del sistema en el nivel raíz (más potente) del sistema.

NOTA SUDO también registra todos los comandos y argumentos.

2.1.69
control de supervisión y adquisición de datos SCADA

Una combinación de hardware y software utilizado para enviar comandos y adquirir datos con el objeto de seguimiento y control (ver Figura
1).

01.02.70
centro de telecomunicaciones
Una instalación que alberga equipos de comunicación y de red que permite conexiones entre dispositivos individuales finales, usuarios y
servicios.

2.1.71 terceros

Se refiere a los vendedores, personal de apoyo, otras compañías.

01.02.72
protocolo de control de transmisión / protocolo de Internet TCP / IP

TCP es uno de los principales protocolos de redes TCP / IP que permite a dos anfitriones para establecer una conexión e intercambiar flujos de datos, mientras
que ofertas de IP solamente con los paquetes.

NOTA TCP garantiza la entrega de los datos y que los paquetes serán entregados en el mismo orden en el que fueron enviados.
02/01/73
amenaza
Cualquier persona, circunstancia, la capacidad, la acción o evento con el potencial para causar daño, pérdida o daño. Ejemplos de amenazas
podrían incluir la modificación de los datos almacenados, el programa o configuración, instalación o malware, o causar una perturbación de la red.

2.1.74 trivial
TFTP FTP

Una forma simple de la FTP, TFTP utiliza el protocolo de datagrama de usuario (UDP), no proporciona características de seguridad y a menudo es utilizado por servidores
para arrancar estaciones de trabajo sin disco, terminales X, y los routers.

Figura 1 General SCADA Sistemas Layout

2.1.75
utilidades
El suministro de energía eléctrica, agua, gas natural y telecomunicaciones a un centro de control.

01.02.76
Máquina / sistemas virtuales
Es la creación de un servidor virtual y todas sus aplicaciones asociadas que actúa como un servidor físico con las mismas aplicaciones. Las
aplicaciones de software se separan de los recursos de hardware subyacentes.

2.1.77
red privada virtual VPN

A autenticado, conexión lógica, cifrada que se construyó utilizando redes no seguras que usa

Página 15 de 73
dieciséis S API ORMA 1164

cifrado y otros mecanismos de seguridad para garantizar que sólo los usuarios autorizados puedan acceder a la red y que los datos no pueden ser
interceptados y descifrados por personas no autorizadas.

01.02.78
la telefonía de voz sobre IP / IP VoIP /
IPT
Una tecnología que permite la gestión y transmisión de llamadas de voz mediante una red IP.

2.1.79
vulnerabilidad
Cualquier defecto o debilidad en un diseño de sistemas, ejecución o funcionamiento y gestión que puede ser explotada por un adversario o por
accidente. Un ejemplo de una vulnerabilidad es una contraseña por defecto de fábrica.

01.02.80
evaluación de vulnerabilidad
Una evaluación de los componentes del sistema y tecnología, para cualquier área susceptible a la explotación.

2.1.81
Listado blanco
Una lista de entidades que se están proporcionando un privilegio especial, el servicio, la movilidad, el acceso o el reconocimiento. Entidades de la lista serán
aceptadas, mientras que los que no están en la lista son rechazados.

2.1.82
red de área amplia WAN

Una red física o lógica que proporciona comunicaciones de datos a un número mayor de usuarios independientes que generalmente son atendidos por una
red LAN y que por lo general se extiende sobre un área geográfica más grande que la de una LAN.

2.2 Siglas

ACL lista de control de acceso

BCP plan de negocios continuo

DBMS sistema de administración de base de datos

DHCP protocolo de configuración huésped dinámico

DMZ zona desmilitarizada
DNA ácido desoxirribonucleico
DRP plan de recuperación en un desastre

DSOP política de operación de seguridad digital

FTP Protocolo de transferencia de archivos

ESCONDIDO sede de detección de intrusiones

HMI interfaz de máquina humana

ICMP Internet Control Message Protocol
IDPS detección de intrusiones y el sistema de prevención
IDS sistema de deteccion de intrusos
IETF Grupo de Trabajo de Ingeniería de Internet
IIS Servicios de Información de Internet
ESTOY Mensajería instantánea
IP protocolo de Internet
IPS Sistema de Prevención de Intrusión
IPsec seguridad IP
IPv6 Protocolo de Internet versión 6
IRP plan de respuesta a incidentes

RDSI red digital de servicios integrados

ISP proveedor de servicios de Internet

LAN Red de área local

 L2TP la capa dos (2) Protocolo de túnel
MIB base de información de gestión
NAS red de almacenamiento conectado

NFS sistema de archivos de red

NID detección de intrusiones de red

NIST Instituto Nacional de Estándares y Tecnología
NNTP protocolo de transferencia de noticias de la red

PBX cambio de marca privada

ordenador personal computadora personal
PCN la red de control de procesos
PHMSA Tuberías y materiales peligrosos Administración de Seguridad
SOCIEDAD ANÓNIMA Controlador lógico programable
PPP punto-a-punto protocolo
RAS servicios de acceso remoto
RSA un algoritmo de criptografía de clave pública, desarrollado por Rivest, Shamir y Adleman (apellidos)

RTU unidad terminal Remota

SAN red de área de almacenamiento

SCADA control de supervisión y Adquisición de Datos

SEIM Seguridad de la Información y Gestión de Eventos
SMTP Protocolo simple de transferencia de correo

SNMP Protocolo Simple de Manejo de Red

SSH cubierta segura
SSL Secure Sockets Layer
SUDO superusuario hacer

TCP / IP Protocolo de Control de Transmisión / Protocolo de Internet

TFTP trivial FTP
TIA Asociación de la Industria de Telecomunicaciones
UDP protocolo de datagrama de usuario

VoIP / IPT voz sobre IP / IP

VPN red privada virtual
VSAT terminales de muy pequeña apertura por satélite

PÁLIDO red de área amplia

WINS ventanas de servicio de nombres de Internet

3 Sistema de Gestión

El operador deberá desarrollar un sistema de programa de gestión de la seguridad SCADA con las políticas y procedimientos definidos que
complementa y trabaja con el plan de seguridad del oleoducto desarrollado bajo la dirección de las API Directrices de seguridad para la industria
del petróleo.

3.1 plan de seguridad

El operador deberá desarrollar un plan de seguridad que atienda a los elementos esenciales de las organizaciones políticas de seguridad
cibernética, prácticas y procedimientos, así como describir las características de seguridad física y cibernética están empleando para proteger un
activo en particular. El plan también incluirá una visión general de los requisitos de seguridad para los sistemas de control del operador y una
descripción de las medidas de seguridad establecidas o previstas para cumplir con esos requisitos. El operador puede aprovechar ejemplos de
planes de seguridad, como la que se encuentra en la API de Directrices de seguridad para la industria petrolera en el desarrollo de su plan específico
y en el anexo B de esta norma.

Página 17 de 73
18 S API ORMA 1164

3.2 Personal

El operador deberá desarrollar una política de comunicación de seguridad y la formación del personal que define las funciones y responsabilidades, y
esboza un programa de entrenamiento. Esto es para asegurar que los empleados y contratistas con acceso al sistema SCADA mantienen un alto nivel
de conciencia con respecto a los riesgos potenciales de seguridad y responsabilidades individuales.

Los empleados y contratistas deben:

• Tener una comprensión de la naturaleza de la información que están manejando,

• Sepa cómo proteger la información,

• Saber cómo clasificar correctamente la información,

• Saber cómo informar y responder a las amenazas potenciales.

El operador deberá desarrollar responsabilidades de trabajo para el personal clave, incluyendo los administradores de sistemas, coordinadores de seguridad,
personal de apoyo, SCADA y controladores. Cada empleado debe estar obligado a seguir estas responsabilidades de trabajo.

El operador deberá desarrollar un proceso para asegurar que el personal esté capacitado para gestionar el sistema SCADA, y han cumplido con los requisitos de
seguridad de la empresa específica.

3.3 Políticas de seguridad

El operador deberá desarrollar un conjunto de políticas de seguridad, ejecutados por un plan de seguridad, para garantizar operaciones seguras y confiables.

3.4 Riesgos y Evaluación de la vulnerabilidad

El operador deberá llevar a cabo evaluaciones de riesgo y vulnerabilidad periódicas. Este proceso ayuda a los esfuerzos de enfoque en mejorar la
seguridad del operador SCADA a las áreas de mayor riesgo y ayuda a garantizar operaciones seguras y protegidas en todo el ciclo de vida del sistema.

Realización de la evaluación cualitativa del riesgo y la vulnerabilidad debe ser realizada por un grupo de expertos con fondos mixtos tales como,
pero no limitado a SCADA especialista, especialista de la red, especialista en información sobre Tecnología, Operaciones y Mantenimiento y
Supervisión.

En la realización de estas evaluaciones el operador debe utilizar criterios coherentes y metodología de evaluación para determinar la criticidad de
componentes, así como la clasificación de riesgo, vulnerabilidad, y la consecuencia.

Como guía, ocupando la criticidad del sistema puede ser:

• Los activos que son esenciales para la seguridad y / o la fiabilidad de una instalación se clasifican como activos críticos.

• Los activos que no son esenciales para la seguridad y / o la fiabilidad de una instalación se clasifican como activos no críticos.

Llevar a cabo una evaluación de riesgos y la vulnerabilidad es un proceso que evalúa el riesgo, la vulnerabilidad, las garantías existentes, la amenaza, y las
consecuencias de los sistemas.

Este proceso de evaluación guía al operador en la determinación de la probabilidad de un evento mediante la evaluación de la vulnerabilidad del
sistema y las garantías existentes. Cuanto mayor es la probabilidad de un evento, y el más grave de los resultados de ese evento ocurriendo el mayor
será el riesgo. salvaguardias existentes incluyen cualquier cosa en
colocar a reducir las posibilidades de una vulnerabilidad de sistemas que están siendo explotados. Ejemplos de salvaguardias existentes podrían incluir el uso de un
cortafuegos corporativo, VPN, anti-virus, controles de seguridad física, y así sucesivamente.

La severidad del evento se determina mediante la evaluación de la amenaza y la combinación consecuencias. Los niveles más altos de amenaza combinada con
consecuencias más graves tendrán como resultado una clasificación mayor severidad.

Selección de la metodología de evaluación de riesgo de la organización derecha es subjetiva y se guía por sus políticas de operación y de las
infraestructuras de apoyo. Hay una serie de metodologías disponibles en el mercado, así como los enfoques desarrollados internamente, que
pueden ser aprovechados. Algunas organizaciones pueden encontrar que prefieren utilizar un método similar a lo que se hace para evaluar sus
riesgos de proceso. Independientemente del enfoque la metodología seleccionada y utilizada debe ser definida y documentada antes de iniciar la
evaluación de riesgos.

La figura 2, es un ejemplo de una metodología común que se utiliza dentro de la industria. Este enfoque combina la probabilidad de un evento con
la severidad del evento en una matriz de 5 por 5, como se muestra a continuación. En esta matriz, cada vulnerabilidad está clasificado para la
probabilidad de 1 a 5 siendo 1 no es probable y siendo muy probable 5. Del mismo modo, cada amenaza explotado por la vulnerabilidad podría ser
clasificado para la severidad con la que no severa como A y muy graves como E. La metodología debe definir / documento de los puntos de ruptura
entre los diferentes niveles. Las clasificaciones probabilidad y la gravedad resultantes se colocan en la celda apropiada. La colocación evaluación
identifica el nivel de riesgo empresarial. Sobre la base de las expectativas razonables de respuesta de nivel de riesgo asignado se definen
entonces. Como ejemplo,

Matriz de riesgo

5
PROBABILIDAD II II III IV IV

4 yo II III III IV

3 yo II II III III

2 yo yo II II II

1 yo yo yo yo II

Probabilidad UN segundo do re mi
X
Severidad
= GRAVEDAD
Riesgo

Figura 2-Matriz de Riesgos Ejemplo

Riesgo = Probabilidad X Severidad

Riesgo = vulnerabilidad ( debilidad) - salvaguardas existentes

Gravedad = Amenaza ( Qué podría pasar) X Consecuencia ( ¿y si fue así)

Página 19 de 73
20 S API ORMA 1164

Si bien esta es una metodología en uso dentro de la industria, las referencias y las directrices externas adicionales también están disponibles para
su uso en la realización de estas evaluaciones. El propietario debe evaluar qué metodología se adapte a su organización, documentan su enfoque,
capacitar al personal sobre cómo aplicar la metodología, y aplicar sistemáticamente la metodología.

3.5 nuevo o de reemplazo Diseño de seguridad del sistema

Durante el diseño de un valor nuevo o de reemplazo cibernético sistema SCADA deben ser incluidos en las fases iniciales especificación, diseño y
pruebas. Durante cada una de las fases de todos los aspectos de esta norma se deben tomar en consideración y se aplican según sea necesario.

3.6 Plan de Continuidad de Negocio (BCP)

A BCP facilita la preparación para la interrupción y la capacidad de operar a través de o recuperarse de un evento no deseado. Un BCP es parte del
plan de seguridad y abarca personas, procesos y tecnología. “La gente” incluye la consideración de las acciones requeridas por el personal clave
durante una crisis (respuesta) y después (recuperación). “Procesos” son operaciones críticas que deben ser restaurados para garantizar la
continuidad y seguridad del negocio. áreas “Tecnología” que soportan esos procesos críticos y fomentar la respuesta y la fase de recuperación
también deben ser considerados. continuidad de negocio y planes de recuperación deben ser considerados como parte de las consideraciones de
disponibilidad del sistema.

El operador deberá establecer un BCP para hacer frente a las interrupciones previsibles al sistema SCADA, en particular los relacionados con las
instalaciones de control de tubería. El BCP debe contener los objetivos de recuperación documentados que identifica como necesaria la gestión del
operador para mantener la operación segura de los activos de tuberías. Los planes deben ser incluidos en el BCP para abordar todos los elementos
necesarios para alcanzar los objetivos de recuperación. Los sistemas críticos de copia de seguridad y procedimientos de restauración se ponen en marcha
para apoyar el BCP.

BCP del operador debe documentar las funciones y responsabilidades de un equipo de recuperación de BCP. El equipo debe contener todo el
personal necesario para implementar con éxito el BCP. El equipo debe probar, practicar y perfeccionar el proceso de recuperación BCP a intervalos
periódicos especificados.

Un BCP debe permitir un funcionamiento continuo y seguro de todos los activos de tuberías del operador. Debido a los muchos riesgos potenciales para
instalaciones de control individuales, BCP del operador incluirá un centro de control de copia de seguridad capaz de garantizar el funcionamiento seguro y
fiable de todos los activos de tuberías en todo caso, que hace que la instalación de control primario inoperable o inhabitable. El control de acceso también
debe ser considerado cuando se prepara para, durante y después de una interrupción.

Elementos de un BCP incluyen un plan de recuperación de desastres (DRP). A DRP incluye e identifica las características y funciones esenciales, incluyendo,
pero no limitado a:

• almacenamiento de datos de copia de seguridad y restauración;

• Las listas de contactos para entidades como en el personal de atención telefónica, vendedores, proveedores de servicios y personal de emergencia;

• servicios de mantenimiento de las instalaciones y servicios de catering;

• Personal;

• Las licencias de software;

• hardware específico como plataformas de ordenador, dispositivos de red, impresoras, máquinas de fax y equipos de telecomunicaciones;
• medios de instalación de software específicos e instrucciones que apoyan las necesidades para el funcionamiento de los sistemas y soporte de las aplicaciones de
software;

• proveedores de servicios de telecomunicaciones, voz y datos;

• proveedores de terceros.

3.7 Plan de Respuesta a Incidentes (IRP)

El operador debe establecer un IRP para identificar y documentar los procedimientos que se utilizan para detectar, responder y minimizar el impacto
de un incidente de seguridad cibernética. Este plan debe tener participación y aprobación de la gestión del operador, así como todos los equipos
funcionales susceptibles de ser afectados por o tienen responsabilidades para responder a un incidente de seguridad cibernética. El plan debe abordar
todos los aspectos de las fases de planificación, respuesta y recuperación del incidente. Debe incluir una lista de todas las funciones y
responsabilidades pertinentes, así como los nombres específicos e información de contacto para los miembros del equipo de respuesta a incidentes.

Un programa de entrenamiento debe ser establecida para todo el personal con responsabilidades asociadas con el IRP. La prueba periódica adecuada y
la evaluación del IRP deben ser implementados para asegurar una pronta respuesta, coherente y documentada a los incidentes de seguridad
cibernética.

3,8 de inventario de activos / Categorización / Seguimiento

El operador deberá desarrollar y mantener un inventario de los componentes del sistema SCADA. El tipo de información incluida para cada
componente podría incluir la criticidad de componentes, especificaciones de hardware (fabricante, tipo, modelo, número de serie, la ubicación
física), la información de licencia de software, propietario componente del sistema de información, nombre de la máquina, y la dirección de red. El
inventario debe ser actualizado como componentes instalados, eliminados, y actualizados. Las máquinas virtuales pueden ser difíciles de controlar
porque no son visibles a la red cuando no esté en uso. El operador debe mantener lo más al día, completa y precisa un inventario de lo razonable.
El operador debe tener la capacidad de detectar cualquier componente no autorizados en el entorno SCADA y acceso a la red de alerta y / o
inhabilitar a los componentes no autorizadas

Cada operador deberá desarrollar un procedimiento para determinar los componentes del sistema de criticidad. Normalmente, esto se puede hacer mediante la realización
de una evaluación de riesgos en el componente. Consulte la Sección 3.4, Riesgo y Evaluación de la vulnerabilidad, para obtener detalles adicionales.

3.9 Gestión del Cambio

los procesos de gestión del cambio definen las políticas y procedimientos específicos para la gestión de los cambios en la instalación, configuración
y mantenimiento de todos los componentes del sistema SCADA. Estos sistemas incluyen, pero no se limitan a, los anfitriones SCADA, servidores
historiador, controlador lógico programable unidad / remoto terminal (PLC / RTU) y otros dispositivos de campo, interfaz hombre-máquina (HMI)
estaciones de trabajo, servidores de autenticación y gestión de red / vigilancia, y dispositivos de infraestructura de red (routers, switches y firewalls),
y sus sistemas operativos y software asociados. El operador deberá desarrollar y comunicar un plan de gestión del cambio para gestionar los
cambios dentro del sistema SCADA. El plan debe establecer claramente los objetivos del operador en la gestión del cambio para asegurar la
disponibilidad, integridad y confidencialidad del sistema SCADA.

El plan de gestión del cambio debe establecer un estándar de configuración de línea de base para todos los componentes del sistema SCADA. La
configuración de la línea de base debe documentar toda la información relacionada con el componente de sistema SCADA a un nivel de especificidad
que permita al componente que se recrea en el período de tiempo

Página 21 de 73
22 S API ORMA 1164

especificada en el BCP del operador. Esta configuración de línea de base debe ser documentado y actualizado con cada cambio de sistema SCADA
aprobado.

El plan de gestión del cambio debe establecer la separación de funciones para evitar conflictos de intereses. Es decir, el personal que revisar y
aprobar el cambio no son los mismos que los que implementan el cambio. Además, el plan debe describir la necesidad de una revisión técnica
exhaustiva del cambio propuesto antes de su aprobación por una persona con conocimientos técnicos. El plan también debe definir cómo una
revisión técnica secundaria se llevará a cabo antes de la aplicación final.

Cualquier cambio planificado a la configuración de la línea de base debe incluir procedimientos de “retroceso” detallada “back-out” o para recuperar la
línea de base si la ejecución se encuentra con el cambio impactos o fallos inesperados. Siempre que sea posible, todos los cambios en el sistema
SCADA planificadas deben ser implementadas y evaluadas en un entorno de desarrollo o banco de pruebas antes de su implementación en el
entorno de producción.

El plan de gestión del cambio debe definir las políticas y procedimientos que se utilizarán para planificar, comunicar, documentar, aprobar, ejecutar
y revisar todos los cambios a la línea base del sistema SCADA. Las políticas y procedimientos deben especificar claramente las funciones y
responsabilidades de todo el personal implicado, así como la forma de la documentación y la comunicación que se va a utilizar en la gestión del
cambio. Estas políticas y procedimientos deben ser diseñados para abordar de manera realista la salud, la seguridad del operador, y los requisitos
de seguridad, las limitaciones de personal y de recursos, y los requisitos operativos del negocio. Los procedimientos deben ser cuidadosamente a
escala para reflejar el riesgo en relación con el sistema SCADA representado por cada cambio propuesto a la configuración de la línea de base.

El plan de gestión del cambio debe indicar claramente las limitaciones de tiempo que deben seguirse debido al nivel de riesgo identificado y en
plena alineación con las políticas del operador.

3.10 del sistema operativo y actualizaciones de aplicaciones

redes SCADA están diseñados principalmente para soportar sistemas de control patentados que utilizan protocolos eficientes con los requisitos de
ancho de banda bajo y la tolerancia limitada para retardos de transmisión. Dado que estas redes se dispersan en amplias zonas geográficas, con
conexiones históricamente caros red de área amplia (WAN), que a menudo han sido diseñados con las especificaciones mínimas de ancho de
banda. Por esta razón, la adición a la red SCADA de protocolos adicionales, aplicaciones, o comunicar paquetes de software será abordada con
gran cuidado para preservar intacta la disponibilidad del sistema SCADA.

• Sin protocolos adicionales, aplicaciones o software, debe añadirse a las redes SCADA que no son esenciales para la operación de
gasoductos o para el mantenimiento de la infraestructura de red SCADA.

• servicios de software de negocio y de información comercial, tales como acceso a Internet, correo electrónico o de mensajería instantánea no
deben ser puestos a disposición en la red SCADA.

• de eventos del sistema o notificaciones de alarma que utilizan aplicaciones de tipo de correo electrónico se aplica sólo de salida con la seguridad adecuada.

• Ningún software o aplicación, debe añadirse a la red SCADA que podría crear una responsabilidad sin control por infracción de derechos de
autor o contenido ofensivo definido legalmente.

• Cualquier nuevo protocolo, aplicación o software que se propone agregar a la red SCADA deben ejecutarse en un entorno de banco de
pruebas o desarrollo para evaluar el potencial de alterar el rendimiento del sistema SCADA, en particular con respecto a los requisitos de
ancho de banda, ya que los servidores modernos y paquetes de software pueden consumir fácilmente la capacidad de WAN a expensas de
tráfico SCADA crítico.
Vulnerabilidades identificadas durante la evaluación de riesgos y la vulnerabilidad, la referencia de la sección 3.4, y deben ser mitigados. Esas vulnerabilidades de
mayor riesgo deben tener la más alta prioridad para la mitigación. contramedidas para mitigar vulnerabilidades incluyen el endurecimiento del sistema, aplicación de
parches y actualizaciones de software, y la disposición adecuada de los equipos y medios de comunicación.

3.10.1 Sistema de endurecimiento

El operador debe establecer procedimientos para endurecer todos los componentes utilizados en el sistema SCADA. El operador debe tener en cuenta los
siguientes elementos de endurecimiento del sistema:

• configuraciones seguras para todos los dispositivos de red como firewalls, routers y switches deben ser desarrollados y utilizados para establecer
la configuración de línea de base para estos dispositivos. Estas configuraciones deben ser revisados ​periódicamente, al menos una vez cada 15
meses.

• la configuración del sistema de base que incluya servicios y puertos debe ser desarrollado y revisado periódicamente para asegurar que no se
han hecho cambios no autorizados.

• Una configuración de la línea de base del tráfico de red y servicios en ejecución debe ser desarrollado y revisado periódicamente para asegurar que
no se han producido cambios no autorizados.

• servicios del sistema operativo que no se utilizan por el sistema SCADA producción deben ser retirados o desactivada para reducir el riesgo de ser
utilizado como un mecanismo de ataque. Los servicios pueden estar en ejecución por defecto cuando el sistema operativo está instalado en el
servidor, pero no utilizado por el sistema SCADA. Estos servicios deben ser desactivados para evitar su uso en la apropiada. Otros servicios deben
ser analizados mediante una evaluación de riesgos para determinar si los beneficios de tener funcionando superan el potencial de explotación.

• Los protocolos de red habilitados en todos los dispositivos conectados en red deben ser revisados ​y protocolos no esenciales deben ser
desactivados. Por ejemplo, el protocolo IPv6 debe ser desactivada si la red no está habilitado para IPv6.

• Todas las aplicaciones necesarias y puertos abiertos tanto para el funcionamiento normal y el funcionamiento de emergencia deben estar documentados. Todos los puertos que
no se utilicen deben ser desactivados.

• Las funciones de control remoto que un sistema operativo proporciona sólo deben utilizarse cuando se deben utilizar versiones necesarias y sólo
seguras.

• El uso de FTP en los sistemas SCADA debe ser desalentado y estrictamente controlada. Una forma segura de FTP debe ser considerado.

• Debería considerarse la posibilidad de inhabilitar o proteger los dispositivos extraíbles de medios de comunicación (puertos USB, unidad de CD / DVD y otros
dispositivos de medios extraíbles) ya que estos dispositivos pueden ser una vía para eludir otras medidas de seguridad tales como cortafuegos de otro modo.

• Todas las cuentas de invitados deben eliminarse

• Todas las contraseñas por defecto deberían ser modificados.

• dispositivos no endurecidos no deben ser permitidos en la red.

• Las técnicas de codificación seguras deben ser utilizados en el desarrollo de aplicaciones. Las prácticas deben incluir, pero no limitarse a la
prevención de desbordamientos de búfer, inyección SQL, cross-site scripting y otras vías de inyección de código malicioso.

• El acceso administrativo a todos los sistemas SCADA debe ser estrictamente controlado.

Página 23 de 73
24 S API ORMA 1164

• Las cuentas administrativas deben tener contraseñas seguras.

• Todo el código fuente debe estar asegurado para evitar tanto su visualización y modificación no autorizada.

• Las contraseñas deben cambiarse periódicamente sobre la base de la política de la empresa y siempre que dictan los cambios de personal.

3.10.2 parches de software y actualizaciones

Debido a la complejidad del sistema, sistemas operativos y software de aplicación no son inherentemente seguro. Además, la constante evolución del
entorno de computación y redes revela continuamente nuevas vulnerabilidades. Para hacer frente a este problema, los fabricantes publican revisiones,
service packs y actualizaciones de la aplicación. A menudo es necesario aplicar correcciones y actualizaciones de software calientes para mantener la
estabilidad y la seguridad del sistema, pero el riesgo de la aplicación de parches y actualizaciones a los sistemas en tiempo real siempre debe
sopesarse con el riesgo planteado por las actuales vulnerabilidades. El operador debe desarrollar políticas y procedimientos para la gestión de los
parches y actualizaciones de software, el software anti-virus y anti-malware.

preocupaciones de seguridad operacional y SCADA requieren que se tomen ciertas precauciones al aplicar modificaciones de software:

• El operador debe aplicar todo proveedor esencial del sistema SCADA aprobado actualizaciones del sistema operativo;

• Cualquier actualización debe ser certificada por el proveedor SCADA antes de ser aplicada al sistema SCADA;

• Las actualizaciones deben ser analizados para la aplicabilidad en cada entorno;

• El operador debe garantizar que la seguridad de aplicaciones y base de datos críticos parches se aplican de acuerdo con las
recomendaciones del proveedor del sistema SCADA;

• Actualizaciones nunca deben ser aplicados directamente a través de Internet;

• Un entorno de prueba fuera de línea debe ser utilizado para probar las actualizaciones antes de aplicarse a un entorno de producción;

• pruebas de funcionalidad aplicable debe realizarse antes de sistema modificado compilaciones son movido en entornos de producción;

• Una vez que las modificaciones del sistema se completa, una lista de verificación de cumplimiento de seguridad debe ser revisada para asegurar que el sistema SCADA
sigue cumpliendo con las políticas de seguridad del operador;

• Anti-virus, anti-malware y otro software de protección deben ser utilizadas y actualizan de acuerdo con las recomendaciones del proveedor
del sistema SCADA;

• El operador debe inventario de forma periódica el nivel de parches de software de todos los sistemas de la red para estar al tanto de los sistemas sin
parches.

A los efectos de este documento, los operadores que desarrollan y mantienen los sistemas SCADA en el local se consideran un proveedor SCADA.
Estos procedimientos deben realizarse de acuerdo con el plan de gestión del cambio del operador.

3.10.3 Eliminación adecuada de los equipos y medios de comunicación.

La información contenida en o en equipos y medios de comunicación SCADA de un operador podría ser utilizado para desarrollar vectores de ataque contra el sistema
SCADA. Un eliminan de manera inadecuada dispositivo puede contener una gran cantidad de útiles
información. El operador debe establecer políticas y procedimientos para la eliminación adecuada y segura de los equipos y medios de comunicación
asociados.

Las políticas y procedimientos deben incluir la desinfección de la información, tanto digitales y no digitales, antes de su eliminación o liberación para su
reutilización. De desinfección es el proceso utilizado para eliminar la información de los medios de comunicación del sistema cibernético de tal manera que hay
una seguridad razonable, en proporción a la confidencialidad de la información, que la información no puede ser recuperada o reconstruido.

3.11 Contratación

El operador deberá desarrollar e implementar las normas de adquisición del sistema SCADA, que los sistemas posibles, componentes y servicios
se evalúan. Las normas de adquisición deben incluir detalles relativos a:

• Administración de cuentas

• codificación de las prácticas

• La detección de malware y Protección

• Incorporación de medidas de seguridad cibernética y controles en el diseño del sistema y operación, así como las modificaciones del sistema y
los cambios.

• Definir las funciones y responsabilidades de supervisión y de los usuarios con respecto a los servicios de sistema de información externo

Los operadores también deben desarrollar políticas y procedimientos de compra, por el sistema SCADA proveedores externos que tienen un impacto en
la seguridad del sistema, lo que les mantiene a las mismas políticas y procedimientos de seguridad que la organización interna para mantener el nivel
general de seguridad SCADA. En adición:

• Los contratos con proveedores externos deben definir claramente los requisitos para la física, así como el acceso lógico

• acuerdos de confidencialidad deben indicar claramente todos los requisitos intelectuales

• Identificar claramente los procedimientos de gestión de cambios

4 Seguridad física

Los operadores de la infraestructura crítica de transporte deberán tomar medidas y controles para impedir que cualquier persona no autorizada acceda
a las instalaciones de controlar. Algunas de las medidas de seguridad física buena sala de control se describen en las siguientes secciones. Para más
información, por favor refiérase a la Guía de seguridad de API para la industria petrolera.

El operador debe tener requiere inicio de sesión y una identificación con foto de todos los contratistas, proveedores y visitantes de propiedad de la compañía. El operador
también debe restringir el acceso de los contratistas, proveedores y visitantes en instalaciones esenciales y las actividades de los visitantes mientras se encuentran en o
alrededor de las instalaciones críticas.

El operador deberá desarrollar y mantener una política de seguridad y los procedimientos asociados que requieren todo el personal con acceso a las
instalaciones SCADA para someterse a revisiones de seguridad periódicas.

El operador deberá desarrollar y mantener un plan de seguridad para los servicios públicos controlados por el operador que irrigan el funcionamiento del
centro de control. Estas utilidades incluyen, pero no se limitan a, sistemas de distribución de potencia, fuentes de alimentación ininterrumpida (UPS), y equipo
de generación de energía.

Página 25 de 73
26 S API ORMA 1164

El operador deberá desarrollar y mantener un plan de seguridad para todas las infraestructuras de red SCADA controlados por el operador. El
operador debe asegurar el acceso a todos los puertos de red y computación y desactivar los puertos no utilizados.

El operador deberá realizar una evaluación de riesgos de todos los establecimientos controlados por el operador donde reside el equipo SCADA y deberá
desarrollar un proceso para controlar el acceso a ese equipo. El operador debe considerar la instalación de detección de intrusos en sitios no tripulados tales
como sitios de válvulas, estación de bombeo, instalaciones de medición, etc. El personal no autorizado será conducido por personal autorizado cuando se
accede a las instalaciones SCADA.

5 Sistema de Control de Acceso

5.1 Acceso Restringido

Control de acceso mediante la autenticación es el método más eficaz de los usuarios identificando positivamente red, host, aplicaciones, servicios y recursos
que utilizan la autenticación fuerte multifactorial. el acceso de múltiples capas y autenticación de múltiples factores tienen una mayor probabilidad de prevenir
comprometer el sistema de un único sistema de capas. En un sistema de múltiples capas, el fracaso de una capa no pone en peligro todo el sistema porque
cada uno funciones de la capa de forma independiente. El uso de una defensa en el sistema de seguridad de múltiples capas de profundidad puede reducir en
gran medida la probabilidad de un compromiso del sistema.

será necesario el acceso mediante la autenticación fuerte de múltiples capas en la capa DMZ, a veces se define como red de proceso de
información (PIN). Sesiones que acceden al sistema, se pondrá fin después de un período de inactividad.

5.2 Lógica de control de acceso a los sistemas de control y redes de control

El acceso al sistema de control de redes externas a menudo se requiere para un respaldo. Este acceso estará estrictamente controlado y el uso de la
autenticación de múltiples capas se utilizará en todo momento. Esto debe llevarse a cabo mediante el uso de VPN y autenticación de múltiples
factores con el uso de un token. El acceso remoto por personal autorizado debe producirse mediante la conexión a la LAN empresarial con
credenciales-corporativos emitidos, a continuación, se conecta al SCADA dispositivos de seguridad con las credenciales SCADA y un token
perímetro.

Otros controles de acceso lógico que deben ser considerados incluyen:

• Restricción de conectividad remota de terceros a través del uso de controles avanzados tales como restringir las conexiones a trabajar horas y
límites sobre los mecanismos para mover archivos.

• El acceso se concede por la longitud de tiempo para realizar el trabajo requerido, pero ya no se

• El acceso al sistema de control requiere un método de autenticación diferente, tal como una llave de control, tipo de tarjetas con una contraseña única, y así
sucesivamente.

5.3 Cuentas de usuario

sistemas SCADA tienen típicamente dos capas de cuentas de usuario; la capa del sistema operativo, y una capa de aplicación, de los derechos específicos de usuario
dentro de la aplicación SCADA. los derechos específicos de los usuarios deben basarse en las tareas asignadas y en lo posible los derechos de control de acceso se
basa en una clara segregación entre las clasificaciones de trabajo, las responsabilidades del trabajo y las necesidades de control de acceso. Se debe mantener una
lista de control de acceso (ACL) a cualquiera de las capas. Una razón de negocios válida debe existir antes de que las personas que dan acceso al sistema SCADA o
recursos. Las cuentas deben ser implementadas de manera que el acceso a datos se limita únicamente a los datos requeridos por el usuario y por el período de tiempo
específico cuando se requiere el acceso. Los usuarios deben estar provistos de concienciación sobre la seguridad básica del sistema y la formación antes de conceder
la autorización de acceso.

Todos los usuarios deberán tener cuentas de inicio de sesión y contraseñas individuales. Deben iniciar sesión se lleva a cabo cada trabajo a tiempo parcial y cierre de sesión
después de la finalización de la obra.
5.4 Las cuentas del sistema operativo

El acceso al sistema operativo “administrador de sistemas” o cuenta de “supervisor” administrador es el más alto nivel de acceso de seguridad que permite el control total
del sistema de ancho de una estación de trabajo. Cualquier archivo o dispositivo en una estación de trabajo pueden ser modificados o eliminados. El acceso a la cuenta de
administrador de sistemas debe ser estrictamente controlado. Se recomienda que la mayoría del trabajo de aplicación debe hacerse utilizando una cuenta de acceso de
seguridad más bajo que no tiene los privilegios completos del sistema de cambio de ancho. Sólo las personas que requieren las capacidades de que la cuenta de
administrador de sistemas proporciona debe dar acceso. En algunos sistemas operativos, el uso de una herramienta como superusuario hacer (SUDO) puede
proporcionar algunas de las funcionalidades de la cuenta de administrador de sistemas (raíz) y sin privilegios del sistema completo. Otros sistemas operativos tienen
herramientas similares para proporcionar una funcionalidad similar.

consolas de operación SCADA pueden permanecer conectado en todo momento para controlar adecuadamente la operación de gasoductos. El uso del
sistema operativo compartido da cuenta de las consolas de control que se utilizan las 24 horas del día / siete (7) días a la semana es aceptable. Estas
consolas están generalmente protegidos por los requisitos de seguridad físicas definidas por PHMSA y son atendidos las 24 horas del día / siete (7) días a la
semana. El uso de estas cuentas de usuario compartidas debe revisarse periódicamente y se limita a operaciones de la consola específicos.

vendedores SCADA a veces utilizan o crean cuentas del sistema operativo para que puedan controlar y mantener el sistema SCADA. Estas cuentas
pueden proporcionar un fácil acceso a los intrusos. Todas las cuentas del sistema operativo estarán firmemente fijados y utilizan contraseñas y / o
biometría fuertes.

Algunos sistemas operativos y / o aplicaciones usan cuentas internas. Estas cuentas generalmente tienen acceso considerable al sistema
operativo. Estas cuentas deben ser revisados ​para asegurar niveles adecuados de seguridad están en su lugar para evitar que usuarios no
autorizados puedan utilizar estas cuentas.

5.5 Cuentas SCADA

Todos los usuarios de una aplicación de sistema SCADA deben tener una cuenta única que requiere una contraseña o métodos biométricos para acceder al
sistema. cuentas únicas ayudan a realizar un seguimiento de la actividad inusual en un sistema.

Algunos operadores no utilizan cuentas individuales de cada operador debido al potencial riesgo operacional. Los operadores deben tratar de emplear procesos
que minimicen los riesgos operacionales, mientras que el estudio de procedimientos de inicio de sesión del operador alternativas que podrían mejorar la seguridad
del sistema. Todas las cuentas de SCADA no deberían usar la consola seguridad mejorada.

El uso de temporizadores de inactividad para las estaciones de trabajo / ordenadores personales (PC) que no se utilizan con fines de explotación debe ser considerado.
Estos temporizadores deben cerrar la sesión en los usuarios que pueden haber dejado su terminal para más de un período de tiempo especificado.

5.6 Controles de contraseña

Normas para las contraseñas deben ser definidos en una política de operación de seguridad digital (BDP) que se aplica directores para la selección, la protección y la
caducidad de las contraseñas. Un esquema de contraseña segura es la piedra angular de un buen sistema de seguridad. Algunos atributos de un esquema de
contraseña segura incluyen:

- períodos de expiración;

- requisitos de longitud mínima para las contraseñas;

- prohibir la reutilización de contraseñas, el uso de palabras comunes, el uso de patrones numéricos o alfa;

- requisito de que las contraseñas entre mayúsculas y minúsculas;

- bloqueo después de un cierto número de intentos fallidos;

- sustitución de contraseñas por defecto y la cuenta inicial de inicio de sesión inicial.

Página 27 de 73
28 S API ORMA 1164

Todos los sistemas / equipos debe implementar ya que muchas de estas características como sea posible. Los sistemas informáticos proporcionan muchas
herramientas y técnicas para simplificar las actividades del día a día, incluyendo los archivos de secuencia de comandos, alias y accesos directos. Se debe tener
cuidado para asegurar que las contraseñas no están integrados en estas herramientas, ya que los intrusos pueden leer estos archivos y el uso de las contraseñas
para manipular el sistema. código fuente SCADA también puede tener contraseñas codificadas duro. La política de seguridad SCADA debe desalentar / prohibir la
incorporación de contraseñas sensibles en el código fuente, los guiones, los alias y accesos directos. Si es necesario, se deben utilizar técnicas de cifrado. Todo el
código fuente también debe asegurarse para minimizar el acceso de otros usuarios a las contraseñas incrustadas. Las contraseñas deben ser introducidos por el
usuario en cada inicio de sesión en lugar de almacenarse durante inicio de sesión automático.

El administrador debe proporcionar un servicio para expedir, modificar o restablecer una contraseña si así lo solicita un usuario autorizado. Si una
contraseña ha sido olvidada, el administrador debe seguir la contraseña restablecer los principios de la DSOP para restablecer la contraseña de usuario.

Autenticación 5,7 de múltiples factores

autenticación de múltiples factores (a veces referido como la autenticación de dos factores) es un aumento a la / combinación nombre de usuario
común contraseña, que añade una capa de seguridad que requiera al menos dos factores diferentes (de conocimiento, posesión o inherencia).

- El conocimiento es algo que sólo el usuario conoce, como una contraseña, PIN o patrón.

- Posesión de ser algo que sólo el usuario tiene físicamente, como un teléfono móvil, aplicación para teléfonos inteligentes, tarjetas inteligentes, o ficha /
key-fob.

- Inherencia ser algo que sólo es el usuario, tales como la biometría - una huella dactilar, palma, o de los ojos.

La correcta aplicación de al menos dos de éstos puede reducir en gran medida la superficie de ataque, como autores ya no pueden acceder con las
credenciales simplemente hackeados o robados. Es importante tener en cuenta que los factores utilizados deben ser independientes el uno del otro a tener
en cuenta múltiples factores de autenticación “verdadero”. Por ejemplo, preguntar a un usuario para múltiples códigos de un token no se consideraría una
solución de múltiples factores, ya que es sólo con un único factor (token) varias veces.

autenticación de múltiples factores se utiliza a menudo en el perímetro de la red, como una capa de protección para aquellos que acceden a cosas
como el correo web, entornos virtuales, redes privadas virtuales, portales web seguros, etc. Otro lugar en el que su implementación se debe
considerar es que el acceso a la red SCADA (s).

Hay una serie de proveedores que respaldan muchos de los diferentes tipos de factores de autenticación. Pueden variar desde tan simple como un código de
una sola vez enviado como mensaje de texto oa través de una llamada telefónica, a tan sofisticado como los sistemas biométricos complejas que exploran los
patrones únicos para cada individuo. No importa lo que la tecnología o que el proveedor, se debe dar consideraciones cuidadosas para asegurar el ajuste
correcto de la tecnología, facilidad de uso y seguridad para cada entorno.

5.8 Biometría

La biometría es la aplicación de la utilización de atributos humanos reconocidos en base únicamente a base de uno o más intrínsecas rasgos físicos o de
comportamiento para obtener acceso a sitios seguros, información o aplicaciones. Algunos ejemplos de los datos biométricos incluyen:

- fisiológica-cara, huellas dactilares, geometría de la mano, iris, ácido desoxirribonucleico (ADN);

- conductual-golpe de teclado, la firma, la voz.

Hay varias razones para usar biometría dentro de la red SCADA y control de procesos (PCN) sistemas tales como:
- la identificación positiva de un individuo específico,

- conveniencia sin tarjeta de identificación o contraseña o token de seguridad dispositivo para llevar a todas partes.

La biometría puede ser una valiosa segunda entrada donde la autenticación de múltiples tiene sentido y es compatible con la defensa en los conceptos de
profundidad. técnicas de biometría como el reconocimiento de una huella podrían aplicarse en lugar de la cuenta de usuario / contraseña controles de acceso.

La biometría contribuye a la seguridad cibernética cuando se aplica correctamente, pero los controles biométricos no son infalibles; que pueden verse
comprometidos. La investigación ha demostrado que la huella dactilar, el iris y escáner de retina todos tienen una alta probabilidad de elusión. La biometría es una
tecnología emergente. Estrategia de ejecución, las tasas de error de cruce, la disponibilidad de la plataforma deben ser considerados antes de su uso.

5.9 Los servicios requeridos para no discapacitados

servicios del sistema operativo que no se utilizan por el sistema SCADA producción deben ser retirados o desactivada para reducir el riesgo de ser
utilizado como un mecanismo de ataque. Esto se conoce como endurecimiento del sistema. Los servicios pueden estar en ejecución por defecto cuando
el sistema operativo está instalado en el servidor, pero no utilizado por el sistema SCADA. Estos servicios deben ser desactivados para evitar su uso en
la apropiada. Otros servicios deben ser analizados mediante una evaluación de riesgos para determinar si los beneficios de tener funcionando superan el
potencial de explotación. Los ejemplos de los servicios del sistema operativo, que son discapacitados comúnmente son:

- actualizaciones automáticas,

- protocolo de configuración dinámica de host (DHCP),

- sistema de archivos distribuido,

- cliente DNS,

- protocolo de transferencia de archivos (FTP),

- Servicio de administración de IIS,

- servicio de indexación,

- mensajería instantánea (IM),

- sistema de archivos de red (NFS),

- protocolo de transferencia de noticias de servicio de red (NNTP),

- remsh,

- rexec,

- protocolo simple de transferencia de correo (SMTP),

- telnet,

- ventanas de servicio de nombres de Internet (WINS),

- en todo el mundo servicio de publicación web.

Página 29 de 73
30 S API ORMA 1164

Los componentes del sistema SCADA deben ser endurecidos en conformidad con las directrices del vendedor en el nivel de red, plataforma de servidor y de
aplicación. Si el asesoramiento específico del vendedor no es violado, las siguientes actividades de endurecimiento deben utilizarse:

- Sólo los puertos USB necesarios para casos de emergencia (por ejemplo, que se utiliza para la continuidad del negocio [véase 8.3]) y periféricos críticos
(por ejemplo, teclado y ratón) se debe dejar habilitado.

- Otros controladores USB cuyos puertos son susceptibles de ser utilizados por los lápices de memoria debe estar desactivado.

- SFTP, o similares, se deben utilizar para facilitar la transferencia segura de datos, en caso necesario.

- dispositivos de memoria externos o discos serán analizados en busca de virus antes de exponerlos al sistema de automatización.

- El uso de tarjetas de memoria personal o no designado no debe ser permitido

- de inicio de sesión de autos debe ser desactivado para el sistema operativo y el software de aplicación en áreas normalmente no tripulados.

- Una contraseña del BIOS se debe establecer.

- El BIOS debe estar configurado para permitir el arranque sólo desde la unidad C.

- puertos de red del sistema de automatización no utilizados deben estar atado a una VLAN maniquí o discapacitados.

5.10 Herramientas del sistema operativo

La cáscara remoto, acceso remoto, y las funciones de copia remota de ciertos sistemas operativos permiten conexiones “de confianza” entre estaciones de
trabajo. Si esta funcionalidad está disponible, una persona que ha iniciado sesión correctamente a una estación de trabajo puede tener acceso a todas las
otras estaciones de trabajo en la red. Las funciones de control remoto que un sistema operativo proporciona sólo deben usarse cuando sea necesario. Esta
funcionalidad debe ser desactivada para la mayoría de usuarios. En los casos donde se requieren funciones de control remoto, el uso de herramientas
inseguras como Telnet debe ser evitado y herramientas seguras como “Secure Shell” (SSH) puede mejorar la seguridad de estas funciones.

Debido a que el acceso remoto presenta la vulnerabilidad a la intrusión no autorizada y el malware, el software anti-virus debe ser instalado y
mantenido hasta la fecha, así como parches del sistema operativo.

FTP permite que los archivos a ser enviados o recibidos en una estación de trabajo / PC. Sin seguridad adecuada, un intruso podría utilizar esta herramienta para instalar
programas que les permiten tomar el control de una estación de trabajo / PC. El uso de FTP en un sistema SCADA debe ser estrictamente controlado. La cuenta de
administrador de sistemas no debe concederse capacidad de FTP. En los casos donde se requieren las funciones FTP, el uso de herramientas de seguridad puede
mejorar la seguridad de estas funciones.

El acceso a cualquier función SCADA en un entorno de sistema operativo se proporciona típicamente a través de una concha o ventana. Además de la
función prevista, una concha o ventana se pueden utilizar como un punto de acceso en el resto del sistema SCADA. El uso de una herramienta de shell
o ventana garantizado y buen diseño cuenta limitará el acceso a otras partes del sistema.

Acceso 5,11 Device

Hay muchos dispositivos de una red, además de estaciones de trabajo y ordenadores personales, tales como conmutadores de red, routers, firewalls y servidores
de terminales. En el campo, esto también puede incluir transmisores, PLC, computadores de flujo, etc. Muchos de estos dispositivos tienen contraseñas por defecto
de fábrica o contraseñas nulas. Estos dispositivos también pueden ser manipulados por los intrusos para obtener acceso a un sistema SCADA. Los dispositivos que
tienen la capacidad deben estar
asegurado con una contraseña segura y no utilizará la contraseña predeterminada proporcionada por el vendedor. Cambio de la ID o cuenta de algo
diferente de incumplimiento por parte del proveedor para estos dispositivos también debe ser considerado.

Administración de Personal 5.12

Si bien este tema se trata en la sección de sistema de gestión, es importante reiterar que, como parte de un plan de seguridad, existen políticas
que requieren revisión de cuentas en un sistema SCADA y / o el dispositivo deben ser revisados ​y auditados de forma regular. Del mismo modo,
también deben existir políticas que requieren que los empleados o contratistas que salen a abordar de inmediato.

6 Distribución de la información

La puesta en común de determinados tipos de información podría aumentar las posibilidades de acceso inapropiado y mal uso del sistema SCADA.
Por lo tanto, se recomienda que se analizarán todos los tipos de información sobre el sistema SCADA y clasifican, según el plan y los procedimientos
de seguridad del operador, antes de que se comparte. Es igualmente importante determinar qué tipo de información puede ser compartida con cada
individuo en función de su trabajo / papel. Cuando la información confidencial / restringido debe ser compartida con el personal de terceros, acuerdos
de confidencialidad, investigación de antecedentes y capacitación / sensibilización de los procedimientos de seguridad debe ser considerada.

El operador deberá aplicar las políticas establecidas de la compañía para el manejo de información.

Se recomienda que un mínimo de cuatro niveles de clasificación se debe utilizar para obtener información SCADA. El operador determinará los
niveles de usar basado en las siguientes directrices:

- confidencial,

- restringido,

- solo para uso interno,

- público.

6.1 confidencial

La información confidencial sólo debe ser compartida con el personal en base a la necesidad de saber. El acceso a la información confidencial sólo se
debe utilizar con el fin de satisfacer las necesidades de un trabajo o tarea. La información confidencial es información que no es ampliamente
compartida y que absolutamente protegido. Los detalles específicos relacionados con el sistema SCADA se clasifican como información confidencial. La
información clasificada como confidencial se debe proteger de la mejor manera.

Los elementos siguientes son ejemplos de información confidencial (esto no está destinado a servir como una lista completa):

- los conjuntos de reglas de acceso,

- esquemas de direccionamiento,

- diseños de registro del PLC,

- diagramas del sistema,

- configuraciones del sistema,

Página 31 de 73
32 S API ORMA 1164

- información de la cuenta de usuario.

6.2 Restringido

información restringida puede ser específica, ya pesar de que puede ser compartida con un mayor número de individuos que la información confidencial, se
sigue protegida. información restringida es compartida por la conciencia y para cumplir con los requerimientos trabajo o tarea, pero no para el conocimiento
general.

Los elementos siguientes son ejemplos de información restringida (esto no está destinado a servir como una lista completa):

- medios de comunicación,

- protocolos de comunicación utilizados,

- listas de equipo,

6.3 Solo para uso interno

Sólo para uso interno es la información que está restringido al personal interno que tienen un fin comercial legítimo para acceder a esos datos. Se
recomienda que estos datos no puede ser compartida con personas fuera de la organización. Manipulación o difusión de esta información fuera de
la organización por lo general implica un acuerdo de confidencialidad. Considere el marcado de uso interno de datos para identificar su intención y
la clasificación para evitar el uso no autorizado, divulgación, modificación y / o destrucción.

Los elementos siguientes son ejemplos de información de uso interno (esto no está destinado a servir como una lista completa):

- información socio de negocios no cubiertos por un acuerdo de confidencialidad más restrictivos

- Procedimientos de operación

- datos de seguridad de la información, auditorías u otras actividades internas de naturaleza sensible

- documentos de planificación

- contratos

- planes de seguridad.

6.4 Público

La información pública es de carácter general y puede ser compartida con todos los individuos. La información pública es compartida por la conciencia y no se requiere para
satisfacer las tareas o puestos de trabajo.

Debido a la naturaleza crítica de los sistemas SCADA, un mínimo de información relacionada con el sistema debería ser clasificada como pública.
SCADA información clasificada como pública debe pasar por una revisión por la dirección apropiada para evaluar el riesgo de la liberación.

7 Diseño de Redes / Seguridad e Intercambio de Datos

En el pasado, los sistemas SCADA eran típicamente aisladas y corrieron con independencia de otras funciones y aplicaciones empresariales. Sin
embargo, como la tecnología ha avanzado, la interconectividad ha convertido en algo común. Hay una ventaja para los sistemas de empresas tengan
acceso a los datos SCADA. En las secciones siguientes se abordarán lograr la interconectividad sistema seguro.
7.1 Diseño de Redes

Hay muchos métodos que se pueden utilizar para conectar los sistemas SCADA para sistemas de negocio corporativos. Sin embargo, estas
conexiones deben limitarse a los servicios o dispositivos específicos y deberán estar asegurados. Es importante señalar que la conexión de
cualquier dispositivo al PCN requiere una evaluación de riesgo a la red, así como el riesgo de ser conectado el dispositivo.

7.1.1 Interconectado Negocios y Redes SCADA

Figura 3-Typical-aislado no Implementación-No Recomendado

7.1.2 Comunicación Puntos de demarcación

Un lugar físicamente seguro debe ser proporcionada por los puntos de demarcación de comunicación para minimizar el acceso de personal no
autorizado.

7.1.3 Los cortafuegos

Un servidor de seguridad monitorizada y mantenida proporciona perímetro de defensa en la capa de red y en la capa de aplicación. Un servidor de
seguridad se utilizará cuando se conecta la red SCADA y cualquier otra red informática no SCADA. El servidor de seguridad se puede configurar
para bloquear todos los accesos innecesarios y permitir que el tráfico sólo es esencial según lo aprobado por la política de seguridad (ver Figura
3-Típica aislado Incumplimiento-no recomendado).

NOTA Un cortafuegos de capa 7 con la conciencia aplicación avanzada se recomienda, ya que proporciona un mejor control sobre las entradas,
salidas y / o acceso a, a, o por una aplicación o servicio.

7.1.4 zona desmilitarizada (DMZ)

Una DMZ es una red separada que incluye dos servidores de seguridad que se coloca entre el cortafuegos de red SCADA y el cortafuegos de red
de negocios (véase la Figura 3 y Figura 4). Computadoras u otros equipos que

Página 33 de 73
34 S API ORMA 1164

debe comunicarse con ambas redes se colocan en la red DMZ. Esto asegura que no hay comunicación directa entre la red SCADA y el tejido
empresarial. Este enfoque proporciona los medios para utilizar sistemas de detección de intrusos que pueden indicar la penetración de un firewall.

7.1.5 con base dual Computadoras

computadoras con base dual que conectan dos dominios de seguridad diferentes (distintos de los servidores de seguridad dedicados) no se llevarán a cabo
dentro de la red SCADA. A no ser que funciona como un servidor de seguridad, un ordenador de base dual tiene el potencial de evitar el aislamiento de
seguridad de red (ver Figura 6).

Aislamiento Figura 4-Típica Aislamiento Firewall Aplicación-Minimal

-
Figura 5-implementación típica recomendado DMZ

Figura 6-Implementación de base dual puente de ordenador (no recomendado)

7.1.6 Defensa en profundidad

Por lo general no es posible conseguir los objetivos de seguridad deseados mediante el uso de una única contramedida o técnica. Un enfoque
superior es utilizar el concepto de defensa en profundidad, que consiste en aplicar

Página 35 de 73
36 S API ORMA 1164

múltiples contramedidas de una manera en capas o por etapas. Por ejemplo, los sistemas de detección de intrusión se pueden utilizar para señalizar la penetración
de un servidor de seguridad (Véase la Figura 3 y 4).

7.1.7 Gestión de Firewall

La gestión eficaz firewall posee una estrategia de filtrado y la configuración común. La política de firewall más restrictiva tiende a ser el más seguro.
Al planificar una configuración de cortafuegos, se recomiendan los siguientes conceptos de estrategia:

- La configuración básica de cada política de firewall debe ser de negar todas las comunicaciones de forma predeterminada y sólo permitir la
comunicación por excepción para satisfacer una necesidad operativa crítica. Esto se aplica tanto a la comunicación interactiva de usuario, y la
comunicación-tarea a la tarea entre los dispositivos. Siempre que sea posible, la comunicación debe ser filtrada por los puertos y servicios entre pares
emparejados IP para los dispositivos que se comunican a través de interfaces del servidor de seguridad.

- Puertos y servicios con frecuencia se utilizan como vectores de ataque y no deben abrirse a través de la Firewall. Cuando se requiere el
servicio debido a la justificación de negocio, las contramedidas apropiadas se deben emplear para compensar el riesgo. A modo de ejemplo,
http entrada a la zona de distensión SCADA o LAN, que es un vector de ataque común, puede ser necesario para apoyar una función de
negocio importante. contramedidas de compensación adicionales, tales como el bloqueo de secuencias de comandos entrantes y el uso de
un servidor proxy http ayudaría a reducir el riesgo de abrir este puerto alto riesgo y el servicio.

- Cuanto menor sea el número de puertos abiertos y servicios a través del firewall, mejor. tecnologías de la comunicación que requieren un
gran número de puertos estén abiertos deben ser evitados.

7.1.8 La virtualización

Los operadores están desplegando sistemas SCADA en un entorno virtualizado. La virtualización puede proporcionar muchos beneficios a estos sistemas
como el aumento de la disponibilidad y fiabilidad. La virtualización rompe la de un empate entre el servidor y el hardware del servidor permite a los servidores
de control de procesos a ejecutarse desde cualquier servidor físico de un grupo de servidores. plataformas de virtualización son capaces de utilizar esta
independencia del hardware de un único host para recuperarse de los fallos de hardware catastróficos rápidamente.

La virtualización también proporciona opciones mejoradas de recuperación de desastres para servidores y sitios enteros. productos de virtualización proporcionan una
característica conocida como instantáneas. Las instantáneas permiten a los administradores de sistemas crear un punto en lugar de recuperación de tiempo para una
máquina virtual. Esto se puede hacer antes de instalar los parches de sistema operativo, parches de aplicaciones o realizar cambios de configuración en un servidor. En
el caso de que algo va mal con la modificación de que el servidor puede ser rápidamente revertida hasta el punto en el tiempo instantánea. Las instantáneas se pueden
tomar de forma automática de volúmenes de almacenamiento enteras de alojamiento varios servidores. Estas instantáneas se pueden replicar fuera del sitio para la
recuperación de desastres fuera del sitio o se usa localmente para recuperarse de un evento catastrófico, tal como un virus.

Además de instantáneas de recuperación de desastres también puede mejorar en gran medida un desarrollo organizaciones y capacidades de prueba.
Las instantáneas del entorno de producción se pueden utilizar para actualizar un entorno de virtualización de desarrollo con las copias de las máquinas
de producción que permitan un proceso más completa y precisa las pruebas de cambios en el servidor antes de implementar en la producción.

Esta tecnología también abre varias nuevas vías potenciales para el ataque que deban estar asegurados. Los métodos descritos a continuación deben
aplicarse en general a través de todos los proveedores. Además, las medidas implementadas para asegurar el entorno virtualizado también dependen en
gran medida de la arquitectura del sistema. Por ejemplo, algunos entornos puede utilizar Network Attached Storage (NAS) y algunos pueden utilizar una
red de área de almacenamiento (SAN). Algunos entornos pueden ejecutar su hipervisor encima de otro sistema operativo, mientras que otros pueden
ejecutar el hipervisor instalado directamente en el hardware anfitrión.
7.1.8.1 Permisos

Cualquier plataforma de virtualización escalable proporcionará una interfaz de administración central para gestionar las máquinas virtuales y hosts físicos
en el medio ambiente. El modelo de menor acceso privilegiado se adoptará para la asignación de derechos a las personas que necesitan acceder a esta
consola de gestión centralizada para evitar cambios accidentales o no autorizados o el acceso al hardware de la máquina virtual, discos, estado de la
alimentación, el acceso a la consola del servidor, modificación de la física anfitriones, etc. Los usuarios sólo se les debe permitir modificar o acceder a
máquinas virtuales dentro de esta consola que necesitan específicamente el acceso a.

hosts físicos también tienen su propio conjunto de inicios de sesión para acceder al sistema operativo del host y el hipervisor. Estas conexiones deben
ser únicos y papel basada como se define en esta norma.

Del mismo modo, los sistemas de almacenamiento utilizados para proporcionar recursos de almacenamiento para el entorno virtual se ajustará al modelo de privilegios de
acceso menos tan bien. La arquitectura del entorno virtualizado resultará en muchos servidores que tienen sus volúmenes del sistema operativo almacenado en el mismo
volumen de almacenamiento lógico. Las modificaciones en el volumen de un sistema de almacenamiento por lo tanto, podrían afectar a un gran número de servidores.

7.1.8.2 hipervisor y la Máquina Virtual Services

Específica a este entorno:

- Las máquinas virtuales deben tener todo el hardware no utilizado eliminado.

- La Plataforma de Gestión virtual debe ser parcheado y mantiene al día de acuerdo con este cambio de gestión de las normas y requisitos de
parches.

- El hipervisor debe ser parcheado y mantiene al día de acuerdo con este cambio de gestión de las normas y requisitos de parches.

- Si el hipervisor se ejecuta en la parte superior de otro sistema operativo, el sistema operativo anfitrión debe ser parcheado y mantiene al día de
acuerdo con este cambio de gestión de las normas y requisitos de parches.

7.1.8.3 Redes

Una red de administración independiente para la gestión de entornos virtuales, hosts físicos y dispositivos SAN / NAS de almacenamiento deberá
estar en su lugar. Esta red se encuentra detrás de un firewall y sólo permiten la gestión de los clientes autorizados.

Se creará una red de almacenamiento separado para los hosts virtuales y los dispositivos NAS. Los dispositivos NAS deben configurarse para permitir sólo
los hosts virtuales en esta red de almacenamiento de acceso a los volúmenes que serán utilizados en el entorno virtual. Esta red debe ser aislado de la
capa 2. En los casos en que esta red tiene que ser encaminado, un servidor de seguridad se utilizará para protegerlo.

Además, una tercera red de gestión debe ser creado para la transferencia de la máquina virtual entre los ejércitos. Esta red debe ser aislado a la
capa 2.

Los dispositivos NAS sólo debe permitir que los protocolos específicos necesarios en sus interfaces de red. Por ejemplo, el tráfico de
almacenamiento sólo debe permitirse para atravesar a través de los interfaces conectadas a la red y la gestión del almacenamiento de tráfico, sólo
debe ser permitido en las interfaces conectadas a la red de gestión.

El servidor que aloja la plataforma de gestión de virtualización también se encuentra detrás de un firewall en una red de gestión. Esta red sólo
permitirá la comunicación con los clientes de gestión autorizados y servicios necesarios.

Página 37 de 73
38 S API ORMA 1164

Si los hosts de Virtual Server tienen cortafuegos estos deben ser activado y configurado. Del mismo modo, el anfitrión de servidor virtual únicamente
permitirán ciertos servicios y funciones, tales como la gestión de huésped, transferencia de la máquina virtual, a través de los interfaces específicas está
destinado el tráfico para.

7.1.8.4 Asignación de Recursos

Con la virtualización, los recursos informáticos se agruparon de manera que puedan ser compartidas entre las máquinas virtuales. Una práctica común
es sobre la asignación de recursos informáticos, por lo general no todas las máquinas virtuales necesitarán los recursos al mismo tiempo. Con el
compromiso de recursos en el entorno de controles de proceso puede crear un vector de ataque para los ataques de denegación de servicio contra
este ambiente al agotar los recursos disponibles entre las máquinas virtuales compartidos. En el entorno SCADA, todas las asignaciones de recursos a
las máquinas virtuales SCADA deben ser configurados para que estén garantizados. La virtualización también permite el rápido despliegue de
servidores adicionales, según sea necesario. En el entorno SCADA esto debe ser monitoreado y planificado adecuadamente para garantizar el medio
ambiente puede mantener estos recursos de garantía contra el crecimiento.

7.2 Gestión de Redes

Gestión de redes requiere documentación y diagramas de hasta al día de cómo está diseñada la red y la forma en que está destinado a funcionar.
procesos de gestión de la red deben estar alineados con el plan general de gestión del cambio.

El operador debe garantizar que los archivos de configuración utilizados para los dispositivos de red del programa (tales como routers, switches, firewalls)
están archivados adecuadamente, y que esos archivos representar lo que está en producción. El operador debe revisar periódicamente versiones de
software que se ejecutan en los dispositivos de la red, y revisar y evaluar las vulnerabilidades conocidas, con la intención de remediar como sea necesario.
La línea de tiempo de revisión recomendada es al menos una vez al año no exceda los 15 meses.

Conmutadores y routers dirigen y controlan la mayor parte de los datos que fluyen a través de las redes del sistema PCN. Se requiere la debida seguridad para
controlar el acceso, resistir a los ataques de denegación de servicio (DoS), proteger a otros sistemas de red y proteger la integridad y confidencialidad de tráfico de
la red. Estos dispositivos de red de teclas deben estar correctamente configurado para alcanzar la seguridad necesaria. A continuación se presentan una serie de
medidas a tener en cuenta para fijar los dispositivos de red.

- Menos de privilegios de acceso - Al igual que en otros sistemas, sólo el acceso mínimo necesario para la funcionalidad debe ser permitido. Se deben
establecer varios niveles de acceso. Los ejemplos son de sólo lectura de los registros para solucionar problemas de conectividad, solo lectura de
configuración fuera de línea para la solución avanzada de problemas, y de administración para realizar cambios de configuración.

- No hay contraseñas por defecto de fábrica - de configuración de dispositivos y contraseñas de conexión se pueden cambiar desde el valor predeterminado de fábrica

- El cambio de contraseñas periódicamente - Las contraseñas deben cambiarse periódicamente.

- Configuraciones de copia de seguridad - El archivo de configuración se ejecuta actualmente deben ser guardados. Muchos dispositivos tienen memoria no
volátil para proporcionar la configuración después de la energía se restaura en el dispositivo. Por lo general, los comandos especiales son necesarios para
guardar la configuración actualmente en ejecución en la memoria no volátil. La configuración también se debe guardar en un lugar seguro fuera del
dispositivo para facilitar la recuperación de fallos de hardware y actualizaciones.

- Habilitar el cifrado de contraseñas - contraseñas de los dispositivos se pueden guardar en texto claro en archivos de configuración fuera de línea a menos que se
activa la codificación. cifrado de la contraseña debe estar habilitado si está disponible.
- Servicios de verificación activadas por defecto. servicios innecesarios deben ser desactivados. Ejemplos de ello son PAD - ensamblador de paquetes /
desensamblador que está habilitado por defecto en los routers y sólo se utiliza con enlaces X.25. Si las conexiones X.25 no están presentes en un
sistema, este servicio no es necesario y debe ser desactivada.

- protocolos de riesgo no utilizado y de alta deben ser habilitadas o enrutado. Por ejemplo la práctica estándar es desactivar interfaz HTTP
para configurar los dispositivos de red, ya que no es seguro. Interruptores y routers comerciales pueden tener protocolos que no son
apropiadas para el PCN y debe ser desactiva. Por ejemplo voz sobre IP. los protocolos no utilizados pueden incluir dominio udp protocolos,
NetBIOS, TFTP o tiempo mientras se usan sus homólogos TCP.

- Muchos dispositivos de red tienen el protocolo SNMP habilitado por defecto con ampliamente utilizado por defecto Comunidades SNMP. Este
protocolo se utiliza a menudo para la conectividad de dispositivos de red de monitoreo y la salud. Este potente protocolo también se puede utilizar
para realizar cambios en los dispositivos de red. Si SNMP se utiliza el valor por defecto de fábrica comunidades SNMP deberán cambiarse. Las
comunidades SNMP deben cambiarse periódicamente.

- puertos físicos no estén en uso deben ser desactivados. Por defecto, la mayoría conmutadores y routers tienen todos los puertos físicos habilitados
para facilitar la facilidad de uso. Esto hace que sea más fácil para la conexión no autorizada o accidental a una red de proceso si alguien debe tener
acceso físico a los dispositivos de red.

- Algunos dispositivos permiten restricciones dirección MAC en una base por interfaz. Esto sólo permite que los dispositivos en esa lista de
direcciones MAC para conectarse a esa interfaz. El uso de restricción de direcciones MAC puede ayudar a evitar que alguien desconectar un
dispositivo y se conecta a su propio dispositivo para obtener acceso a la red. El uso de restricciones dirección MAC se debe considerar sin
embargo, requerirá la educación del personal de campo y la coordinación para el cambio de hardware a cabo.

- Debe existir un sistema para monitorear la red de autenticación de acceso al dispositivo, autorización y contabilidad que proporcionará
alertas de intentos no autorizados de acceder a los dispositivos.

- Configuración del dispositivo de la red debe ser revisado periódicamente, como en una vez al año no exceda los 15 meses, para la configuración de seguridad
adecuadas y copia de seguridad actual.

El operador debe gestionar la red de tráfico de la red de vigilancia y la actividad general, evite el uso de dispositivos no administrados, y supervisar el
uso de la red y los patrones de tráfico. El operador debe revisar periódicamente los archivos de registro de la red, mensajes de error y otros eventos
para realizar un seguimiento de los posibles fallos de seguridad u otra actividad anómala.

El proceso de gestión de dispositivos de red se puede mejorar mediante herramientas apropiadas.

7.2.1 Red de Vigilancia y Protección avanzada contra amenazas

Aunque no existen mejores prácticas universalmente aceptadas para la supervisión de la red en un sistema SCADA o el control, la aplicación de una
combinación de tecnologías, además de servidores de seguridad es necesaria para mejorar la seguridad y la gestión de la red. Protocolo de Control
de Transmisión / Protocolo de Internet (TCP / IP) redes basadas han convertido en el habilitador subyacente de conectividad basada en estándares de
la industria. Esta relativa facilidad de uso presenta muchos desafíos en la gestión y seguridad de la red.

Más allá de la aplicación de la tecnología, los datos generados deben ser revisados ​de forma regular, como se define en el plan de seguridad. La
agregación y la correlación de información de múltiples fuentes, y la necesidad de presentarlo de una manera significativa puede ser una tarea
onerosa y puede ser asistido por las herramientas apropiadas.

Página 39 de 73
40 S API ORMA 1164

7.2.2 Seguridad de Red

Además de la implementación de cortafuegos, la vigilancia del tráfico, y el registro de eventos, las tecnologías que se centran en los riesgos de
seguridad específicos deben ser considerados. Varias áreas que se deben dar una fuerte consideración son la detección y prevención de
intrusiones, detección de malware y de evitación, Seguridad de la Información y Gestión de Eventos (SEIM), Host / Endpoint Security, así como de
Auditoría y Control de archivos.

7.2.2.1 Detección de intrusiones y sistemas de prevención (PDI)

El operador debe evaluar el uso de los desplazados internos para monitorear el comportamiento de la red para identificar eventos que pueden
considerarse inusual o indeseable. Métodos para emplear las PDI incluyen:

- supervisión de la red, donde se examinan los segmentos o dispositivos de red para actividades sospechosas en la red y de aplicaciones protocolos
(también se hace referencia como detección de intrusos NID de la red);

- inalámbrico, donde se examina el tráfico de red inalámbrica de actividad sospechosa en los protocolos;

- conductual o heurística, donde la red se examina para el flujo de tráfico inusual;

- de supervisión del sistema, donde un equipo host se examina para actividad sospechosa (también conocida como detección de intrusos
HID-host).

Debido a la naturaleza del tráfico SCADA (que por lo general se considera que es diferente de los sistemas de negocios más tradicionales), y protocolos
únicos que pueden ser implementadas, el uso de las PDI se debe examinar cuidadosamente para asegurar que el funcionamiento seguro y fiable del
bienestar del sistema controlada no se ve comprometida por acciones automatizadas de la PDI. El sistema de detección de intrusión (IDS) debe ser
implementado y revisado con bastante antelación de permitir que el sistema de prevención de intrusiones (IPS).

7.2.2.2 Detección de Malware y evitación

El operador debe evaluar el uso de detección de malware y prevención para monitorear el tráfico que entra en y que recorren la red (s) en un
intento de detectar y prevenir el malware infecte un host / punto final. Esto puede incluir fuentes externas, tales como Internet y correo electrónico,
así como servidores de archivos internos.

7.2.2.3 Información de Seguridad y Gestión de Eventos (SIEM)

El operador debe considerar la implementación de una herramienta SIEM como un medio de agregar los datos de una variedad de sistemas para: detección
en tiempo real y correlación de eventos de red y seguridad, alertas, análisis forense, y para ayudar a los informes de cumplimiento. Este tipo de herramienta
también puede ser instrumental en los inicios de sesión fallidos de forma proactiva monitoreo, uso de credenciales elevadas, la creación / eliminación de
cuentas, etc.

7.2.2.4 listas blancas

listas blancas es el proceso de elaboración de una lista detallada de las entidades que se permite el acceso a un servicio, la red, y así sucesivamente. Se
proporciona un medio de definir claramente lo que está permitido para ser ejecutado. El operador debe considerar el uso de listas blancas como uno de sus
mecanismos de protección del sistema.

7.2.2.5 Host / Endpoint Security

El operador debe implementar el software antivirus en todos los puntos finales, y garantizar que se mantienen con los archivos de definición de hasta al
día. El operador también debe considerar el uso de listas blancas como un medio de protección de puntos finales de permitir la ejecución de archivos que
no han sido específicamente lista blanca para funcionar en el entorno. despliegue inicial de este tipo de herramientas en general, se puede hacer de un
modo de supervisión única, la cual
permite la debida diligencia en la determinación de lo que es necesario ejecutar en el medio ambiente antes de instigar un modo de bloqueo completamente hacia abajo, con lo que

cualquier cosa que no explícitamente permitido para funcionar será bloqueado

7.2.2.6 Auditoría y Control del archivo

El operador debe controlar los archivos y registrar los cambios de preservar el sistema SCADA e integridad de datos. El seguimiento de los archivos no se
espera que cambie (incluyendo el sistema operativo, aplicaciones y archivos de configuración) se debe realizar de tal manera que los cambios se detectan
y registran. El proceso de gestión de auditoría y control de los archivos se puede mejorar mediante herramientas apropiadas.

7.3 Intercambio de Datos

Las conexiones entre la red SCADA y otras redes son impulsados ​por muchas necesidades empresariales. Si el programa de seguridad SCADA
permite estas conexiones se reconoce que suponen un riesgo para la seguridad cibernética. Este riesgo será analizada y las precauciones apropiadas
implementado de acuerdo con las líneas de guía de programas de seguridad. Como parte de esta implementación, políticas y procedimientos deben
desarrollarse y llegar a un acuerdo sobre cómo la empresa y las organizaciones externas deben responder si se identifica un riesgo para la seguridad
del sistema SCADA.

7.3.1 Conexiones entre las instalaciones operativas SCADA centro de control, centro de datos, y el Centro de Telecomunicaciones

Se recomienda que siempre que sea posible las instalaciones en funcionamiento del centro de control deben estar situados lo más cerca posible a
los servicios de datos SCADA y servicios de telecomunicaciones. diseños de sistemas deben garantizar que los operadores SCADA nunca están
sin la posibilidad de conectarse al sistema SCADA y los servidores SCADA no están aislados de las conexiones de telecomunicaciones a lugares
remotos de tuberías.

7.3.2 conexiones entre el sistema SCADA y Redes de Negocios

El uso de los datos SCADA y PCN por entidades corporativas distintas de las operaciones se ha convertido en la regla más que la excepción. Se tendrá
que asegurarse de los datos y la red utilizados por las operaciones siguen siendo fiables y no quedarán afectadas por las actividades de adquisición de
datos corporativos. Sistemas de los que se accede por entidades distintas de las operaciones deben hacerlo desde un sistema separado que el de
operaciones. Una zona de seguridad por separado o subred, tal como una DMZ, se deben utilizar para replicar los datos del sistema y de forma segura
proporcionar datos a los consumidores de datos corporativos. deberían existir medidas de seguridad de red adecuado entre los sistemas SCADA
producción y de replicación, en la forma de cortafuegos, DMZ, y otros dispositivos de red adecuados.

7.3.3 conexiones entre el sistema SCADA y Business Partners sistemas SCADA

En muchas situaciones, es necesario que el sistema SCADA de una compañía de comunicar los datos de control para el sistema SCADA de otra
compañía. Estos datos incluyen, pero no se limitan a, las solicitudes de apagado, la información de medición, estado de la válvula, etc. Esta
información puede ser transmitida de muchas maneras diferentes, tales como host-a-host, PLC a PLC, etc. Cuando este tipo de se requiere la
comunicación, los operadores deben desarrollar mutuamente un método seguro de comunicación.

7.3.4 Conexiones a terceros para la ayuda

Es importante que el personal de terceras partes sean capaces de soportar los sistemas que venden, y en algunos casos que requieren acceso al
sistema SCADA para este propósito. Los métodos para el acceso de terceros al sistema SCADA incluyen acceso a través de una extranet, Internet,
módem, etc. conexiones de terceros deben ser controlados y asegurados con un método de autenticación. Un método seguro será establecido y
controlado de acuerdo con la política de seguridad del operador, la referencia Sección 5.2 de las directrices de control de acceso de terceros.

Página 41 de 73
42 S API ORMA 1164

el acceso a Internet es a veces necesaria para el soporte del proveedor del sistema SCADA. Este acceso debe ser controlado a través de servidores de
seguridad y otros dispositivos de seguridad. Debería permitirse el acceso a una red corporativa segura inicialmente, a continuación, en Acceso concedido al
sistema SCADA de allí. analista de sistemas de supervisión es necesaria para eliminar los derechos de acceso dadas al proveedor una vez que el trabajo se
ha completado. Un servidor de seguridad se utiliza para aislar la red SCADA a través de Internet.

7.3.5 El acceso a Internet y la Red de Negocios

los activos del sistema SCADA no serán utilizados para acceder a los recursos de red de negocios o internet. El método preferido para acceder a los
recursos no son de confianza es proporcionar una estación de trabajo independiente, específicamente para uso en los negocios, tales como correo
electrónico o la navegación de Internet, conectado a un segmento de red no asociado con la red SCADA o PCN.

7.3.6 telefonía de voz sobre IP / IP (VoIP / IPT)

Las empresas han implementado sistemas de VoIP como un método para reducir los costos de comunicación. Mientras que VoIP no está
recomendado para su uso en sistemas SCADA hay situaciones donde un circuito de comunicaciones físico se comparte con los usuarios no
SCADA. Además, la VoIP se puede utilizar dentro de la red SCADA para proporcionar servicios de misión crítica. Si se requiere el uso de VoIP
como se ha descrito anteriormente, se llevará a cabo las medidas de control adicionales para asegurar y segregar el tráfico de voz. el tráfico de
VoIP no se debe permitir a reemplazar el tráfico SCADA.

7.3.7 Mensajería Instantánea (IM)

IM se utiliza como una herramienta de comunicación crítica para el negocio. Los riesgos asociados a los sistemas de mensajería instantánea incluyen programas espía,
troyanos, virus, ataques de gusanos, spam y pérdida de información crítica y corporativa. Los sistemas de mensajería instantánea a través de Internet no se debe permitir en
un sistema SCADA. Si la política de la empresa requiere el uso de la mensajería instantánea, la empresa tomará las medidas de control para evitar que el sistema de
mensajería instantánea de interferir con el sistema SCADA. Los sistemas de monitoreo deben aplicar para evitar estos riesgos. Si se requiere de mensajería instantánea,
pero sólo se utiliza para la comunicación, el intercambio de archivos debe ser desactivada si es posible.

7.3.8 Redes Inalámbricas

El papel de las redes inalámbricas debe ser cuidadosamente evaluado y evaluado por el riesgo, tal como se indica en la sección 3.4, antes de la
implementación. La red inalámbrica tiene un elevado nivel de preocupación de seguridad para los sistemas SCADA PCN y / o. Por esta razón, una
evaluación de riesgos debe ser completado para sopesar los beneficios de la implementación de redes inalámbricas frente a los riesgos
potenciales. prácticas de gestión SCADA, como el cifrado y la segmentación del cortafuegos deben aplicarse a las redes inalámbricas. tecnologías
de control de redes inalámbricas adicionales también deben ser considerados. Estos pueden incluir, pero no se limitan a, el uso de protocolos
seguros, autenticación mejorada, un túnel, y el control de los puntos de acceso.

Control de acceso físico al equipo de telefonía móvil es necesario para evitar el acceso no autorizado al equipo. Además, la infraestructura de red
debe estar asegurado para impedir la introducción no autorizada de tecnología inalámbrica. La conectividad inalámbrica se debe incluir en la
documentación de la red, las políticas y procedimientos. tecnología de red inalámbrica cambia con frecuencia y seguridad depende de la capacidad
de mantenerse al día y protegidos.

El operador debe desarrollar el sistema SCADA tecnologías inalámbricas de diseño, despliegue y las políticas del ciclo de vida de utilización y
procedimientos específicos. Desarrollo, implementación y mantenimiento de estas políticas y procedimientos deben considerar e incluir, en su caso,
los siguientes:

- Revisión y cambio de ajustes predeterminados de fábrica, según proceda en todos los dispositivos
- Inventario y controlar todos los puntos de acceso y mantener una comprensión completa de la topología de la red inalámbrica

- Poner en práctica las capacidades más seguras disponibles en todos los dispositivos

- Instalar cortafuegos entre dispositivos cableados e inalámbricos

- Bloquear todos los servicios no autorizados y puertos

- criptografía fuerte Usuario

- Reducir al mínimo las distancias de transmisión de datos

- Etiqueta y mantener inventarios de la radio por campos y dispositivos de mano

- Crear copias de seguridad de datos con frecuencia

- Realizar pruebas de seguridad y evaluación periódica de la red inalámbrica

- Realizar, auditorías de seguridad en curso programado al azar para monitorear y realizar un seguimiento de los dispositivos inalámbricos y de mano

- Aplicar parches de software y firmware y mejoras de seguridad

- Monitorear la industria inalámbrica de cambios en las normas que mejoran las características de seguridad y para el lanzamiento de nuevos productos

- Monitorear la tecnología inalámbrica para las nuevas amenazas y vulnerabilidades

7.3.9 Audio / Video Conferencia

conferencias de audio y vídeo puede ser una buena manera de conectar con personal remoto y facilitar mejor el intercambio de ideas para fines
comerciales. Sin embargo, debido a las preocupaciones de seguridad y ancho de banda necesarios para conferencias de audio y vídeo, no deben
ser utilizados dentro de la red de comunicaciones SCADA.

En el caso de que se requiere de conferencias de audio y / o vídeo dentro de la red de comunicación SCADA, se deben poner en marcha para limitar su
impacto en la información SCADA. Tales medidas podrían incluir la priorización de datos para las operaciones de SCADA, las asignaciones de limitación
de ancho de banda para los datos de conferencia, u otra medidas de calidad de servicio que van a limitar el impacto de las operaciones SCADA dentro de
la infraestructura. No hay audio o video conferencias de tráfico debe atravesar cualquier servidor de seguridad de control de procesos, debido a la mayor
exposición a las vulnerabilidades de seguridad.

7.3.10 Video Vigilancia

vigilancia de vídeo puede ser considerado como un tipo especial de datos SCADA y se utiliza para supervisar la seguridad y mejorar la seguridad de los
lugares remotos. En el caso de que se requiere tareas de supervisión en la red SCADA; medidas se deben poner en marcha para limitar su impacto en las
operaciones SCADA. Tales medidas podrían incluir la priorización de datos para obtener información SCADA no de vídeo, las asignaciones de limitación de
ancho de banda para los datos de vigilancia, o de otro tipo de medidas de calidad de servicio que van a limitar el impacto de las operaciones SCADA
dentro de la infraestructura. los datos de vigilancia de video deben ser protegidos como se indica en la Sección 6 de este documento. controles adecuados
deben estar en su lugar cuando se transfieren los datos de vigilancia de vídeo entre las zonas de seguridad.

Página 43 de 73
44 S API ORMA 1164

7.3.11 Cloud Computing

el uso de organización de la computación en nube y almacenamiento de datos basado en la empresa es cada vez mayor. Este cambio es impulsado en parte por los
beneficios de las funciones de hardware y software internos u operados localmente y gestionados reducidos. Al mismo tiempo la computación en la nube requiere
que la organización confían en el proveedor de servicio en la nube para proporcionar todas las funciones de seguridad cibernética, así como la fiabilidad del sistema
y los requisitos de disponibilidad.

La decisión de utilizar la computación en nube para los sistemas de misión crítica se determinará sobre la base de una evaluación de riesgos. Un
elemento esencial del análisis de riesgos es un análisis y diseño de los requisitos de seguridad cibernética toda la revista, como está previsto en
NIST Special Publication 800-53 2010 y 2011 el NIST Special Publication 800-82. Algunas áreas de consideración deben incluir, pero no limitarse
a:

- acuerdos de nivel de servicio requerido. ¿Qué niveles de disponibilidad y fiabilidad se requerirá?

- Los datos y la confidencialidad de la información. ¿Qué procesos, herramientas, métodos, y así sucesivamente ¿El uso proveedor de servicio en la nube?

- problemas de latencia de datos. Lo retrasos, y por cuánto tiempo son las demoras, en la adquisición de datos y acciones de comando y control? Será la
latencia retrasos cambian si los servicios de los proveedores de servicios cloud cambiar entre las regiones? Puede latencia retrasos cambian la
secuencia de eventos que pueden ocurrir?

- Lo que se está empleando criptografía como los datos se transfieren hacia y desde la nube?

- ¿Qué red de telecomunicaciones se está utilizando para transferir los datos desde y hacia la nube? ¿Es una red privada, VPN, o por otros
medios?

- Cumplimiento normativo

- las políticas y los requisitos de conservación de registros

- El cumplimiento de las leyes de seguridad

- auditabilidad

La misión fundamental nube de computación está en su infancia y los operadores necesitan entender completamente los riesgos antes de implementar este
enfoque.

8 Field Communication

La comunicación juega un papel especial en un sistema SCADA con éxito. Más allá de proporcionar los métodos básicos de conectividad, el sistema de
comunicación proporciona confidencialidad, integridad y disponibilidad de los flujos de datos. la comunicación SCADA se ha movido en gran medida
fuera de-serie basada línea arrendada dedicada o métodos de acceso telefónico en favor de los servicios basados ​en IP. La conexión de comunicación
SCADA es típicamente el camino de comunicaciones de largo desde el centro de control para el dispositivo remoto. La utilización de las
telecomunicaciones externa al centro de control expone el sistema de monitoreo o la manipulación no autorizada. En las secciones siguientes se
destacarán los aspectos únicos de un sistema de comunicación SCADA.

8.1 Tecnología dispositivo de campo

Los dispositivos de campo proporcionan el sistema SCADA con una interfaz para dispositivos industriales que están diseñados para proporcionar
información analógica y el estado de los transductores y sensores. Estas señales se convierten en valores digitales y se transmiten a petición usando
varios métodos de telemetría. Los comandos se transmiten a los dispositivos de campo y se procesan de una manera similar. Ciertas clases de
dispositivos de campo, tales como PLCs, fluir
ordenadores, dispositivos de motor / motor de seguridad, y equipos eléctricos, proporcionan una funcionalidad específica. Estos dispositivos pueden suponer un
riesgo operativo si comprometida.

Los dispositivos de campo pueden tener acceso local o remoto para la configuración, calibración y programación. Esto crea problemas de seguridad debido a
que los dispositivos de campo por lo general no tienen la capacidad requerida para garantizar la conectividad de red. Por esta razón, todos los controles de
seguridad recomendadas en este documento deben aplicarse a estos dispositivos.

Una lista parcial de los controles de seguridad incluyen los siguientes.

- Las contraseñas deben ser únicos para cada dispositivo y cambia de acuerdo con la política de gestión de contraseñas del operador. Existen
vulnerabilidades cuando los puertos de serie proporcionados por los fabricantes de equipos no están protegidos por contraseñas o cuando se utilizan
las contraseñas por defecto.

- Cuando sea práctico, los dispositivos de campo deben utilizar la autenticación mejorada, incluyendo la autorización de usuarios multinivel. Si esta
capacidad no está disponible, las precauciones deben ser incorporados para la protección externa de los puertos de comunicación.

- Los paneles de interface de operador deben incorporar la protección de contraseña para impedir que personas no autorizadas accedan a la
interfaz.

- El operador debe requerir los dispositivos de campo para tener lógica interna que protege la instalación que está controlando. Si se reciben órdenes no
autorizadas, los dispositivos de campo deberían reaccionar de una manera a prueba de fallos para proteger la instalación.

- software de configuración y herramientas de desarrollo para dispositivos de campo ofrecen una seguridad limitada. Acceso dispositivo debe
requerir autenticación mejorada. La seguridad física debe ser suministrada para la carcasa del dispositivo de campo.

- desarrollo de software, las actualizaciones y la gestión del cambio de estos dispositivos deben seguir los requisitos de seguridad descritos en
3.6.

Acceso 8.2 Sistema

El sistema SCADA es a menudo conectado a diversas entidades, tanto internos como externos a la red SCADA. En esta sección se discute varias
interconexiones y las mejores prácticas asociadas.

8.2.1 Protocolos de red

TCP / IP se está convirtiendo en el protocolo de elección para la interoperabilidad de los dispositivos de acogida y de campo. servicios innecesarios
[tales como protocolo simple de gestión de red (SNMP) y FTP trivial (TFTP)] deben ser desactivados. Cuando los servicios como estos deben ser
utilizados, los nombres de usuario y contraseñas por defecto deben cambiar a cadenas de lectura / escritura y complejas contraseñas seguras.
protocolos no seguros tales como Telnet y FTP deben ser reemplazados con alternativas seguras, cuando sea posible.

8.2.2 Cifrado de datos sobre rutas de acceso para

La conectividad entre sistemas de campo y SCADA debe ser cifrado. tecnologías de cifrado seguras se pueden aplicar para reducir los riesgos para
la confidencialidad, integridad y disponibilidad. No se recomienda el uso de Internet para comunicaciones de datos de campo. Si internet es la única
conexión posible, conectividad segura cifrado se utiliza para conectar la ubicación campo para el sistema SCADA. Antes de la incorporación de
cualquier método de cifrado, un análisis debe ser realizado para asegurar que la seguridad mejorada no interfiere con el funcionamiento apropiado
del sistema SCADA.

Página 45 de 73
46 S API ORMA 1164

8.2.3 informal usuario Acceso a la Red

estaciones de trabajo y PCs no autorizadas debe prohibirse a conectarse a la red. puertos de red no utilizados deben ser desactivados.

8.2.4 Componentes de acceso remoto SCADA

El acceso remoto a los componentes tales como SCADA HMI, PLC, RTU, etc., sólo se debe activar cuando sea necesario y aprobado mediante la
autenticación fuerte. Estas medidas deben requieren medidas de seguridad mejorada cibernéticos para compensar la falta de seguridad física.
Cuando deben ser considerados viables, las mejores prácticas de la industria adicionales para la conectividad remota segura.

8.2.5 Acceso a módem para el mantenimiento

Cualquier módem de acceso telefónico utilizado para fines de mantenimiento requiere una mayor seguridad. servidores de autenticación de devolución de
llamada y mejoras son deseables debido al hecho de que los módems son inherentemente difícil de asegurar. módems de acceso telefónico deben
desconectarse de la red cuando no es necesario. El uso de módems de acceso telefónico debe reducirse al mínimo.

9 Anual Review, Nueva evaluación y actualización

Mientras que los sistemas SCADA tienen un ciclo de vida largo organizaciones cambiar, cambian las amenazas, los riesgos cambian, cambian las políticas y así
sucesivamente. Para asegurar que el programa de seguridad cibernética SCADA de la organización sigue siendo, críticas y actualizaciones periódicas actuales,
como ejemplo, una vez al año no exceda los 15 meses, se producirá. Mientras que una periodicidad de revisión anual es sugerir que se reconoce que muchos
factores de la organización tendrán un impacto y determinar la duración real entre las revisiones.

Si bien la periodicidad puede variar entre las organizaciones de cada organización debe establecer, documentar y llevar a cabo las revisiones de
acuerdo a las políticas establecidas.
 Anexo A
(informativo)

La siguiente lista se compiló a partir del texto escrito de la API de 1164 y de las mejores prácticas de la industria, y debe ser utilizado por el operador
como una guía en la revisión de sus sistemas SCADA para el nivel adecuado de protección. Este anexo es de ninguna manera una lista exhaustiva,
y no está destinada a cubrir todas las posibles vulnerabilidades de seguridad en sistemas SCADA.

En lugar /
Plan de seguridad y Procedimiento requeridos no / Verificada por:
Necesaria

Son los planes de seguridad, políticas y procedimientos que se ocupan de las personas, los procesos y la tecnología?

Se han identificado y acordado a nivel organizativo activos críticos y funciones operativas?

Se prioridades claramente identificadas en todos los niveles de la organización? Estos incluyen la seguridad, el cumplimiento,
la seguridad física y la información, etc., están considerados éstos en todo el plan de seguridad?

Son los roles y responsabilidades para la gestión y horarios para su revisión y, si es necesario actualizar el
plan de seguridad claramente definido?

En lugar /
Información de Retención / Archivo / Normas de copia de seguridad requeridos no / Verificada por:
Necesaria

Los datos contenidos en las aplicaciones están sujetos a los requisitos de retención de información establecidos en la política de
retención de la información de la compañía. Los operadores deberán tener en cuenta estos requisitos de retención cuando se
desarrollan los horarios fuera de las instalaciones de rotación de copia de seguridad y de retención para cada aplicación que se
apoyan, en base a los requisitos establecidos por el operador y el programa de retención de registros. Este horario deberá
reflejar la evaluación de riesgos de la información que se almacena.

Página 47 de 73
 48 S API ORMA 1164

El administrador del sistema deberá garantizar que todos los datos están respaldados acuerdo con los requisitos del operador y el
programa de retención de registros. servidores de archivos / base de datos tendrá como mínimo una copia de seguridad incremental
realizado al menos diariamente, y una copia de seguridad completa que se realiza semanalmente. Las copias de las copias de seguridad
deberán ser enviados fuera del sitio. Es responsabilidad del administrador del sistema para asegurar que el sistema puede ser
restaurado y disponible para satisfacer los requerimientos del negocio como se define por el propietario de la información.

Los operadores deberán documentar los procedimientos de backup y recuperación basada en las necesidades de los
propietarios de la información.

Sistemas de información de datos clasificados como restringido o confidencial se copia de seguridad diaria y se almacenan en un
lugar adecuado fuera de sitio como se define en la política de retención de información.

Sistemas de información de datos clasificados como públicos deberán ser respaldadas periódicamente, según lo determinado
conjuntamente por el custodio del operador y la información, y moverse periódicamente a un lugar seguro.

depositarios de información de los sistemas de aplicación son responsables de documentar y mantener procedimientos
de software y recuperación de hardware.

El software incluye, pero no se limita a, cualquier / aplicación / sistema de programa necesario para reconstruir el
entorno de procesamiento.

En lugar /
Planificación de la Continuidad del Negocio requeridos no / Verificada por:
Necesaria

Cada organización con la misión-crítica y / o restringidas o datos confidenciales deberán desarrollar y

mantener un BCP actual.

El operador determinará los requisitos de disponibilidad de sus sistemas de información. Esta determinación
se basa en el análisis del impacto de la organización, y con qué rapidez se debe recuperar el sistema.

El operador es responsable del mantenimiento, pruebas, documentación y ejecución de un DRP. Esta DRP es un componente
de la continuidad del negocio y debe abarcar los procedimientos de recuperación de datos y copia de seguridad y los
procedimientos de software y recuperación de hardware.
Un BCP deberá ser revisado y actualizado por lo menos anualmente con el fin de estar al día.

El marco de tiempo para la reanudación de procesamiento del sistema en el BCP / DRP es consistente con los requisitos de
negocio y estrategias de recuperación.

Los operadores deberán realizar pruebas del proceso de restauración al menos anualmente tras la aplicación con éxito de un
proceso de copia de seguridad y restauración o si hay un cambio en los componentes de un proceso de copia de seguridad (fuente,
medios de comunicación, los equipos, enrutamiento lógico, etc.). Sólo el operador puede autorizar al personal (guardianes de
información, administradores de sistemas) para recuperar las copias de seguridad y realizar restauraciones.

El plan incluirá un inventario de todo el software de los sistemas necesarios y suficientes para reconstruir el
entorno de procesamiento y para soportar aplicaciones críticas.

Cada unidad de reporte deberá probar su BCP / DRP sobre una base anual. Esta prueba debe ser documentada y
los resultados reportados para el operador y cualquier otro comité que se designa con la gestión empresarial.

las pruebas de restauración se realizará con los datos de copia de seguridad de producción en vivo en los sistemas de prueba en sólo
el entorno de prueba.

Copias del BCP / DRP y software de copia de seguridad (sistema de datos e) deberán ser alojados en una instalación de almacenamiento
fuera del sitio.

, métodos de procesamiento manual alternativos serán identificados y documentados en el plan de operaciones

continuas, mientras que el medio ambiente está siendo recuperado.

El plan deberá incluir, pero no limitarse a, las provisiones para una instalación de emergencia y equipos de hardware. La
instalación de contingencia debe ser una instalación completamente operativo configurado con las especificaciones de la unidad
de reporte.

El BCP / DRP incluirá disponibilidad y ubicación de hardware del sistema alternativo.

Dependencias y procesos de recuperación relacionados con los proveedores de terceros [es decir, el proveedor de servicios de
Internet (ISP), las empresas de servicios públicos, o por teléfono] serán identificados e incorporados en el BCP / DRP.

Página 49 de 73
 50 S API ORMA 1164

El hardware incluye pero no se limita a ninguna unidad de procesamiento central (CPU), unidad de memoria, periférica,
terminal remoto, controlador, equipo de comunicación y / o de la línea, la impresora, y cualesquiera otros elementos
relacionados de hardware necesarios para reconstruir el entorno de procesamiento.

Sistema de copia de seguridad y software de aplicación se llevarán a cabo antes de las actualizaciones y / o
mantenimiento del sistema se produce.

copias de seguridad de cinta de toda la información clasificada como restringida o confidencial deberán ser enviados fuera del sitio a una
ubicación remota en los intervalos especificados en el BC / DRP.

Deben existir procesos para incorporar los cambios, al igual que las actualizaciones de software o hardware, al entorno del
sistema en el BCP / DRP.

El plan deberá incluir opciones alternativas basadas en el tipo de desastre que se produce.

El plan deberá identificar y dependencias de red y dirección de otra aplicación si es que existen.

El plan incluirá disposiciones, horarios, responsabilidades y seguimiento para la formación y desarrollo de habilidades de las
personas que se requieren para estar en el sitio de recuperación para restaurar el sistema y sus datos. El equipo de
recuperación debe incluir a los propietarios de negocios y los usuarios del sistema. El equipo incluirá suplentes que también
están capacitados plenamente en la reconstrucción del sistema.

El plan incluirá procedimientos para solicitar los medios de copia de seguridad fuera del sitio.

Los procedimientos de comunicación para los miembros del equipo de recuperación para utilizar después del desastre, durante la
recuperación, y después de la recuperación serán documentados.

Los usuarios del sistema deben participar en las pruebas del BCP / DRP para asegurar que el sistema funciona según lo previsto.
 En lugar /
Cambios, configuración y las normas de gestión de problemas requeridos no / Verificada por:
Necesaria

El operador debe garantizar el desarrollo y la documentación de los procedimientos de control de cambios.

Las solicitudes de cambio de aplicaciones y / o sistemas que contienen información restringida o confidencial se
documenta a través de un formulario de solicitud de cambio aprobada unidad de información. El formulario de solicitud de
cambio debe, como mínimo contener la siguiente información:

- que está poniendo en marcha el cambio,

- que es responsable de la implementación del cambio,

- que es responsable de la aprobación,

- justificación de negocio para el cambio,

- naturaleza del defecto (si procede),

- necesidades de recursos estimados necesarios para completar el cambio,

- pruebas requeridas y que es responsable de la prueba,

- copias de los procedimientos,

- sistemas afectados,

- la información de contacto del usuario.

Página 51 de 73
 52 S API ORMA 1164

El operador debe aprobar las solicitudes de cambio.

Un número limitado de factores que pueden hacer que el proceso de cambio necesario prohibitivo (por ejemplo, un número
limitado de empleados). En estos casos, desarrollar controles de mitigación y solicita una excepción.

las normas de gestión de cambios deberán incluir procedimientos de control para hacer frente a situaciones de
emergencia dentro de los sistemas SCADA y redes de apoyo que suponen una amenaza para la salud, la seguridad
o el medio ambiente.

Todas las solicitudes de emergencia deben estar documentados después de la implementación. La documentación debe
incluir la actividad, tales como la cuenta de la persona (s) de realizar el cambio, la hora, la fecha, los comandos ejecutados,
los archivos de programa y de datos afectados, etc. La persona (s) de realizar el cambio de emergencia también debe
proporcionar una descripción escrita de lo se hizo para atender la emergencia al operador apropiado.

El operador es responsable de supervisar la instalación de correcciones de emergencia. En raros casos en que los
programadores necesitan actualizar el acceso al entorno de producción, se crearán cuentas temporales o especiales
de acceso. Estas cuentas temporales deben ser desactivados o eliminados una vez terminada la sesión de
emergencia.

Los roles y responsabilidades de las personas involucradas en el proceso de control de cambios, deberán estar claramente
definidos y documentados. responsabilidades incompatibles deben estar separados (es decir, los programadores
responsables de codificar los cambios no deben mover estos mismos cambios en la producción).

Los desarrolladores de aplicaciones no tendrán acceso de escritura en el entorno de producción y la producción de

código ejecutable.

Las solicitudes deberán cumplir los entornos controlados por separado para:

- desarrollo / puesta en escena,

- integración y pruebas de aceptación del usuario,

- fuente de producción (en su caso),

- la producción de código ejecutable.

El Operador de asegurar la identificación y documentación de las condiciones (tipos de cambios) que requieren el
cumplimiento de estos procedimientos de control de cambios detallados (es decir, la versión de alto riesgo actualizaciones vs
mantenimiento de bajo riesgo).

Operador deberá mantener la documentación de los procedimientos de control de cambios.

En pequeñas tiendas donde la separación de funciones y un entorno de prueba puede no ser práctico, controles
atenuantes se pueden desarrollar. El proceso de excepción debe ser utilizada para estos casos.

Todos los archivos de código fuente y de configuración del sistema SCADA se limitarán únicamente a personal
técnico autorizado.

Sólo será un repositorio de código fuente de producción. Los desarrolladores podrán obtener el código fuente de
este repositorio al modificar los programas. Todas las modificaciones en el código fuente de producción deben ser
documentados para el control de la versión correcta.

Los privilegios de acceso de los desarrolladores a bibliotecas producción se limite tal que sólo se permitirá
copiar el código fuente de la producción en su área de desarrollo y escribir o mover el código modificado en
una biblioteca de puesta en escena.

Un proceso de control de cambio deberá estar en su lugar para asegurar que los programadores se restringen
adecuadamente el acceso a la producción y prueba de entornos.

Toda la información está sujeta a programas de retención de información operadores.

Todas ellas deberán estar a prueba de integración (por ejemplo, las interdependencias de prueba para asegurarse de que
no interrumpen otras funciones) antes de la implementación del software en el entorno compañía de cómputo de
producción.

Cualquier dato utilizado para las pruebas deberán cumplir con las normas de protección de la información.

El plan de aceptación de los usuarios de aplicaciones incluirá pruebas de todas las funciones principales, los procesos y
sistemas de interfaz. Deberán documentarse los procedimientos de prueba.

Durante las pruebas de aceptación del usuario, restricciones de acceso lógico se asegurarán de que los desarrolladores
no tienen acceso a la actualización y que el código está probando no pueden ser modificados sin notificación al propietario
de la información.

Página 53 de 73
 54 S API ORMA 1164

Todos los cambios no sean de emergencia a las redes de computadoras de la compañía seguirán a cambio de compañía y
las normas de gestión de problemas. Los cambios en las redes internas de la empresa incluyen, pero no se limitan a:

- carga de un nuevo software de red,

- el cambio de direcciones de red,

- routers reconfiguración,

- la adición de líneas de acceso telefónico,

- la creación de relaciones de confianza de acogida.

En lugar /
Sistema Operativo y Normas de Aplicación requeridos no / Verificada por:
Necesaria

Los nuevos sistemas operativos e implementaciones de aplicaciones deben incorporar medidas de seguridad en
fase de desarrollo. Las medidas de seguridad deberán ser probados antes de los nuevos sistemas operativos y
aplicaciones se colocan en el entorno de producción.

Sistema operativo y procedimientos de actualización de la aplicación están en su lugar.

En lugar /
Normas de aplicación y la base de datos requeridos no / Verificada por:
Necesaria

Aplicaciones y bases de datos no tendrán medios para obtener acceso no autorizado ( “puertas traseras”).

El Operador de realizar un análisis de aplicaciones y bases de datos para determinar la criticidad, la sensibilidad
de datos, y el tipo de aplicación. Esta determinación será identificar si los requisitos de línea de base son
suficientes o si se aplicarán los requisitos críticos / sensibles adicionales. Categorizar sensibilidad de los datos
como:

- confidencial,

- restringido,

- público.
Nuevas aplicaciones y bases de datos, ya sea en la casa de diseño personalizado o comercial fuera de la plataforma, se
incorporarán medidas de seguridad, según lo establecido por las políticas y procedimientos de seguridad, a partir de la
etapa de desarrollo. Las medidas de seguridad deberán ser probados antes de que estas aplicaciones y bases de datos
se colocan en el entorno de producción.

Se requiere el cumplimiento de todas las aplicaciones y bases de datos, en el local desarrollado, o vendedor compró /
desarrollado.

Todas las aplicaciones basadas en roles requieren cuentas de usuario y contraseñas fuertes que proporcionan autenticación de
usuario que soporta la capacidad de hacer cumplir la separación de funciones.

deberán estar protegidos cuentas de usuario de aplicaciones. No almacene las cuentas de usuario y contraseñas en las tablas de
base de datos a menos que sea absolutamente necesario. Si es necesario almacenar las contraseñas en las tablas de base de datos,
entonces cifrar las contraseñas.

privilegio de administración de bases de datos (borrar, insertar, seleccionar y actualizar) el acceso se limitará al papel de
administrador de la base autorizada del operador.

Todo el acceso a datos restringidos o confidenciales a través de aplicaciones analíticas o de servicios públicos que carecen de
controles de acceso deberá ser gestionado a través del sistema operativo y / o funciones de control de acceso de base de datos.

aplicaciones basadas en roles requieren procedimientos de autorización de acceso y / o procesos de control de acceso para los
datos restringidas o confidenciales. El acceso deberá ser coherente con las responsabilidades del trabajo del usuario.

Los usuarios finales no tendrán la capacidad de acceder al código de la aplicación o bases de datos desde fuera de los
controles de la aplicación. Este acceso deberá estar restringido a personal autorizado (es decir, del sistema o de soporte
de aplicaciones de personal).

Todos los usuarios deberán ser identificados y autenticados antes de ser concedido el acceso de datos de la aplicación o
base de datos.

aplicaciones basadas en funciones o aplicaciones que acceden a datos confidenciales o restringidos deberán limitar el
acceso administrativo a la base por lo menos privilegiada aceptable para completar tareas administrativas.

“Todos los superusuarios /” cuentas de acceso estará limitado a sólo los administradores que necesitan un acceso ilimitado a fin
de satisfacer una necesidad de negocio.

Página 55 de 73
 56 S API ORMA 1164

Ejecutables serán restringidos de ejecuciones o alteraciones no autorizadas.

A título orientativo, las aplicaciones deben obligar a los usuarios no-operador después de 15 minutos de inactividad, siempre que sea
posible. El usuario deberá volver a autenticar antes de que se restablezca el acceso.

Cada operador debe asegurar que existe documentación para el uso y la administración de aplicaciones de
misión crítica.

Cada operador debe asegurar que existe documentación del sistema y programa. Esto incluye, pero no
se limita a:

- configuración de hardware y software,

- diseño de base de datos y estructura que incluye esquemas de bases lógicas y físicas,

- de mantenimiento y de modificación de procedimientos.

Cada operador garantizará una copia de seguridad y el plan de recuperación está documentado en consonancia con los
requisitos del negocio.

Todos los datos serán introducidos por los usuarios autorizados. La separación de funciones se mantendrá.

la validación y la integridad (por ejemplo, reglas de negocio) de datos se aplicarán acorde con los
requerimientos del negocio.

La solicitud deberá ser el único método de entrada de datos, supresión o actualización. Si se requiere la entrada de datos,
supresión o actualización de los datos fuera de los controles de la aplicación, a continuación, se aplican las normas de
gestión de cambios y problemas.

No se permitirán cambios a los archivos importados. Deben existir controles para evitar cambios no
autorizados en los archivos que se interfaz de un entorno de producción a otro.

La aplicación tendrá los controles internos implementados para asegurar que los datos son correctamente y con
precisión procesados.

Los datos confidenciales serán transmitidos de forma segura mediante el cifrado necesario, de conformidad
con la sección de cifrado bajo estándares informáticos, telefónicos y de uso de la red.
Sólo las cuentas del sistema (aquellos definidos y utilizados solamente por la aplicación o sistema operativo) será capaz de
ejecutar trabajos en segundo plano.

Se establecerán establecer interfaz / controles y procedimientos de transferencia para asegurar la pérdida de datos o se
detectan y corrigen la corrupción.

En lugar /
Normas de seguridad física requeridos no / Verificada por:
necesario

Información de la empresa en cualquier formato (papel, discos, cintas, etc.) deberán ser protegidas por todos los
empleados y contratistas a un nivel acorde con su valor.

Todos los servidores que ejecutan o datos confidenciales de vivienda deberán residir en centros de datos seguros, cuando estén
disponibles, o las salas de datos garantizados.

Medios, incluyendo discos duros de ordenador, que contienen información confidencial nivel deberán ser almacenados en un
entorno restringido el acceso (es decir, la bóveda, los centros de datos, caja fuerte).

Toda la información almacenada en los medios de comunicación se asume para ser clasificado como público y no necesita ser
etiquetado como tal. Todas las otras clasificaciones de información (restringido y confidencial) serán etiquetados apropiadamente en
los medios de comunicación.

Inmediatamente después de la reubicación permanente o temporal, un equipo de trabajo será asignado para llevar a cabo un barrido
final e inspección de todas las áreas de trabajo vacantes y muebles para asegurarse de que no hay activos de información
permanecen. Se debe tener cuidado al asignar la responsabilidad de todas las áreas comunes (por ejemplo, gabinetes de archivos
hall, salas de archivos, armarios, trasteros, etc.).

Siguiendo las reubicaciones permanentes y temporales todos los puertos de red y todas las líneas telefónicas deberán ser
desactivados inmediatamente después de la reubicación a menos de activación continuada está autorizado por el cliente paga
actualmente por el puerto de red y línea telefónica.

Durante los cambios de ubicación del espacio de trabajo, toda la documentación de control de inventario se actualiza para reflejar
los cambios realizados.

Página 57 de 73
 58 S API ORMA 1164

Todo SCADA de computación, telecomunicaciones, redes y centros debe ser monitoreada continuamente [24 horas al
día / siete (7) días a la semana]. Este seguimiento se puede hacer mediante cámaras con alarma, puertas y ventanas,
personas manejando los centros, o una combinación de los anteriores.

Cada centro de control SCADA debe tener un conjunto de procedimientos operativos para proteger los equipos que
contiene. Estos procedimientos deben incluir, pero no limitarse a, la consideración de los siguientes:

- prevención de fuego,

- detección de fuego,

- supresión de incendios,

- Los procedimientos de apagado,

- desastres naturales,

- terrorismo,

- servicios públicos (energía y agua),

- vandalismo,

- detección de agua.

centros de control SCADA deben estar equipados con puertas que se cierran automáticamente inmediatamente
después de haber sido abierto, y que una señal de alarma cuando se han mantenido abierto más allá de un período
de 30 segundos.

centros de control SCADA deben estar equipados con cámaras de vigilancia para controlar las entradas al
centro de control.

paredes incendio circundante centros de control SCADA deben ser incombustibles y resistentes al fuego para al menos
una (1) hora. Todas las aberturas a estas paredes (puertas, conductos de ventilación, etc.) deben ser de cierre y del
mismo modo nominal de al menos una (1) hora.

El acceso físico a la cinta magnética, disco y bibliotecas de documentación se limitará a los trabajadores cuyas
responsabilidades de trabajo requieren el acceso a estos lugares.
Todos los medios de almacenamiento de información (tales como discos duros, disquetes, cintas magnéticas, y CD-ROM)
que contienen datos confidenciales deberán estar asegurados físicamente del acceso no autorizado, cuando no esté en
uso. Una excepción se hará si esta información está protegida mediante un sistema de cifrado que cumple con los
estándares de encriptación.

El acceso a todos los puertos físicos utilizados en el ordenador y la red de equipo debe ser desactivada. Esto incluye puertos
Ethernet de los conmutadores, enrutadores y servidores de seguridad, así como los puertos de bus serie universal (USB) en
servidores.

Los edificios que albergan equipos de la empresa o de los sistemas de comunicación deberán estar protegidos con
medidas de seguridad físicas que impiden que personas no autorizadas tengan acceso al edificio.

El acceso físico a todas las habitaciones que contienen los sistemas informáticos de la compañía, el cableado o equipo
de comunicaciones [armarios de cableado, cambio de marca privada (PBX) habitaciones, etc.] será cerrada en todo
momento con acceso restringido al personal autorizado. Los propietarios de estos equipos deberán mantener una lista
de las personas autorizadas para acceder y revisar esta lista sobre una base de dos veces al año.

Todos los empleados, contratistas y visitantes en instalaciones de la empresa deberán llevar etiquetas de identificación en todo
momento. cardkeys perdidos o dispositivo de autorización de acceso equivalente deberán ser reportados dentro de 24 horas
para el oficial de seguridad local aplicable.

El acceso se revocará de inmediato, en ningún caso después de 24 horas, una vez que el acceso ya no
es necesaria. Es responsabilidad del supervisor inmediato ver que cardkeys se recuperan y se cancelan
para los empleados y contratistas despedidos o transferidos.

El personal autorizado no permitirán que las personas desconocidas o no autorizadas en áreas restringidas sin
escolta. Personal sin una razón válida para estar en la sala de ordenadores serán llevados fuera de la sala de
ordenadores de inmediato y personal de seguridad apropiadas en contacto.

En lugar /
Normas de autenticación requeridos no / Verificada por:
necesario

Las cuentas de usuario podrán ser creados únicamente con la documentación a través de un formulario que identifica:

- la identidad del usuario,

Página 59 de 73
 60 S API ORMA 1164

- que se ha autorizado la adición de la cuenta de usuario.

Las cuentas de usuario se pueden desactivar la terminación del empleo.

Las cuentas de usuario se revisarán y un proceso en el lugar para desactivar si está inactivo durante más de 90 días
si es apropiado.

Cada cuenta de usuario de la computadora y el sistema de comunicación (la única excepción de las cuentas administrativas
obligatorias) identificará de forma única un solo usuario. cuentas de usuario compartidas o de grupo no son el estado deseado,
pero pueden ser permitidos para la consola. Los usuarios tampoco se les permite compartir su contraseña con nadie más.

Cada cuenta de usuario de la computadora y el sistema de comunicación será única y exclusivamente para
siempre conectada con el usuario al que se le ha asignado. Después de un empleado o contratista deja la
compañía, no habrá re-utilización de las cuentas de usuario asociadas con ese empleado o contratista, a no
ser reasignado a la misma persona.

Los usuarios son responsables de todas las actividades realizadas con sus cuentas de usuario personales. Las cuentas de usuario no
pueden ser utilizados por cualquier persona, pero los individuos a los que se han emitido. Los usuarios no deben permitir que otros para
llevar a cabo cualquier actividad con sus cuentas de usuario.

Los usuarios con acceso privilegiado (administradores del sistema) se les asignará una cuenta separada, único, diferente de su
cuenta sin privilegios. sistemas de información de la empresa deberán utilizar una convención de nomenclatura para las cuentas de
usuario con privilegios consistentes con los estándares de identificador de usuario del propietario del dominio.

Siempre que sea posible, (dependiendo del sistema operativo) los usuarios con acceso a superusuario o cuentas privilegiadas
(administradores del sistema) deberán usar su cuenta personal para acceder a los sistemas. Luego, los administradores
deberán cambiar la cuenta corriente a la cuenta privilegiada según sea necesario.

Los usuarios con acceso privilegiado (administradores del sistema) usarán privilegios especiales sólo cuando actúan como
administradores; van a utilizar sus cuentas de usuario no privilegiados con privilegios limitados para el trabajo normal.
Siempre que sea posible, el administrador iniciar sesión con sus cuentas de usuario no privilegiados y luego actualizar a la
cuenta privilegiada según sea necesario.

El uso de cuentas de superusuario / administrativas que no son asignados de forma única a un individuo estará limitada a
sólo aquellas situaciones absolutamente necesarias para mantener la operación de gasoductos.
reglas de complejidad se llevarán a cabo dentro de la funcionalidad del sistema operativo. Si un sistema no tiene ninguna
funcionalidad de complejidad de contraseñas (o es insuficiente), entonces serán implementado un filtro de contraseña u otro
control de compensación.

Los usuarios generales y administradores:

- expiración de la contraseña: 90 días,

- ocho (8) longitud mínima de caracteres,

- contraseñas se componen de una combinación de letras y números y pueden incluir símbolos,

- capacidades de historial de contraseñas serán habilitadas y los últimos 12 contraseñas cifradas almacenadas por
usuario.

cuenta de servicio (host-a-host cuentas de transferencia de datos):

- expiración de la contraseña: cuando una persona que conoce los papeles cambios de contraseña,

- longitud mínima de 14 caracteres,

- contraseñas se componen de una combinación de letras y números y símbolos,

- cuando existe la capacidad del sistema historial de contraseñas se habilita y con los últimos 12 contraseñas
cifradas almacenadas por usuario.

Si el cifrado plataformas de sistemas operativos o aplicaciones de apoyo, entonces los archivos de contraseñas estarán
protegidos y encriptados.

Las contraseñas en tránsito serán codificadas dentro del paquete o transmitidos a través de un conducto de cifrado
[como capa de conexión segura (SSL)].

contraseñas por defecto de aplicaciones, sistemas operativos, sistemas de gestión de bases de datos (DBMS) u otros
programas deberán cambiarse inmediatamente después de la instalación.

La combinación de una cuenta de la compañía y la contraseña no se utilizará para la autenticación en

las páginas externas.

contraseñas de inicio de sesión inicial y restablecer deberán seguir las reglas de complejidad de contraseñas y requieren que el usuario
cambie la contraseña inmediatamente.

Al crear contraseñas fuertes evitar el uso de la siguiente hora de crear una fuerte

Página 61 de 73
 62 S API ORMA 1164

contraseña.

- Palabras fácilmente asociados con la empresa, ID de cuenta de propietario, dirección o nombre de usuario.

- palabras del diccionario o nombres propios.

- combinaciones Calendario, por ejemplo jan2001, feb2001, etc.

- números secuenciales con las palabras, por ejemplo word0001, word002, word003, etc., o 001word,
002word, 003word, etc.

- Las contraseñas que son demasiado similares. Hacer al menos tres caracteres totalmente diferente a la
contraseña anterior.

- patrones o palíndromos repetidas, por ejemplo aaa1aaa.

Los usuarios son los propietarios de sus contraseñas. Como tal, que:

- no deben compartir sus contraseñas con otros;

- no deberá escribir la contraseña en cualquier lugar disponible;

- deberá ser consciente de su entorno y de las situaciones en las que la contraseña puede ser extraída de la
observación, etc .;

- no podrá incrustar contraseñas en archivos / scripts.

se permite un cambio de contraseña de usuario por sistema o aplicación por día.

los administradores de sistemas informáticos deberán crear las contraseñas de usuario iniciales que son un mínimo de
ocho (8) caracteres de longitud y se componen de letras, números y caracteres especiales (siempre que sea
técnicamente posible).

contraseñas iniciales no serán fácilmente asociados con la empresa o el usuario (es decir, número de la seguridad
social, número de empleado, dirección, equivalente numérico del nombre, etc.).

Cuando sea técnicamente factible, los nuevos usuarios se ven obligados por el sistema están accediendo a cambiar su
contraseña inicial a uno que cumpla con los estándares de contraseña.

Todas las contraseñas por defecto suministrados con hardware y software deben ser cambiados con la instalación para cumplir
con los estándares de contraseñas empresa.

El uso de un código de frase de paso en el que una letra, número o símbolo de cada palabra de la frase se
utiliza en la contraseña es una buena práctica.
Para las consolas no operador, en cinco (5) errores de autenticación consecutivos, los usuarios serán
bloqueados del recurso en el que están tratando de obtener acceso.

Los usuarios deberán demostrar un caso de negocio justificable con el fin de obtener el permiso del propietario
información para acceder a los datos SCADA.

Cuando los usuarios subvenciones operador de acceso a los datos SCADA, dicha autorización deberá ser documentada a través de un
formulario que identifica:

- que está solicitando acceso,

- lo que están solicitando acceso a,

- que ha aprobado el acceso.

El operador debe garantizar que los destinatarios previstos de la información tienen el derecho y deben conocer la
información que se proporciona antes de conceder el acceso. El derecho a conocer principio se puede equiparar a un modelo
de negocio justificable. Si el usuario necesita acceder a la información para llenar un negocio de buena fe tiene por qué
entonces ese usuario tendrá acceso.

Los datos y la información no serán utilizados, o acceder a utilizar, excepto por los empleados y / o contratistas
autorizados en su trabajo asignado y la responsabilidad sobre la necesidad de conocer, necesidad-a-ver, o base de la
necesidad de usar.

Los operadores son responsables de revisar los privilegios del sistema en forma semestral y revocará inmediatamente a
todos los privilegios ya no son necesarios los usuarios, incluidos los administradores del sistema. Los exámenes se
realizan sobre una base semi-anual debido al entorno empresarial en constante cambio y la importancia de los datos.
Es responsabilidad de los administradores de sistemas para asegurar que los operadores disponen de los informes
adecuados para revisar todos los accesos de usuario.

Los privilegios de acceso serán revisados ​después de la transferencia de los empleados o de reasignación de trabajo.

El operador deberá quitar el acceso a la información tan pronto como sea que el acceso ya no es necesaria. Es
responsabilidad del tanto al usuario como al operador ver que los privilegios de acceso están alineadas con las
necesidades del negocio y se asignan sobre la base de la necesidad de saber.

Página 63 de 73
 64 S API ORMA 1164

En lugar /
Normas de seguridad personal requeridos no / Verificada por:
necesario

El departamento de recursos humanos facilitará información segura y confidencial manejo de las políticas en la
introducción de nuevos individuos a la empresa. Todos los nuevos empleados recibirán una copia de las políticas
de seguridad de la información y / o materiales de sensibilización de seguridad apropiadas para su posición y su
papel dentro de la empresa y reconocer que entiendan sus responsabilidades como se indica en las políticas y
normas.

Una comunicación de seguridad personal y la política de formación que define los roles, responsabilidades, condición para el
empleo, la contratación de los procesos de selección, y esboza un programa de entrenamiento está en su lugar.

Cada unidad de reporte debe establecer y mantener un proceso para registrar todos los empleados y contratistas de
acceso a los sistemas de información y datos, así como, asignado propiedad de la compañía, incluyendo, pero no
limitado a:

- tarjetas de acceso,

- tarjetas de crédito / de llamadas,

- llaves,

- ordenadores portátiles / ordenadores de sobremesa,

- asistentes digitales personales (PDA),

- móviles,

- acceso remoto.

El supervisor o administrador notificará a todos los operadores que han concedido acceso a los sistemas de información
o datos de revocar inmediatamente dicha acceso en el caso de terminaciones, o revocar / modificar dicho acceso en el
caso de las transferencias.

El supervisor o gerente recogerá artículos emitidos al empleado, contratista o tercero, como ordenadores
portátiles, software, datos, documentación, manuales, tarjetas inteligentes, dispositivos de mano, etc.
Cuando los usuarios con acceso a información confidencial o restringida se transfieren o terminados, el supervisor del empleado
o el patrocinador del contratista deberán coordinar directamente con el operador de la fecha para la eliminación de los derechos
de acceso de los usuarios. Si el usuario va a ser despedido, el acceso a continuación, se revocará antes que el usuario es
notificado de la terminación.

Para situaciones en las que los usuarios con acceso a los centros de datos se transfieren o terminados, se revoca el
supervisor del empleado o el patrocinador del contratista notificará a la seguridad local para garantizar el acceso a
las áreas protegidas.

Cuando un empleado abandona cualquier posición en la empresa, el gerente del departamento revisará ambos
archivos residentes informáticos y archivos de papel para determinar quién será el custodio de dichos archivos.

controles de acceso físico se aplicarán a las instalaciones de la empresa donde se almacenan los activos de
información. Estos controles deberán ser compatibles con la compañía de seguridad política de personal y los
bienes.

En lugar /
Clasificación de la información y las normas de aplicación de criticidad requeridos no / Verificada por:
Necesaria

Toda la información de producción dentro de la empresa tendrá un dueño de Información designado. responsabilidades
de los propietarios de información se detallan en las funciones de protección de la información y las normas
responsabilidades.

Las operaciones deberán compilar y mantener un catálogo repositorio de datos o de alto nivel de descripción de
información confidencial y restringido. Este catálogo deberá ser revisado y actualizado anualmente.

La información no puede ser rebajado a una clasificación más baja, sin someterse a un esfuerzo de evaluación de riesgo
patrocinado por el propietario de la información.

Operador deberá asignar la criticidad de aplicación y las clasificaciones de sensibilidad de datos.

Página sesenta y cinco de 73

 66 S API ORMA 1164

En lugar /
Normas de conectividad de red requeridos no / Verificada por:
necesario

Una DMZ se establece entre confianza, la red privada de la empresa e Internet.

Tanto en host y los IDS basado en red deben desplegarse en la zona desmilitarizada.

Dos dispositivos de filtrado de tráfico (es decir, de router y firewall) se debe utilizar en la serie para filtrar el tráfico
entrante y saliente y para restringir el acceso sólo a los recursos necesarios.

El monitoreo debe ocurrir por desplazamiento del tráfico de un no fiable a zona de confianza.

El acceso de terceros se limitará a sólo los recursos necesarios para satisfacer las necesidades del negocio.

Un interruptor no deberá ser configurado para gestionar simultáneamente interna, DMZ y el tráfico externo.

arquitectura de red deberá ser diseñado para reducir al mínimo la posibilidad de que un solo punto de fallo evitaría
cualquier sistema crítico de cumplir con su función.

Con la excepción de los quioscos, todos los usuarios deberán autenticarse en la red antes de acceder
a los recursos de red.

ordenadores SCADA deben ser auditados periódicamente y actualizadas de los parches de seguridad y correcciones calientes.

Todas las ACL de dispositivos de red deben estar documentados. La documentación debe incluir el propósito de cada
regla, las interdependencias, y consideraciones de seguridad dirigidas.

Donde no se han definido los requisitos de seguridad, no se permiten las conexiones sin explícita,
revisión y aprobación documentada.
Todas las redes inalámbricas estarán adecuadamente asegurados.

Todo el acceso remoto al sistema SCADA deberá ser aprobado antes de su implementación.

Todo el acceso remoto al sistema SCADA deberá utilizar la autenticación fuerte.

Los operadores deberán mantener una lista de usuarios con acceso remoto.

Los sistemas remotos no se pueden configurar para que se conecte automáticamente al sistema SCADA de entrada
sin la autentificación de un usuario autorizado.

Las revisiones periódicas deben producirse para identificar el acceso no autorizado al sistema SCADA.

Las revisiones periódicas deben ocurrir para asegurar la documentación de la red es actual.

En lugar /
Sistema de Auditoría de Seguridad y revisar las normas requeridos no / Verificada por:
necesario

Registros que contienen eventos relevantes ordenador o sistema de comunicaciones de seguridad se conservarán durante un período
tal como se define en la política de retención de información. Registros deberán estar asegurados para evitar la modificación. Sólo se
permiten personal autorizado para revisar estos registros. Estos registros son importantes para la corrección de errores, recuperación
de violación de la seguridad, investigaciones y esfuerzos relacionados.

Todos los empleados de la compañía deberán vigilar e informar con prontitud, cualquier incidente de seguridad potenciales,
incluyendo virus, intrusiones, y fuera de cumplimiento situaciones inmediatamente utilizando informes de las empresas incidente,
escalada, y los procedimientos de resolución.

Registros de actividad de los usuarios el acceso se mantendrán para aquellos usuarios que la información de acceso
restringido o confidencial, de conformidad con los requisitos establecidos por la política de retención de la información de
la compañía. El operador revisar estos registros en una base mensual y se mantendrá en estos registros.

Página 67 de 73
 68 S API ORMA 1164

El operador es responsable de la supervisión y el registro de la actividad del sistema con el fin de descubrir los eventos
de seguridad. sólo las personas autorizadas con la aprobación previa de la gerencia evaluarán y / o el uso de pruebas /
software de monitorización de red o hardware.

En lugar /
Contratistas, proveedores, consultores, y las Normas de terceros requeridos no / Verificada por:
Necesaria

Todos los contratos relativos a los servicios de seguridad de la información y los productos deberán cumplir las políticas de
seguridad aplicables a todos los operadores.

La aprobación por parte del operador se obtendrá si los servicios prestados por los contratistas pueden o afectarán a la
información confidencial.

El gerente responsable del contrato con el contratista velará por que el contrato especifique el
cumplimiento de todas las políticas y acciones a tomar para violaciónes.

La propiedad del software desarrollado por los contratistas se definirá en el acuerdo de contrato.

Contratistas que tienen acceso a información de la compañía serán obligados por contrato a mantener las políticas de
seguridad de la información del operador. La aprobación de la lengua contractual se obtiene a partir departamento legal
del operador.

El operador deberá revisar periódicamente el cumplimiento del contratista con las políticas de seguridad de la información del
operador.

Contratistas estarán sujetos a las restricciones de acceso requeridos para cumplir con las condiciones del contrato.

Cada empresa contratista y los empleados de la misma, realizando servicios para el operador deberá firmar un acuerdo
de confidencialidad de acuerdo con las políticas de seguridad del operador.
 En lugar /
Normas de uso del ordenador y de la red requeridos no / Verificada por:
Necesaria

El uso personal de la computación SCADA y recursos de comunicación no debe permitirse.

Está prohibido el uso de los recursos informáticos y de comunicaciones SCADA del operador para las siguientes
actividades:

- actividades no éticas o ilegales,

- intentar acceder a información no autorizada para ver,

- divulgación no autorizada de información confidencial o restringida,

- cualesquiera otras actividades prohibidas por las políticas de seguridad del operador.

escáneres de virus y / o programas de detección deben ser instalados cuando su aplicación no causa
perturbación o impacto negativo en el funcionamiento del sistema SCADA. Si no se utilizan, deben tomarse
otras medidas para aislar o proteger el sistema contra virus.

Cualquier archivo de fuera del sistema SCADA se escanean y se verifican en busca de virus y autenticidad antes de la
instalación o ejecución. medios de almacenamiento externos deben ser escaneados y verificados antes de su uso.

En lugar /
Normas ordenador, teléfono, y el uso de la red requeridos no / Verificada por:
Necesaria

Antes de ser dado la oportunidad de conectarse a cualquier ordenador SCADA operador, los usuarios deberán presentarse con una
pancarta de inicio de sesión de acuerdo con la política de seguridad del operador, o un banner que dice:

- el sistema SCADA es para ser utilizado sólo por usuarios autorizados;

- al continuar usando el sistema SCADA, el usuario declara que él / ella es un usuario autorizado;

- uso del sistema SCADA constituye el consentimiento a la supervisión.

La siguiente es una forma aceptable de un mensaje de login en lugares de Estados Unidos:

“Este sistema SCADA es para uso exclusivo de los usuarios autorizados. Cualquier persona que utiliza este
sistema, por tal uso, reconoce y consiente a la derecha de la empresa

Página 69 de 73
 70 S API ORMA 1164

supervisar, acceder, utilizar y revelar cualquier tipo de información generada, recibida o almacenada en los
sistemas, y la renuncia a cualquier derecho de privacidad o expectativa de privacidad por parte de ese individuo en
relación con su uso de este sistema. El uso no autorizado y / o inadecuado de este sistema, según lo delineado por
las políticas corporativas, no se tolera y la empresa puede tomar acción formal contra estas personas “.

ubicaciones fuera de Estados Unidos pueden tener leyes específicas que regulan el uso y control del sistema. departamentos
legales en lugares fuera de Estados Unidos deben revisar el banner de texto de inicio de sesión, modificar la redacción banner
para cumplir con las leyes locales, y documentar las modificaciones. referencia legal responsable de la modificación de la
bandera deberá ser citado.

Los administradores de sistemas son responsables de implementar el mensaje de login y cualquier modificación.

Identificación del operador, sistema de información específico, la red, la ubicación o anfitrión no debe aparecer antes de un
inicio de sesión correcto.

Los sistemas se configuran no proporcionar ninguna información acerca de un inicio de sesión fallido. Esto incluye
identificar qué parte de la secuencia de inicio de sesión (cuenta de usuario o contraseña) era incorrecta.

Cuando se utiliza el cifrado se debe aplicar mediante los métodos estándar de la industria más segura
compatibles con el sistema SCADA.

Restringido o información confidencial debe ser cifrado cuando se almacena o transmitida

fuera del sistema SCADA.

El operador deberá cumplir con la política del operador para la retención de la información y el programa de
administración de registros de la compañía que establece horarios y requisitos de los registros comerciales de la
empresa de retención y destrucción.

medios de almacenamiento de información electrónica deberán ser desechados de una manera acorde con la clasificación
de la información almacenada en el más alto de los medios.

Todos los medios electrónicos que ha almacenado información confidencial deben ser destruidos físicamente si, en el momento de la
eliminación de los medios de comunicación, que la información todavía se considera confidencial.

Todos los medios electrónicos que ha almacenado información restringida deben ser al menos desmagnetizado o eliminados si, en el
momento de la eliminación de los medios de comunicación, que la información todavía se considera dinero restringido. Si los medios de
comunicación no pueden ser borrados o desmagnetizado, los medios de comunicación será destruido físicamente.
PC / portátiles fuera de las zonas controladas por la seguridad SCADA no deberá quedar sin vigilancia sin invocar un
bloqueo de terminal o protegido por contraseña salvapantallas. El funcionamiento de sistemas que permiten que la estación
de trabajo que va a bloquear, y proporcionando de este modo el mismo nivel de protección que un sistema operativo que
requiere autenticación antes de arranque, son aceptables.

PCs / portátiles y servidores fuera de las zonas controladas por la seguridad SCADA, cuando sea posible, se deben configurar
con una contraseña protegida de protector de pantalla. El protector de pantalla requerirá la introducción de una contraseña
después de una consola PC / ordenador portátil o servidor haya permanecido inactivo durante 10 minutos.

Página 71 de 73
72 S API ORMA 1164

Recursos adicionales

Los siguientes enlaces proporcionan un buen punto de partida para obtener información adicional. Como enlaces de Internet cambian, se sugiere que el usuario
debe comenzar con el sitio web de las organizaciones para la versión actualizada o descubrir otras referencias.

[1] gobierno australiano patrocinado (8 páginas) guía corta para los CEOs y Consejos de Administración que explican mejor los riesgos de
seguridad asociados a los sistemas de control,
http://www.wurldtech.com/library/pdf/SCADA%20Security%20Advice%20for%20CEO's.pdf

[2] Plan de Protección de la Infraestructura Nacional (NIPP) proporciona el enfoque coordinado que se utiliza para
establecer las prioridades nacionales, los objetivos y requisitos, www.dhs.gov/xlibrary/assets/NIPP_Plan.pdf

[3] Instituto Nacional de Estándares y Tecnología (NIST)-Computer Seguridad División Especial

800 series de publicaciones. Muchas de las normas que existen temas de seguridad específicos de direcciones. Por ejemplo, los más comunes
incluyen 800 documentos de la serie 800-53, Sistemas de Computación Federal; 800-82, seguridad y privacidad Los controles para los sistemas y
organizaciones de Información Federal; 800-53,
Normas de control industriales; y 800-97 Inalámbrico. http://csrc.nist.gov/publications/PubsSPs.html

[4] Norte América Consejo de Confiabilidad (NERC) la lista de vulnerabilidades y mitigaciones,

http://www.esisac.com/publicdocs/Top_10_vuln_2006_16mar2006_ss.pdf

[5] Departamento de Energía de Estados Unidos de 21 pasos para mejorar la seguridad cibernética de Redes SCADA, incluye
propietarios importante del sistema de control deben tomar medidas, y se hace referencia en un anexo a principios de este documento,

http://www.oe.netl.doe.gov/docs/prepare/21stepsbooklet.pdf

[6] Una iniciativa de colaboración entre la industria y el Departamento de Energía, un estadounidense Hoja de ruta para asegurar los
sistemas de control en el sector de la energía es un recurso común, http://www.controlsystemsroadmap.net/

[7] Departamento de Seguridad Nacional de Estados Unidos, sitio web del Programa de Seguridad de los Sistemas de Control contiene

numerosas publicaciones sobre la seguridad cibernética,

http://www.us-cert.gov/control_systems/csdocuments.html#docs

[8] El intercambio de información y el Centro de Análisis Multi-Estado, http://www.msisac.org/, tiene una variedad de recursos que incluyen las
especificaciones de compras específicas para los aspectos de los sistemas de control, preparado por el Departamento de Seguridad Nacional y el
Laboratorio Nacional de Idaho Estados Unidos, con apoyo activo de Chief Information Security Officer Nueva York Unidos,

http://msisac.org/scada/documents/12July07_SCADA_procurement.pdf

[9] Reino Unido Centro para la Protección de la Infraestructura Nacional ha creado el Control de procesos
y las Directrices de Seguridad SCADA-Buenas Prácticas,
http://www.cpni.gov.uk/ProtectingYourAssets/scada.aspx

[10] Sin-Ciber seguridad de la información y la formación, http://www.sans.org

[11] Informe AGA 12, http://www.aga.org

[12] Instituto Americano del Petróleo, Orientación de seguridad para la industria petrolera, Tercera edición, abril de
2005
[13] La Sociedad Internacional de Automatización Directrices (ISA) de la tubería de seguridad tales como ISA / IEC-62443,
anteriormente identificado como la serie ISA-99 de las normas

Informe de protección de infraestructuras críticas Oficina de Responsabilidad [14] Gobierno de Estados Unidos para el Congreso
GAO-04-354, marzo de 2004

[ 15 ] Interestatal Asociación de Gas Natural de América (INGAA) Guía de seguridad Sistemas de Control de Ciber para la Industria del
Gasoducto

Página 73 de 73