Requisitos de Seguridad de Ingeniería

Abstracto

La mayoría de los ingenieros de requisitos están mal capacitados para obtener, analizar y especificar la seguridad requisitos, a menudo les confunde con los mecanismos de seguridad de arquitectura que son Tradicionalmente utilizado para cumplirlas. De este modo, terminan especificando la arquitectura y el diseño limitaciones en lugar de los requisitos de seguridad de confianza. Este artículo define los distintos tipos de los requisitos de seguridad y proporciona ejemplos asociados y guildlines con la intención de permitir a los requisitos de los ingenieros para especificar adecuadamente los requisitos de seguridad sin restringir innecesariamente los equipos de seguridad y arquitectura de utilizar el la mayoría de los mecanismos de seguridad apropiados para el trabajo.

1 REQUISITOS DE SEGURIDAD

La ingeniería de los requisitos para un negocio, sistema o aplicación de software, componente o (contactos, datos, o la reutilización) Centro implica mucho más que simplemente la ingeniería sus requisitos funcionales. También hay que diseñar su calidad, de datos, y la interfaz de requisitos, así como sus limitaciones de arquitectura, diseño, implementación y pruebas. Mientras que algunos requisitos ingenieros podrían recordar para obtener, analizar, especificar, y gestionar los requisitos de calidad tales como la interoperabilidad, la disponibilidad operacional, rendimiento, portabilidad, confiabilidad y facilidad de uso, muchos están en una pérdida cuando se trata de requisitos de seguridad. La mayoría de los ingenieros de requisitos no están capacitados para nada en la seguridad, y los pocos que han sido entrenados sólo se han dado una visión general de la seguridad arquitectónica mecanismos como contraseñas y cifrado en lugar de en la seguridad real requisitos. Por lo tanto, el problema más común con los requisitos de seguridad, cuando están especificada en absoluto, es que tienden a ser reemplazados accidentalmente con específicas de seguridad limitaciones arquitectónicas que pueden restringir innecesariamente el equipo de seguridad del uso de los mecanismos de seguridad más adecuadas para cumplir el verdadero valor subyacente requisitos. Este artículo le ayudará a distinquish entre los requisitos de seguridad y los mecanismos para alcanzarlos, y le proporcionará buenos ejemplos de cada uno tipo de requisito de seguridad.

En el mundo actual de alertas diarias de virus, crackers maliciosos, y las amenazas de ciberterrorismo, sería bueno recordar los siguientes objetivos de la seguridad requisitos:

• Asegúrese de que los usuarios y las aplicaciones cliente se identifican y que sus identidades son debidamente verificados.

• Asegúrese de que los usuarios y las aplicaciones cliente sólo puede acceder a los datos y servicios para las que han sido debidamente autorizado.

• Detectar intentos de intrusión por parte de personas no autorizadas y las aplicaciones cliente.

• Asegurar que los programas maliciosos no autorizadas (por ejemplo, virus) no infectan el aplicación o componente.

• Asegúrese de que las comunicaciones y los datos no están dañados intencionalmente.

• Asegúrese de que las partes en la interacción con la aplicación o componente no pueden más tarde repudiar esas interacciones.

• Asegúrese de que las comunicaciones confidenciales y los datos se mantienen en privado.

• Habilitar el personal de seguridad para auditar el estado y el uso de la seguridad mecanismos.

• Asegúrese de que las aplicaciones y los centros sobreviven ataque, posiblemente en modo degradado.

• Asegúrese de que los centros y sus componentes y el personal están protegidos contra destrucción, daño, robo, o el reemplazo subrepticia (por ejemplo, debido al vandalismo, sabotaje o terrorismo).

• Asegúrese de que el mantenimiento del sistema no interrumpe involuntariamente la seguridad mecanismos de la aplicación, componente, o el centro.

Para cumplir con los objetivos anteriores, abordaremos brevemente cada uno de los siguientes tipos de requisitos de seguridad correspondientes:

• Requisitos de identificación

• Requisitos de autenticación

• Requisitos de autorización

• Requisitos de inmunidad

• Requisitos de integridad

• Requisitos de detección de intrusiones

• Requisitos no repudio

• Requisitos de Privacidad

• Requisitos de Auditoría de Seguridad

• Requisitos de Supervivencia

• Requisitos de protección física

• Requisitos del sistema de seguridad Mantenimiento

