Documentación técnica. Nota explicativa del proyecto técnico Nota explicativa del ejemplo de especificación técnica
El objetivo principal del documento de Nota Explicativa es proporcionar información general sobre el sistema y justificación de las decisiones técnicas tomadas durante su desarrollo. Por lo tanto, la base para el desarrollo de la Nota Explicativa serán principalmente los Términos de Referencia.
La nota explicativa es uno de los documentos más importantes del proyecto técnico. El diseño técnico se desarrolla con el objetivo de identificar soluciones técnicas finales que proporcionen una imagen completa del diseño del producto.
Al desarrollar un programa para crear una nota explicativa, se recomienda utilizar GOST 19.404-79 “Nota explicativa. Requisitos de contenido y diseño."
Para crear una nota explicativa de un proyecto técnico que describa un sistema automatizado (SA), se recomienda utilizar la norma RD 50-34.698-90 “Sistemas automatizados. Requisitos para el contenido de los documentos".
Muchas secciones de los documentos anteriores se superponen, por lo que como ejemplo consideraremos el documento Nota explicativa creado sobre la base del RD 50-34.698-90.
1. Disposiciones generales
1.1 Nombre del altavoz diseñado
Esta sección del documento de Nota Explicativa contiene el nombre completo y abreviado del AS.
Por ejemplo: “En este documento el sistema que se está creando se denomina Portal de Información Corporativo. También está permitido utilizar el nombre abreviado "KIP" o "Sistema".
1.2 Documentos a partir de los cuales se diseña el sistema
Esta sección del documento de Nota Explicativa debe contener referencias al contrato y Términos de Referencia para el desarrollo de un sistema automatizado.
1.3 Organizaciones involucradas en el desarrollo de sistemas.
Esta sección del documento de Nota explicativa indica los nombres de las organizaciones de clientes y desarrolladores.
1.4 Objetivos del desarrollo de AS
En este apartado del documento Nota Explicativa se deben indicar los beneficios técnicos, económicos y de producción que recibirá el cliente luego de implementar el sistema desarrollado.
Por ejemplo: “El propósito del sistema que se está creando es:
- optimización del flujo de documentos de la empresa;
- apoyo a la cultura corporativa de la empresa;
- Optimización de las comunicaciones entre los empleados de la empresa. »
1.5 Propósito y alcance de uso del sistema de altavoces desarrollado
Esta sección del documento de Nota Explicativa debe incluir una descripción del tipo de actividad que se automatiza y una lista de los procesos para los cuales el sistema pretende automatizar.
Por ejemplo: “KIP está diseñado para proporcionar información completa y oportuna, así como una organización eficaz del trabajo de los empleados. El sistema debe garantizar la organización del trabajo conjunto de los empleados utilizando las siguientes capacidades:
- Creación de conferencias para discutir temas;
- Envío/Recepción de mensajes de correo electrónico;
- Garantizar la colaboración en los documentos;
- Coordinación de documentos;
- Mantener registros de la documentación entrante y saliente”.
1.6 Información sobre los documentos reglamentarios y técnicos utilizados en el diseño.
Esta sección debe indicar los estándares que se utilizaron para crear el documento de Nota Explicativa.
Por ejemplo: “Durante el diseño se utilizaron los siguientes documentos reglamentarios y técnicos:
- GOST 34.201-89 “Tecnología de la información. Conjunto de normas para sistemas automatizados. Tipos, integridad y designaciones de documentos al crear sistemas automatizados";
- GOST 34.602-89 “Tecnología de la información. Conjunto de normas para sistemas automatizados. Especificaciones técnicas para la creación de un sistema automatizado";
- GOST 34.003-90 “Tecnología de la información. Conjunto de normas para sistemas automatizados. Sistemas automatizados. Términos y definiciones";
- GOST 34.601-90 “Tecnología de la información. Conjunto de normas para sistemas automatizados. Sistemas automatizados. Etapas de la creación";
- RD 50-682-89 “Instrucciones metodológicas. Tecnologías de la información. Un conjunto de normas y directrices para sistemas automatizados. Provisiones generales";
- RD 50-680-88 “Instrucciones metodológicas. Sistemas automatizados. Disposiciones básicas";
- RD 50-34.698-90 “Instrucciones metodológicas. Tecnologías de la información. Un conjunto de normas y directrices para sistemas automatizados. Sistemas automatizados. Requisitos para el contenido de los documentos."
1.7. Secuencia de creación del sistema.
Para sistemas creados en varias iteraciones, la Nota Explicativa debe indicar la cantidad de trabajo para cada iteración. Por otra parte, es necesario destacar el trabajo previsto para esta iteración.
Por ejemplo: “La implementación del proyecto Portal de Información Corporativo está prevista en dos etapas.
La primera etapa de la instrumentación incluye la organización del trabajo conjunto de los empleados de la empresa mediante la introducción de capacidades tales como:
- Mensajería instantánea;
- Organización de la conferencia;
- Envío/recepción de correo electrónico;
- Coordinación de documentos utilizando el Sistema.”
2 Descripción del proceso de la actividad
Esta sección del documento de Nota Explicativa debe reflejar los procesos y funciones automatizadas por el sistema a lo largo de todo el proceso comercial.
Para ilustrar el material en la nota explicativa, se permite utilizar notaciones UML, ARIS o IDF0, así como imágenes esquemáticas creadas utilizando aplicaciones estándar (Visio).
Para comprender la relación entre funciones automatizadas y no automatizadas en el documento de Nota explicativa, es necesario distinguir claramente entre acciones del usuario y acciones del sistema.
Por ejemplo: “1. El usuario crea un documento.
- El usuario inicia el proceso de envío de un documento para su aprobación.
- El sistema cambia el estado del documento a "para aprobación". »
- Principales soluciones técnicas.
2.1. Decisiones sobre la estructura del sistema y subsistemas.
Esta sección del documento Nota Explicativa proporciona soluciones sobre la estructura funcional del sistema y sus subsistemas.
2.2. Medios y métodos de interacción entre los componentes del sistema. Interconexión con sistemas externos
En este apartado del documento Nota Explicativa es necesario indicar una lista de sistemas con los que debe interactuar el producto creado. Al describir la interacción de los componentes del sistema en la Nota Explicativa, es necesario indicar el formato de intercambio de datos.
Por ejemplo: “Como parte de la interacción de instrumentación y sistemas externos, se utilizan las siguientes tecnologías:
- “Contabilidad empresarial”: intercambio de archivos en el formato XML/Excel establecido”.
2.3. Decisiones sobre modos de funcionamiento.
Esta sección del documento de Nota Explicativa incluye una lista y descripción de los modos de funcionamiento del sistema. Por lo general, se distinguen los siguientes modos: modo normal, modo de operación de prueba, modo de servicio. La nota explicativa deberá proporcionar una descripción tanto del propio régimen como de los supuestos en los que se introduce.
2.4. Decisiones sobre el número, calificaciones y funciones del personal de la central nuclear.
Esta sección del documento Nota Explicativa regula las actividades del personal funcional y de mantenimiento. La nota explicativa debe indicar la categoría de empleados que pertenece a un tipo particular de personal y describir sus funciones en el marco del sistema.
Por ejemplo: “El administrador del portal es responsable de:
- integridad de la base de datos y del software;
- medidas preventivas para garantizar la seguridad de los datos;
- distribución de derechos de acceso y registro de usuarios en el sistema. »
2.5. Asegurar las características del consumidor del sistema especificadas en las especificaciones técnicas.
Esta sección del documento Nota Explicativa se crea sobre la base de los requisitos de calidad del producto especificados en las especificaciones técnicas. Aquí es necesario describir el parámetro mediante el cual se determina la calidad del sistema. La nota explicativa también indica las soluciones mediante las cuales se logró esta característica en el sistema.
Por ejemplo: "La tolerancia a fallos y la operatividad de los módulos de software de instrumentación se garantizan mediante el uso de plataformas de software industrial IBM WebSphere Portal, Enterprise Oracle 10g".
2.6. Composición de funciones y conjunto de tareas implementadas por el sistema.
Esta sección del documento Nota explicativa contiene una lista de tareas que resuelve el sistema. En la nota explicativa, las funciones y un conjunto de tareas se pueden presentar en forma de lista sin numerar.
2.7. Decisiones sobre un conjunto de equipos técnicos y su ubicación en el sitio.
Esta sección del documento de Nota Explicativa contiene decisiones sobre la arquitectura técnica del sistema y requisitos para el conjunto de medios técnicos necesarios para garantizar su correcto funcionamiento.
Se recomienda colocar los requisitos para un conjunto de medios técnicos en la nota explicativa en forma de tabla.
Por ejemplo: "
|
Equipo |
Especificaciones técnicas |
|
Servidor de base de datos |
|
|
Versión de montaje en bastidor |
No más de 4U |
|
Arquitectura del procesador |
RISC (64 bits) |
|
frecuencia de la CPU |
al menos 1,5 GHz |
|
caché de la CPU |
Al menos 1 MB |
|
SO |
Ventanas 2003 SP2 |
|
Número posible de procesadores instalados |
Al menos 4 |
|
Número de procesadores instalados |
|
|
Posible capacidad de RAM |
32 GB con ECC |
|
capacidad de RAM |
Mínimo 8GB |
|
Disponibilidad de interfaces |
Interfaces Ethernet 10/100/1000 Base-T 2 uds.; |
|
Tarjeta de video: |
Al menos 8 MB. |
|
Posible número de discos duros instalados |
Al menos 4 |
|
Número de discos instalados |
|
|
Lector |
|
|
Fuente de alimentación |
Parámetros de entrada: |
»
Al describir la ubicación de objetos de un complejo de medios técnicos en la nota explicativa, es necesario guiarse por los requisitos de SNiP 11-2-80 para edificios de categoría "B".
2.8. Volumen, composición, métodos de organización, secuencia de procesamiento de la información.
El soporte de información incluye soporte de información dentro y fuera de la máquina. El soporte de la información interna es proporcionado por la Base de Datos (DB), documentos de entrada y salida provenientes de sistemas externos.
La base de información fuera de máquina está formada por datos contenidos en documentos en papel. A menudo, cuando se desarrollan sistemas automatizados, solo se utiliza una base de información interna, por lo que el énfasis principal en el documento de Nota explicativa debe estar en el contenido de esta sección.
Al describir la base de información interna en el documento de Nota Explicativa, es necesario indicar los documentos y mensajes de entrada y salida para todos los subsistemas y sistemas externos.
Por ejemplo: “La información de entrada para el subsistema de gestión de documentos electrónicos es:
- versiones electrónicas de documentos del flujo de trabajo de producción;
- firma digital electrónica;
La información de salida para el subsistema de gestión de documentos electrónicos es:
- documentar el registro del historial del ciclo de vida;
- registro del historial de aprobación de documentos;
- Archivo de la versión electrónica del documento en formato RTF. »
2.9. Composición de productos de software, lenguajes operativos, algoritmos de procedimientos y operaciones y métodos de su implementación.
Esta sección del documento de Nota Explicativa debe proporcionar tecnologías y medios para desarrollar el sistema.
Por ejemplo:
«
- Servidor de base de datos: Oracle 10g
- Portal: Websphere Portal Ampliar v6.0.
- Modelado de Negocios: ARIS
»
3 Medidas para preparar el objeto de automatización para la puesta en funcionamiento del sistema
Esta sección del documento de Nota Explicativa describe las siguientes actividades:
- medidas para llevar la información a un formato adecuado para el procesamiento informático;
- actividades de formación y prueba de las cualificaciones del personal;
- medidas para crear las unidades y puestos de trabajo necesarios;
- medidas para cambiar el objeto de automatización;
- otras medidas basadas en las características específicas de los sistemas que se están creando
27.10.2016 09:57:23
Este artículo analiza la etapa técnica del proyecto, que se relaciona con una de las etapas del ciclo de vida del sistema de seguridad de la información (ISS): la etapa de "diseño", que, de acuerdo con la norma nacional GOST 34.601-90, sigue inmediatamente al desarrollo de los Términos de Referencia para el sistema de seguridad de la información.
1. Desarrollo de documentación técnica de diseño para NIB.
El ciclo de vida de un sistema de seguridad de la información (en adelante ISS) en general consta de las siguientes etapas:
- análisis de requisitos para sistemas de seguridad de la información;
- diseño;
- implementación;
- implementación;
- explotación.
Este artículo analiza la etapa del proyecto técnico, que pertenece a la etapa de "diseño" y, de acuerdo con la norma nacional GOST 34.601-90, sigue inmediatamente al desarrollo de los Términos de Referencia para el sistema de seguridad de la información.
1.1. ¿Por qué desarrollar documentación para NIB?
La respuesta a esta pregunta debe considerarse en dos planos: en el plano del propietario de los recursos de información (para cuya protección se crea un sistema de seguridad de la información) y en el plano del desarrollador directo del sistema de seguridad de la información.
Para el propietario de los recursos de información, es importante obtener el resultado en forma de un sistema de seguridad de la información que funcione y que reduzca los riesgos de comprometer la información de acceso restringido en la organización. El proyecto técnico en este caso sirve para desarrollar los principios fundamentales del futuro sistema, es decir, incluye una descripción de cómo se construirá y funcionará la ISS, qué medidas y medios garantizarán la protección de la información, cuáles son las posibilidades de desarrollo y mejora. el sistema. Al finalizar el desarrollo de un proyecto técnico para un sistema de seguridad de la información, el Cliente recibe un conjunto completo de documentación para el sistema de seguridad de la información, que describe todos los matices técnicos del futuro sistema.
Para el ejecutor directo, en la etapa del proyecto técnico, es necesario establecer la arquitectura ISS más adecuada, así como elegir correctamente las medidas y medios para proteger la información en la organización. También es importante asegurar que las características y propiedades del sistema cumplan con las especificaciones técnicas, o justificar, con la participación y consentimiento del Cliente, el ajuste de los requisitos especificados en las especificaciones técnicas para aumentar la eficiencia de el sistema que se está creando.
Así, como resultado del desarrollo de la documentación técnica de diseño, el Cliente tendrá respuestas a las siguientes preguntas:
- cuál es la arquitectura general del NIB;
- qué medidas y medios se utilizarán para implementar los requisitos de protección de la información;
- cómo funcionará el NIB;
- qué cambios en la organización necesarios para aumentar el nivel de seguridad de la información se producirán como resultado de la implementación de la ISS;
- ¿Se tendrán en cuenta los requisitos del Cliente (requisitos comerciales) y los requisitos de los actos legales reglamentarios en el campo de la seguridad de la información al desarrollar e implementar el sistema de seguridad de la información y, en caso afirmativo, cómo?
En el proceso de elaboración de la documentación técnica del proyecto, el contratista recibirá los siguientes resultados:
- una base para la transición a las siguientes etapas de la construcción de una ISS, es decir, las etapas de documentación de trabajo e implementación;
- comprensión de la arquitectura, tecnologías y herramientas utilizadas, el orden de construcción del sistema;
- cómo se implementan para el sistema los requisitos del Cliente (requisitos comerciales) y los documentos reglamentarios en el campo de la seguridad de la información.
1.2. Revisión de enfoques para el desarrollo de documentación técnica de proyectos.
El desarrollo de un proyecto técnico para un sistema de seguridad de la información suele realizarse sobre la base de normas y documentos de orientación pertinentes. Además, su uso es obligatorio para instituciones gubernamentales, pero recomendado para instituciones comerciales. En la práctica, las organizaciones comerciales también utilizan estándares estatales al desarrollar la documentación técnica del proyecto por las siguientes razones:
- un enfoque probado repetidamente para la creación de sistemas de información;
- estructura y contenido reflexivos de los documentos;
- un conjunto de documentos suficiente para el desarrollo y descripción de casi cualquier sistema.
Para desarrollar la documentación para la etapa de proyecto técnico (TP) del NIB, se utilizan estándares estatales y documentos orientativos de la serie 34:
- GOST 34.201-89 "Tipos, integridad y designación de documentos al crear sistemas automatizados". Esta norma especifica:
- tipos y nombres de documentos en la etapa TP;
- integridad de la documentación;
- designaciones de documentos aceptados;
- Reglas para designar sistemas de información y sus partes.
- GOST 34.003-90 “Términos y definiciones”;
- GOST 34.601-90 “Sistemas automatizados. Etapas de la creación." La norma especifica:
- lista de etapas de trabajo realizadas en la etapa técnica;
- descripción detallada del trabajo realizado en la etapa técnica;
- lista de organizaciones que participan en la creación de la ISS;
- RD 50-34.698-90 “Sistemas automatizados. Requisitos para el contenido de los documentos." Este documento de orientación especifica los requisitos para el contenido de los documentos en la etapa de CT.
Es importante comprender que según la serie 34 de normas, el diseño técnico es una etapa en la creación de un sistema, y no solo un conjunto de documentos. En la práctica, esta etapa suele combinarse con la etapa de diseño preliminar, que sirve para desarrollar varias soluciones preliminares y justificar la más adecuada. Esta combinación está permitida por la norma, pero hay que tener en cuenta que esto no niega la necesidad de lograr los objetivos de la etapa de diseño preliminar.
Muy a menudo, la etapa de diseño preliminar se desarrolla en el caso en que los requisitos de las especificaciones técnicas del sistema se pueden implementar de varias maneras fundamentalmente diferentes, y también en el caso en que entre estos métodos no hay ninguno claramente preferible.
Sin embargo, vale la pena señalar que los estándares anteriores son demasiado generales e implementan principalmente funciones estructurales generales y de diseño. Para desarrollar la parte sustantiva de los documentos técnicos de la etapa del proyecto, los diseñadores utilizan información de las siguientes fuentes:
Documentos regulatorios vigentes (RLA) que regulan los requisitos para la protección de cierta información de acceso restringido. Estas regulaciones presentan requisitos para las medidas para proteger la información en los sistemas de información, describen los matices de la implementación de estas medidas y medidas de fortalecimiento adicionales. Entre los actos jurídicos vigentes se encuentran los siguientes:
- Orden de la FSTEC de Rusia de 18 de febrero de 2013 No. 21 “Sobre la aprobación de la composición y contenido de las medidas organizativas y técnicas para garantizar la seguridad de los datos personales durante su procesamiento en los sistemas de información de datos personales”;
- Orden del FSTEC de Rusia de 11 de febrero de 2013 No. 17 "Sobre la aprobación de los requisitos para la protección de la información que no constituye un secreto de estado contenida en los sistemas de información estatales"
- Orden del FSTEC de Rusia de 14 de marzo de 2014 No. 31 “Sobre la aprobación de los requisitos para garantizar la seguridad de la información en los sistemas de control automatizados para procesos productivos y tecnológicos en instalaciones críticas, instalaciones potencialmente peligrosas, así como instalaciones que representan un mayor peligro para la vida y la salud de las personas y del medio ambiente natural;
- documento metodológico “Medidas para la protección de la información en los sistemas de información estatales”, aprobado por el FSTEC de Rusia el 11 de febrero de 2014.
Los requisitos para la protección de información de acceso restringido y las listas de medidas de protección varían para sistemas de información de diferentes niveles/clases de seguridad. Si la información de una organización no está protegida de acuerdo con las leyes federales de la Federación de Rusia (por ejemplo, secretos oficiales), entonces el propietario de esta información puede utilizar los enfoques propuestos en estos actos legales regulatorios para construir un sistema de seguridad de la información corporativa. .
Normas rusas y extranjeras que describen diversos enfoques sobre las formas de implementar las etapas del ciclo de vida de la construcción de una ISS, incluida la etapa de diseño técnico:
- una serie de estándares estatales GOST R ISO/IEC 2700X, idénticos a los estándares internacionales ISO/IEC 2700X. Estos estándares describen el enfoque del proceso PDCA (Planificar, Hacer, Verificar, Actuar) para la implementación del ciclo de vida de un sistema de gestión de seguridad de la información, que es una parte integral del sistema de seguridad de la información;
- NIST SP 800-64 es un estándar del Instituto Nacional de Estándares y Tecnología de EE. UU. que describe el ciclo de vida del desarrollo de sistemas de información;
- NIST SP 800-37 es un estándar del Instituto Nacional de Estándares y Tecnología de EE. UU. que proporciona orientación para integrar la gestión de riesgos en el ciclo de vida del desarrollo de sistemas de información.
Documentación operativa del fabricante de equipos de seguridad de la información y equipos auxiliares. Estos documentos contienen información técnica completa sobre las herramientas utilizadas en la construcción de sistemas de seguridad de la información, incluidas aquellas directamente relacionadas con la implementación de medidas de seguridad de la información no relacionadas, por ejemplo, con servidores, sistemas de almacenamiento de datos, herramientas de virtualización y otros. El conjunto general de dichos documentos varía de un fabricante a otro y depende, entre otras cosas, de la implementación de una herramienta particular (hardware/software). A continuación se muestra un conjunto estándar de documentación operativa para herramientas de seguridad de la información utilizadas para desarrollar documentos en la etapa del proyecto técnico:
- descripción general (hoja de datos);
- guía del administrador (puede incluir guía de gestión local y centralizada);
- guía del usuario;
- Guía rápida de instalación e implementación (para sistemas de protección de información de hardware);
- manual del operador;
- Orientación para la implementación en infraestructura virtual (para sistemas de seguridad de la información de software);
Información general sobre arquitecturas ISS disponibles, mejores prácticas en términos de construcción de ISS, pautas de seguridad e integración de sistemas de seguridad de la información entre sí, información sobre problemas en la interacción de ciertos sistemas de seguridad de la información. Ejemplos de dicha información pueden incluir los siguientes documentos:
- guías sobre arquitecturas de sistemas de seguridad de la información, por ejemplo: Defense-in-Depth, Cisco SAFE, Check Point SDP y otros;
- mejores prácticas en el campo de la seguridad de la información, por ejemplo, disponibles en estos enlaces (https://www.sans.org/reading-room/whitepapers/bestprac/, http://csrc.nist.gov/publications/nistpubs/ 800-14 /800-14.pdf). Estos documentos suelen presentarse en inglés; sin embargo, cualquier fabricante ruso de equipos de protección tiene sus propias mejores prácticas para implementar medidas de seguridad y puede proporcionarlas si lo solicita;
- directrices de seguridad para la seguridad de la información y entornos operativos. Un ejemplo es la sección "Seguridad" del portal oficial de Microsoft (https://technet.microsoft.com/ru-ru/library/dd637672.aspx).
1.3. Desarrollo de un proyecto técnico para NIB de acuerdo con GOST 34.
El desarrollo de documentos en la etapa de proyecto técnico para ISS lo llevan a cabo con mayor frecuencia los integradores de estos servicios y se implementa principalmente de acuerdo con el siguiente plan:
Determinar la lista de documentos a desarrollar: esta información se indica en las especificaciones técnicas de la ISS. En algunos casos, el desarrollador del documento, de acuerdo con el Cliente, podrá ampliar o reducir esta lista, si esta posibilidad está prevista en las especificaciones técnicas;
Desarrollo de plantillas de documentos para la etapa TP: la estructura se utiliza de acuerdo con RD 50-34.698-90 y GOST 2.106 (para algunos documentos), formateada de acuerdo con GOST 2.105-95;
Elaboración de la parte sustantiva de los documentos. Los requisitos del sistema se establecen en las especificaciones técnicas del NIB. De acuerdo con estos requisitos, se determina una lista de medidas técnicas y organizativas de protección necesarias para su implementación en el sistema. Las medidas de protección se pueden determinar en las regulaciones relevantes (dependiendo del tipo de información que se protege), estándares corporativos y políticas de seguridad de la información, así como en función de la presencia de amenazas de seguridad actuales identificadas durante el desarrollo del modelo de amenazas de la organización. Según la lista de medidas de protección, el desarrollador de SI selecciona las herramientas de seguridad de la información adecuadas y desarrolla la estructura funcional del sistema de seguridad de la información (subsistemas, componentes). Además, los documentos de diseño técnico describen la implementación práctica de medidas de protección basadas en la protección de seguridad seleccionada o las medidas organizativas en la infraestructura de la organización.
Coordinación de la documentación desarrollada y las soluciones presentadas en la misma con el Cliente del sistema.
Al desarrollar la documentación técnica del proyecto, la mayoría de las veces no es necesario desarrollar una lista completa de los documentos especificados en GOST 34.201-89, ya que este estándar está desactualizado y algunos de los documentos no tienen en cuenta las tendencias de desarrollo y las tecnologías de los sistemas de información modernos. . El conjunto mínimo de documentos requeridos para describir el sistema de seguridad de la información es el siguiente:
- declaración de diseño técnico;
- nota explicativa del proyecto técnico;
- diagrama de estructura funcional;
- diagrama estructural de un complejo de medios técnicos;
- diagrama de estructura organizacional;
- lista de artículos comprados.
A petición del Cliente o en el caso de que la ISS sea un sistema complejo multicomponente, también se podrán desarrollar adicionalmente los siguientes documentos:
- esquema de automatización;
- descripción de funciones automatizadas;
- descripción del soporte de información del sistema;
- descripción del complejo de medios técnicos;
- descripción del software;
- descripción de la estructura organizacional.
Cabe señalar que GOST 34.201-89 permite ampliar la gama de documentos en la etapa TP, pero en la práctica estos documentos son más que suficientes.
Ficha de diseño técnico
Designación: TP.
Este documento tiene como objetivo describir la lista de documentos desarrollados en la etapa técnica del proyecto. También se indica el número de páginas de cada uno de los documentos desarrollados.
Nota explicativa del proyecto técnico
Designación: P2.
Este documento es el principal para la etapa TP e incluye una descripción de la arquitectura de la ISS, medidas técnicas y organizativas, funciones de la ISS, sistemas de software y hardware, etc. Según la norma, consta de cuatro apartados principales:
- provisiones generales;
- descripción del proceso de actividad;
- soluciones técnicas básicas;
- medidas para preparar el objeto de automatización para la puesta en funcionamiento del sistema.
Diagrama de estructura funcional
Designación: C2.
Este documento describe la estructura lógica de la ISS, a saber:
- subsistemas y componentes lógicos incluidos en la ISS;
- funciones implementadas mediante subsistemas y componentes;
- conexiones de información entre elementos lógicos del SIS y tipos de mensajes durante el intercambio.
Diagrama estructural de un complejo de medios técnicos.
Designación: C1.
Este documento incluye una descripción de los siguientes elementos de la ISS:
- medios técnicos como parte de subsistemas lógicos y componentes de sistemas de seguridad de la información;
- Canales de comunicación e intercambio entre medios técnicos indicando protocolos de transporte.
Organigrama
Designación: C0.
Este documento describe la estructura organizacional de la organización en términos de gestión de ISS, a saber:
- divisiones y personas responsables de la organización involucradas en el funcionamiento de la ISS;
- funciones desempeñadas y conexiones entre departamentos y personas responsables.
Lista de artículos comprados
Designación: VP.
Este documento incluye una lista de todo el software y hardware, así como las licencias utilizadas para crear un sistema de seguridad de la información. Desarrollado de acuerdo con GOST 2.106.
Nota. También vale la pena señalar aquí que el documento rector RD 50-34.698-90 permite la adición de cualquier documento en la etapa TP (la inclusión de secciones e información diferente a la propuesta), la fusión de secciones, así como la exclusión de algunas secciones individuales. Las decisiones al respecto las toma el desarrollador de documentos en la etapa TP y se basan en las características del NIB creado.
1.4. Reglas para desarrollar documentación.
- cumplimiento estructural de las normas estatales;
- estricto cumplimiento de los requisitos de las especificaciones técnicas del sistema;
- aplicación de plantillas de documentos (uso de estilos uniformes, marcas, campos, etc.);
- un enfoque individual y el uso simultáneo de los desarrollos existentes al completar secciones de documentos.
Nota explicativa del proyecto técnico:
- el desarrollo del documento se lleva a cabo en el entorno de Microsoft Word; una vez finalizado el desarrollo, se recomienda convertir el documento al formato PDF para mayor comodidad;
- los términos y abreviaturas deben ser coherentes en todas las secciones del documento;
- Se recomienda evitar repeticiones evidentes y aumentos innecesarios de la extensión del documento;
- Las soluciones técnicas deben describirse con el mayor detalle posible, indicando:
- arquitectura y tecnologías utilizadas;
- ubicaciones de software y hardware en la infraestructura de la organización;
- herramientas de seguridad de la información utilizadas con descripción de sus características, funciones implementadas, información sobre certificación;
- configuraciones básicas de las herramientas de seguridad de la información en términos de mecanismos de protección, direccionamiento, enrutamiento, interacción con sistemas y herramientas relacionados, etc.;
- controles, métodos de acceso a los mismos y lugares de su instalación;
- diagramas (estructurales, funcionales, organizativos):
- desarrollar diagramas en Microsoft Visio;
- después del desarrollo, inserte diagramas en el documento usando el cuadro de diálogo "Pegado especial" en formato EMF (metarchivo de Windows);
- desarrollar diagramas separados para el sistema, subsistemas y componentes de subsistemas;
- uniformar el diseño de los diagramas, utilizando los mismos elementos, abreviaturas, iconos, estilos de texto, etc.
1.5. Recursos para ayudarle a desarrollar documentación
Internet contiene una gran cantidad de información que, en un grado u otro, puede ayudar en el desarrollo de la documentación técnica del proyecto. Los recursos clave se presentan en la siguiente tabla.
Mesa. Recursos de diseño técnico del SIS
| Tipo de recurso | Información | Ejemplos de recursos |
|---|---|---|
| Portales de Internet de las autoridades ejecutivas federales. | Documentos regulatorios, recomendaciones metodológicas, registros (incluidos sistemas certificados de seguridad de la información), bases de datos (incluidas bases de datos de vulnerabilidades y amenazas) | fstec.ru clsz.fsb.ru minsvyaz.ru/ru/ |
| Portales de Internet de fabricantes de seguridad de la información, distribuidores de soluciones de seguridad de la información. | Descripción de soluciones de seguridad de la información, documentación operativa para la seguridad de la información, materiales y artículos analíticos. | códigodeseguridad.ru kaspersky.ru/ drweb.ru/ ptsecurity.ru/ infowatch.ru/ infotecs.ru/ cisco.com/c/ru_ru/index.html punto de control.com altx-soft.ru |
| Recursos especializados en seguridad de la información. | Comparación de soluciones de seguridad de la información, artículos de revisión sobre soluciones de seguridad de la información, pruebas de soluciones de seguridad de la información, información técnica detallada sobre tecnologías de seguridad de la información. | anti-malware.ru bis-experto.ru seguro.cnews.ru seguridadlab.ru/ vulners.com/ csrc.nist.gov itsecurity.com owasp.org sans.org |
1.6. Ejemplos de documentos técnicos en etapa de proyecto.
Para comprender los requisitos para el contenido de la documentación en la etapa TP, a continuación se muestran ejemplos de cómo completar los documentos principales (secciones de documentos).
1.6.1. Nota explicativa del proyecto técnico
La nota explicativa es un documento bastante voluminoso, por lo que aquí se muestra un ejemplo del contenido de la sección "Soluciones técnicas básicas" en parte de uno de los subsistemas del SIS: el subsistema de análisis de seguridad.
Subsistema de análisis de seguridad de la ISS
Estructura y composición del subsistema.
El subsistema de análisis de seguridad (SAS) está diseñado para monitorear sistemáticamente el estado de seguridad de las estaciones de trabajo automatizadas (AWS) del personal y los servidores de la organización. La base del ESD es la herramienta de software "Prueba" producida por Information Security LLC. SZI Test está certificado por FSTEC de Rusia por el cumplimiento de las especificaciones técnicas (TU) de seguridad de la información y por el cuarto nivel de control sobre la ausencia de capacidades no declaradas.
El ESD incluye los siguientes componentes:
- Servidor de gestión del servidor de prueba;
- Consola de gestión de Test Console.
En la siguiente tabla se presenta una descripción de los componentes del subsistema.
Mesa. Componentes ESD
| Componente | Descripción |
|---|---|
| Servidor de prueba Servidor de administración | Proporciona gestión de tareas de escaneo, realiza funciones de monitoreo del estado de seguridad de la estación de trabajo y los servidores de la organización. Los parámetros de escaneo los establece el administrador de seguridad de la información en el servidor de administración del servidor de prueba. Toda la información recopilada sobre los resultados del análisis se almacena en el almacenamiento del servidor de prueba basado en el sistema de administración de bases de datos Microsoft SQL Server 2008. |
| Consola de prueba | Permite al administrador de seguridad de la información conectarse al servidor de prueba, ver y cambiar su configuración, crear y modificar tareas de escaneo, ver información sobre el progreso de las tareas y los resultados de su ejecución. La consola de administración está instalada en la estación de trabajo del administrador de seguridad de la información. |
Proporcionar funciones
El ESD proporciona las siguientes funciones:
- implementación de protección proactiva de las estaciones de trabajo y servidores de la organización mediante el monitoreo del estado de seguridad de la información;
- automatización de procesos para monitorear el cumplimiento de políticas internas y ciertos estándares de seguridad;
- reducción de costos por auditoría y control de seguridad, elaboración de informes de estado;
- automatización de procesos de inventario de recursos, gestión de vulnerabilidades, seguimiento del cumplimiento de políticas de seguridad y control de cambios.
Solución para un complejo de herramientas de hardware y software.
La lista de software y hardware ESD usados se proporciona en la siguiente tabla.
Mesa. Software y hardware ESD
Servidor de control ESD
Medios técnicos
El servidor físico utilizado como servidor de administración de ESD debe cumplir con los requisitos técnicos para el software y el sistema operativo instalado en él, que se indican en la siguiente tabla.
Mesa. Requisitos de software y sistema operativo para el servidor de control ESD
| Software | Requerimientos técnicos | |
|---|---|---|
| UPC | RAM, megabytes | |
| Servidor Microsoft Windows 2008 R2 | 3000MHz, 4 núcleos | 8192 |
| Servidor Microsoft SQL 2008 R2 | ||
| Software de servidor de prueba | ||
Software
SO del servidor de administración
El sistema operativo Windows 2008 R2 se instala en el servidor de administración de la forma habitual desde una distribución de arranque.
El sistema operativo del servidor de administración se administra localmente desde la consola y mediante el protocolo RDP.
Servidor de gestión DBMS
La base de datos Microsoft SQL Server 2008 R2 se instala con una cuenta con derechos de administrador local mediante el asistente de instalación estándar del kit de distribución proporcionado por el desarrollador del producto.
Software de servidor de prueba
El software Test Server se instala en el servidor de administración mediante el asistente de instalación estándar.
La configuración inicial y la posterior administración del software Test Server en modo normal se llevan a cabo utilizando la consola de administración Test Console instalada en la estación de trabajo del administrador de IS.
Estación de trabajo del administrador de IS
Medios técnicos
Como plataforma se utiliza la estación de trabajo existente de un empleado del departamento de la organización responsable de brindar seguridad de la información, que ejecuta la familia de sistemas operativos Microsoft Windows.
Los medios técnicos de la estación de trabajo del administrador de seguridad de la información deben tener las siguientes características de configuración hardware (al menos recomendadas):
- CPU de 2 GHz;
- RAM 4 GB;
- Disco duro de 80 GB.
Software
Software de consola de prueba
La estación de trabajo del administrador de seguridad de la información en la que está instalado el software Test Console debe funcionar bajo uno de los siguientes sistemas operativos:
- Microsoft Windows 7, 32 y 64 bits;
- Microsoft Windows 8/8.1, 32 y 64 bits.
Además, para que el software de la consola de administración de Test Console funcione correctamente, se debe instalar Microsoft .NET Framework versión 3.5 SP1 o superior en la estación de trabajo del administrador de seguridad de la información, y la configuración de seguridad del sistema operativo utilizado debe permitir el acceso al servidor de prueba.
La instalación del software Test Console en la estación de trabajo del administrador de ESD se realiza mediante el asistente de instalación del software Test Server estándar con la opción seleccionada para instalar la consola de administración de Test Console y otras configuraciones predeterminadas.
Interacción con sistemas adyacentes.
Para ESD, los adyacentes son:
- herramientas del subsistema de firewall;
- Servicios de directorio de Active Directory;
- Estación de trabajo y servidores de la organización.
Para garantizar la interacción de la red con sistemas adyacentes y directamente entre los propios componentes ESD, se debe organizar el paso del tráfico de red necesario.
Para garantizar la capacidad de recibir actualizaciones de la base de conocimientos y los módulos de software de prueba para el escáner del servidor de prueba, es necesario proporcionar acceso al servidor web update.com de la empresa Information Security LLC a través del puerto 443/tcp.
Al escanear en modo PenTest, la interacción entre el escáner del servidor de prueba y la estación de trabajo y los servidores de la organización se realiza a través del protocolo IP. Al escanear en los modos Auditoría y Cumplimiento, se utilizan los protocolos de administración remota WMI, RPC, etc. Para escanear hosts en dispositivos con funciones de firewall, debe permitir conexiones desde el servidor de prueba a los hosts escaneados a través de IP. En consecuencia, el servidor de prueba debe tener acceso a los puertos de red de los hosts escaneados utilizando los protocolos de control remoto adecuados.
Dado que ESD, cuando escanea en los modos Auditoría y Cumplimiento, utiliza protocolos de control remoto para el análisis, las herramientas de escaneo del software de prueba deben someterse a autenticación y autorización en el nodo escaneado. En ESD, para escanear nodos en los modos Auditoría y Cumplimiento, se utilizan cuentas con privilegios administrativos en cada tipo de nodo (estación de trabajo, servidor, sistemas de aplicaciones, DBMS, etc.).
Todos los eventos de seguridad de la información registrados se almacenan en el DBMS de Microsoft SQL. Estos eventos se pueden enviar al subsistema de monitoreo de eventos de seguridad de la información mediante conectores especiales.
Operación y mantenimiento de ESD.
Usuarios del subsistema
La operación y mantenimiento de las herramientas ESD lo llevan a cabo empleados de la organización con el rol funcional de “administrador de SI”.
Un administrador de seguridad de la información se define como un especialista cuyas tareas incluyen:
- determinar los parámetros de escaneo de los nodos de la organización;
- configurar e iniciar tareas de escaneo;
- análisis de los resultados del escaneo para detectar vulnerabilidades en los sistemas de información, errores de configuración o incumplimiento de estándares técnicos;
- control sobre la eliminación de vulnerabilidades;
- formación de estándares y requisitos que se aplican para garantizar la seguridad de las estaciones de trabajo y servidores de la organización.
Modos de funcionamiento del sistema
Modo de funcionamiento normal
En funcionamiento normal, el ESD funciona las 24 horas del día, los 7 días de la semana.
En funcionamiento normal, el administrador de seguridad de la información realiza:
- escaneo de nodos programado y no programado;
- generar informes;
- Actualización de bases de conocimiento y módulos de software de prueba.
Operación de emergencia
Si se altera el funcionamiento del equipo de seguridad, se altera el funcionamiento del subsistema. La falla en operar el equipo ESD no afecta el funcionamiento de las estaciones de trabajo y servidores automatizados de la organización.
1.6.2. Diagrama de estructura funcional
Se pueden desarrollar diagramas funcionales para todo el sistema de seguridad de la información o para parte de él, por ejemplo, un subsistema o componente.
En la siguiente figura se muestra un ejemplo de un diagrama funcional general de una ISS.
1.6.3. Diagrama estructural de un complejo de medios técnicos.
Se puede desarrollar un diagrama de bloques de un complejo de medios técnicos tanto para toda la ISS como para sus partes: subsistemas y componentes. La viabilidad de desarrollar diagramas para partes del sistema de seguridad de la información está determinada por la escala del sistema y el detalle requerido.
En la siguiente figura se presenta un ejemplo de un diagrama de bloques de un complejo de sistemas de seguridad e información técnica.
Ministerio de Desarrollo Económico y Comercio de la Federación de Rusia
YO APROBÉ |
||||||||||||||||||||||||||||||||||||||
|
Contrato estatal No. 000-05-07 de 29 de octubre de 2007, celebrado entre el Ministerio de Desarrollo Económico y Comercio de la Federación de Rusia y CJSC PROGNOZ, para la realización de trabajos sobre el tema "Desarrollo de un módulo automatizado para el seguimiento federal de las actividades sociales". -el desarrollo económico de las entidades constitutivas de la Federación de Rusia en el marco de la creación de un sistema de información unificado para monitorear los indicadores clave del desarrollo socioeconómico de la Federación de Rusia y monitorear el desempeño de los órganos gubernamentales para lograrlos”. Al desarrollar este documento, se utilizó el documento guía sobre estandarización GOST RD 50-34.698-90. 1. Disposiciones generales... 5 1.1. Nombre completo del sistema... 5 1.2. Documentos a partir de los cuales se realiza el diseño.. 5 1.3. Etapas y plazos.. 5 1.4. Metas y propósito.. 7 1.5. Cumplimiento de las soluciones de diseño con los requisitos de seguridad ... 8 1.6. Documentos reglamentarios y técnicos... 9 2. Descripción del proceso de la actividad. 10 2.1. Lista de tareas... 10 2.2. Principales funciones que realiza el Módulo... 11 3. Soluciones técnicas básicas. 13 3.1. Estructura del módulo, lista de subsistemas... 13 3.1.1. Subsistema de Almacenamiento Centralizado de Datos. 14 3.1.2. Componente de interfaz. 15 3.1.3. Componentes del software del adaptador. dieciséis 3.6.3. El grado de adaptabilidad a las desviaciones en los parámetros del objeto de automatización. 26 3.6.4. Límites aceptables para la modernización y desarrollo del sistema. 26 3.6.5. Requisitos de confiabilidad. 27 3.6.6. Requisito de seguridad. 27 3.6.7. Requisitos de ergonomía y estética técnica. 28
|
- provisiones generales;
- descripción de la actividad;
- soluciones técnicas básicas;
- eventos en
[de la cláusula 2.2.1 RD 50-34.698-90]
Provisiones generales
En el apartado “Disposiciones Generales” establecen:
- diseño y nombres de los documentos, su número y fecha, sobre cuya base se lleva a cabo el diseño de la central nuclear;
- lista de involucrados en el sistema, plazos;
- metas, propósito y AS;
- confirmación del cumplimiento de las soluciones de diseño con las normas vigentes y seguridad contra incendios y explosiones, etc.;
- información sobre los utilizados en el diseño;
- información sobre las mejores prácticas utilizadas en el desarrollo del proyecto;
- el orden de creación del sistema y el volumen de cada uno.
[de la cláusula 2.2.2 RD 50-34.698-90]
Descripción del proceso de actividad.
El apartado “Descripción del proceso de actividad” refleja la composición de los procedimientos (), teniendo en cuenta la interrelación y compatibilidad de procesos y actividades, formando la organización del trabajo en la planta [de la cláusula 2.2.3 RD 50-34.698-90 ]
Principales soluciones técnicas.
En el apartado “Principales soluciones técnicas” se dan:
- decisiones sobre la estructura del sistema, medios y métodos de comunicación para el intercambio de información entre subsistemas;
- decisiones sobre la interconexión del sistema con sistemas relacionados y su soporte;
- soluciones para la operación del sistema;
- decisiones sobre el número, calificaciones y funciones, modos de funcionamiento, orden de interacción;
- información sobre cómo garantizar las características específicas del consumidor del sistema (subsistemas) que lo definen;
- composición de complejos de tareas () implementados por el sistema (subsistema);
- decisiones sobre el complejo, su ubicación;
- decisiones sobre la composición de la información, volumen, métodos, tipos de computadora y documentos, secuencia y otros componentes;
- decisiones sobre la composición, idiomas de las actividades, procedimientos y operaciones y métodos de su implementación.
La sección proporciona ilustraciones de otros documentos que pueden incluirse de acuerdo con GOST 34.201 [de la cláusula 2.2.4 del RD 50-34.698-90]
Medidas para preparar el objeto de automatización para la puesta en funcionamiento del sistema.
En el apartado “Medidas preparatorias para la puesta en funcionamiento del sistema” se detalla lo siguiente:
- medidas para llevar la información a un formato adecuado para;
- actividades de formación y prueba de las cualificaciones del personal;
- medidas para crear las unidades y puestos de trabajo necesarios;
- medidas para cambiar el objeto de automatización;
- otras medidas basadas en las características específicas de los sistemas que se están creando.
Cargando...
