Upload
iraldo-pinzon
View
244
Download
3
Embed Size (px)
Citation preview
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
10/6/2014 Guía de Gestión de Riesgos párr Sistemas Informáticos
http://translate.googleusercontent.com/translate_f 2/45
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.
10/6/2014 Guía de Gestión de Riesgos párr Sistemas Informáticos
http://translate.googleusercontent.com/translate_f 3/45
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.
10/6/2014 Guía de Gestión de Riesgos párr Sistemas Informáticos
http://translate.googleusercontent.com/translate_f 4/45
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
10/6/2014 Guía de Gestión de Riesgos párr Sistemas Informáticos
http://translate.googleusercontent.com/translate_f 5/45
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
10/6/2014 Guía de Gestión de Riesgos párr Sistemas Informáticos
http://translate.googleusercontent.com/translate_f 6/45
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
10/6/2014 Guía de Gestión de Riesgos párr Sistemas Informáticos
http://translate.googleusercontent.com/translate_f 7/45
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.
10/6/2014 Guía de Gestión de Riesgos párr Sistemas Informáticos
http://translate.googleusercontent.com/translate_f 8/45
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.
10/6/2014 Guía de Gestión de Riesgos párr Sistemas Informáticos
http://translate.googleusercontent.com/translate_f 9/45
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
10/6/2014 Guía de Gestión de Riesgos párr Sistemas Informáticos
http://translate.googleusercontent.com/translate_f 10/45
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
10/6/2014 Guía de Gestión de Riesgos párr Sistemas Informáticos
http://translate.googleusercontent.com/translate_f 11/45
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)
10/6/2014 Guía de Gestión de Riesgos párr Sistemas Informáticos
http://translate.googleusercontent.com/translate_f 12/45
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,
Lista de corriente yLos controles previstos
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
• 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• Los controles actuales• Los controles previstos
• Historia del ataque del sistema• Los datos de inteligenciaagencias, NIPC, OIG,FedCIRC, medios de comunicación,
10/6/2014 Guía de Gestión de Riesgos párr Sistemas Informáticos
http://translate.googleusercontent.com/translate_f 13/45
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
10/6/2014 Guía de Gestión de Riesgos párr Sistemas Informáticos
http://translate.googleusercontent.com/translate_f 14/45
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
SP 800-30 Página 11
• 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
10/6/2014 Guía de Gestión de Riesgos párr Sistemas Informáticos
http://translate.googleusercontent.com/translate_f 15/45
SP 800-30 Página 12
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
10/6/2014 Guía de Gestión de Riesgos párr Sistemas Informáticos
http://translate.googleusercontent.com/translate_f 16/45
SP 800-30 Página 13
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
10/6/2014 Guía de Gestión de Riesgos párr Sistemas Informáticos
http://translate.googleusercontent.com/translate_f 17/45
SP 800-30 Página 14
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
10/6/2014 Guía de Gestión de Riesgos párr Sistemas Informáticos
http://translate.googleusercontent.com/translate_f 18/45
SP 800-30 Página 15
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
SP 800-30 Página 16
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
10/6/2014 Guía de Gestión de Riesgos párr Sistemas Informáticos
http://translate.googleusercontent.com/translate_f 19/45
SP 800-30 Página 17
• 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
10/6/2014 Guía de Gestión de Riesgos párr Sistemas Informáticos
http://translate.googleusercontent.com/translate_f 20/45
SP 800-30 Página 18
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 ,
10/6/2014 Guía de Gestión de Riesgos párr Sistemas Informáticos
http://translate.googleusercontent.com/translate_f 21/45
SP 800-30 Página 19
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
10/6/2014 Guía de Gestión de Riesgos párr Sistemas Informáticos
http://translate.googleusercontent.com/translate_f 22/45
SP 800-30 Página 20
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
SP 800-30 Página 21
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.
10/6/2014 Guía de Gestión de Riesgos párr Sistemas Informáticos
http://translate.googleusercontent.com/translate_f 23/45
Página 28
SP 800-30 Página 22
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
10/6/2014 Guía de Gestión de Riesgos párr Sistemas Informáticos
http://translate.googleusercontent.com/translate_f 24/45
SP 800-30 Página 23
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
10/6/2014 Guía de Gestión de Riesgos párr Sistemas Informáticos
http://translate.googleusercontent.com/translate_f 25/45
SP 800-30 Página 24
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.
10/6/2014 Guía de Gestión de Riesgos párr Sistemas Informáticos
http://translate.googleusercontent.com/translate_f 26/45
SP 800-30 Página 25
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
10/6/2014 Guía de Gestión de Riesgos párr Sistemas Informáticos
http://translate.googleusercontent.com/translate_f 27/45
SP 800-30 Página 26
Página 33
SP 800-30 Página 27
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
10/6/2014 Guía de Gestión de Riesgos párr Sistemas Informáticos
http://translate.googleusercontent.com/translate_f 28/45
SP 800-30 Página 28
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
10/6/2014 Guía de Gestión de Riesgos párr Sistemas Informáticos
http://translate.googleusercontent.com/translate_f 29/45
SP 800-30 Página 29
• 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
10/6/2014 Guía de Gestión de Riesgos párr Sistemas Informáticos
http://translate.googleusercontent.com/translate_f 30/45
SP 800-30 Página 30
• 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
10/6/2014 Guía de Gestión de Riesgos párr Sistemas Informáticos
http://translate.googleusercontent.com/translate_f 31/45
SP 800-30 Página 31
Figura 4-2. Mitigación de Riesgos Metodología Organigrama
Página 38
SP 800-30 Página 32
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-
10/6/2014 Guía de Gestión de Riesgos párr Sistemas Informáticos
http://translate.googleusercontent.com/translate_f 32/45
SP 800-30 Página 33
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).
10/6/2014 Guía de Gestión de Riesgos párr Sistemas Informáticos
http://translate.googleusercontent.com/translate_f 33/45
SP 800-30 Página 34
• 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
10/6/2014 Guía de Gestión de Riesgos párr Sistemas Informáticos
http://translate.googleusercontent.com/translate_f 34/45
SP 800-30 Página 35
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
10/6/2014 Guía de Gestión de Riesgos párr Sistemas Informáticos
http://translate.googleusercontent.com/translate_f 35/45
SP 800-30 Página 36
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
SP 800-30 Página 37
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
10/6/2014 Guía de Gestión de Riesgos párr Sistemas Informáticos
http://translate.googleusercontent.com/translate_f 36/45
SP 800-30 Página 38
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
10/6/2014 Guía de Gestión de Riesgos párr Sistemas Informáticos
http://translate.googleusercontent.com/translate_f 37/45
SP 800-30 Página 39
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
10/6/2014 Guía de Gestión de Riesgos párr Sistemas Informáticos
http://translate.googleusercontent.com/translate_f 38/45
SP 800-30 Página 40
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.
10/6/2014 Guía de Gestión de Riesgos párr Sistemas Informáticos
http://translate.googleusercontent.com/translate_f 39/45
SP 800-30 Página 41
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?
10/6/2014 Guía de Gestión de Riesgos párr Sistemas Informáticos
http://translate.googleusercontent.com/translate_f 40/45
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.
10/6/2014 Guía de Gestión de Riesgos párr Sistemas Informáticos
http://translate.googleusercontent.com/translate_f 41/45
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
10/6/2014 Guía de Gestión de Riesgos párr Sistemas Informáticos
http://translate.googleusercontent.com/translate_f 42/45
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
10/6/2014 Guía de Gestión de Riesgos párr Sistemas Informáticos
http://translate.googleusercontent.com/translate_f 43/45
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
10/6/2014 Guía de Gestión de Riesgos párr Sistemas Informáticos
http://translate.googleusercontent.com/translate_f 44/45
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
10/6/2014 Guía de Gestión de Riesgos párr Sistemas Informáticos
http://translate.googleusercontent.com/translate_f 45/45
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.