Directrices

Las siguientes directrices han demostrado ser útiles en la obtención de, analizar, especificar, y el mantenimiento de los requisitos de seguridad:

• Politica de seguridad

Un requisito de seguridad suele ser un requisito detallado que implementa una la política de seguridad de primer orden.

• Requisitos de exactitud

Los requisitos de seguridad dependen de los requisitos de corrección debido defectos de implementación son a menudo los errores que producen vulnerabilidades de seguridad. Por lo tanto, utilizando un idiomas de tipo inseguro tales como C puede resultar en defectos de contorno que array puede ser explotado para ejecutar scripts maliciosos.

• Factibilidad

Es imposible construir un 100% la seguridad de los negocios, la aplicación, componente o centro. El aumento de la seguridad por lo general:

o Aumenta el costo asociado.

o Aumenta el programa asociado.

o Disminuye la capacidad de uso asociado.

• casos de mal uso

Considerando que los requisitos funcionales están normalmente especifican como casos de uso, requisitos tradicionales narrativas Inglés seguridad lenguaje a menudo puede ser analizado, refinado, y por lo tanto hay más especificaciones como casos mal uso o abuso [Sindre y Opdahl 2 001] [Alexander2003] según el cual:

o El cliente usuario externo (actor o aplicación humana) de un caso de uso se sustituye por un abusón (por ejemplo, galleta o empleado descontento) que intente violar la seguridad de una aplicación, componente, o centro.

o Las interacciones normales iniciados por el usuario del caso del usuario se sustituyen por el interacciones de ataque iniciada por un uso indebido del caso el mal uso.

o la aplicación o componente de respuesta a las interacciones necesarias y poscondiciones del caso del usuario se sustituyen por la aplicación requerida o respuestas orientadas a la seguridad de los componentes y poscondiciones del caso el mal uso.

o Tenga en cuenta que mientras que las metas en coche requisitos de casos de uso, amenazas coche caso el mal uso

requisitos.

o Tenga en cuenta también que un problema muy común con el uso de casos de uso indebido como enfoque requisitos es que a menudo asumen la existencia previa de mecanismos de seguridad de arquitectura para ser frustrados, y por lo tanto los casos de uso indebido de mayo ser más adecuados para el análisis de amenaza a la seguridad y la generación de prueba de seguridad casos que para la especificación de los requisitos de seguridad. Si casos de mal uso se van a utilizar para los requisitos, deben ser los casos de uso indebido 'esenciales' que no contienen arquitectura y diseño restricciones innecesarias.

• Amenazas contra Objetivos

Mientras que la mayoría de los requisitos se basan en mayores objetivos de nivel, los requisitos de seguridad son impulsados por las amenazas de seguridad. Así, mientras que la mayoría de los requisitos se indican en términos de lo que debe suceder, los requisitos de seguridad a menudo se especifican en términos de lo que no se debe permitir que suceda. Por lo tanto, parte de la ingeniería de seguridad es similar a (y puede ser pensado como una forma especializada de) la gestión del riesgo. Por lo tanto, basar los requisitos de seguridad en los resultados de un riesgo de seguridad a fondo evaluación por parte del equipo de seguridad. Tal evaluación identifica la significativa amenazas y sus frecuencias estimados asociados, las pérdidas individuales, y al año pérdidas. Esto permite que el equipo de requisitos para asegurar que los requisitos de seguridad son rentables.

• Requisitos vs. Mecanismos arquitectónicos y las decisiones de diseño

Se debe tener cuidado para evitar la innecesaria y prematura especificando mecanismos de arquitectura para el cumplimiento de los requisitos de seguridad no especificado (por ejemplo, especificando el uso de identificadores de usuario y contraseñas como la identificación y requisitos de autenticación). El equipo de los requisitos a menudo no está capacitado para tomar decisiones de arquitectura, y si lo hace puede causar problemas en la relación entre el equipo de los requisitos y el equipo de arquitectura. Especificación de la seguridad restricciones también pueden innecesariamente impedir que el equipo de arquitectura, desde la elección diferente, y potencialmente mejor, mecanismos de seguridad (por ejemplo, dispositivos biométricos, como escáneres de retina, lectores de huellas digitales) para cumplir con la seguridad real subyacente requisitos. Si los mecanismos y diseños arquitectónicos de seguridad específico deberán ser especificada (por ejemplo, por razones legales, constractural, o razones similares), a continuación, especifique como limitaciones de arquitectura y diseño, no como los requisitos de seguridad.

