nist 800-30_esp

10/6/2014 Guía de Gestión de Riesgos párr Sistemas Informáticos

http://translate.googleusercontent.com/translate_f 1/45

Página 1

Guía de gestión de riesgos para

Sistemas de Tecnología de la Información

Recomendaciones del Instituto Nacional de

Normas y Tecnología

Gary Stoneburner, Alice Goguen, y Alexis Feringa

Special Publication 800-30

Página 2



SP 800-30 Página ii

COMPUTERSECURITY

División de Seguridad InformáticaLaboratorio de Tecnologías de la InformaciónInstituto Nacional de Estándares y TecnologíaGaithersburg, MD 20899-8930

1Booz Allen Hamilton Inc.3190 Fairview Park DriveFalls Church, VA 22042

07 2002

EE.UU. Departamento de ComercioDonald L. Evans, Secretario

ADMINISTRACIÓN DE TECNOLOGÍAPhillip J. Bond, Subsecretario de Tecnología

INSTITUTO NACIONAL DE NORMAS Y TECNOLOGÍAArden L. Bement, Jr., Director

NIST Special Publication 800-30Guía de gestión de riesgos para

Sistemas de Tecnología de la Información

Recomendaciones de la

Instituto Nacional de Estándares y Tecnología

Gary Stoneburner, Alice Goguen 1, Y

Alexis Feringa 1

Página 3

Informes sobre Sistemas Computer Technology

El Laboratorio de Tecnología de la Información (DIT) en el Instituto Nacional de Estándares y Tecnologíapromueve la economía de EE.UU. y el bienestar público al proporcionar liderazgo técnico para la nación dela medición y la infraestructura de las normas. ITL desarrolla pruebas, métodos de prueba, datos de referencia, prueba deimplementaciones de concepto y análisis técnicos para avanzar en el desarrollo y el uso productivo detecnología de la información. Responsabilidades de ITL incluyen el desarrollo de técnicas, físicas,normas y directrices para la seguridad económica y la privacidad de los administrativos y de gestión

información no clasificada sensible en los sistemas informáticos federales. La Publicación Especial 800-seriesinformes sobre la investigación, la guía de liras italianas, y los esfuerzos de difusión de la seguridad informática, y su colaboraciónactividades con la industria, el gobierno y organizaciones académicas.



SP 800-30 Página iii

Instituto Nacional de Estándares y Tecnología de la publicación especial 800-30

Natl. Inst. Párese. Technol. Spec. Publ. 800-30, 54 páginas (julio de 2002)

CODEN: NSPUE2

Ciertas entidades comerciales, equipos o materiales pueden ser identificadas en este documento con el fin de describir unprocedimiento experimental o concepto adecuadamente. Esta identificación no pretenden dar a entender recomendación uaprobación por parte del Instituto Nacional de Estándares y Tecnología, ni pretende dar a entender que las entidades,

materiales o equipos son necesariamente los mejores disponibles para ese fin.

Página 4

Agradecimientos

Los autores, Gary Stoneburner, del NIST y Alice Goguen y Alexis Feringa de BoozAllen Hamilton desean expresar su agradecimiento a sus colegas de las dos organizaciones que

borradores revisados de este documento. En particular, Timothy Grance, Marianne Swanson, y Joan

Hash de NIST y Debra L. Banning, Jeffrey Confer, Randall K. Ewell, y WaseemMamlouk de Booz Allen proporcionó información valiosa que contribuyeron sustancialmente a la

contenido técnico de este documento. Por otra parte, agradecemos y apreciamos el

muchos comentarios de los sectores público y privado cuyas reflexiva y constructiva

comentarios mejoraron la calidad y la utilidad de esta publicación.



SP 800-30 Página iv

Página 5

TABLA DE CONTENIDO

1. INTRODUCTION..............................................................................................................................................1

1.1 LaUTORIDAD.................................................................................................................................................11.2 PROPÓSITO......................................................................................................................................................11.3 OBJETIVO..................................................................................................................................................21.4 TARGETLaUDIENCE.....................................................................................................................................21.5 REXALTADAREFERENCIAS................................................................................................................................31.6 TGUÍA DEL USUARIOSSTRUCTURA......................................................................................................................................3

2. PANORAMA GENERAL DE GESTIÓN DEL RIESGO .............................................................................................................4

2.1 YoIMPORTANCIA DERISKMGESTIÓN .........................................................................................................42.2 YoINTEGRACIÓN DERISKMGESTIÓN EN SDLC ................................................. .................................... 42.3 KEYROLES.................................................................................................................................................6

3. EVALUACIÓN DE RIESGOS ........................................................................................................................................8

3.1 STEP1: S ISTEMACHARACTERIZATION......................................................................................................103.1.1 Relacionadas con el sistema Information................................................................................................................103.1.2 Técnicas de recogida de información .....................................................................................................11

3.2 STEP2: T Hreat YoDENTIFICACIÓN.............................................................................................................123.2.1 Amenaza-fuente Identification................................................................................................................123.2.2 La motivación y la amenaza acciones ............................................................................................................13

3.3 STEP3: V Ulnerabilidad YoDENTIFICACIÓN.................................................. .............................................. 153.3.1 Vulnerabilidad Sources...........................................................................................................................163.3.2 Pruebas de seguridad del sistema .......................................................................................................................173.3.3 Desarrollo de Requisitos de Seguridad Lista de control ............................................. ................................... 18

3.4 STEP4: C ONTROLLaNÁLISIS....................................................................................................................193.4.1 Control Methods..................................................................................................................................203.4.2 Control de Categorías ..............................................................................................................................203.4.3 Análisis de control Technique.................................................................................................................20

3.5 STEP5: L IKELIHOODDETERMINACIÓN.....................................................................................................213.6 STEP6: MPACTLaNÁLISIS.......................................................................................................................213.7 STEP7: R ISKDETERMINACIÓN.................................................................................................................24

3.7.1 Riesgo Nivel Matrix.................................................................................................................................243.7.2 Descripción de Riesgo Level.....................................................................................................................25

3.8 STEP8: C ONTROLRRECOMENDACIONES...................................................................................................263.9 STEP9: R ESULTADOSDOCUMENTACIÓN.........................................................................................................26

4. RIESGO MITIGATION.......................................................................................................................................27

4.1 RISKMITIGATIONOPCIONES.......................................................................................................................274.2 RISKMITIGATIONSESTRATEGIA....................................................................................................................284.3 LaNFOQUE PARACONTROLYoEJECUCIÓN .................................................. .......................................... 294.4 CONTROLCATEGORIES.............................................................................................................................32

4.4.1 Seguridad Técnica Controls.................................................................................................................324.4.2 Security Management Controls............................................................................................................354.4.3 Seguridad Operacional Controls.............................................................................................................36

4.5 COST-BENEFICIOLaNÁLISIS.........................................................................................................................37



SP 800-30 Página iv

4.6 RESIDUALRISK.........................................................................................................................................39

5. EVALUACIÓN Y ASSESSMENT............................................................................................................41

5.1 TOODSEGURIDADPRactique.......................................................................................................................415.2 KEYS PARASL éxito ...................................................................................................................................41

Apéndice A-Ejemplo de preguntas de la entrevista ............................................................................................................. A-1

Apéndice B-Ejemplo de informe de evaluación de riesgos Outline...........................................................................................B-1

Página 6

SP 800-30 Página v

Apéndice C-Sample Plan de Salvaguarda Implementación Cuadro Resumen ......................................... ......................... C-1

Apéndice D—Acronyms.......................................................................................................................................... D-1

Apéndice E—Glossary..............................................................................................................................................E-1

Apéndice F—References...........................................................................................................................................F-1

LISTA DE FIGURAS

Figura 3-1 Evaluación de Riesgos Metodología Flowchart...................................................................................................9

Figura 4-1 Mitigación de Riesgos Acción Points....................................................................................................................28

Figura 4-2 Mitigación de Riesgos Metodología Flowchart...................................................................................................31

Figura 4-3 Técnica de Seguridad Controls.......................................................................................................................33

Implementación Figura 4-4 Control y Riesgo Residual ......................................... .................................................. .... 40

LISTA DE TABLAS

Tabla 2-1 Integración de la Gestión de Riesgos a la ....................................... SDLC .................................................. ..... 5

Tabla 3-1 Amenazas humanas: Amenaza-Source, la motivación y acciones de amenaza .................................. ............................. 14

Tabla 3-2 Vulnerabilidad / Amenaza Pairs...........................................................................................................................15

Tabla 3-3 Criterios de seguridad ..........................................................................................................................................18

Tabla 3-4 Definiciones de probabilidad ................................................................................................................................21

Tabla 3-5 Magnitud del Impacto Definiciones ................................................................................................................23

Tabla 3-6 Riesgo Nivel Matrix.......................................................................................................................................25

Tabla 3-7 Escala de Riesgo y acciones necesarias ..............................................................................................................25



Página 7

SP 800-30 Página 1

1. INTRODUCCIÓN

Cada organización tiene una misión. En esta era digital, como las organizaciones utilizan la información automatizada

tecnología (TI) 1 para procesar su información para un mejor apoyo de su misión, el riesgo

gestión juega un papel fundamental en la protección de los activos de información de una organización, y por lo tanto

su misión, de los riesgos relacionados con las TI.

Un proceso eficaz de gestión de riesgos es un componente importante de una seguridad de TI con éxito

programa. El objetivo principal del proceso de gestión de riesgos de una organización debe ser la protección de

la organización y su capacidad para llevar a cabo su misión, no sólo sus activos de TI. Por lo tanto, el riesgo

proceso de gestión no debe ser tratado principalmente como una función técnica llevada a cabo por la TI

expertos que operan y administran el sistema informático, sino como una función esencial de la administración de la

organización.

1.1 AUTORIDAD

Este documento ha sido desarrollado por el NIST en cumplimiento de sus responsabilidades legales en virtud de

la Ley de Seguridad Informática de 1987 y la Ley de Reforma de la Gestión de la Tecnología de la Información

1996 (en concreto 15 del Código de los Estados Unidos (USC) 278 g-3 (a) (5)). Esto no es una pauta dentro de

el significado de 15 USC 278 g-3 (a) (3).

Estas directrices son para uso de las organizaciones federales que procesan información sensible.

Son consistentes con los requisitos de la OMB Circular A-130, Apéndice III.

Las presentes directrices no son obligatorias y las normas vinculantes. Este documento puede ser utilizado por

las organizaciones no gubernamentales sobre una base voluntaria. No está sujeto a derechos de autor.

Nada en este documento que pretenda contradecir las normas y directrices hizo

obligatorio y vinculante para las agencias federales por el Secretario de Comercio bajo su legal

autoridad. Tampoco deberían estas directrices pueden interpretar como la alteración o reemplazando el existente

autoridades de la Secretaría de Comercio, el Director de la Oficina de Gerencia y Presupuesto,

o cualquier otro funcionario federal.

1.2 PROPÓSITO

El riesgo es el impacto negativo neto del ejercicio de una vulnerabilidad, teniendo en cuenta tanto la probabilidad

y el impacto de la ocurrencia. La gestión del riesgo es el proceso de identificación de riesgos, evaluación de riesgos,

y tomar medidas para reducir el riesgo a un nivel aceptable. Esta guía proporciona una base para la

desarrollo de un programa de gestión de riesgos efectiva, que contiene tanto las definiciones y laorientación práctica necesaria para evaluar y mitigar los riesgos identificados en los sistemas de TI. La

objetivo final es ayudar a las organizaciones a gestionar mejor los riesgos relacionados con las TI de misión.

1 El término "sistema informático" se refiere a un sistema de apoyo general (por ejemplo, la computadora central, ordenador de gama media, localesred de área, columna vertebral agencywide) o una de las principales aplicaciones que se pueden ejecutar en un sistema de apoyo general y cuyauso de los recursos de información satisface un conjunto específico de necesidades de los usuarios.

Página 8

Además, esta guía proporciona información sobre la selección de los controles de seguridad rentables. 2

Estos controles se pueden utilizar para mitigar los riesgos para la mejor protección de misión crítica

la información y los sistemas informáticos que procesan, almacenan y transportan esta información.

Las organizaciones pueden optar por ampliar o abreviar los procesos y medidas integrales

se sugiere en esta guía y adaptarlos a su entorno en la gestión de misión relacionados con TI

riesgos.

1.3 OBJETIVO

El objetivo de la realización de la gestión de riesgos es permitir a la organización para llevar a cabo su



SP 800-30 Página 2

misión (s) (1) por mejor asegurar los sistemas que almacenan, procesan o transmiten organizacionalinformación; (2) haciendo posible la gestión para tomar decisiones de gestión de riesgos con conocimiento de causa a

justificar los gastos que forman parte de un presupuesto de TI; y (3) por ayudar a la administración en

autorizar (o acreditación de) los sistemas de TI 3 sobre la base de la documentación de apoyo

derivados de la realización de la gestión de riesgos.

1.4 DESTINATARIOS

Esta guía proporciona una base común para la experiencia y sin experiencia, técnica y

personal no técnico que apoyan o usan el proceso de gestión de riesgos para sus sistemas de TI.

Este personal incluye

• La alta dirección, los propietarios de la misión, los que toman las decisiones acerca de la seguridad de TI

presupuesto.

• Jefes de los Servicios de Información Federal, que garanticen la puesta en práctica de riesgo

la gestión de los sistemas de TI de la agencia y la seguridad proporcionados para estos sistemas de TI

• La Autoridad Designada Aprobatoria (DAA), que es responsable de la final

decisión sobre si se debe permitir el funcionamiento de un sistema informático

• El administrador del programa de seguridad de TI, que implementa el programa de seguridad

• Los oficiales de seguridad del sistema de información (ISSO), que son responsables de la seguridad de TI

• Los propietarios de sistemas de TI de software y / o hardware del sistema utilizados para apoyar las funciones de TI.

• Los dueños de la información de los datos almacenados, procesados y transmitidos por los sistemas de TI

• Los gerentes de negocios o funcionales, que son responsables del proceso de adquisición de TI

• El personal de apoyo técnico (por ejemplo, redes, sistemas, aplicaciones y bases de datos

administradores; especialistas en informática; Los analistas de seguridad de datos), que gestionan y

administrar la seguridad de los sistemas informáticos

• Sistema de TI y programadores de aplicaciones, que desarrollan y mantienen el código que podría

sistema y la integridad de datos afectará

2 Los términos "garantías" y "controles" se refieren a las medidas de reducción de riesgos; estos términos se utilizan indistintamente eneste documento de orientación.

3 Oficina de Administración y Presupuesto de noviembre de 2000 la Circular A-130 de la Ley de Seguridad Informática de 1987, y elInformación del Gobierno de Ley de Reforma de Seguridad en octubre de 2000 exige que un sistema informático ser autorizado antes de laa partir de entonces volvió a autorizar la operación y al menos cada 3 años.

Página 9

• El personal de garantía de calidad de TI, que ponen a prueba y garantizar la integridad de los sistemas informáticos

y los datos

• Los auditores de sistemas de información, quienes auditan sistemas de TI

• Los consultores de TI, que apoyan a los clientes en la gestión de riesgos.

1.5 REFERENCIAS RELACIONADAS

Esta guía se basa en los conceptos generales presentados en el Instituto Nacional de Estándares y

Tecnología (NIST) Publicación Especial (SP) 800-27, Principios de Ingeniería de Seguridad Informática,

junto con los principios y prácticas de NIST SP 800-14, Principios Generalmente Aceptados y

Prácticas recomendadas para proteger Sistemas Informáticos. Además, es coherente con la

políticas que se presentan en la Oficina de Administración y Presupuesto (OMB) Circular A-130, Apéndice III,

"La seguridad de Federal Automatizado de Información de Recursos"; la Ley de Seguridad Informática (CSA) de

1987; y la Ley de Reforma de la Seguridad de Información del Gobierno de octubre de 2000.

1.6 GUÍA DE ESTRUCTURA

Las secciones restantes de esta guía discutir lo siguiente:

• La Sección 2 proporciona una visión general de la gestión del riesgo, cómo se integra en el sistema

el desarrollo del ciclo de vida (SDLC), y las funciones de las personas que apoyan y utilizan esta

proceso.



SP 800-30 Página 3

• La sección 3 describe la metodología de evaluación de riesgos y los nueve pasos principales enrealizar una evaluación de riesgo de un sistema informático.

• La sección 4 describe el proceso de mitigación de riesgos, incluidas las opciones de mitigación de riesgos y

estrategia, el enfoque de la aplicación de control, las categorías de control, el costo-beneficio

análisis, y el riesgo residual.

• Sección 5 analiza las buenas prácticas y la necesidad de una evaluación de riesgos en curso y

evaluación y los factores que conduzcan a un programa de gestión de riesgos exitosa.

Esta guía también contiene seis anexos. El Apéndice A proporciona preguntas de la entrevista de la muestra.

Apéndice B proporciona un esquema de ejemplo para su uso en la documentación de los resultados de la evaluación de riesgos. Apéndice

C contiene una tabla de ejemplo para el plan de implementación de salvaguardia. Apéndice D proporciona una lista de

las siglas utilizadas en este documento. Apéndice E contiene un glosario de términos de uso frecuente en

esta guía. Apéndice F incluye las referencias.

Página 10

2. PANORAMA GENERAL DE GESTIÓN DEL RIESGO

En esta guía se describe la metodología de gestión de riesgos, cómo se integra en cada fase de la SDLC,

y cómo el proceso de gestión de riesgos está ligado al proceso de autorización del sistema (o

acreditación).

2.1 IMPORTANCIA DE LA GESTIÓN DE RIESGOS

La gestión de riesgos se compone de tres procesos: evaluación de riesgos, mitigación del riesgo y evaluación

y la evaluación. Sección 3 de este manual se describe el proceso de evaluación de riesgos, que incluye

identificación y evaluación de los riesgos e impactos de riesgo, y la recomendación de reducir el riesgo-

medidas. La sección 4 describe la mitigación de riesgos, que se refiere a la priorización, ejecución y

mantenimiento de las medidas de reducción del riesgo adecuadas recomendadas por la evaluación de riesgos

proceso. Sección 5 discute el proceso de evaluación continua y las claves para la implementación de un

programa de gestión de riesgos exitosa. La DAA o autorizar sistema oficial es responsable de

determinar si el riesgo restante es a un nivel aceptable o si la seguridad adicionalcontroles deben implementarse para reducir aún más o eliminar el riesgo residual antes

autorizar (o acreditación de) el sistema informático para la operación.

La gestión del riesgo es el proceso que permite a los administradores de TI para equilibrar el funcionamiento y

los costos económicos de las medidas de protección y lograr ganancias en la capacidad de la misión de proteger la

Sistemas de información y de datos que apoyan las misiones de sus organizaciones. Este proceso no es única para la

Entorno de TI; de hecho, impregna la toma de decisiones en todos los ámbitos de nuestra vida cotidiana. Tomemos el caso

de seguridad para el hogar, por ejemplo. Muchas personas deciden tener sistemas de seguridad instalados y

pagar una cuota mensual a un proveedor de servicios para que estos sistemas monitorizados para la mejor protección

de su propiedad. Es de suponer que los propietarios han sopesado el costo de la instalación del sistema y

monitoreo contra el valor de sus artículos para el hogar y la seguridad de su familia, un derecho fundamental

Necesidad "misión".

El jefe de una unidad de organización debe asegurarse de que la organización tiene la capacidad necesaria

para cumplir su misión. Estos dueños de misión deben determinar las capacidades de seguridad que

sus sistemas de TI deben tener para proporcionar el nivel deseado de apoyo a la misión ante la vida real

amenazas mundiales. La mayoría de las organizaciones cuentan con presupuestos limitados para la seguridad de la información; Por lo tanto, la seguridad de TI

el gasto debe ser revisado tan a fondo como otras decisiones de gestión. Un riesgo bien estructurado

metodología de gestión, cuando se utiliza con eficacia, puede ayudar a identificar la gestión adecuada

controla para proporcionar las funciones de seguridad esenciales para la misión.



SP 800-30 Página 4

2.2 INTEGRACIÓN DE LA GESTIÓN DE RIESGOS EN SDLC

Minimizar el impacto negativo en la organización y la necesidad de base sólida en la toma de decisiones son

las organizaciones razones fundamentales implementar un proceso de gestión de riesgo para proyectos de TI

sistemas. La gestión eficaz del riesgo debe estar totalmente integrado en el SDLC. De un sistema de TI

SDLC tiene cinco fases: inicio, desarrollo o adquisición, implementación, operación o

mantenimiento y eliminación. En algunos casos, un sistema de TI puede ocupar varias de estas fases en

al mismo tiempo. Sin embargo, la metodología de gestión del riesgo es el mismo independientemente de la SDLC

fase para la que se está llevando a cabo la evaluación. La gestión de riesgos es un proceso iterativo que

se puede realizar durante cada fase importante del SDLC. La Tabla 2-1 describe las características

Página 11

de cada fase SDLC e indica cómo la gestión del riesgo se puede realizar en apoyo de cada

fase.

Tabla 2-1 Integración de la Gestión de Riesgos en el SDLC

Fases SDLC Características de fase El apoyo de RiesgoActividades de gestión

Fase 1-Iniciación La necesidad de un sistema de TI esexpresado y el propósito yalcance del sistema de TI esdocumentado

• Riesgos identificados se utilizan paraapoyar el desarrollo de larequisitos del sistema, incluyendorequisitos de seguridad, y unaconcepto de seguridad de las operaciones(Estrategia)

Fase 2-Desarrollo oAdquisición

El sistema informático está diseñado,comprado, programado,desarrollada, o de otra maneraconstruido

• Los riesgos identificados durante estefase se puede utilizar para el apoyoanálisis de la seguridad de la TIsistema que puede llevar aarquitectura y diseño con el comerciooffs durante sistemadesarrollo

Fase 3 Implementación Las funciones de seguridad del sistemadebe ser configurado, se activa,probado, y verificada

• El proceso de gestión de riesgosapoya la evaluación de lala implementación del sistema en contrasus requisitos y dentro de sumodelo operativomedio ambiente. Decisionescon respecto a los riesgos identificados debenhacerse antes de sistemaoperación

Fase 4-Funcionamiento oMantenimiento

El sistema realiza sufunciones. Típicamente, el sistema esse modifique en un cursobase a través de la adición dehardware y software y porcambios en la organizaciónlos procesos, las políticas yprocedimientos

• Actividades de gestión de riesgos sonrealizado para sistema periódicoreautorización (oreacreditación) o siempreprincipales cambios se hacen para unaSistema informático en su funcionamiento,entorno de producción (por ejemplo,interfaces de nuevo sistema)

Fase 5-Eliminación Esta fase puede implicar ladisposición de la información,de hardware y software.Las actividades pueden incluir en movimiento,archivo, los descartes, odestrucción de información odesinfectar el hardware y elsoftware

• Actividades de gestión de riesgosse llevan a cabo para el sistema decomponentes que seráneliminarlo o bien reemplazado aasegurarse de que el hardware y elsoftware en las debidas disposicionesde, que los datos residuales esCon manejo apropiado, y quese lleva a cabo la migración del sistemaen un lugar seguro y sistemáticomanera



SP 800-30 Página 5

Página 12

SP 800-30 Página 6

2.3 FUNCIONES PRINCIPALES

La gestión de riesgos es una responsabilidad de gestión. En esta sección se describen las funciones principales de la

personal que deben apoyar y participar en el proceso de gestión de riesgos.

• Alta Dirección. La alta dirección, bajo la norma de la diligencia debida y

la responsabilidad final de cumplimiento de la misión, debe asegurarse de que la necesaria

los recursos se apliquen de manera efectiva para desarrollar las capacidades necesarias para llevar a cabo la

misión. También deben evaluar e incorporar los resultados de la actividad de evaluación de riesgos

en el proceso de toma de decisiones. Un programa eficaz de gestión de riesgos que

evalúa y mitiga los riesgos relacionados con las TI de misión requiere el apoyo y la participación

de la alta dirección.

• Jefe de Información (CIO). El CIO es el responsable de IT de la agencia

planificación, presupuestación, y el rendimiento incluidos sus componentes de seguridad de la información.

Las decisiones tomadas en estas áreas deben estar basadas en una gestión eficaz del riesgo

programa.

• Sistema de Información y Propietarios. Los propietarios de los sistemas y de la información son

responsable de asegurar que los controles adecuados están en su lugar para hacer frente a la integridad,

confidencialidad y disponibilidad de los sistemas informáticos y los datos que poseen. Típicamente, la

propietarios de los sistemas y de la información son responsables de cambios en sus sistemas de TI. Por lo tanto,por lo general tienen que aprobar y firmar en cambios en sus sistemas de TI (por ejemplo, el sistema de

mejora, los principales cambios en el software y hardware). El sistema y

Por lo tanto, los propietarios de la información deben entender su papel en la gestión de riesgos

procesar y totalmente apoyar este proceso.

• Negocios y Gerentes Funcionales. Los responsables de negocio

operaciones y proceso de adquisición de TI deben tener un papel activo en el riesgo

proceso de gestión. Estos gestores son las personas con la autoridad y

la responsabilidad de tomar las decisiones de trade-off esenciales para el logro de misión.

Su participación en el proceso de gestión de riesgos permite el logro de adecuada

seguridad de los sistemas informáticos, que, si se gestiona adecuadamente, proporcionará misión

eficacia con un gasto mínimo de recursos.

• ISSO. IT directores de los programas de seguridad y oficiales de seguridad informática son responsables

para programas de seguridad de sus organizaciones, incluyendo la gestión de riesgos. Por lo tanto,

que desempeñan un papel destacado en la introducción de una metodología estructurada adecuada para ayudar a

identificar, evaluar y minimizar los riesgos de los sistemas de TI que apoyan su

misiones de organizaciones. Issos también actúan como los principales consultores en apoyo de la alta

administración para asegurar que esta actividad se lleva a cabo de manera continua.

• Los profesionales de TI de seguridad. Profesionales de seguridad de TI (por ejemplo, redes, sistemas,

aplicación, y los administradores de bases de datos; especialistas en informática; los analistas de seguridad;

consultores de seguridad) son responsables de la correcta aplicación de la seguridad

requisitos de sus sistemas de TI. Cuando se producen cambios en el sistema de TI existente

medio ambiente (por ejemplo, la expansión de la conectividad de red, los cambios en el vigente

políticas de infraestructura y de organización, la introducción de nuevas tecnologías), la TI

profesionales de la seguridad deben apoyar o utilizar el proceso de gestión de riesgos para identificar y

evaluar nuevos riesgos potenciales e implementar nuevos controles de seguridad según sea necesario para

salvaguardar sus sistemas de TI.

Página 13

• Los formadores de la conciencia de la Seguridad (Seguridad / Subject Matter Profesionales). El

el personal de la organización son los usuarios de los sistemas de TI. El uso de los sistemas de TI y

datos de acuerdo con las políticas de la organización, las directrices y normas de comportamiento es

fundamental para la mitigación de riesgos y la protección de los recursos de TI de la organización. Para reducir al mínimo

riesgo a los sistemas de TI, es esencial que se proporcionen a los usuarios de sistemas y aplicaciones

con la formación de la conciencia de la seguridad. Por lo tanto, los instructores en seguridad de TI o

seguridad / sujetos profesionales materia deben entender el proceso de gestión de riesgos, para



SP 800-30 Página 7

que puedan desarrollar materiales de formación adecuados e incorporar la evaluación de riesgosen los programas de formación para educar a los usuarios finales.

Página 14

3. EVALUACIÓN DE RIESGOS

La evaluación de riesgos es el primer proceso en la metodología de gestión de riesgos. Las organizaciones utilizan el riesgo

evaluación para determinar el grado de la amenaza potencial y el riesgo asociado con un TI

sistema largo de su SDLC. El resultado de este proceso ayuda a identificar los controles apropiados para

reducir o eliminar los riesgos durante el proceso de mitigación de riesgos, como se discutió en la Sección 4.

El riesgo es una función de la probabilidad de una determinada amenaza de código de ejercer un particular potencial

la vulnerabilidad y el impacto resultante de ese acontecimiento adverso en la organización.

Para determinar la probabilidad de un evento adverso futuro, las amenazas a un sistema de TI deben ser analizados

junto con las posibles vulnerabilidades y los controles establecidos para el sistema de TI.

El impacto se refiere a la magnitud del daño que podría ser causado por el ejercicio de una amenaza de un

vulnerabilidad. El nivel de impacto se rige por los posibles impactos de la misión ya su vez

produce un valor relativo de los activos de TI y los recursos afectados (por ejemplo, la criticidad y

sensibilidad de los componentes del sistema de TI y datos). La metodología de evaluación de riesgos

abarca nueve pasos principales, que se describen en las secciones 3.1 a 3.9

• Paso 1 Sistema de Caracterización (Sección 3.1)

• Paso 2 Amenaza de identificación (Sección 3.2)



SP 800-30 Página 8

• Paso 3 Vulnerabilidad de identificación (Sección 3.3)

• Paso 4 análisis del control (sección 3.4)

• Paso 5 determinación de probabilidad (sección 3.5)

• Paso 6 Análisis de Impacto (Sección 3.6)

• Paso 7 Determinación de Riesgos (Sección 3.7)

• Recomendaciones Paso 8 control (sección 3.8)

• Paso 9 Resultados Documentación (Sección 3.9).

Pasos 2, 3, 4, y 6 se puede realizar en paralelo después de la Etapa 1 se ha completado. Figura 3-1

representa los pasos y las entradas y salidas del cada paso.

Página 15

Lista de corriente yLos controles previstos

Paso 4 Análisis de control.

Declaración de AmenazasPaso 2.

Amenaza de identificación

Lista de PotencialVulnerabilidades

Paso 3.Vulnerabilidad de identificación

• Los informes de riesgo antes deevaluaciones

• Cualquier observación de auditoría• Los requisitos de seguridad• Los resultados de las pruebas de seguridad

• Hardware• Software• Acoplamientos del sistema• Los datos y la información• Personas• La misión del Sistema

Paso 1.Caracterización Sistema

Riesgo ClasificaciónPaso 5.Determinación de la probabilidad

• Motivación Amenaza de código• Capacidad de Amenazas• La naturaleza de la vulnerabilidad• Los controles actuales

Paso 6 Análisis de Impacto.

• La pérdida de integridad• Pérdida de disponibilidad• Pérdida de confidencialidad

Impacto en el

• Análisis del impacto de la Misión• evaluación de la criticidad del activo• criticidad de datos• Sensibilidad de datos

Entrada Evaluación de Riesgos Actividades Salida

• Límite de sistema• Funciones del sistema• Sistema y DatosCriticidad

• Sistema y DatosSensibilidad

• Los controles actuales• Los controles previstos

• Historia del ataque del sistema• Los datos de inteligenciaagencias, NIPC, OIG,FedCIRC, medios de comunicación,



Paso 4 Análisis de control.

Declaración de AmenazasPaso 2.

Amenaza de identificación

Lista de PotencialVulnerabilidades

Paso 3.Vulnerabilidad de identificación





• Hardware• Software• Acoplamientos del sistema• Los datos y la información• Personas• La misión del Sistema

Paso 1.Caracterización Sistema

Riesgo ClasificaciónPaso 5.Determinación de la probabilidad

• Motivación Amenaza de código• Capacidad de Amenazas• La naturaleza de la vulnerabilidad• Los controles actuales

Paso 6 Análisis de Impacto.

• La pérdida de integridad• Pérdida de disponibilidad• Pérdida de confidencialidad

Impacto en el

• Análisis del impacto de la Misión• evaluación de la criticidad del activo• criticidad de datos• Sensibilidad de datos

Entrada Evaluación de Riesgos Actividades Salida

• Límite de sistema• Funciones del sistema• Sistema y DatosCriticidad

• Sistema y DatosSensibilidad

• Los controles actuales• Los controles previstos• Los controles actuales• Los controles previstos

• Historia del ataque del sistema• Los datos de inteligenciaagencias, NIPC, OIG,FedCIRC, medios de comunicación,



SP 800-30 Página 9

Figura 3-1. Evaluación de Riesgos Metodología Organigrama

Paso 9.Resultados Documentación

Evaluación de RiesgosInforme

Riesgos yRiesgo asociado

NivelesPaso 7. Determinación del Riesgo

• Probabilidad de amenazaexplotación

• Magnitud del impacto• Adecuación de la prevista o

controles actuales

RecomendadoControles