• Requisitos Validando Seguridad

Los requisitos de seguridad típicamente requieren pruebas de seguridad específica además de la tipos tradicionales de las pruebas. Los casos de prueba pueden basarse en casos de mal uso que son análoga a los casos de prueba desarrollados para pruebas funcionales basados casos de uso. También, carga y pruebas de estrés puede ser útil para probar denegación de servicio (DoS).

2 REQUISITOS DE IDENTIFICACIÓN

Un requisito de identificación es ningún requisito de seguridad que especifica en qué medida que un negocio, aplicaciones, componentes, o el centro deberán identificar sus aspectos externos (por ejemplo, actores humanos y aplicaciones externas) antes de interactuar con ellos.

Ejemplos

• "La solicitud deberá identificar todas sus aplicaciones de cliente antes de permitirles utilizar sus capacidades ".

• "La solicitud deberá identificar todos sus usuarios humanos antes de permitirles usar sus capacidades ".

• "El centro de datos debe identificar a todo el personal antes de permitirles entrar."

• Single Sign-on) "La aplicación no requerirá un usuario individual para identificar a sí mismo varias veces durante una sola sesión ".

• "La solicitud deberá asegurarse de que el nombre del empleado en el ser humano oficial bases de datos de nómina de recursos y coincide exactamente con el nombre impreso en la tarjeta de seguro social del empleado. "

Justificación: Se trata de un requisito oficial de la Seguridad Social de los Estados Unidos Administración.

Directrices

• requisitos de identificación suelen ser insuficientes por sí solos. Ellos son típicamente requisitos previos necesarios para los requisitos de autenticación.

• requisitos de identificación se pueden cuantificar mediante la especificación del mínimo porcentaje del tiempo que la identificación de un [tipo] externo especificado en una se producirá situación especificada.

• Requisitos de identificación no deben especificarse en términos de los tipos de mecanismos de la arquitectura de seguridad que normalmente se utilizan para ponerlas en práctica, por ejemplo,

No:

o ¿Quién dice ser:

o Nombre, identificador de usuario, o identificador nacional (por ejemplo, número de seguro social).

o lo que usted tiene:

o Digital posesiones, como un certificado digital o ficha.

o posesiones físicas tales como una tarjeta de identificación de empleado, una llave de hardware, o una tarjeta inteligente habilitado con una infraestructura de clave pública (PKI).

o quién eres:

o Los rasgos fisiológicos (por ejemplo, huellas digitales, impresión de la mano, reconocimiento facial, iris el reconocimiento y exploración de la retina).

o características de comportamiento (por ejemplo, el patrón de voz, estilo de la firma, y dinámica de tecleo).

• No analizar y especificar requirments de identificación con los casos de uso. Una muy requisitos comunes error es especificar el uso de identificadores de usuario y contraseñas asociadas con los casos de uso de inicio de sesión a nivel de diseño.

• requisitos de identificación deben estar en consonancia con los requisitos de privacidad, que puede requerir el anonimato de los usuarios.

3 requisitos de autenticación

Un requisito de autenticación es ningún requisito de seguridad que especifica en qué medida que un negocio, aplicaciones, componentes, o centro de comprobarán la identidad de su externos (por ejemplo, actores humanos y aplicaciones externas) antes de interactuar con ellos. Por lo tanto, los objetivos típicos de un requisito de autenticación son asegurar que los externos son en realidad quién o qué dicen ser y por lo tanto para evitar poner en peligro la seguridad de un impostor.

Ejemplos

• "La solicitud deberá verificar la identidad de todos sus usuarios antes de permitirles utilizar sus capacidades ".

• "La solicitud deberá verificar la identidad de todos sus usuarios antes de permitirles actualizar su información de usuario ".

• "La solicitud deberá verificar la identidad de sus usuarios antes de aceptar una tarjeta de crédito el pago de ese usuario ".

• "La solicitud deberá verificar la identidad de todas sus aplicaciones de cliente antes que les permite utilizar sus capacidades ".

• "El centro de datos deberá verificar la identidad de todo el personal que antes lo permita la ellos entrar."

Directrices

• Autenticación depende de la identificación. Si la identidad es lo suficientemente importante para especificar, que así es la autenticación.

• requisitos de autenticación son típicamente insuficientes por sí solos, pero son requisitos previos necesarios para los requisitos de autorización.

• Requisitos de autenticación no deben ser especificados en términos de los tipos de mecanismos de la arquitectura de seguridad que normalmente se utilizan para ponerlas en práctica. Nota que la mayoría de los mecanismos de la arquitectura de seguridad de autenticación pueden utilizarse para aplicar simultáneamente tanto la identificación y los requisitos de autenticación.

o ¿Quién usted que:

o Los últimos cuatro dígitos de su número de seguro social, soltera de su madre nombre, el nombre de su mascota, etc.

o lo que usted tiene:

o Digital posesiones, como un certificado digital o ficha.

o posesiones físicas tales como una tarjeta de identificación de empleado, una llave de hardware, o una tarjeta inteligente habilitado con una infraestructura de clave pública (PKI).

o quién eres:

o Los rasgos fisiológicos (por ejemplo, huellas digitales, impresión de la mano, reconocimiento facial, iris el reconocimiento y exploración de la retina).

o características de comportamiento (por ejemplo, el patrón de voz, estilo de la firma, y dinámica de tecleo).

• Tenga en cuenta que algunos de los mecanismos de la arquitectura de seguridad de autenticación anterior puede ser usado para aplicar de forma simultánea tanto la identificación y autenticación

requisitos.

• No analizar y especificar requirments de autenticación con los casos de uso. Una muy requisitos comunes error es especificar el uso de identificadores de usuario y contraseñas asociadas con los casos de uso de inicio de sesión a nivel de diseño.

• Debido a la estrecha relación entre la identificación y la autenticación requisitos, a veces se agrupan en especificaciones de requisitos.

4 REQUISITOS DE AUTORIZACIÓN

Un requisito de autorización es cualquier requisito de seguridad que especifica el acceso y privilegios de uso de los usuarios autenticados y las aplicaciones cliente.

Los objetivos típicos de un requisito de autorización son:

• Asegúrese de que una o más personas (que han sido nombrados correctamente en nombre del la organización que posee y controla la aplicación o componente) son capaces de autorizar específica usuarios autenticados y aplicaciones cliente de acceso específica aplicación o capacidades de los componentes o información.

• Asegúrese de que específica externos autenticados pueden acceder a aplicaciones específicas o capacidades o la información de componentes si y sólo si han sido explícitamente autorizado para ello por una persona (s) debidamente designado.

• De esta manera prevenir que usuarios no autorizados:

o La obtención de acceso a los datos inapropiados o confidenciales.

o Solicitud de la prestación de servicios inadecuados o restringidos.

Ejemplos

• "La solicitud deberá permitir a cada cliente para obtener acceso a todo su propia información de su cuenta personal. "

• "La aplicación no permitirá que cualquier cliente para acceder a cualquier información de la cuenta de cualquier otro cliente ".

• "La aplicación no permitirá que los agentes de servicio al cliente para acceder a la tarjeta de crédito la información de los clientes ".

• "La solicitud deberá permitir a los agentes de servicio al cliente al correo electrónico de forma automática una nueva

contraseña de cliente de correo electrónico de ese cliente ". (Tenga en cuenta que esta autorización requisito es cuestionable, ya que contiene una autenticación implícita limitación - el uso de contraseñas como otros mecanismos de autenticación que se oponen tales como firmas digitales).

• "La aplicación no permitirá que los agentes de servicio al cliente para acceder a cualquiera de los contraseña de cliente original o nuevo cuando emailing la nueva contraseña del cliente para dirección de correo electrónico del cliente. "

• "La aplicación no permitirá que uno o más usuarios a utilizar con éxito una negación de de servicio (DoS) para inundar con solicitudes legítimas de servicio. "

Directrices

• Autorización depende tanto de la identificación y autenticación.

• Requisitos de autorización no deben ser especificados en términos de los tipos de mecanismos de la arquitectura de seguridad que normalmente se utilizan para ponerlas en práctica:

o listas de autorización o bases de datos.

o Persona frente de rol basado vs. autorización basada en grupo.

o sistemas de prevención de intrusiones de Comercio. llaves electrónicas o hardware.

o Los controles de acceso físico (por ejemplo, cerraduras, guardias de seguridad).