Paso 8.Recomendaciones para el control

Paso 9.Resultados Documentación

Evaluación de RiesgosInforme

Riesgos yRiesgo asociado

NivelesPaso 7. Determinación del Riesgo

• Probabilidad de amenazaexplotación

• Magnitud del impacto• Adecuación de la prevista o

controles actuales

RecomendadoControles

Paso 8.Recomendaciones para el control

Página 16

3.1 PASO 1: SISTEMA DE CARACTERIZACIÓN

En la evaluación de los riesgos para un sistema informático, el primer paso es definir el alcance del esfuerzo. En este paso,

de los límites del sistema de TI son identificados, junto con los recursos y la información que

constituyen el sistema. Caracterización de un sistema de TI establece el alcance de la evaluación de riesgosesfuerzo, delinea los límites de la autorización operacional (o acreditación), y proporciona

información (por ejemplo, hardware, software, conectividad del sistema, y la división responsable o el apoyo

personal) esenciales para la definición del riesgo.

Sección 3.1.1 se describe la información relacionada con el sistema utilizado para caracterizar un sistema de TI y su

entorno operativo. Sección 3.1.2 sugiere las técnicas de recopilación de información que puede

ser utilizado para solicitar información relativa al medio ambiente de procesamiento del sistema de TI.

La metodología descrita en este documento se puede aplicar a las evaluaciones de simple o múltiple,

sistemas interrelacionados. En este último caso, es importante que el dominio de interés y todas las interfacesy dependencias de estar bien definidos antes de la aplicación de la metodología.

3.1.1 Sistema de Información relacionada con

La identificación de los riesgos de un sistema de TI requiere un profundo conocimiento de procesamiento del sistema

medio ambiente. La persona o personas que llevan a cabo la evaluación de riesgos deben, por tanto, en primer lugar recopilar

información relacionada con el sistema, que por lo general se clasifica de la siguiente manera:

• Hardware

• Software

• Las interfaces del sistema (por ejemplo, la conectividad interna y externa)

• Los datos y la información

• Las personas que apoyan y utilizan el sistema de TI

• La misión del sistema (por ejemplo, los procesos realizados por el sistema de TI)

• Sistema y criticidad de datos (por ejemplo, el valor del sistema o de la importancia de una organización)

• Sistema y sensibilidad de los datos. 4

Información adicional relacionada con el medio ambiente operativo del sistema informático y sus datos

incluye, pero no se limita a, los siguientes:

• Los requisitos funcionales del sistema de TI

• Los usuarios del sistema (por ejemplo, los usuarios de sistemas que prestan apoyo técnico a la TI

sistema; usuarios de las aplicaciones que utilizan el sistema de TI para llevar a cabo las funciones de negocio)

• Las políticas de seguridad Sistema que rigen el sistema de TI (políticas de la organización, federal

requisitos, leyes, prácticas de la industria)

• La arquitectura de seguridad del sistema



SP 800-30 Página 10

4 El nivel de protección necesario para mantener el sistema y la integridad de los datos, confidencialidad y disponibilidad.

Página 17


• topología de red actual (por ejemplo, diagrama de la red)

• Protección de almacenamiento de información que el sistema de salvaguardias y la disponibilidad de datos, la integridad,

y confidencialidad

• Flujo de información relacionada con el sistema de TI (por ejemplo, las interfaces del sistema, la entrada del sistema

y diagrama de flujo de salida)

• Los controles técnicos utilizados para el sistema de TI (por ejemplo, una función de complemento o producto de seguridad

que apoya la identificación y autenticación, discrecional o de acceso obligatorio

la protección del control, auditoría, información residual, métodos de cifrado)

• Los controles de gestión utilizados para el sistema de TI (por ejemplo, reglas de comportamiento, la seguridad

planificación)

• Los controles operacionales utilizados para el sistema de TI (por ejemplo, la seguridad personal, la copia de seguridad,

operaciones de contingencia y reanudación y recuperación; mantenimiento del sistema; fuera de las instalaciones

almacenamiento; cuenta de usuario del establecimiento y procedimientos de eliminación; controles para la segregación

de las funciones de los usuarios, como el acceso de usuarios privilegiados frente acceso de usuario estándar)

• entorno de seguridad física del sistema informático (por ejemplo, protección de la instalación, centro de datos

políticas)

• La seguridad ambiental implementado para el entorno de ejecución del sistema de TI (por ejemplo,

controles de humedad, el agua, la energía, la contaminación, la temperatura y los productos químicos).

Para un sistema que está en el inicio o la fase de diseño, la información del sistema se puede derivar de la

diseño o los requisitos de documentos. Para un sistema de TI en fase de desarrollo, es necesario definirnormas de seguridad clave y atributos previstas para el futuro sistema de TI. Documentos de diseño de sistemas y

el plan de seguridad del sistema puede proporcionar información útil sobre la seguridad de un sistema informático que es

en desarrollo.

Para un sistema operativo, se recogen datos sobre el sistema de TI en su producción

medio ambiente, incluyendo datos sobre la configuración del sistema, la conectividad y documentada y

procedimientos y prácticas de indocumentados. Por lo tanto, la descripción del sistema se puede basar en laseguridad proporcionada por la infraestructura subyacente o en los planes de seguridad de futuro para el sistema de TI.

3.1.2 Técnicas de recogida de información

Cualquier, o una combinación, de las siguientes técnicas pueden ser utilizadas en la recopilación de información relevante

al sistema de TI dentro de sus límites operativos:

• Cuestionario. Para recopilar la información pertinente, el personal de evaluación del riesgo puede

desarrollar un cuestionario relativo a la gestión y los controles operativos previstos

o utilizados con el sistema informático. Este cuestionario debe ser distribuido a la aplicable

personal técnico y no técnico de gestión que están diseñando o de apoyo

el sistema de TI. El cuestionario también se podría utilizar durante las visitas sobre el terreno yentrevistas.

• Entrevistas en sitio. Entrevistas con el apoyo del sistema de TI y gestión de personal

puede permitir que el personal de evaluación de riesgos para recopilar información útil acerca de la TI

sistema (por ejemplo, cómo funciona el sistema y logró). Las visitas in situ permiten también el riesgo

Página 18

personal de evaluación para observar y recopilar información sobre las características físicas,seguridad ambiental y operativo del sistema informático. El apéndice A contiene

preguntas de la entrevista de la muestra que se hacen durante las entrevistas con el personal del sitio para lograr un

mejor comprensión de las características operativas de una organización. Para




Amenaza: El potencial de una amenaza-

fuente de ejercicio (accidentalmente el gatilloo intencionalmente explotar) una específica

vulnerabilidad.

Amenaza-Fuente: O (1) intención y el método

dirigida a la explotación intencional de un

vulnerabilidad o (2) una situación y método

que pueden desencadenar accidentalmente una vulnerabilidad.

sistemas todavía en la fase de diseño, visita in situ serían recopilación de datos cara a caraejercicios y podría proporcionar la oportunidad de evaluar el entorno físico en el

que el sistema va a operar.

• Revisión de documentos. Documentos de política (por ejemplo, documentación legislativa, directivas),

documentación del sistema (por ejemplo, la guía de usuario del sistema, manual de administración del sistema,

diseño del sistema y documento de requerimientos, documento de adquisición), y la seguridad relacionada

documentación (por ejemplo, anterior informe de auditoría, el informe de evaluación de riesgos, resultados de las pruebas del sistema,

plan de seguridad del sistema5, Las políticas de seguridad) pueden proporcionar una buena información sobre lacontroles de seguridad utilizados por y planificadas para el sistema de TI. La misión de una organización

análisis de impacto o criticidad de los activos de evaluación proporciona información sobre el sistema

y la criticidad de datos y la sensibilidad.

• El uso de la herramienta automatizada de escaneo. métodos técnicos proactivos pueden ser usados para

recoger información del sistema de manera eficiente. Por ejemplo, una herramienta de mapeo de red puede

identificar los servicios que se ejecutan en un gran grupo de hosts y proporcionar una forma rápida de

la creación de perfiles individuales del sistema de TI de destino (s).

La recolección de información se puede realizar durante todo el proceso de evaluación de riesgos, de la Etapa 1

(Sistema de Caracterización) hasta el Paso 9 (Resultados Documentación).

De salida de la Etapa 1 Caracterización del sistema de TI evaluados, una buena imagen de la TI

entorno del sistema, y la delimitación de las fronteras del sistema

3.2 PASO 2: IDENTIFICACIÓN DE AMENAZA

Una amenaza es la posibilidad de una amenaza de código especial para ejercer con éxito una determinadavulnerabilidad. Una vulnerabilidad es una debilidad que puede

se dispare accidentalmente o intencionalmente explotados. La

amenaza de código no presenta un riesgo cuando no hay

vulnerabilidad que puede ser ejercida. En la determinación de la

probabilidad de que una amenaza (Sección 3.5), se debe considerar

amenaza los recursos, vulnerabilidades potenciales (Sección 3.3),

y los controles existentes (Sección 3.4).

3.2.1 Amenaza-Identificación de fuentes de

El objetivo de este paso es identificar el potencial

amenaza los recursos y elaborar una declaración de amenaza

listado de potenciales amenazas recursos que son aplicables

al sistema informático que se está evaluando.

5 Durante la fase inicial, una evaluación de riesgos podría ser utilizado para desarrollar el plan inicial de la seguridad del sistema.

Página 19

Amenaza Fuentes Comunes

Amenazas naturales-inundaciones, terremotos, tornados,

deslizamientos de tierra, avalanchas, tormentas eléctricas, y otros tales

eventos.

Humanos Amenazas-Eventos que están habilitados por o

causada por los seres humanos, como los actos no intencionales

Acciones (entrada de datos involuntaria) o deliberadas (red

ataques basados, carga el software malicioso, sin autorización

el acceso a la información confidencial).

Amenazas ambientales de larga duración de corte de energía,

la contaminación, los productos químicos, las fugas de líquido.

Una amenaza de código se define como cualquier

circunstancia o evento con lapotencial de causar daño a una red IT

sistema. La amenaza común

fuentes pueden ser naturales, humanos, oambiental.

En la evaluación de las amenazas recursos, es

importante tener en cuenta todos los posibles

amenaza los recursos que podrían causar

daño al sistema informático y su

procesamiento de medio ambiente. Para

ejemplo, aunque la amenaza

declaración para un sistema informático

situada en un desierto no puede




incluir "natural de las inundaciones", porquede la baja probabilidad de que ocurran una, las amenazas ambientales tales de eventos tales como una tubería reventar

puede inundar rápidamente una sala de ordenadores y causar daños a los activos de TI de una organización y

recursos. Los seres humanos pueden ser de amenaza los recursos a través de actos intencionales, como los ataques deliberados depersonas malintencionadas o empleados descontentos o actos involuntarios, tales como la negligencia y los errores.

Un ataque deliberado puede ser (1) un intento malicioso para obtener acceso no autorizado a una red IT

sistema (por ejemplo, por medio de adivinación de contraseñas) para el sistema y la integridad de los datos en peligro,

disponibilidad o confidencialidad o (2) una benigna, pero no obstante decidido, intento de eludir

la seguridad del sistema. Un ejemplo de este último tipo de ataque deliberado es de un programador escribir un

Programa de caballo de Troya para eludir la seguridad del sistema con el fin de "hacer el trabajo".

3.2.2 Motivación y amenazas acciones

La motivación y los recursos para llevar a cabo un ataque hacen los humanos potencialmente peligrosos

amenaza los recursos. La Tabla 3-1 presenta un resumen de muchas de las amenazas humanas comunes de hoy en día, su

posibles motivaciones y los métodos o acciones de amenaza por los que podrían llevar a cabo un ataque.

Esta información será útil para las organizaciones que estudian sus entornos de amenazas humanas yla personalización de sus declaraciones de amenazas humanas. Además, la revisión de la historia del sistema de romper-

ins; informes de violación de la seguridad; informes de incidentes; y entrevistas con los administradores del sistema,

personal de asistencia técnica, y la comunidad de usuarios durante la recopilación de información ayudará a identificar humanaamenaza los recursos que tienen el potencial para dañar un sistema informático y sus datos y que pueden ser una preocupación

donde existe una vulnerabilidad.

Página 20

Tabla 3-1. Acciones Amenaza-Source, la motivación y de la amenaza: Amenazas humanas

Amenaza-fuente Motivación Acciones de amenazas

Hacker, cracker

Desafío

Ego

Rebelión

• Hackear• Ingeniería social• Intrusión del sistema, los robos• El acceso no autorizado al sistema

Criminal de ordenador

Destrucción de la información

Ilegal divulgación de información

La ganancia monetaria

Alteración no autorizada de datos

• El delito informático (por ejemplo, cyberacecho)

• Acto fraudulento (por ejemplo, repetición,suplantación, interceptación)

• Información de soborno• Spoofing• Intrusión Sistema

Terrorista

Chantaje

Destrucción

Explotación

Venganza

• Bomba / Terrorismo• La guerra de información• Ataque del sistema (por ejemplo, distribuyó

denegación de servicio)• La penetración del sistema• Manipulación del sistema

Espionaje industrial(empresas, extranjerasgobiernos, otroslos intereses del gobierno)

Ventaja competitiva

Espionaje económico

• Explotación económica• El robo de información• Intrusión en la privacidad personal• Ingeniería social• La penetración del sistema• El acceso no autorizado al sistema

(Acceso a clasificado, propiedad,y / o la tecnología relacionadainformación)

• Asalto a un empleado• Chantaje• Navegación del propietario




Insiders (mal entrenados,descontentos, malicioso,negligente, fraudulento, oempleados despedidos)

CuriosidadEgo

Inteligencia

La ganancia monetaria

Venganza

Errores involuntarios yomisiones (por ejemplo, la entrada de datoserror, error de programación)

información• Abuso de computadora• Fraude y robo• Información de soborno• Entrada de falsificada, datos corruptos• Interceptación• El código malicioso (por ejemplo, virus, lógica

bomba, caballo de Troya)• Venta de información personal• Errores del sistema• Intrusión Sistema• Sabotaje Sistema• El acceso no autorizado al sistema

Una estimación de la motivación, los recursos y capacidades que se requieran para llevar a cabo una

ataque exitoso debe desarrollarse después de que se han identificado las posibles amenazas recursos, en

Para determinar la probabilidad de que una amenaza de ejercer una vulnerabilidad del sistema, como se describe en

Sección 3.5.

Página 21

Vulnerabilidad: Un defecto o debilidad en el sistemaprocedimientos de seguridad, diseño, implementación, o

controles internos que podrían ser ejercidas

(Accidentalmente o intencionalmente provocado explotados)y dar lugar a un fallo de seguridad o una violación de la

política de seguridad del sistema.

La declaración de amenaza, o la lista de posibles amenazas recursos, deben adaptarse a la persona

organización y su entorno de procesamiento (por ejemplo, hábitos de computación de usuario final). En general,

información sobre las amenazas naturales (por ejemplo, inundaciones, terremotos, tormentas) debe estar fácilmente disponible.

Amenazas conocidas han sido identificados por muchas organizaciones gubernamentales y del sector privado.

Herramientas de detección de intrusos también son cada vez más frecuentes, y el gobierno y la industria

organizaciones recogen continuamente datos sobre los eventos de seguridad, mejorando así la capacidad de

evaluar de manera realista las amenazas. Las fuentes de información incluyen, pero no se limitan a, lo siguiente:

• Las agencias de inteligencia (por ejemplo, la Oficina Federal de Investigación Nacional de

Centro de Protección de la Infraestructura)

• Centro Federal Computer Respuesta a Incidentes (FedCIRC)

• Los medios de comunicación, en particular de los recursos basados en la Web, tales como SecurityFocus.com,

SecurityWatch.com, SecurityPortal.com, y SANS.org.

De salida de la Etapa 2 Una declaración de amenaza que contiene una lista de las amenazas recursos que podrían explotarvulnerabilidades del sistema

3.3 PASO 3: IDENTIFICACIÓN DE VULNERABILIDAD

El análisis de la amenaza a un sistema informático

deben incluir un análisis de lavulnerabilidades asociadas con el sistema

medio ambiente. El objetivo de este paso es

elaborar una lista de las vulnerabilidades del sistema

(defectos o debilidades) que podrían ser

explotado por la amenaza potencial recursos.