• Autorización puede concederse a:

o personas individuales o aplicaciones.

o grupos de personas o aplicaciones relacionadas.

• Autorización debe concederse sobre la base del análisis de usuario y la asociada requisitos operacionales.

• Sólo un número limitado de personas (o roles) debe ser designado para otorgar o cambio

autorizaciones.

• Una amenaza común a la seguridad de una aplicación es una denegación de servicio (DoS) ataque en el que una aplicación está inundado con solicitudes legítimas de servicio.

Considerando lo funcional, la disponibilidad operativa y requisitos de fiabilidad cubierta solicitudes ordinarias de servicio, un requisito de autorización adicional puede ser útil porque nadie está autorizado a inundar una aplicación con la legítima peticiones. Tenga en cuenta que el estrés y las pruebas de carga son útiles para validar anti-DoS los requisitos de autorización.

5 Requisitos de inmunidad

Un requisito inmunidad es cualquier requisito de seguridad que especifica el grado en que una aplicación o componente deberán protegerse de la infección por el autorizado programas no deseados (por ejemplo, virus informáticos, gusanos y caballos de Troya).

Los objetivos típicos de un requisito de la inmunidad son para evitar cualquier indeseable programas de destruir o dañar los datos y las aplicaciones.

Ejemplos

• "La solicitud deberá protegerse de la infección mediante el escaneo de todos los entrado o datos descargados y software para los virus informáticos conocidos, gusanos, troyanos caballos y otros programas dañinos similares ".

• "La solicitud deberá desinfectar cualquier archivo encontrado que contienen un programa nocivo en caso de desinfección es posible ".

• "La solicitud deberá notificar al administrador de seguridad y el usuario asociado (si hay) si detecta un programa dañino durante una exploración ".

• "Para protegerse de la infección por los nuevos programas infecciosos, ya que se identifican y publicado, la aplicación actualizará diariamente sus definiciones de conocida virus informáticos, gusanos, caballos de Troya y otros programas dañinos similares ".

Directrices

• Requisitos de inmunidad no deben ser especificados en términos de los tipos de seguridad mecanismos de arquitectura que normalmente se utilizan para ponerlas en práctica:

o programas antivirus comerciales.

o cortafuegos.

o Prohibición de las lenguas de tipo inseguro (por ejemplo, C) que pueden permitir desbordamientos de búfer que contienen scripts maliciosos. normas o de programación (por ejemplo, para garantizar los límites de seguridad de tipo y de la matriz comprobación).

• Las aplicaciones pueden delegar requisitos de inmunidad a sus centros de datos que contienen, pero sólo si esos centros de datos proporcionan (y seguirán proporcionando) adecuada mecanismos de seguridad para cumplir con los requisitos. Esto sería una legítima decisión arquitectónica bajo ciertas circunstancias.

6 requisitos de integridad

Un requisito integridad es ningún requisito de seguridad que especifica el grado en que una aplicación o componente se asegurarán de que sus comunicaciones de datos y no son intencionadamente corrompido a través de la creación no autorizada, modificación o supresión.

Los objetivos típicos de un requisito de integridad son para asegurar que las comunicaciones y los datos se puede confiar.

Ejemplos

• "La aplicación impedirá que la corrupción no autorizada de correos electrónicos (y su archivos adjuntos, en su caso) que envía a los clientes y otros usuarios externos. "

• "La solicitud deberá evitar que la corrupción no autorizado de los datos recogidos de clientes y otros usuarios externos ".

• "La solicitud deberá evitar que la corrupción no autorizada de todas las comunicaciones pasando a través de las redes que son externos a los centros de datos protegidos ".

Directrices

• Requisitos de integridad no deben ser especificados en términos de los tipos de seguridad mecanismos de arquitectura que normalmente se utilizan para ponerlas en práctica:

o criptografía.

o códigos hash.

7 REQUISITOS detección de intrusos

Un requisito de detección de intrusos es ningún requisito de seguridad que especifica en qué medida que una aplicación o componente deberán detectar y registrar intento de acceso o modificación por personas no autorizadas.

Los objetivos típicos de un requisito de detección de intrusiones son:

• Detectar las personas no autorizadas y los programas que intentan acceder al aplicación o componente.

• Registre la información sobre los intentos de acceso no autorizados.

• Notificar al personal de seguridad para que puedan manejar adecuadamente.

Ejemplos

• "La solicitud deberá detectar y registrar todos los intentos de accesos que no identificación, los requisitos de autenticación o autorización. "

• "La solicitud deberá notificar al día el oficial de seguridad del centro de datos de todos fallado intento de accesos durante las últimas 24 horas ".

• "La solicitud deberá notificar al oficial de seguridad del centro de datos dentro de los 5 minutos de cualquier intento fallido repite acceder a los datos financieros de los empleados y las empresas bases de datos ".

Directrices

• requisitos de detección de intrusiones dependen de identificación, autenticación y los requisitos de autorización.

• requisitos de detección de intrusiones no deben ser especificados en términos de los tipos de mecanismos de la arquitectura de seguridad que normalmente se utilizan para ponerlas en práctica:

o alarmas.

o de informes de eventos.

o Uso de un comercial-off-the-shelf específico (COTS):

o Sistema de detección de intrusiones (IDS).

o Sistema de prevención de intrusiones (IPS).

8 REQUISITOS no repudio

Un requisito no repudio es ningún requisito de seguridad que especifica en qué medida que un negocio, aplicación o componente impedirán que una parte en una de sus interacciones (por ejemplo, de mensajes, de transacción) de negar haber participado en la totalidad o parte de la interacción.

Los objetivos típicos de un requisito no repudio son:

• Asegúrese de que los registros a prueba de manipulaciones adecuadas se mantienen para evitar que las partes en interacciones de negar que han tenido lugar.

• Reduzca al mínimo los posibles futuros problemas legales y de responsabilidad que pudieran derivarse de alguien disputando uno de sus interacciones.

Ejemplos

• "La solicitud deberá realizar y almacenar registros a prueba de manipulación de la siguiente información sobre cada orden recibida de un cliente y cada factura enviada a un cliente:

o El contenido de la orden o factura.

o La fecha y hora en que se envió la orden o factura.

o La fecha y la hora que el orden o la factura fue recibida.

o La identidad del cliente. "

Directrices

• Los requisitos de no repudio se refieren principalmente a asegurar que a prueba de manipulación adecuada se llevan registros. Es insuficiente para simplemente hacer discos; estos registros debe ser completa y prueba de manipulaciones.

• Los requisitos de no repudio típicamente implican el almacenamiento de una cantidad significativa de información acerca de cada interacción incluyendo:

o la identidad de todas las partes involucradas en la transacción autenticado.

o Fecha y hora en que la interacción fue enviada, recibida, y confirmados (si relevante).

o Información Significativa que se pasa durante la interacción.

• Requisitos de no repudio se basan en, se puede especificar en referencia a, y no debe especificar redundantemente:

o requisitos funcionales especificar interacciones obligatorios.

o Los requisitos de datos que especifican los datos que se almacena y se pasa con ellos interacciones. Tenga en cuenta que los requisitos de no repudio pueden agregar haciendo los datos a prueba de manipulaciones.

• Los requisitos de no repudio están relacionados con, pero potencialmente más restrictiva que requisitos auditabilidad.

• Requisitos de no repudio no debe confundirse con (y especificados en términos de) los mecanismos de seguridad que se pueden utilizar para ponerlas en práctica:

o firmas digitales (para identificar las partes).

o marcas de tiempo (para captar las fechas y horas).

o cifrado y descifrado (para proteger la información).

o funciones hash (para asegurar que la información no ha sido cambiado).

9 REQUISITOS DE PRIVACIDAD

Un requisito privacidad es cualquier requisito de seguridad que especifica el grado en que una negocio, aplicaciones, componentes, o el centro deberá mantener sus datos confidenciales y comunicaciones privadas de los individuos y programas no autorizados.

Los objetivos típicos de un requisito de privacidad son:

• Asegurar que las personas no autorizadas y los programas no tengan acceso a la sensible de datos y comunicaciones.

• Facilitar el acceso a los datos y las comunicaciones en una base "necesidad de saber".

• Reducir al mínimo el potencial mala prensa, la pérdida de confianza de los usuarios, y responsabilidades legales.

Ejemplos

• El anonimato.

o "La aplicación no almacenará ninguna información personal sobre los usuarios."

• Comunicaciones de Privacidad.

o "La aplicación no permitirá que personas o programas no autorizados el acceso a cualquier comunicación ".