La Tabla 3-2 presenta ejemplos de pares de vulnerabilidad / amenaza.

Tabla 3-2. Pares de Vulnerabilidad / Amenaza

Vulnerabilidad Amenaza-fuente Acción Amenaza

Sistema de empleados despedidos 'identificadores (ID) no se eliminandel sistema

Los empleados despedidos Marcar en la compañía dela red y el accesode datos propiedad de la empresa

Firewall de la empresa permite entrantetelnet, y los huéspedes ID está activado enServidor XYZ

Los usuarios no autorizados (por ejemplo,hackers, terminadoempleados, equipocriminales, los terroristas)

Uso de telnet con el servidor XYZy archivos del sistema de navegacióncon el invitado ID




El vendedor ha identificado fallas enel diseño de la seguridad del sistema;Sin embargo, los nuevos parches no tienenha aplicado al sistema de

Los usuarios no autorizados (por ejemplo,hackers, descontentosempleados, equipocriminales, los terroristas)

La obtención no autorizadaacceso al sistema sensiblearchivos en función conocidavulnerabilidades del sistema

Página 22


Vulnerabilidad Amenaza-fuente Acción Amenaza

Centro de datos utiliza rociadores de aguapara suprimir el fuego; lonas aproteger el hardware y equipode daños por agua no están enlugar

Fuego, personas negligentes Rociadores de agua sonencendida en el centro de datos

Métodos recomendados para la identificación de las vulnerabilidades del sistema son el uso de la vulnerabilidad

fuentes, el rendimiento de las pruebas de seguridad del sistema y el desarrollo de una seguridad

requisitos de lista de verificación.

Cabe señalar que esa existirán los tipos de vulnerabilidades, y la metodología necesaria para

determinar si las vulnerabilidades están presentes, por lo general variará dependiendo de la naturaleza de

el sistema informático y la fase que se encuentra, en el SDLC:

• Si el sistema aún no se ha diseñado, la búsqueda de vulnerabilidades debe centrarse

sobre las políticas de seguridad de la organización, los procedimientos de seguridad previstas, y el sistema

definiciones de requerimientos y análisis de productos de seguridad de los proveedores o desarrolladores

(por ejemplo, libros blancos).

• Si se está implementando el sistema informático, la identificación de vulnerabilidades debe ser

ampliado para incluir información más específica, por ejemplo, las características de seguridad previstas

se describe en la documentación de diseño de seguridad y los resultados de la certificación del sistemaprueba y evaluación.

• Si el sistema está operativo, el proceso de identificación de las vulnerabilidades deben

incluir un análisis de las características de seguridad del sistema de TI y los controles de seguridad,

técnico y de procedimiento, que se utiliza para proteger el sistema.

3.3.1 Fuentes de Vulnerabilidad

Las vulnerabilidades técnicas y no técnicas asociados con el procesamiento de un sistema de TI

medio ambiente puede ser identificado a través de las técnicas de recolección de información que se describen en la Sección3.1.2. Una revisión de otras fuentes de la industria (por ejemplo, las páginas Web de los proveedores que identifican los errores del sistema y

defectos) serán útiles en la preparación de las entrevistas y en el desarrollo de cuestionarios eficaces para

identificar las vulnerabilidades que pueden ser aplicables a los sistemas informáticos específicos (por ejemplo, una versión específica de unsistema operativo específico). El Internet es otra fuente de información sobre el sistema conocido

vulnerabilidades publicadas por los proveedores, junto con revisiones, service packs, parches y otros

las medidas correctivas que se pueden aplicar para eliminar o mitigar las vulnerabilidades. Documentado

fuentes de vulnerabilidad que deben ser considerados en un análisis de la vulnerabilidad a fondo incluyen, pero

no se limitan a, lo siguiente:

• Anterior documentación de la evaluación de riesgos del sistema de TI evaluado

• Los informes del sistema de TI de auditoría, informes de anomalías del sistema, informes de revisión de la seguridad, y

informes de las pruebas del sistema y evaluación

• Las listas de vulnerabilidad, tales como la base de datos de vulnerabilidad I-CAT NIST