• Almacenamiento de privacidad de datos.

o "La aplicación no permitirá que personas o programas no autorizados el acceso a los datos almacenados ".

Directrices

• Los requisitos de privacidad deben identificar claramente su ámbito de aplicación:

o Los datos y comunicaciones específicas que son sensibles, confidenciales, el comercio secretos, etc.

o Los lugares específicos donde esta comunicación se lleva a cabo (por ejemplo, sobre el Internet, fuera de un centro de datos seguro).

• Los requisitos de privacidad están relacionados con, pero van más allá, los requisitos, porque la gente y las aplicaciones deben tener acceso sólo a los datos y las comunicaciones para que están autorizados.

• Requisitos de privacidad pueden superponerse ciertas restricciones legales, como las leyes que requerir ciertos datos (por ejemplo, información de tarjeta de crédito) que se le mantenga privado.

• Los requisitos de privacidad no deben ser confundidos con (ni especifican en términos de) la mecanismos de seguridad arquitectónicos que se pueden utilizar para ponerlas en práctica:

o cifrado de clave pública o privada y el descifrado.

o paquetes de criptografía Comercial-off-the-shelf.

• Requisitos de privacidad deben ser consistentes con los requisitos de auditabilidad, los requisitos de identificación y los requisitos de no rechazo, que requieren los usuarios para ser identificado y la información sobre sus interacciones para ser almacenados. Por ejemplo, considerar una aplicación de mercado electrónico privacidad orientada que actúa como intermediario entre compradores, comerciantes y una puerta de entrada de procesamiento de autorización de tarjeta de crédito.

Los compradores pueden no querer proporcionar información personal privada (por ejemplo, su nombre, dirección de facturación, número de tarjeta de crédito y fecha de vencimiento) a los comerciantes que realmente no lo necesitan si no van a ser los que obtengan la compra las autorizaciones de los procesadores de autorización de tarjetas de crédito. Tenga en cuenta que electrónico billeteras socavan la privacidad, ya que hacen que sea fácil para los compradores de la oferta privada información a los comerciantes. En cambio, el mercado electrónico apoya firmemente la privacidad a través de:

o Esconder los clientes información personal privada de los comerciantes.

o Autorizar la compra de tarjetas de crédito para el comprador (por lo que el comerciante quiere que la información privada).

o Sólo abastecer el comerciante con la información no privada (por ejemplo, la entrega dirección y el pago de crédito de información, como la aprobación de crédito).

o cifrar encarecidamente a todas las comunicaciones y el almacenamiento de la información privada.

10 REQUISITOS auditoría de seguridad

Un requisito auditoría de seguridad es cualquier requisito de seguridad que especifica en qué medida que un negocio, aplicaciones, componentes, o el centro deberán permitir que el personal de seguridad a auditar el estado y el uso de sus mecanismos de seguridad.

Los objetivos típicos de un requisito de la auditoría de seguridad son para garantizar que el aplicación o componente recopila, analiza y reporta información sobre:

• Estado (por ejemplo, permitió vs. discapacitados, versiones actualizadas) de sus mecanismos de seguridad.

• El uso de los mecanismos de seguridad (por ejemplo, acceso y modificación por la seguridad personal).

Ejemplos

• "La solicitud deberá recoger, organizar, resumir, e informará periódicamente el estado de sus mecanismos de seguridad, incluyendo:

o Identificación, autenticación y autorización.

o inmunidad.

o de privacidad.

o detección de intrusiones ".

Directrices

• Se debe tener cuidado para evitar la duplicación innecesaria entre la seguridad de los de auditoría y los requisitos de detección de intrusos.

• requisitos de auditoría de seguridad no se deben confundir con (ni especifican en términos de) los mecanismos de seguridad arquitectónicos que se pueden utilizar para implementar ellos:

o Audit Trails.

o registros de eventos.

11 REQUISITOS supervivencia

Un requisito de supervivencia es cualquier requisito de seguridad que especifica el grado en que una aplicación o centro deberán sobrevivir a la pérdida intencional o destrucción de un componente.

El objetivo típico de un requisito de supervivencia es asegurar que una aplicación o centro o bien falla con gracia o de lo contrario sigue a la función (posiblemente en un modo degradado), a pesar de que ciertos componentes han sido intencionalmente dañados o destruidos.

Ejemplos