(Http://icat.nist.gov)

Página 23




• Recomendaciones de seguridad, tales como FedCIRC y el Departamento de Informática de la EnergíaBoletines de capacidad de asesoramiento de Incidentes

• avisos de proveedores

• Los equipos de respuesta a incidentes informáticos Comercial / emergencia y listas de correos (por ejemplo,

Mailings foro SecurityFocus.com)

• Las alertas y boletines para los sistemas militares Información sobre la vulnerabilidad de Aseguramiento

• la seguridad del software de sistema analiza.

3.3.2 Sistema de Pruebas de Seguridad

Métodos proactivos, empleando las pruebas del sistema, se puede utilizar para identificar las vulnerabilidades del sistema

de manera eficiente, dependiendo de la criticidad del sistema y los recursos de TI disponibles (por ejemplo, asignado

fondos, la tecnología disponible, las personas con la experiencia necesaria para realizar la prueba). Métodos de ensayo

incluir

• Herramienta automatizada de análisis de vulnerabilidades

• Prueba de seguridad y la evaluación (ST & E)

• Las pruebas de penetración.6

La herramienta automatizada de análisis de vulnerabilidades se utiliza para explorar un grupo de hosts o de una red deservicios vulnerables conocidos (por ejemplo, el sistema permite que el Protocolo de transferencia de archivos anónimo [FTP],

sendmail retransmisión). Sin embargo, debe tenerse en cuenta que algunas de las potenciales vulnerabilidades

identificado por la herramienta automatizada de exploración pueden no representar las vulnerabilidades reales en el contexto de

el entorno del sistema. Por ejemplo, algunas de estas herramientas de escaneo de vulnerabilidades potenciales califica

sin tener en cuenta el medio ambiente y las necesidades del sitio. Algunas de las "vulnerabilidades"

marcado por el software automatizado de exploración en realidad no puede ser vulnerable a un sitio en particular

pero puede ser configurado de esa manera porque su entorno lo requiere. Por lo tanto, este método de ensayo

puede producir falsos positivos.

ST & E es otra técnica que se puede utilizar en la identificación de las vulnerabilidades del sistema de TI durante el

proceso de evaluación de riesgos. Incluye el desarrollo y ejecución de un plan de pruebas (por ejemplo, la prueba de

scripts, procedimientos de prueba y los resultados de las pruebas que se espera). El propósito de las pruebas de la seguridad del sistema es

comprobar la eficacia de los controles de seguridad de un sistema informático, ya que se han aplicado en un

entorno operativo. El objetivo es asegurar que los controles aplicados cumplen con el aprobadoespecificación de seguridad para el software y el hardware e implementar la seguridad de la organización

normas de política o de la industria se encuentran.

Las pruebas de penetración se puede utilizar para complementar la revisión de los controles de seguridad y asegurarse de que

diferentes facetas del sistema de TI están asegurados. Las pruebas de penetración, cuando se emplean en el riesgo

proceso de evaluación, se puede utilizar para evaluar la capacidad de un sistema de TI para resistir los intentos intencionales

para burlar la seguridad del sistema. Su objetivo es poner a prueba el sistema de TI desde el punto de vista de un

amenaza de código e identificar posibles fallos en los sistemas de protección de sistema de TI.

6 El proyecto de SP NIST 800-42, Pruebas de seguridad de la red general , se describe la metodología para el sistema de redprueba y el uso de herramientas automatizadas.

Página 24

Los resultados de este tipo de pruebas de seguridad opcional ayudarán a identificar las vulnerabilidades de un sistema.

3.3.3 Desarrollo de los Requisitos de Seguridad Checklist

Durante este paso, el personal de evaluación de riesgos a determinar si los requisitos de seguridad

estipulado para el sistema de TI y recogidos durante la caracterización del sistema se están cumpliendo por

existente o controles de seguridad previstos. Por lo general, los requisitos de seguridad del sistema pueden serse presenta en forma de tabla, con cada requisito acompañada de una explicación de cómo la

diseño o implementación del sistema tiene o no cumplen ese requisito de control de seguridad.

Una lista de verificación de los requisitos de seguridad contiene las normas básicas de seguridad que se pueden utilizar paraevaluar sistemáticamente e identificar las vulnerabilidades de los activos (personal, hardware,

software, información), los procedimientos no automatizados, procesos e información transferencias




asociado a un sistema de TI que figura en las siguientes zonas de seguridad:

• Gestión

• Operacional

• Técnico.

La Tabla 3-3 enumera los criterios de seguridad sugeridas para su uso en la identificación de las vulnerabilidades de un sistema informático encada área de la seguridad.

Tabla 3-3. Criterios de seguridad

Área de Seguridad Criterios de seguridad

Security Management• Asignación de responsabilidades• La continuidad de la ayuda• Capacidad de respuesta a incidentes• Revisión periódica de controles de seguridad• Investigaciones de liquidación de personal y de fondo• La evaluación de riesgos• La formación en seguridad y técnica• Separación de funciones• Sistema de autorización y reautorización• Plan de seguridad del sistema o de la aplicación

Seguridad Operacional• El control de los contaminantes transportados por el aire (humo, polvo, productos químicos)• Controles para garantizar la calidad del suministro de energía eléctrica• El acceso y la eliminación de medios de Datos• Distribución de datos externa y el etiquetado• Protección de la instalación (por ejemplo, sala de informática, centro de datos, oficina)• Control de humedad• Control de la temperatura• Las estaciones de trabajo, portátiles y ordenadores personales independientes

Página 25

Área de Seguridad Criterios de seguridad

Seguridad Técnica• Comunicaciones (por ejemplo, acceso telefónico, de interconexión de sistemas, enrutadores)• Criptografía• Control de acceso discrecional• Identificación y autenticación• La detección de intrusiones• Reutilización de objetos• Sistema de auditoría

El resultado de este proceso es la lista de comprobación de requisitos de seguridad. Las fuentes que se pueden utilizar en

compilar una lista de control de este tipo incluyen, pero no se limitan a, el siguiente gobierno reguladory las directivas de seguridad y fuentes aplicables al entorno de procesamiento del sistema de TI:

• CSA de 1987

• Normas de Procesamiento de Información Federal de Publicaciones

• OMB 11 2000 Circular A-130

• Ley de Privacidad de 1974

• El plan de seguridad del sistema del sistema de TI evaluado

• Las políticas de la organización de seguridad, directrices y normas

• Las prácticas de la industria.

El NIST SP 800-26, Guía de Autoevaluación de Seguridad para Sistemas Informáticos ,




ofrece un extenso cuestionario que contiene los objetivos de control específicos contra el que unsistema o grupo de sistemas interconectados pueden ser probados y medidos. Los objetivos de control

se abstrae directamente de los requisitos de larga data que se encuentran en la ley, la política, y orientación sobre

la seguridad y la privacidad.

Los resultados de la lista de verificación (o cuestionario) se puede utilizar como entrada para una evaluación de

el cumplimiento y el incumplimiento. Este proceso identifica sistema, proceso, y de procedimientodebilidades que representan vulnerabilidades potenciales.

De salida de la Etapa 3 Una lista de las vulnerabilidades del sistema (observaciones)7 que podrían ser ejercidas

por la amenaza potencial que los recursos

3.4 PASO 4: ANÁLISIS DE CONTROL

El objetivo de este paso es analizar los controles que se han implementado o están previstas para

aplicación, por la organización para minimizar o eliminar la probabilidad (o la probabilidad) de un

La amenaza de ejercer una vulnerabilidad del sistema.

7 Debido a que el informe de evaluación de riesgos no es un informe de auditoría, algunos sitios pueden preferir hacer frente a la identificadavulnerabilidades como las observaciones en lugar de los hallazgos en el informe de evaluación de riesgos.

Página 26

Para obtener una calificación general probabilidad de que indica la probabilidad de que una vulnerabilidad potencial

puede ser ejercida dentro de la construcción del medio ambiente amenaza asociada (paso 5 más abajo), la

implementación de los controles actuales o previstas deben ser considerados. Por ejemplo, una vulnerabilidad

(Por ejemplo, el sistema o la debilidad de procedimiento) no es probable que se ejerza o la probabilidad es baja si hay

es un bajo nivel de interés amenaza de código o la capacidad o si hay controles de seguridad eficaces que

puede eliminar, o reducir la magnitud de causar un daño.

Secciones 3.4.1 a través de 3.4.3, respectivamente, discutir métodos de control, las categorías de control, y el

controlar técnica de análisis.

3.4.1 Métodos de control

Los controles de seguridad abarcan el uso de métodos técnicos y no técnicos. Los controles técnicos

salvaguardias que se incorporan en el hardware, software, o de firmware (por ejemplo, acceso

mecanismos de control, los mecanismos de identificación y autenticación, métodos de encriptación,software de detección de intrusión). Controles no técnicos son la gestión y los controles operacionales,

tales como las políticas de seguridad; procedimientos operacionales; y personal, física y medioambiental

seguridad.

3.4.2 Control de Categorías

Las categorías de control de los métodos de control tanto técnicos como no técnicos pueden estar más

clasificado como preventivo o detective. Estos dos subcategorías se explican de la siguiente manera:

• Los controles preventivos inhiben los intentos de violar la política de seguridad e incluyen tales

controla como la aplicación de control de acceso, cifrado y autenticación.

• Los controles Detectives advierten de violaciónes o intentos de violaciónes de la política de seguridad y

incluir controles tales como pistas de auditoría, los métodos de detección de intrusos, y sumas de comprobación.

Sección 4.4 explica, además, estos controles desde el punto de vista de la implementación. La

aplicación de los controles durante el proceso de mitigación de riesgo es el resultado directo de laidentificación de las deficiencias en los controles actuales o previstas durante el proceso de evaluación de riesgos

(Por ejemplo, los controles no están en su lugar o los controles no se aplican correctamente).

3.4.3 Análisis de Control Técnica

Como se discutió en la Sección 3.3.3, el desarrollo de una lista de verificación los requisitos de seguridad o el uso de un

lista de comprobación disponible será útil en el análisis de los controles de una manera eficiente y sistemático.La lista de verificación de los requisitos de seguridad se puede utilizar para validar el incumplimiento de seguridad, así como

cumplimiento. Por lo tanto, es esencial para actualizar esas listas de control para reflejar los cambios en un




ambiente de control de la organización (por ejemplo, los cambios en las políticas de seguridad, métodos yrequisitos) para asegurar la validez de la lista de verificación.

La salida de la Etapa 4 Lista de los controles actuales o previstas utilizados para el sistema de TI para mitigar el

probabilidad de ser ejercida de una vulnerabilidad y reducir el impacto de un evento adverso

Página 27


3.5 PASO 5: RIESGO DETERMINACIÓN

Para obtener una calificación general probabilidad de que indica la probabilidad de que una vulnerabilidad potencial

puede ser ejercida dentro de la construcción del medio ambiente amenaza asociada, la siguiente

factores que gobiernan deben ser considerados:

• Motivación Amenaza de código y la capacidad

• La naturaleza de la vulnerabilidad

• Existencia y eficacia de los controles actuales.

La probabilidad de que una vulnerabilidad potencial podría ser ejercida por una amenaza determinada fuente puede serdescrito como alto, medio o bajo. Tabla 3-4 siguiente se describen estos tres niveles de probabilidad.

Tabla 3-4. Definiciones de probabilidad

Nivel de Riesgo Probabilidad Definición

Alto La amenaza de código está muy motivado y suficientemente capaz, y controles paraprevenir la vulnerabilidad de la que se ejerce son ineficaces.

Medio La amenaza de código está motivado y capaz, pero los controles son en el lugar que puedeobstaculizar el ejercicio con éxito de la vulnerabilidad.

Bajo La amenaza de código carece de motivación o capacidad, o los controles se han establecido paraprevenir o impedir al menos de manera significativa, la vulnerabilidad de ser ejercido.

De salida de la Etapa 5 Calificación de probabilidad (alta, media, baja)

3.6 PASO 6: ANÁLISIS DE IMPACTO

El siguiente paso importante en el nivel de riesgo de medición es determinar los efectos adversos resultantes de

un ejercicio de amenaza exitosa de una vulnerabilidad. Antes de iniciar el análisis de impacto, es

necesario para obtener la siguiente información necesaria como se discutió en la Sección 3.1.1:

• La misión del sistema (por ejemplo, los procesos realizados por el sistema de TI)

• Sistema y criticidad de datos (por ejemplo, el valor del sistema o de la importancia de una organización)

• Sistema y sensibilidad de los datos.

Esta información puede obtenerse a partir de la documentación de la organización existente, como lainforme de análisis de impacto misión o activo informe de evaluación de la criticidad. Un análisis del impacto misión

(También conocido como análisis de impacto en el negocio [BIA] para algunas organizaciones) prioriza el impacto

niveles asociados con el compromiso de los activos de información de una organización basada en unaevaluación cualitativa o cuantitativa de la sensibilidad y criticidad de dichos activos. Un activo

evaluación de la criticidad identifica y da prioridad a la información de la organización sensible y crítica

los activos (por ejemplo, hardware, software, sistemas, servicios y tecnología relacionada activos) que apoyan lamisiones críticas de la organización.



Página 28


Si esta documentación no existe o tipo de evaluaciones para los activos de TI de la organización no tienesido realizado, el sistema y los datos de sensibilidad puede ser determinada basándose en el nivel de

la protección necesaria para mantener el sistema y la disponibilidad de los datos, la integridad y la confidencialidad.

Independientemente del método utilizado para determinar el grado de sensibilidad de un sistema informático y sus datos son, la

propietarios de los sistemas y de la información son los responsables de determinar el nivel de impacto de

su propio sistema y la información. Por consiguiente, en el análisis de impacto, el enfoque apropiado

es entrevistar al sistema y el propietario (s) de la información.

Por lo tanto, el impacto negativo de un evento de seguridad se puede describir en términos de pérdida o degradación

de algunos, o una combinación de cualquiera de los siguientes tres objetivos de seguridad: integridad, disponibilidad y

confidencialidad. La siguiente lista proporciona una breve descripción de cada objetivo de seguridad y laconsecuencia (o impacto) de su no se cumplan:

• Pérdida de la integridad. sistema y la integridad de datos se refiere a la exigencia de que

información será protegida contra la modificación incorrecta. La integridad se pierde si no autorizada

se realizan cambios en los datos o sistema de TI ya sea por actos intencionales o accidentales. Si

la pérdida del sistema o integridad de los datos no se corrige, el uso continuado de la contaminación

sistema o datos dañados podrían causar inexactitud, fraude o decisiones erróneas.Además, la violación de la integridad puede ser el primer paso de un ataque exitoso contra el sistema

disponibilidad o confidencialidad. Por todas estas razones, la pérdida de la integridad reduce la

seguridad de un sistema informático.

• Pérdida de la disponibilidad. Si un sistema de TI de misión crítica no está disponible para sus usuarios finales,

La misión de la organización puede verse afectada. La pérdida de la funcionalidad del sistema y

eficacia operativa, por ejemplo, puede resultar en la pérdida de tiempo productivo, por lo tanto

obstaculizar el rendimiento de los usuarios finales de sus funciones en el apoyo a la

La misión de la organización.

• La pérdida de confidencialidad. sistema y confidencialidad de los datos se refiere a la protección de los

información de su divulgación no autorizada. El impacto de la divulgación no autorizada de

información confidencial puede ir desde la puesta en peligro de la seguridad nacional a la

divulgación de datos de la Ley de Privacidad. No autorizada, no previstos, o no intencionaldivulgación pueda resultar en la pérdida de la confianza pública, la vergüenza, o la acción legal

en contra de la organización.

Algunos impactos tangibles se pueden medir cuantitativamente en pérdidas de ingresos, el costo de la reparación de la

sistema, o el nivel de esfuerzo necesario para corregir los problemas causados por una acción de amenaza exitosa.

Otros impactos (por ejemplo, la pérdida de la confianza pública, la pérdida de credibilidad, el daño a una organización de

intereses) no se puede medir en unidades específicas, sino que puede ser calificado o descrito en términos de altura,medio y bajo impacto. Debido a la naturaleza genérica de esta discusión, esta guía designa

y describe sólo el impacto cualitativo categorías: alta, media y baja (ver Cuadro 3.5).

Página 29

Tabla 3-5. Magnitud del Impacto Definiciones

Magnitud deImpacto

Definición de Impacto

AltoEjercicio de la vulnerabilidad (1) puede dar lugar a la muy costosa pérdida deprincipales activos o recursos tangibles; (2) pueda violar de manera significativa, daño, oobstaculizar la misión de una organización, la reputación o intereses; o (3) puede resultaren la muerte humanas y heridos graves.

MedioEjercicio de la vulnerabilidad (1) puede resultar en la pérdida de la costosa tangiblebienes o recursos; (2) pueda violar, dañar o impedir la organización de




misión, reputación o intereses; o (3) puede dar lugar a lesiones.

BajoEl ejercicio de la vulnerabilidad (1) puede resultar en la pérdida de algunos tangibleactivos o recursos o (2) puede afectar notablemente a una organización demisión, reputación o intereses.

Cuantitativo frente Evaluación cualitativa

Al realizar el análisis de impacto, se debe considerar las ventajas y

desventajas de comparación cuantitativa evaluaciones cualitativas. La principal ventaja de la

análisis de impacto cualitativo es que prioriza los riesgos e identifica áreas para inmediatala mejora en el tratamiento de las vulnerabilidades. La desventaja del análisis cualitativo es

que no proporcionan mediciones cuantificables específicos de la magnitud de los impactos,

por lo tanto, hacer un análisis de costo-beneficio de los controles recomendados difíciles.

La principal ventaja de un análisis cuantitativo de impacto es que proporciona una medida de la

magnitud impactos ", que se puede utilizar en el análisis coste-beneficio de los controles recomendados.

La desventaja es que, dependiendo de los rangos numéricos utilizados para expresar la medición,el significado del análisis de impacto cuantitativo puede ser poco clara, lo que requiere que el resultado sea

interpretado de manera cualitativa. Los factores adicionales a menudo se deben considerar para determinar la

magnitud del impacto. Estos pueden incluir, pero no se limitan a-

• Una estimación de la frecuencia de ejercicio de la amenaza-fuente de la vulnerabilidad

durante un período de tiempo determinado (por ejemplo, 1 año)

• Un costo aproximado de cada ocurrencia de ejercicio de la amenaza-fuente de la

vulnerabilidad

• Un factor ponderado basado en un análisis subjetivo del impacto relativo de un determinado

La amenaza de ejercer una vulnerabilidad específica.

De salida de la Etapa 6 Magnitud del impacto (Alta, Media o Baja)

Página 30

3.7 PASO 7: DETERMINACIÓN DEL RIESGO

El propósito de este paso es evaluar el nivel de riesgo para el sistema de TI. La determinación del riesgo

para un par amenaza / vulnerabilidad particular, se puede expresar como una función de

• La probabilidad de intentar ejercer una vulnerabilidad dado un de amenaza determinada fuente

• La magnitud del impacto en caso de una amenaza de código ejercer con éxito la

vulnerabilidad

• La adecuación de los controles de seguridad planificadas o existentes para reducir o eliminar

riesgo.

Para medir el riesgo, una escala de riesgo y una matriz de nivel de riesgo se deben desarrollar. Sección 3.7.1 se presenta unmatriz estándar de nivel de riesgo; Sección 3.7.2 se describen los niveles de riesgo resultantes.

3.7.1 Riesgo Nivel Matrix

La determinación final del riesgo de la misión se obtiene multiplicando la calificación otorgada por la amenaza

probabilidad (por ejemplo, probabilidad) y el impacto de amenazas. Tabla 3.6 muestra cómo el riesgo global

Las calificaciones pueden ser determinados con base en las aportaciones de los efectos probabilidad amenaza y la amenazacategorías. La siguiente matriz es una matriz de 3 x 3 de la probabilidad de amenaza (Alta, Media y Baja)

y el impacto de amenazas (Alta, Media y Baja). Dependiendo de los requisitos del sitio y la




granularidad de la evaluación de riesgo deseado, algunos sitios puede utilizar una 4 x 4 o una matriz de 5 x 5. Este últimopuede incluir un / Muy Alta probabilidad de peligrosidad muy baja y un impacto de peligrosidad muy baja / muy alta a

generar un nivel Muy Bajo / Muy alto riesgo. Un "Muy Alto" nivel de riesgo puede requerir posible

apagado del sistema o interrupción de todos los esfuerzos de integración y pruebas de sistemas de TI.

La matriz de la muestra en la Tabla 3-6 muestra cómo los niveles generales de riesgo de Alta, Media y Baja son

derivada. La determinación de estos niveles de riesgo o calificaciones puede ser subjetiva. La justificación de

esta justificación se puede explicar en términos de la probabilidad asignada para cada probabilidad amenazanivel y un valor asignado para cada nivel de impacto. Por ejemplo,

• La probabilidad asignada para cada nivel de probabilidad de amenaza es 1.0 para alto, 0,5 para

Mediana, 0.1 para Baja

• El valor asignado para cada nivel de impacto es 100 para alta, 50 de media, y 10 para

Low.

Página 31

Tabla 3-6. Matriz de Riesgo de nivel

ImpactoAmenaza

ProbabilidadBajo

(10)

Medio

(50)

Alto

(100)

Alta (1,0) Bajo

10 X 1,0 = 10

Medio

50 X 1,0 = 50

Alto

100 X 1,0 = 100

Medio (0,5) Bajo

10 X 0,5 = 5

Medio

50 X 0,5 = 25

Medio

100 X 0,5 = 50

Low (0.1) Bajo

10 X 0,1 = 1

Bajo

50 X 0,1 = 5

Bajo

100 X 0,1 = 10

Escala de riesgo: High (> 50 a 100); Medio (> 10 a 50); Bajo (1 a 10)8

3.7.2 Descripción del Nivel de Riesgo

La Tabla 3-7 describe los niveles de riesgo que aparecen en la matriz anterior. Esta escala de riesgo, con las calificaciones de

Alta, Media y Baja, representa el grado o nivel de riesgo al que un sistema informático, instalación o

procedimiento podría estar expuesto si una vulnerabilidad dada fuera ejercida. La escala de riesgo también presenta

acciones que la alta dirección, los propietarios de la misión, deben tomar para cada nivel de riesgo.

Tabla 3-7. Escala de Riesgo y acciones necesarias

Nivel de riesgo Descripción de riesgos y acciones necesarias

Alto

Si una observación o hallazgo se evalúa como de alto riesgo, hay unfuerte necesidad de medidas correctivas. Un sistema existente puedecontinúan operando, sino un plan de acción correctiva debe ser puesto en marchatan pronto como sea posible.

MedioSi una observación está clasificado como de riesgo medio, las acciones correctivas sonnecesaria y un plan debe ser desarrollado para incorporar estas accionesdentro de un período razonable de tiempo.

BajoSi una observación es descrito como de bajo riesgo, DAA del sistema debedeterminar si aún se requieren acciones correctivas o decidenaceptar el riesgo.




La salida de la Etapa 7 El nivel de riesgo (alto, medio, bajo)

8 Si el nivel indicado en ciertos artículos es tan bajo como para ser considerados como "insignificante" o no significativa (el valor es <1en la escala de riesgo de 1 a 100), se puede desear para mantener estos a un lado en un cubo separado en lugar de reenvío paraacciones de gestión. Esto se asegurará de que no se pasan por alto cuando se realiza la próxima riesgo periódicaevaluación. También establece un registro completo de todos los riesgos identificados en el análisis. Estos riesgos pueden pasar a unnuevo nivel de riesgo en una reevaluación debido a un cambio en la probabilidad y / o impacto de la amenaza y es por eso que es fundamentalque su identificación no se perderá en el ejercicio.

Página 32

3.8 PASO 8: RECOMENDACIONES DE CONTROL

Durante este paso del proceso, los controles que podría mitigar o eliminar los riesgos identificados, como

apropiada para las operaciones de la organización, se proporcionan. El objetivo de la recomendada

controles es reducir el nivel de riesgo para el sistema de TI y sus datos a un nivel aceptable. Lasiguientes factores deben ser considerados en la recomendación de los controles y las alternativas de solución a

minimizar o eliminar los riesgos identificados:

• Eficacia de las opciones recomendadas (por ejemplo, la compatibilidad del sistema)

• Legislación y normativa

• Política Organizacional

• Impacto Operacional

• Seguridad y fiabilidad.

Las recomendaciones de control son los resultados del proceso de evaluación de riesgos y proporcionar aportaciones al

el proceso de mitigación de riesgos, en el que la seguridad del procedimiento y técnica recomendadalos controles son evaluados, priorizados, y se apliquen.

Cabe señalar que no todos los controles posibles recomendadas se pueden implementar para reducir la pérdida.

Para determinar cuáles son necesarios y apropiados para una organización específica, una relación costo-beneficioanálisis, como se discute en la Sección 4.6, debe llevarse a cabo para la propuesta recomendada

controles, para demostrar que los costos de implementación de los controles pueden ser justificadas por la

reducción en el nivel de riesgo. Además, el impacto operativo (por ejemplo, el efecto sobre el sistema

rendimiento) y viabilidad (por ejemplo, los requisitos técnicos, la aceptación por el usuario) de la introducción de la

opción recomendada debe ser evaluado cuidadosamente durante el proceso de mitigación de riesgos.

La salida de la Etapa 8 Recomendación de control (s) y soluciones alternativas para mitigar el riesgo

3.9 PASO 9: RESULTADOS DE DOCUMENTACIÓN

Una vez que la evaluación de riesgos se ha completado (amenaza los recursos y vulnerabilidades identificadas, riesgosevaluados, y los controles recomendados de siempre), los resultados deben ser documentados en un funcionario

informe o reunión.

Un informe de evaluación de riesgos es un informe de gestión que ayuda a la alta dirección, la misión

propietarios, a tomar decisiones sobre la política, de procedimiento, el presupuesto, y el sistema operativo y de gestión

cambios. A diferencia de un informe de auditoría o investigación, que se ve por la culpa, una evaluación de riesgosinforme no debe ser presentada en forma acusatoria, sino como una sistemática y analítica

acercarse a la evaluación de riesgos, de manera que la alta dirección comprenda los riesgos y asignar

recursos para reducir y corregir las posibles pérdidas. Por esta razón, algunas personas prefieren dirección

los pares de amenaza / vulnerabilidad como observaciones en lugar de los hallazgos en el informe de evaluación de riesgos.Apéndice B proporciona un esquema sugerido para el informe de evaluación de riesgos.

De salida de la Etapa 9 Informe de evaluación de riesgos que se describen las amenazas y vulnerabilidades,

mide el riesgo, y proporciona recomendaciones para la implementación de control




Página 33


4. REDUCCIÓN DEL RIESGO

La mitigación del riesgo, el segundo proceso de la gestión del riesgo, implica priorizar, evaluar y

la aplicación de los controles de reducción de riesgos pertinentes recomendadas por la evaluación de riesgos

proceso.

Debido a la eliminación de todos los riesgos suele ser poco práctico o casi imposible, es el

la responsabilidad de la alta dirección y los gerentes funcionales y de negocio a utilizar el menor costo

acercarse y poner en práctica los controles más adecuados para disminuir el riesgo de la misión a un nivel aceptablenivel, con un mínimo impacto negativo sobre los recursos y la misión de la organización.

Esta sección describe las opciones de mitigación de riesgos (Sección 4.1), la estrategia de mitigación de riesgos (Sección

4.2), un enfoque para la aplicación de control (Sección 4.3), las categorías de control (Sección 4.4), el

análisis de costo-beneficio utilizado para justificar la aplicación de los controles recomendados (Sección

4,5), y el riesgo residual (Sección 4.6).

4.1 OPCIONES DE MITIGACIÓN DE RIESGO

La mitigación del riesgo es una metodología sistemática utilizada por la administración superior para reducir el riesgo de la misión.

La mitigación del riesgo se puede lograr a través de cualquiera de las siguientes opciones para reducirlo:

• Asunción de Riesgos. Aceptar el riesgo potencial y continuar operando el sistema de TI

o implementar controles para reducir el riesgo a un nivel aceptable

• Evitar Riesgos. Para evitar el riesgo mediante la eliminación de la causa del riesgo y / o consecuencia

(Por ejemplo, renunciar a ciertas funciones del sistema o apagar el sistema cuando los riesgos son

identificado)

• Limitación del riesgo. Para limitar el riesgo mediante la implementación de controles que minimizan el

impacto adverso de una amenaza está ejerciendo una vulnerabilidad (por ejemplo, el uso de apoyo,

preventivos, controles de detección)

• Planificación de Riesgos. Para gestionar el riesgo mediante el desarrollo de un plan de mitigación de riesgos que prioriza,

implementa y mantiene controles

• Investigación y Reconocimiento. Para reducir el riesgo de pérdidas por el reconocimiento de la

vulnerabilidad o fallo y la investigación de controles para corregir la vulnerabilidad

• La transferencia de riesgos. Para transferir el riesgo mediante el uso de otras opciones para compensar la

pérdida, como la compra de un seguro.

Los objetivos y la misión de una organización deben ser considerados en la selección de cualquiera de estos riesgos

las opciones de mitigación. Puede que no sea práctico para hacer frente a todos los riesgos identificados, por lo que la prioridad debe ser

dada a los pares de amenazas y vulnerabilidad que tienen el potencial de causar la misión significativaimpacto o daño. Además, en la protección de la misión de una organización y sus sistemas de TI, debido a

medio ambiente y los objetivos propios de cada organización, la opción utilizada para mitigar el riesgo y

los métodos utilizados para implementar controles pueden variar. El enfoque de "lo mejor del mercado" es el uso de

tecnologías apropiadas de entre los diversos productos de seguridad del proveedor, junto con la

opción de mitigación del riesgo adecuada y, medidas administrativas no técnicas.

Página 34

4.2 RIESGO DE MITIGACIÓN DE ESTRATEGIA

La alta dirección, los propietarios de la misión, a sabiendas de los riesgos potenciales y los controles recomendados,

puede preguntar: "¿Cuándo y bajo qué circunstancias debo actuar? Cuando voy a poner en práctica

estos controles para mitigar los riesgos y proteger a nuestra organización? "

El gráfico de la mitigación de riesgos en la Figura 4-1 se ocupa de estas cuestiones. Puntos apropiados para




implementación de las acciones de control se indican en esta figura con la palabra SÍ.

SistemaDiseño

SÍ

NO

Sin Riesgo

SÍ

NO

Sin Riesgo

Vulnerabilidadpara atacarExiste

AmenazaFuente

SÍ

Aceptar Riesgo

InaceptableRiesgo

RiesgoExiste

SÍ

Aceptar Riesgo

Y

NO NO

Del atacanteCosto <Gain

PérdidaAnticipado> Umbral

Vulnerable? Explotable?

Figura 4-1. Puntos de Acción de Mitigación de Riesgos

Esta estrategia se articula además en los siguientes reglas generales, que proporcionan orientación sobre

acciones para mitigar los riesgos de las amenazas humanas intencionales:

• Cuando existe la vulnerabilidad (o defecto, debilidad) ➞ implementar técnicas de garantía

para reducir la probabilidad de que una vulnerabilidad de que se ejerce.

• Cuando una vulnerabilidad puede ser ejercido ➞ aplique protecciones en capas, de arquitectura

diseños, y los controles administrativos para reducir al mínimo el riesgo de, o prevenir esta

ocurrencia.

• Cuando el costo del atacante es menor que la ganancia potencial ➞ aplicar protecciones a

disminuir la motivación de un atacante mediante el aumento de costo del atacante (por ejemplo, el uso del sistema

controles tales como limitar lo que un usuario del sistema pueden acceder y hacer posible de manera significativa

reducir la ganancia de un atacante).

• Cuando la pérdida es demasiado grande ➞ aplicar los principios de diseño, diseños arquitectónicos y técnicos

y las protecciones no técnicas para limitar el alcance del ataque, lo que reduce el

potencial de pérdida.

La estrategia describe anteriormente, con la excepción del tercer elemento de la lista ("Cuando el costo del atacante

es menor que la ganancia potencial "), se aplica también a la mitigación de los riesgos derivados de medio ambiente

Página 35

o las amenazas humanas intencionales (por ejemplo, del sistema o errores de usuario). (Debido a que no hay un "atacante", no

la motivación o la ganancia es participar.)

4.3 ENFOQUE PARA LA APLICACIÓN DE CONTROL

Cuando es necesario tomar medidas de control, la siguiente regla se aplica:

Abordar los riesgos más importantes y nos esforzamos para la mitigación de riesgos suficiente al menor costo, con

impacto mínimo en otras capacidades de misión.

La siguiente metodología de mitigación de riesgos se describe el enfoque para controlar la puesta en práctica:

• Paso 1 priorizar acciones

Sobre la base de los niveles de riesgo que se presentan en el informe de evaluación de riesgos, la implementación

acciones se priorizan. En la asignación de recursos, se debe dar la máxima prioridad a los riesgos

artículos con clasificaciones inaceptablemente alto riesgo (por ejemplo, riesgo asignado un alto o muy altonivel de riesgo). Estos pares de vulnerabilidad / amenaza requerirá una acción correctiva inmediata

para proteger los intereses y la misión de una organización.

De salida de la Etapa 1 Acciones de clasificación de mayor a menor




• Paso 2 Evaluar Opciones de control recomendadas

Los controles recomendados en el proceso de evaluación del riesgo pueden no ser los más

opciones apropiadas y viables para una organización específica y el sistema de TI. Durante

este paso, la viabilidad (por ejemplo, la compatibilidad, la aceptación del usuario) y la eficacia (por ejemplo,grado de protección y el nivel de mitigación de riesgos) de las opciones de control recomendadas

se analizan. El objetivo es seleccionar la opción de control más apropiado para

minimizando los riesgos.

De salida de la Etapa 2 Lista de controles factibles

• Paso 3 Conducta Análisis Costo-Beneficio

Para ayudar a la gerencia en la toma de decisiones y para identificar los controles rentables, un costo-

se lleva a cabo el análisis de beneficio. Sección 4.5 detalla los objetivos y el método de

llevar a cabo el análisis de costo-beneficio.

De salida de la Etapa 3 El análisis de costo-beneficio que describe el costo y los beneficios de

aplicación o no de los controles

• Paso 4 Seleccione Control

Sobre la base de los resultados del análisis de costo-beneficio, la administración determina la

mayor control económico (s) para reducir el riesgo a la misión de la organización. La

controles seleccionados deben combinar el control técnico, operativo y de gestiónelementos para garantizar la seguridad adecuada para el sistema de TI y la organización.

La salida de la Etapa 4 Control seleccionado (s)

Página 36

• Paso 5 Asignar Responsabilidad

Personas apropiadas (personal de la casa o del personal de contratación externa) que tienen laconocimientos técnicos apropiados y conjuntos de habilidades para poner en práctica el control seleccionado se identifican,

y se le asigna la responsabilidad.

De salida de la Etapa 5 Lista de las personas responsables

• Paso 6 Desarrollar un Plan de Implementación de salvaguardia

Durante este paso, un plan de implementación de salvaguardia9 (O plan de acción) se desarrolla. La

plan debería, como mínimo, la siguiente información:

- Riesgos (pares de vulnerabilidad / amenaza) y los niveles de riesgo asociados (salida de riesgoinforme de evaluación)

- Los controles recomendados (salida de informe de evaluación de riesgos)

- Acciones prioritarias (dando prioridad a los elementos con muy alto y alto riesgoniveles)

- Selección de los controles programados (determinados en función de la viabilidad, eficacia,

beneficios a la organización, y el costo)

- Los recursos necesarios para la aplicación de los controles previstos seleccionados

- Las listas de los equipos y el personal responsable

- Fecha de inicio de la ejecución

- Fecha prevista de finalización de la aplicación

- Los requisitos de mantenimiento.

El plan de implementación de salvaguardia prioriza las acciones de implementación y

proyectos de las fechas de inicio y terminación de destino. Este plan ayudará y agilizar el riesgoproceso de mitigación. Apéndice C proporciona una tabla resumen de la muestra para la salvaguardia

plan de implementación.

De salida de la Etapa 6 Safeguard plan de implementación




• Paso 7 Implementar control seleccionado (s)

Dependiendo de las situaciones individuales, los controles implementados pueden reducir el riesgo

nivel, pero no elimina el riesgo. Riesgo residual se discute en la Sección 4.6.

La salida de la Etapa 7 Riesgo residual

La figura 4-2 muestra la metodología recomendada para la mitigación de riesgos.

9 NIST Interagencial Informe 4749, Declaraciones de muestra de trabajo en materia de Servicios Federales de Seguridad Informática: Para uso In-Casa o la subcontratación. diciembre de 1991.

Página 37

Lista de posiblescontroles

Paso 2.Evaluar recomendados

Opciones de control

Paso 1.Priorizar acciones

• Los niveles de riesgo de lala evaluación de riesgosinforme

Entrada Mitigación de Riesgos Actividades Salida

Acciones del rango deDe mayor a menor

Costo-beneficioanálisis

Paso 3.Realizar análisis de costos y beneficios

• Impacto de la implementación de• Impacto de la no implementación• Los costos asociados

• Viabilidad• Eficacia

• Evaluación de riesgosinforme

Paso 5.Asignar la responsabilidad

Lista de lospersonas responsables

Paso 6. Desarrollar SafeguardPlan de Implementación

• Los riesgos y los niveles de riesgo asociados• Acciones prioritarias• Los controles recomendados• Los controles previstos seleccionados• Personas Responsables• Fecha de inicio• Fecha de Terminación de• Requisitos de mantenimiento

Salvaguardarplan de implementación

Paso 7 .Implementar seleccionado

ControlesRiesgos residuales

Paso 4.Seleccione Controles

Controles seleccionados




Figura 4-2. Mitigación de Riesgos Metodología Organigrama

Página 38


4.4 CATEGORÍAS DE CONTROL

En la aplicación de los controles recomendados para mitigar el riesgo, una organización debería considerar

técnica, de gestión, y los controles de seguridad operativa, o una combinación de tales controles, a

maximizar la eficacia de los controles de sus sistemas de TI y de la organización. Los controles de seguridad,

cuando se usa apropiadamente, puede prevenir, limitar o impedir el daño de amenazas de origen a una organización de

misión.

El proceso de recomendación de control consistirá en elegir entre una combinación de técnica,

la gestión y los controles operacionales para mejorar la postura de seguridad de la organización. La

compensaciones que una organización tendrá que considerar se ilustran mediante la visualización de las decisiones

involucrados en la aplicación de uso de contraseñas de usuario complejas para minimizar la adivinación de contraseñas yagrietamiento. En este caso, un control técnico que requiere add-on software de seguridad puede ser más

complejo y caro que un procedimiento de control, pero el control técnico es probable que sea más

efectiva debido a que la aplicación está automatizado por el sistema. Por otro lado, un procedimientoel control se puede implementar simplemente por medio de un memorando a todas las personas interesadas

y una modificación de las directrices de seguridad de la organización, sino garantizar que los usuarios

seguir constantemente la escritura de constitución y directriz será difícil y requerirá de seguridad

la sensibilización y la aceptación del usuario.

Esta sección proporciona una visión general de alto nivel de algunas de las categorías de control. Más detallada

orientación sobre la implantación y la planificación de los controles de TI se puede encontrar en el NIST SP 800-18,Guía para el desarrollo de Planes de Seguridad para Sistemas Informáticos, y NIST SP 800-12,

Una introducción a la seguridad informática: El Manual NIST.

Secciones 4.4.1 a través de 4.4.3 proporcionan una visión general de la técnica, de gestión y operativa

controles, respectivamente.

4.4.1 Controles de seguridad técnica

Controles de seguridad técnicas para la mitigación de riesgos se pueden configurar para proteger contra determinados tipos de

amenazas. Estos controles pueden ser simples o complejas medidas y por lo general el sistema implicaráarquitecturas; disciplinas de la ingeniería; y paquetes de seguridad con una combinación de hardware, software,

y el firmware. Todas estas medidas deben trabajar juntos para asegurar los datos críticos y sensibles,

funciones de información y sistemas de TI. Los controles técnicos se pueden agrupar en los siguientes

grandes categorías, de acuerdo con el propósito primario:

• Apoyo (Sección 4.4.1.1). Controles de apoyo son de carácter genérico y la mayoría lo sustentan

capacidades de seguridad. Estos controles deben estar en su lugar con el fin de poner en práctica otra

controles.

• Prevenir (Sección 4.4.1.2). Los controles preventivos se centran en la prevención de las violaciones de seguridad

que se produzcan en el primer lugar.

• Detectar y recuperar (Sección 4.4.1.3). Estos controles se centran en la detección y

recuperarse de un fallo de seguridad.

La Figura 4-3 muestra los controles técnicos primarios y las relaciones entre ellos.

Página 39

TransacciónIntimidad

Detectar, recuperar

Evitar

No-




Protecciones del sistema(Mínimo privilegio, reutilización de objetos, la separación de procesos, etc)

Administración de la Seguridad

Gestión de claves de cifrado

Comunicaciones Protegidas(Salvo de divulgación, sustitución, modificación, y repetición)

Recurso

Usuarioo

Proceso

Autenticación

Autorización

Control de AccesoAplicación

Prueba deIntegridad

Detección de Intrusos

y la contención

Identificación

Auditoría

Restaurar estado

Apoyorepudio

Figura 4-3. Controles de seguridad técnica

4.4.1.1 Controles TÉCNICAS DE APOYO

Controles de apoyo son, por su propia naturaleza, omnipresente e interrelacionado con muchos otroscontroles. Los controles de soporte son de la siguiente manera:

• Identificación. Este control proporciona la capacidad para identificar de forma única los usuarios, los procesos,

y recursos de información. Para llevar a cabo otros controles de seguridad (por ejemplo, discrecional

control de acceso [DAC], control de acceso obligatorio [MAC], la rendición de cuentas), esesencial que ambos sujetos y objetos sean identificables.

• Gestión de claves de cifrado. Las claves criptográficas deben ser gestionados de forma segura

cuando las funciones criptográficas se implementan en diversos otros controles.

La gestión de claves de cifrado incluye la generación de claves, la distribución, el almacenamiento y lamantenimiento.

• Administración del Seguro. Las características de seguridad de un sistema de TI deben estar configurados

(Por ejemplo, activado o desactivado) para satisfacer las necesidades de una instalación específica y para la cuenta

los cambios en el entorno operativo. La seguridad del sistema se puede construir enla seguridad del sistema operativo o la aplicación. Off-the-shelf Comercial add-on

productos de seguridad disponibles.

Página 40

• Protección del sistema. Subyacente capacidades funcionales diferentes de seguridad de un sistema

es una base de confianza en la ejecución técnica. Esto representa la calidad de

la aplicación desde la perspectiva tanto de los procesos de diseño utilizados y de la

forma en que se llevó a cabo la aplicación. Algunos ejemplos de sistema de

protecciones son protección de la información residual (también conocida como la reutilización de objetos), menosprivilegio (o "necesidad de saber"), la separación de procesos, la modularidad, capas, y

la reducción al mínimo de lo que debe ser de confianza.

4.4.1.2 Controles técnicos de prevención

Estos controles, que pueden inhibir intentos de violar la política de seguridad, se incluyen los siguientes:

• Autenticación. El control de autenticación proporciona los medios para verificar el

la identidad de un sujeto para asegurar que una identidad reivindicada es válida. Autenticación

mecanismos incluyen contraseñas, números de identificación personal, o PIN, y

tecnología de autenticación emergente que proporciona autenticación fuerte (por ejemplo, modo,

tarjetas inteligentes, certificados digitales, Kerberos).




• Autorización. El control de autorización permite la especificación y la subsiguiente

la gestión de las acciones permitidas para un sistema dado (por ejemplo, el propietario de la información o

el administrador de la base de datos determina quién puede actualizar un archivo compartido se accede por una

grupo de usuarios).

• Aplicación de control de acceso. integridad y confidencialidad de los datos son aplicadas por

controles de acceso. Cuando el sujeto que solicita el acceso ha sido autorizado para el acceso

procesos particulares, es necesario aplicar la política de seguridad definida (por ejemplo, MAC

o DAC). Estos controles basados en políticas se aplican a través de los mecanismos de control de accesodistribuidos por todo el sistema (por ejemplo, las etiquetas de sensibilidad MAC; permisos de archivos CAD

conjuntos, listas de control de acceso, funciones, perfiles de usuario). La eficacia y la fuerza de

control de acceso depende de la exactitud de las decisiones de control de acceso (por ejemplo, cómo el

reglas de seguridad se configuran) y la fuerza de la aplicación de control de acceso (por ejemplo, ladiseño de software o hardware de seguridad).

• No repudio. rendición de cuentas del sistema depende de la capacidad de garantizar que los remitentes

no se puede negar el envío de información y que los receptores no se puede negar que lo recibe.

No rechazo se extiende tanto a la prevención y detección. Se ha colocado en elcategoría de prevención en esta guía debido a que los mecanismos implementados impiden la

repudio con éxito de una acción (por ejemplo, el certificado digital que contiene la

la clave privada del propietario es conocida sólo por el propietario). Como resultado, este control es típicamente

aplicado en el punto de transmisión o recepción.

• Comunicaciones protegido. En un sistema distribuido, la capacidad para llevar a cabo

objetivos de seguridad es altamente dependiente de las comunicaciones de confianza. La

control de las comunicaciones protegidas garantiza la integridad, disponibilidad yconfidencialidad de la información sensible y crítica mientras está en tránsito. Protegido

comunicaciones utilizan métodos de cifrado de datos (por ejemplo, la red privada virtual, Internet

Protocolo de seguridad [IPSEC] Protocolo), y el despliegue de tecnologías criptográficas

(Por ejemplo, Data Encryption Standard [DES], Triple DES, RAS, MD4, MD5, hash seguro

estándar, y en depósito algoritmos de cifrado como Clipper) para minimizar la red

amenazas como la repetición, la intercepción, la detección de paquetes, las escuchas telefónicas o escuchas.

Página 41

• Transacción de privacidad. Ambos sistemas gubernamentales y del sector privado son cada vez más

necesaria para mantener la privacidad de los individuos. Controles de privacidad de transacción (por ejemplo,

Secure Sockets Layer, secure shell) a proteger contra la pérdida de la privacidad con respecto al

operaciones realizadas por un individuo.

4.4.1.3 Detección y Recuperación Técnicas Controles

Los controles de detección advierten de violaciónes o intentos de violaciónes de la política de seguridad e incluyen tales

controla como pistas de auditoría, los métodos de detección de intrusos, y sumas de comprobación. Controles de recuperación pueden ser

se utiliza para restaurar los recursos informáticos perdidos. Son necesarios como complemento a la apoyar

y medidas técnicas de prevención, ya que ninguna de las medidas en estas otras áreas es perfecto.

Los controles de detección y recuperación incluyen-

• Auditoría. La auditoría de sucesos relevantes para la seguridad y el control y seguimiento de los

anomalías del sistema son elementos clave en la detección después de los hechos, y de la recuperación

de, las brechas de seguridad.

• Detección de intrusiones y Contención. Es esencial para detectar fallos de seguridad

(por ejemplo, la red de robos, actividades sospechosas), de modo que una respuesta puede darse en forma oportunamanera. También es de poca utilidad para detectar un fallo de seguridad si no hay respuesta eficaz puede

ser iniciado. El control de detección de intrusos y la contención proporciona estos dos

capacidades.

• Prueba de la Totalidad. El (por ejemplo, la herramienta de la integridad del sistema) de prueba de integridad de control

análisis de la integridad del sistema y las irregularidades e identifica las exposiciones y el potencial

amenazas. Este control no impide violaciónes de la política de seguridad, pero detecta

violaciónes y ayuda a determinar el tipo de acción correctiva necesaria.

• Restaurar estado seguro. Este servicio permite a un sistema para volver a un estado que es

conocido por ser seguro, después de que ocurra un fallo de seguridad.

• Detección de virus y Erradicar. Detección de virus y software instalado erradicación




en servidores y estaciones de trabajo de usuario detecta, identifica y elimina los virus de software paragarantizar la integridad del sistema y los datos.

4.4.2 Controles de seguridad Gestión

Los controles de seguridad de gestión, junto con los controles técnicos y operativos, son

implementado para gestionar y reducir el riesgo de pérdida y de proteger a la misión de una organización.Controles de gestión se centran en la estipulación de la política de protección de información, pautas y

estándares, los cuales se llevan a cabo a través de procedimientos operativos para cumplir las metas de la organización

y las misiones.

Seguridad Gestión de los controles preventivos, de detección y recuperación-que se aplican a

reducir el riesgo se describen en los apartados 4.4.2.1 a través de 4.4.2.3.

Página 42

4.4.2.1 Preventivas Security Controls Gestión

Estos controles incluyen el siguiente:

• Asignar la responsabilidad de seguridad para asegurarse de que se proporciona la seguridad adecuada para el

los sistemas de TI de misión crítica

• Desarrollar y mantener planes de seguridad del sistema para documentar los controles y dirección actuales

controles previstos para los sistemas de TI de apoyo a la misión de la organización

• Implementar controles de seguridad personal, incluyendo la separación de funciones, privilegios mínimos,

y el registro de acceso a la computadora del usuario y terminación

• Realizar la conciencia de seguridad y capacitación técnica para garantizar que los usuarios finales y el sistema

los usuarios son conscientes de las reglas de comportamiento y de sus responsabilidades en la protección de la

La misión de la organización.

4.4.2.2 Controles de seguridad Detección de Gestión

Controles de gestión de detección son como sigue:

• Implementar controles de seguridad del personal, incluida la retirada de personal, los antecedentes

investigaciones, la rotación de los deberes

• Llevar a cabo una revisión periódica de los controles de seguridad para garantizar que los controles son efectivos

• Realizar auditorías periódicas del sistema

• Llevar a cabo la gestión de riesgos en curso para evaluar y mitigar los riesgos

• Autorizar los sistemas de TI para hacer frente y aceptar el riesgo residual.

4.4.2.3 Controles de seguridad Recuperación de Gestión

Estos controles incluyen el siguiente:

• Dar continuidad de apoyar y desarrollar, probar y mantener la continuidad de

plan de operaciones para proporcionar para la reanudación de negocios y garantizar la continuidad del

operaciones durante emergencias o desastres

• Establecer una capacidad de respuesta a incidentes de prepararnos, reconocer, reportar y

responder al incidente y devolver el sistema informático para el estado de funcionamiento.

4.4.3 Controles de seguridad operacional

Estándares de seguridad de una organización debe establecer un conjunto de controles y directrices para asegurar




que los procedimientos de seguridad que rigen el uso de los activos y recursos de TI de la organización soncorrectamente aplicado y puesto en práctica de acuerdo con los objetivos y la misión de la organización.

La dirección juega un papel fundamental en la supervisión de la implementación de políticas y para garantizar la

establecimiento de controles operacionales pertinentes.

Página 43


Los controles operacionales aplicados de acuerdo con un conjunto básico de requisitos (por ejemplo, técnicacontroles) y las buenas prácticas de la industria, se utilizan para corregir las deficiencias operacionales que podrían ser

ejercida por posibles amenazas recursos. Para garantizar la coherencia y uniformidad en la seguridad

operaciones, deben ser paso a paso los procedimientos y métodos para la aplicación de los controles operacionalesclaramente definidos, documentados y mantenidos. Estos controles operacionales incluyen los presentados

en las secciones 4.4.3.1 y 4.4.3.2 a continuación.

4.4.3.1 Controles Operativos preventivos

Controles operacionales preventivas son las siguientes:

• Acceso a los medios de comunicación de datos de control y eliminación (por ejemplo, control de acceso físico, desmagnetización

método)

• Limitar la distribución de datos externo (por ejemplo, el uso de etiquetado)

• Los virus de software de control

• instalaciones de salvaguardia de computación (por ejemplo, guardias de seguridad, los procedimientos del lugar para los visitantes,

sistema de tarjetas electrónicas, control de acceso biométrico, la gestión y la distribución de

cerraduras y llaves, las barreras y vallas)

• Asegure los armarios de cableado que los concentradores y cables de la casa

• Proporcionar la capacidad de copia de seguridad (por ejemplo, los procedimientos de datos y copias de seguridad regulares del sistema,

registros de archivo que guardar todos los cambios de base de datos que se utilizarán en diversos escenarios de recuperación)

• Establecer los procedimientos y la seguridad fuera de las instalaciones de almacenamiento

• Proteger los ordenadores portátiles, ordenadores personales (PC), estaciones de trabajo

• Proteger los activos de TI de daño de fuego (por ejemplo, requisitos y procedimientos para el uso de

extintores, lonas, sistemas de rociadores secos, sistema de supresión de incendios de halones)

• Proporcionar la fuente de energía de emergencia (por ejemplo, los requisitos para la alimentación ininterrumpida

suministros, los generadores de energía en las instalaciones)

• Control de la humedad y la temperatura del aula de informática (por ejemplo, el funcionamiento del aire

acondicionadores, dispersión de calor).

Detección 4.4.3.2 Controles Operativos

Controles operacionales de detección incluyen lo siguiente:

• Brindar seguridad física (por ejemplo, el uso de detectores de movimiento, circuito cerrado de televisión

de vigilancia, sensores y alarmas)

• Garantizar la seguridad del medio ambiente (por ejemplo, el uso de detectores de humo y fuego, sensores y

alarmas).

4.5 ANÁLISIS COSTO-BENEFICIO

Para asignar los recursos e implementar controles rentables, organizaciones, después de identificar todos

posibles controles y la evaluación de su viabilidad y eficacia, deben llevar a cabo un análisis coste-beneficio

Página 44




análisis para cada control propuesto para determinar qué controles son necesarios y apropiados parasus circunstancias.

El análisis costo-beneficio puede ser cualitativa o cuantitativa. Su objetivo es demostrar que elcostos de implementación de los controles pueden ser justificados por la reducción en el nivel de riesgo. Para

ejemplo, la organización no puede querer gastar $ 1,000 en un control para reducir el riesgo de $ 200.

Un análisis de costo-beneficio para los nuevos controles propuestos o controles mejorados abarca el

siguiente:

• Determinar el impacto de la aplicación de los nuevos o mejorados controles

• Determinar el impacto de la no aplicación de los nuevos o mejorados controles

• La estimación de los costos de la implementación. Estos pueden incluir, pero no se limitan

a, lo siguiente:

- Hardware y software compras

- Reducción de la eficacia operativa si el rendimiento o la funcionalidad del sistema es

reducido para una mayor seguridad

- El costo de la implementación de políticas y procedimientos adicionales

- El costo de la contratación de personal adicional para poner en práctica las políticas propuestas, procedimientos o

servicios

- Los costes de formación

- Los costes de mantenimiento

• La evaluación de los costos y beneficios contra el sistema y criticidad datos de ejecución a

determinar la importancia de la organización de la implementación de los nuevos controles, dada

sus costos y el impacto relativo.

La organización tendrá que evaluar los beneficios de los controles en términos de mantener una

postura aceptable para la misión de la organización. Así como hay un costo para la implementación de un

control necesario, hay un costo por no aplicarla. Al relacionar el resultado de no

implementar el control de la misión, las organizaciones pueden determinar si es factiblerenunciar a su aplicación.

Análisis Costo-Beneficio Ejemplo almacena y procesa System X de misión crítica y sensible:privacidad de la información de los empleados; Sin embargo, la auditoría no se ha habilitado para el sistema. Un costo-

beneficio se realiza para determinar si la función de auditoría debe ser habilitado para que

Sistema X.

Artículos (1) y (2) frente a los efectos intangibles (por ejemplo, los factores de disuasión) para la aplicación o no

la aplicación del nuevo control. Artículo (3), enumera los elementos tangibles (por ejemplo, el costo real).

(1) Impacto de habilitar función de auditoría del sistema: La función de auditoría del sistema permite que la seguridad del sistema

administrador para supervisar las actividades del sistema de los usuarios, pero se ralentizará el rendimiento del sistema y

por lo tanto, afectar la productividad del usuario. Asimismo, la aplicación requerirá recursos adicionales, comodescripción del punto 3.

Página 45

(2) Impacto de no permitir característica de auditoría del sistema: las actividades del sistema de usuario y violaciónes no pueden ser

monitoreado y rastreado si la función de auditoría del sistema está desactivado, y la seguridad no se puede maximizar

para proteger los datos confidenciales y la misión de la organización.

(3) la estimación de costos para habilitar la función de auditoría del sistema:

Costo para habilitar la auditoría del sistema de funciones sin inconvenientes, característica integrada$ 0El personal adicional para llevar a cabo el examen de auditoría y archivo, por año $ XX, XXX

Formación (por ejemplo, la configuración de auditoría del sistema, la generación de informes)$ X, XXX

Add-on de informes de auditoría de software $ X, XXX

Mantenimiento de los datos de auditoría (por ejemplo, almacenamiento, archivo), por año$ X, XXX

Costos totales estimados $ XX, XXX




Los directivos de la organización deben determinar lo que constituye un nivel aceptable de la misión

riesgo. El impacto de un control puede entonces ser evaluada, y el control, ya sea incluido o excluido,

después de que la organización determina un rango de niveles de riesgo factibles. Este rango varía entre

organizaciones; sin embargo, las siguientes reglas se aplican para determinar el uso de las nuevas medidas de control:

• Si el control reduciría el riesgo más de lo necesario, y luego ver si un menos costoso

existe alternativa

• Si el control costaría más que la reducción del riesgo proporcionado, y luego encontrar algo más

• Si el control no reduce riesgo suficientemente, y luego buscar más controles o una diferente

control

• Si el control de la reducción del riesgo proporciona lo suficiente y es rentable, a continuación, utilizarlo.

Con frecuencia, el costo de la implementación de un control es más tangible que el costo de no implementar

ella. Como resultado, la alta dirección tiene un papel crítico en las decisiones relativas a laaplicación de medidas de control para proteger la misión de la organización.

4.6 RIESGO RESIDUAL

Las organizaciones pueden analizar el alcance de la reducción del riesgo generado por el nuevo o mejorado

los controles en términos de la probabilidad de amenaza reducido o impacto, los dos parámetros que definen la

nivel de riesgo mitigado a la misión de la organización.

Implementación de controles nuevos o mejorados puede mitigar el riesgo

• La eliminación de algunas de las vulnerabilidades del sistema (fallos y debilidad), con lo que

reducir el número de posibles pares threat-source/vulnerability

• Adición de un control dirigido a reducir la capacidad y la motivación de una amenaza de código

Por ejemplo, un departamento determina que el costo de instalar y mantenersoftware adicional de seguridad para el PC independiente que almacena sus archivos confidenciales no es

justificable, pero que los controles administrativos y físicos deben ser implementados para

Página 46

hacer que el acceso físico a la PC sea más difícil (por ejemplo, guardar la PC en una habitación cerrada,con la llave guardada por el director).

• La reducción de la magnitud de los efectos adversos (por ejemplo, limitar el alcance de una

vulnerabilidad o la modificación de la naturaleza de la relación entre el sistema informático yLa misión de la organización).

La relación entre la aplicación de control y el riesgo residual se presenta gráficamente en

Figura 4-4.

Figura 4-4. Controles implementados y Riesgo Residual

Nuevo o MejoradoControles

Riesgo Residual

Reducir el número deFallos o errores

Añadir un objetivocontrol

Reducir Magnitudde Impacto




El riesgo que permanece después de la implementación de controles nuevos o mejorados es el riesgo residual.

Prácticamente no existe un sistema de TI está libre de riesgo, y no todos los controles implementados puede eliminar el riesgo de queestán destinadas a abordar o reducir el nivel de riesgo a cero.

Conforme a lo dispuesto por la OMB Circular A-130 de la alta dirección de una organización o de la DAA, que

son responsables de proteger los activos de TI de la organización y su misión, debe autorizar (o

acreditar) el sistema de TI para iniciar o continuar operando. Esta autorización o acreditación debe

realizarse por lo menos cada 3 años o cada vez que grandes cambios se realizan en el sistema informático. La intención de

este proceso es identificar los riesgos que no se aborden plenamente y para determinar si adicionalSe necesitan controles para mitigar los riesgos identificados en el sistema informático. Para las agencias federales, después de

los controles apropiados se han puesto en marcha para los riesgos identificados, la DAA firmará un

declaración de aceptar cualquier riesgo residual y autorizar el funcionamiento del nuevo sistema informático o de lacontinuación de la tramitación del sistema informático existente. Si el riesgo residual no se ha reducido a un

nivel aceptable, el ciclo de gestión del riesgo debe repetirse para identificar una forma de disminuir la

riesgo residual a un nivel aceptable.

Página 47

5. EVALUACIÓN Y EVALUACIÓN

En la mayoría de las organizaciones, la propia red en forma continua se ampliará y actualizará su

componentes cambian, y de sus aplicaciones de software reemplazados o actualizados con las nuevas versiones. En

Además, los cambios de personal se producen y las políticas de seguridad es probable que cambien con el tiempo.

Estos cambios significan que los nuevos riesgos saldrán a la superficie y los riesgos mitigados anteriormente puede volverconvertido en una preocupación. Por lo tanto, el proceso de gestión de riesgos está en curso y en evolución.

En esta sección se hace hincapié en las buenas prácticas y la necesidad de una evaluación de riesgos en curso yevaluación y los factores que conduzcan a un programa de gestión de riesgos exitosa.

5.1 BUENAS PRÁCTICAS DE SEGURIDAD

Normalmente, el proceso de evaluación de riesgos se repite por lo menos cada 3 años para las agencias federales,

dispuesto por la Circular OMB A-130. Sin embargo, la gestión del riesgo debe llevarse a cabo y

integrado en el SDLC para los sistemas de TI, no porque es requerido por ley o reglamento, pero

ya que es una buena práctica y apoya los objetivos de negocio de la organización o misión.Debe haber un horario específico para evaluar y mitigar los riesgos de la misión, pero la

proceso que se realiza periódicamente también debe ser lo suficientemente flexible para permitir cambios cuando sea

se justifica, como cambios importantes en el entorno del sistema de TI y el procesamiento debido a los cambioscomo resultado de las políticas y las nuevas tecnologías.

5,2 claves del éxito

Un programa de gestión de riesgos deberá seguir el (1) el compromiso de la alta dirección; (2)

el apoyo y la participación del equipo de TI (ver sección 2.3); (3) la competencia del riesgo

equipo de evaluación, que debe tener los conocimientos necesarios para aplicar la metodología de evaluación de riesgos para un

sitio y sistema específico, identificar los riesgos de la misión, y proporcionar salvaguardias rentables que cumplen

las necesidades de la organización; (4) la sensibilización y la cooperación de los miembros del usuario

comunidad, que debe seguir los procedimientos y cumplir con los controles implementados a

salvaguardar la misión de su organización; y (5) una evaluación y valoración del cursoRelacionados con TI riesgos de la misión.




Página 48

SP 800-30 Página A-1

Apéndice A: Ejemplos de preguntas de la entrevista

Preguntas de la entrevista deben ser adaptados basados en los que el sistema de TI evaluado se encuentra en el SDLC.

Ejemplos de preguntas que se formulan durante las entrevistas con el personal del sitio para obtener una comprensión de

las características operativas de una organización pueden incluir los siguientes:

• ¿Quiénes son los usuarios válidos?

• ¿Cuál es la misión de la organización de usuarios?

• ¿Cuál es el propósito del sistema en relación con la misión?

• ¿Qué tan importante es el sistema de la misión de la organización de usuarios?

• ¿Cuál es el requisito de sistema de disponibilidad?

• ¿Qué información (tanto entrantes como salientes) se requiere por la organización?

• ¿Qué información se genera, consume, procesado en, almacenada en, y

recuperada por el sistema?

• ¿Qué tan importante es la información a la misión de la organización de usuarios?

• ¿Cuáles son los caminos del flujo de información?

• ¿Qué tipo de información son procesados y almacenados por el sistema (por ejemplo, financieros,

personal, investigación y desarrollo, médica, comando y control)?

• ¿Cuál es la sensibilidad (o clasificación) el nivel de la información?

• ¿Qué información manejada por o sobre el sistema no debe darse a conocer y para

quién?

• En los casos en concreto se procesa la información y se almacena?

• ¿Cuáles son los tipos de almacenamiento de información?

• ¿Cuál es el impacto potencial en la organización si la información es revelada a

personal no autorizado?

• ¿Cuáles son los requisitos para la disponibilidad e integridad de la información?

• ¿Cuál es el efecto sobre la misión de la organización si el sistema o información que no es

confiable?

• ¿Cuánto tiempo de inactividad del sistema puede tolerar la organización? ¿Cómo funciona este tiempo de inactividad

Comparar con el tiempo de reparación medio / recuperación? ¿Qué otro tipo de elaboración o

opciones de comunicación puede el acceso de los usuarios?

• ¿Podría un sistema de seguridad o mal funcionamiento o falta de disponibilidad resultado lesiones o la muerte?



Página 49

SP 800-30 Página B-1

APÉNDICE B: RIESGO DE MUESTRA DE INFORME DE EVALUACIÓN RESUMEN

RESUMEN EJECUTIVO

I. Introducción

• Propósito

• Alcance de esta evaluación de riesgos

Describir los componentes del sistema, los elementos, los usuarios, ubicaciones de los sitios de campo (si lo hay), y cualquier otrodetalles sobre el sistema para ser considerado en la evaluación.

II. Método de evaluación de riesgos

Describa brevemente el método utilizado para llevar a cabo la evaluación de riesgos, tales como-

• Los participantes (por ejemplo, los miembros del equipo de evaluación de riesgos)

• La técnica utilizada para recoger información (por ejemplo, el uso de herramientas, cuestionarios)

• El desarrollo y la descripción de la escala de riesgo (por ejemplo, a, 4 x 4, o 5 x 5 niveles de riesgo 3 x 3

matriz).

III. Caracterización Sistema

Caracterizar el sistema, incluido el hardware (servidor, router, switch), software (por ejemplo, la aplicación,

sistema operativo, protocolo), las interfaces del sistema (por ejemplo, enlace de comunicación), datos y usuarios.

Proporcionar diagrama de conectividad o de entrada del sistema y diagrama de flujo de salida para delinear el alcance de estaarriesgar esfuerzo de evaluación.

IV. Declaración de Amenazas

Compilar y enumerar las posibles amenazas recursos y acciones de amenaza asociadas aplicables a la

sistema evaluó.

Resultados de la Evaluación de Riesgos V.

Enumere las observaciones (pares de vulnerabilidad / amenaza). Cada observación debe incluir-

• Número de Observación y breve descripción de observación (por ejemplo, Observación 1: El usuario

las contraseñas del sistema se pueden adivinar o agrietados)

• Una discusión de la pareja amenaza de código y la vulnerabilidad

• Identificación de los controles de seguridad de mitigación existentes

• Discusión de verosimilitud y la evaluación (por ejemplo, Alta, Media o Baja probabilidad)

• Análisis de impacto discusión y evaluación (por ejemplo, Alto, Medio o Bajo impacto)

• La clasificación de riesgo basado en la matriz de nivel de riesgo (por ejemplo, alto, medio, o bajo nivel de riesgo)

• Los controles u opciones alternativas para reducir el riesgo recomendada.

VI. Resumen

Sume el número de observaciones. Resumir las observaciones, los niveles de riesgo asociados, la

Página 50

recomendaciones, y los comentarios en un formato de tabla para facilitar la aplicación decontroles recomendados durante el proceso de mitigación de riesgos.



SP 800-30 Página B-2

Página 51

APÉNDICE C: MODELO DE SALVAGUARDIA PLAN DE IMPLEMENTACIÓN TABLA RESUMEN

(1)

Riesgo

(Vulnerabilidad /

Amenaza par)

(2)

Riesgo

Nivel

(3)

Recomendado

Controles

(4)

Acción

Prioridad

(5)

Seleccionado

Planificado

Controles

(6)

Necesario

Recursos

(7)

Responsable

Equipo / Personas

(8)

Fecha de inicio /

Fecha de finalización

(9)

Mantenimiento

Requisito /

Comentarios

Los usuarios no autorizados puedentelnet al servidor de XYZy navegar sensiblesarchivos de la empresa con elinvitado ID.

Alto

• No permitir entradatelnet

• No permitir el "mundo"el acceso a la sensiblearchivos de la empresa

• Desactive el invitadoIdentificación o asignacióndifícil de adivinarcontraseña para lainvitado ID

Alto

• Rechazartelnet entrante

• RechazarAcceso "mundo"para sensiblesarchivos de la empresa

• Las Personas con Discapacidadinvitado ID

10 horas areconfigurary probar elsistema

John Doe, XYZsistema de servidoradministrador;Jim Smith,firewall de la compañíaadministrador

01/09/2001 a02/09/2001

• Realizarperiódicosistemarevisión de seguridady pruebas paraaseguraradecuadola seguridad esprevistola XYZservidor



SP 800-30 Página C-1

(1) Los riesgos (pares de vulnerabilidad / amenaza) son resultado del proceso de evaluación de riesgos(2) El nivel de riesgo asociado de cada riesgo identificado (par vulnerabilidad / riesgo) es el resultado del proceso de evaluación de riesgos(3) Los controles recomendados son resultado del proceso de evaluación de riesgos(4) se determina la prioridad de acción en base a los niveles de riesgo y los recursos disponibles (por ejemplo, los fondos, las personas, la tecnología)(5) Los controles previstos seleccionados de los controles recomendados para la implementación(6) Los recursos necesarios para la aplicación de los controles previstos seleccionados(7) Lista de equipo (s) y las personas que serán responsables de la aplicación de los nuevos o mejorados controles(8) la fecha y la fecha de finalización prevista para la aplicación de los nuevos o mejorados controles de inicio(9) requisito de mantenimiento para los nuevos o mejorados controles después de la implementación.

Página 52

APÉNDICE D: SIGLAS

AES Advanced Encryption Standard

CSA Ley de Seguridad Informática

DAA Autoridad Aprobatoria Designado

DAC Control de acceso discrecional

DES Data Encryption Standard

FedCIRC Centro de Respuesta a Incidentes de Informática Federal

FTP Protocolo de transferencia de archivos

Identificación Identificador

IPSEC Seguridad del protocolo de Internet

ISSO Oficial de seguridad del sistema de información

Informática Tecnología de la Información

ITL Laboratorio de Tecnologías de la Información

MAC Control de Acceso Obligatorio

NIPC Infraestructura Centro Nacional de Protección

NIST Instituto Nacional de Estándares y Tecnología

OIG Oficina del Inspector General

OMB Oficina de Administración y Presupuesto

PC Ordenador personal

SDLC Ciclo de Vida de Desarrollo

SP Publicación Especial

ST & E Prueba de Seguridad y Evaluación



SP 800-30 Página D-1

Página 53

SP 800-30 Página E-1

E ANEXO: GLOSARIO

PLAZO DEFINICIÓN

Responsabilidad El objetivo de seguridad que genera la necesidad de acciones de una entidad a

ser rastreado de forma única a esa entidad. Esto apoya el no repudio, la disuasión,aislamiento de fallas, detección de intrusiones y prevención, y recuperación después de la acción

y la acción legal.

Garantía Motivos para confiar en que los otros cuatro objetivos de seguridad (integridad,disponibilidad, confidencialidad y responsabilidad) se han cumplido adecuadamente

por una implementación específica. "Adecuadamente satisfecho" incluye (1) una funcionalidad

que realiza correctamente, (2) una protección suficiente contra los errores involuntarios

(Por los usuarios o de software), y (3) suficiente resistencia a la penetración intencional

o bypass.

Disponibilidad El objetivo de seguridad que genera el requisito para la protección contra-

• Intentos intencionales o accidentales (1) realizar la destrucción no autorizadas

de datos o (2) de lo contrario provocar una denegación de servicio o datos

• El uso no autorizado de los recursos del sistema.

Confidencialidad El objetivo de seguridad que genera el requisito de protección contra

intentos intencionales o accidentales para realizar lecturas de datos no autorizada.La confidencialidad abarca datos en el almacenamiento, durante el proceso, y en tránsito.

Denegación de servicio La prevención del acceso no autorizado a los recursos o el retraso de tiempooperaciones críticas.

Debido Cuidado Los gestores y sus organizaciones tienen la obligación de proporcionar la informaciónde seguridad para asegurarse de que el tipo de control, el costo de control, y el

implementación del control son apropiados para ser administrado el sistema.

Integridad El objetivo de seguridad que genera el requisito para la protección contra ya seaintentos intencionales o accidentales de violar la integridad de datos (la propiedad que

de datos tiene cuando no ha sido alterado de manera no autorizada) o sistema de

integridad (la cualidad que tiene un sistema cuando se lleva a cabo su intenciónfuncionan de manera irreprochable, libre de manipulación no autorizada).

Página 54

Riesgos relacionados con TIEl impacto neto de la misión teniendo en cuenta (1) la probabilidad de que un determinadoamenaza de código ejercerá (disparar accidentalmente o intencionalmente explotar) una

la vulnerabilidad del sistema de información en particular y (2) el impacto resultante si

esto debería ocurrir. Riesgos relacionados con las TI se derivan de la responsabilidad legal o pérdida misión

debido a-

1. Unauthorized (intencionada o accidental) la divulgación, modificación o



SP 800-30 Página E-2

destrucción de la información2. Errores y omisiones no intencionales

3. Interrupciones debido a los desastres naturales o de origen humano

4. El no ejercer el debido cuidado y diligencia en la ejecución y

funcionamiento del sistema de TI.

TI Objetivos Objetivo Seguridad Sede de seguridad

Riesgo Dentro de este documento, sinónimo de riesgo relacionados con las TI.

EVALUACIÓN DEL RIESGO El proceso de identificación de los riesgos a la seguridad del sistema y determinar la

probabilidad de ocurrencia, el impacto resultante y salvaguardias adicionales

eso sería mitigar este impacto. Parte de la Gestión de Riesgos y sinónimo

con el Análisis de Riesgos.

Gestión de Riesgos El proceso total de la identificación, el control y la mitigación de la información

riesgos relacionados con el sistema. Incluye la evaluación de riesgos; análisis de costo-beneficio; y

la selección, implementación, prueba y evaluación de la seguridad de las salvaguardias.Esta revisión global de seguridad del sistema tiene en cuenta tanto la eficacia y

eficiencia, incluido el impacto sobre la misión y las limitaciones debido a la política,

reglamentos y leyes.

Seguridad Seguridad de los sistemas de información es una característica del sistema y un conjunto de

mecanismos que abarcan todo el sistema tanto lógica como físicamente.

Objetivos de seguridad Los cinco objetivos de seguridad son la integridad, disponibilidad, confidencialidad,

rendición de cuentas, y la garantía.

Amenaza El potencial de una amenaza-source para el ejercicio (por accidente o desencadenar

intencionalmente explotar) una vulnerabilidad específica.

Amenaza de código O bien (1) la intención y el método dirigido a la explotación intencional de un

vulnerabilidad o (2) una situación y un método que puede activar accidentalmente un

vulnerabilidad.

Análisis de Amenazas El examen de las amenazas recursos contra las vulnerabilidades del sistema a

determinar las amenazas para un sistema en particular en un operativo especial

medio ambiente.

Vulnerabilidad Un defecto o debilidad en los procedimientos de seguridad del sistema, el diseño, la implementación,

o los controles internos que podrían ser ejercidas (accidentalmente activan o

explotado intencionalmente) y resultar en un fallo de seguridad o una violación de la

política de seguridad del sistema.

Página 55

APÉNDICE F: REFERENCIAS

Computer Systems Boletín Laboratorio. Amenazas a los sistemas informáticos: una visión general .

Marzo de 1994.

NIST Interagencial Reports 4749. Declaraciones muestra del trabajo de Federal Computer Security

Servicios: Para uso interno o la subcontratación. diciembre de 1991.

NIST Special Publication 800-12. Una introducción a la seguridad informática: El Manual NIST .

Octubre de 1995.

NIST Special Publication 800-14. Principios y Prácticas Generalmente Aceptados para la seguridad

Sistemas de Tecnología de la Información . Septiembre de 1996. Co-autor con Barbara Guttman.

NIST Special Publication 800-18. Guía para el desarrollo de Planes de Seguridad de la Información

Sistemas de Tecnología . Diciembre de 1998. Co-autor con los Directores de Seguridad Informática Federales

Grupo de trabajo del Foro.

NIST Special Publication 800-26, Guía de Autoevaluación de Seguridad de Tecnología de la Información



SP 800-30 Página F-1

Sistemas . Agosto de 2001.

NIST Special Publication 800-27. Principios de Ingeniería de Seguridad de TI . Junio de 2001.

OMB Circular A-130. Gestión de Recursos de Información Federales. Apéndice III.Noviembre de 2000.

nist 800-30_esp

Documents