• "La aplicación no tendrá un único punto de fallo."

• "La solicitud deberá seguir funcionando (posiblemente en modo degradado) incluso si un centro de datos se destruye ".

Directrices

• Requisitos de Supervivencia a menudo son críticos para aplicaciones militares.

• Evite los requisitos de robustez confusos con los requisitos de supervivencia.

Requisitos Survivabilty ocupan de salvaguardar contra daños o pérdida debido a amenazas maliciosas intencionales, mientras que los requisitos de robustez se ocupan de salvaguarda contra fallos de hardware no intencionales, los errores humanos, etc.

• Requisitos de Supervivencia no debe confundirse con (ni especifican en términos de) los mecanismos de seguridad arquitectónicos que se pueden utilizar para ponerlas en práctica:

o redundancia de hardware.

o redundancia del centro de datos.

o de conmutación por error de software.

12 REQUISITOS DE PROTECCIÓN FÍSICA

Un requisito de protección física es cualquier requisito de seguridad que especifica en qué medida que una aplicación o centro deberán protegerse de asalto físico. Los objetivos típicos de los requisitos de protección física son para asegurar que un aplicación o centro están protegidos contra los daños físicos, destrucción, robo o sustitución de hardware, software o componentes de personal debido a vandalismo, sabotaje,

o el terrorismo.

Ejemplos

• "El centro de datos debe proteger a sus componentes de hardware de los daños físicos, destrucción, robo, o el reemplazo subrepticia. "

• "El centro de datos deberá proteger a su personal de la muerte, lesión, y el secuestro."

Directrices

• requisitos de protección física están relacionados con los requisitos de supervivencia.

Requisitos de supervivencia especificar las continuaron funcionando después de un ataque, mientras que requisitos de protección física especifican la protección de los componentes. Física los requisitos de protección típicamente son requisitos previos para requisitos de supervivencia.

• Requisitos de protección física no se deben confundir con (ni especifican en términos de) los mecanismos de seguridad arquitectónicos que se pueden utilizar para implementar ellos:

o puertas cerradas.

o guardias de seguridad.

o de acceso rápido a la Policía. punto le de fracaso ".

13 SISTEMA REQUISITOS DE SEGURIDAD MANTENIMIENTO

Un requisito de seguridad mantenimiento del sistema es cualquier requisito de seguridad que especifica el grado en que una aplicación, componente, o el centro impedirá autorizado modificaciones (por ejemplo, soluciones a anomalías, mejoras, actualizaciones) de derrotar accidentalmente su mecanismos de seguridad.

El objetivo típico de un requisito de seguridad mantenimiento del sistema es mantener los niveles de seguridad especificados en los requisitos de seguridad durante la fase de uso.

Ejemplos

• "La aplicación no violará sus requisitos de seguridad como resultado de la mejora de una de datos, hardware o componente de software ".

• "La aplicación no violará sus requisitos de seguridad como resultado de la sustitución de un datos, hardware, o componente de software ".

Directrices

• Requisitos de seguridad de mantenimiento del sistema pueden entrar en conflicto con la operativa requisitos de disponibilidad, en que los requisitos de disponibilidad operacional no puede permiten a uno tomar la aplicación o componente fuera de línea durante el mantenimiento y la repetición de las pruebas de seguridad.

• Requisitos de seguridad de mantenimiento del sistema no debe confundirse con (ni especifican en términos de) los mecanismos de seguridad arquitectónicos que se pueden utilizar para ponerlas en práctica:

o Mantenimiento y procedimientos de mejora.

o la formación asociada.

o pruebas de regresión de Seguridad.

14 CONCLUSIÓN

En esta columna se ha abordado la necesidad de analizar y especificar seguridad real sistemáticamente requisitos como parte de los requisitos de calidad de una empresa, la aplicación, componente, o centro. Se ha identificado y definido los diferentes tipos de requisitos de seguridad, proporcionan buenos ejemplos que pueden ser copiados y enumeran las directrices que han demostrado ser útiles cuando suscitar, analizar, especificar, y el mantenimiento de los requisitos de seguridad. En la siguiente columna, voy a hablar de la necesidad de producir varias versiones de especificaciones de requisitos en base a las diversas necesidades de su público destinatario. Lo haré también proporcionan criterios para evaluar las especificaciones y requisitos de gestión de herramientas sobre la base de esta necesidad