Está en la página 1de 18

Requisitos de Seguridad de Ingeniera

Abstracto
La mayora de los ingenieros de requisitos estn 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
diseo limitaciones en lugar de los requisitos de seguridad de confianza. Este
artculo define los distintos tipos de los requisitos de seguridad y proporciona
ejemplos asociados y guildlines con la intencin 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 mayora de los mecanismos de seguridad apropiados para el trabajo.

1 REQUISITOS DE SEGURIDAD
La ingeniera de los requisitos para un negocio, sistema o aplicacin de
software, componente o (contactos, datos, o la reutilizacin) Centro implica
mucho ms que simplemente la ingeniera sus requisitos funcionales. Tambin
hay que disear su calidad, de datos, y la interfaz de requisitos, as como sus
limitaciones de arquitectura, diseo, implementacin y pruebas. Mientras que
algunos requisitos ingenieros podran 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 estn en una prdida cuando se trata
de requisitos de seguridad. La mayora de los ingenieros de requisitos no estn
capacitados para nada en la seguridad, y los pocos que han sido entrenados
slo se han dado una visin general de la seguridad arquitectnica
mecanismos como contraseas y cifrado en lugar de en la seguridad real
requisitos. Por lo tanto, el problema ms comn con los requisitos de
seguridad, cuando estn especificada en absoluto, es que tienden a ser
reemplazados accidentalmente con especficas de seguridad limitaciones
arquitectnicas que pueden restringir innecesariamente el equipo de seguridad
del uso de los mecanismos de seguridad ms adecuadas para cumplir el
verdadero valor subyacente requisitos. Este artculo 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, sera bueno recordar los siguientes objetivos de
la seguridad requisitos:
Asegrese de que los usuarios y las aplicaciones cliente se identifican y que
sus identidades son debidamente verificados.
Asegrese de que los usuarios y las aplicaciones cliente slo puede acceder a
los datos y servicios para las que han sido debidamente autorizado.

Detectar intentos de intrusin por parte de personas no autorizadas y las


aplicaciones cliente.
Asegurar que los programas maliciosos no autorizadas (por ejemplo, virus) no
infectan el aplicacin o componente.
Asegrese de que las comunicaciones y los datos no estn daados
intencionalmente.
Asegrese de que las partes en la interaccin con la aplicacin o componente
no pueden ms tarde repudiar esas interacciones.
Asegrese 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.
Asegrese de que las aplicaciones y los centros sobreviven ataque,
posiblemente en modo degradado.
Asegrese de que los centros y sus componentes y el personal estn
protegidos contra destruccin, dao, robo, o el reemplazo subrepticia (por
ejemplo, debido al vandalismo, sabotaje o terrorismo).
Asegrese de que el mantenimiento del sistema no interrumpe
involuntariamente la seguridad mecanismos de la aplicacin, 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 identificacin
Requisitos de autenticacin
Requisitos de autorizacin
Requisitos de inmunidad
Requisitos de integridad
Requisitos de deteccin de intrusiones
Requisitos no repudio
Requisitos de Privacidad
Requisitos de Auditora de Seguridad
Requisitos de Supervivencia
Requisitos de proteccin fsica
Requisitos del sistema de seguridad Mantenimiento

Directrices
Las siguientes directrices han demostrado ser tiles en la obtencin 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 poltica de seguridad de primer orden.
Requisitos de exactitud
Los requisitos de seguridad dependen de los requisitos de correccin debido
defectos de implementacin 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 aplicacin,
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 estn normalmente especifican
como casos de uso, requisitos tradicionales narrativas Ingls seguridad
lenguaje a menudo puede ser analizado, refinado, y por lo tanto hay ms
especificaciones como casos mal uso o abuso [Sindre y Opdahl 2 001]
[Alexander2003] segn el cual:
o El cliente usuario externo (actor o aplicacin humana) de un caso de uso se
sustituye por un abusn (por ejemplo, galleta o empleado descontento) que
intente violar la seguridad de una aplicacin, 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 aplicacin o componente de respuesta a las interacciones necesarias y
poscondiciones del caso del usuario se sustituyen por la aplicacin 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 tambin que un problema muy comn 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 ms
adecuados para el anlisis de amenaza a la seguridad y la generacin de
prueba de seguridad casos que para la especificacin 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 diseo
restricciones innecesarias.
Amenazas contra Objetivos
Mientras que la mayora 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 mayora de los requisitos se indican en
trminos de lo que debe suceder, los requisitos de seguridad a menudo se
especifican en trminos de lo que no se debe permitir que suceda. Por lo tanto,
parte de la ingeniera de seguridad es similar a (y puede ser pensado como una
forma especializada de) la gestin del riesgo. Por lo tanto, basar los requisitos
de seguridad en los resultados de un riesgo de seguridad a fondo evaluacin
por parte del equipo de seguridad. Tal evaluacin identifica la significativa
amenazas y sus frecuencias estimados asociados, las prdidas individuales, y
al ao prdidas. Esto permite que el equipo de requisitos para asegurar que los
requisitos de seguridad son rentables.
Requisitos vs. Mecanismos arquitectnicos y las decisiones de diseo
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 contraseas como la identificacin y requisitos de autenticacin).
El equipo de los requisitos a menudo no est capacitado para tomar decisiones
de arquitectura, y si lo hace puede causar problemas en la relacin entre el
equipo de los requisitos y el equipo de arquitectura. Especificacin de la
seguridad restricciones tambin pueden innecesariamente impedir que el
equipo de arquitectura, desde la eleccin diferente, y potencialmente mejor,
mecanismos de seguridad (por ejemplo, dispositivos biomtricos, como
escneres de retina, lectores de huellas digitales) para cumplir con la
seguridad real subyacente requisitos. Si los mecanismos y diseos
arquitectnicos de seguridad especfico debern ser especificada (por ejemplo,
por razones legales, constractural, o razones similares), a continuacin,
especifique como limitaciones de arquitectura y diseo, no como los requisitos
de seguridad.
Requisitos Validando Seguridad
Los requisitos de seguridad tpicamente requieren pruebas de seguridad
especfica adems de la tipos tradicionales de las pruebas. Los casos de prueba
pueden basarse en casos de mal uso que son anloga a los casos de prueba

desarrollados para pruebas funcionales basados casos de uso. Tambin, carga y


pruebas de estrs puede ser til para probar denegacin de servicio (DoS).
2 REQUISITOS DE IDENTIFICACIN
Un requisito de identificacin es ningn requisito de seguridad que especifica
en qu medida que un negocio, aplicaciones, componentes, o el centro
debern 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 aplicacin no requerir un usuario individual para
identificar a s mismo varias veces durante una sola sesin ".
"La solicitud deber asegurarse de que el nombre del empleado en el ser
humano oficial bases de datos de nmina de recursos y coincide exactamente
con el nombre impreso en la tarjeta de seguro social del empleado. "
Justificacin: Se trata de un requisito oficial de la Seguridad Social de los
Estados Unidos Administracin.
Directrices
requisitos de identificacin suelen ser insuficientes por s solos. Ellos son
tpicamente requisitos previos necesarios para los requisitos de autenticacin.
requisitos de identificacin se pueden cuantificar mediante la especificacin
del mnimo porcentaje del tiempo que la identificacin de un [tipo] externo
especificado en una se producir situacin especificada.
Requisitos de identificacin no deben especificarse en trminos de los tipos
de mecanismos de la arquitectura de seguridad que normalmente se utilizan
para ponerlas en prctica, por ejemplo,
No:
o Quin dice ser:
o Nombre, identificador de usuario, o identificador nacional (por ejemplo,
nmero de seguro social).
o lo que usted tiene:
o Digital posesiones, como un certificado digital o ficha.

o posesiones fsicas tales como una tarjeta de identificacin de empleado, una


llave de hardware, o una tarjeta inteligente habilitado con una infraestructura
de clave pblica (PKI).
o quin eres:
o Los rasgos fisiolgicos (por ejemplo, huellas digitales, impresin de la mano,
reconocimiento facial, iris el reconocimiento y exploracin de la retina).
o caractersticas de comportamiento (por ejemplo, el patrn de voz, estilo de la
firma, y dinmica de tecleo).
No analizar y especificar requirments de identificacin con los casos de uso.
Una muy requisitos comunes error es especificar el uso de identificadores de
usuario y contraseas asociadas con los casos de uso de inicio de sesin a
nivel de diseo.
requisitos de identificacin deben estar en consonancia con los requisitos de
privacidad, que puede requerir el anonimato de los usuarios.
3 requisitos de autenticacin
Un requisito de autenticacin es ningn requisito de seguridad que especifica
en qu medida que un negocio, aplicaciones, componentes, o centro de
comprobarn la identidad de su externos (por ejemplo, actores humanos y
aplicaciones externas) antes de interactuar con ellos. Por lo tanto, los objetivos
tpicos de un requisito de autenticacin son asegurar que los externos son en
realidad quin 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 informacin de usuario ".
"La solicitud deber verificar la identidad de sus usuarios antes de aceptar
una tarjeta de crdito 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
Autenticacin depende de la identificacin. Si la identidad es lo
suficientemente importante para especificar, que as es la autenticacin.
requisitos de autenticacin son tpicamente insuficientes por s solos, pero
son requisitos previos necesarios para los requisitos de autorizacin.

Requisitos de autenticacin no deben ser especificados en trminos de los


tipos de mecanismos de la arquitectura de seguridad que normalmente se
utilizan para ponerlas en prctica. Nota que la mayora de los mecanismos de
la arquitectura de seguridad de autenticacin pueden utilizarse para aplicar
simultneamente tanto la identificacin y los requisitos de autenticacin.
o Quin usted que:
o Los ltimos cuatro dgitos de su nmero 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 fsicas tales como una tarjeta de identificacin de empleado, una
llave de hardware, o una tarjeta inteligente habilitado con una infraestructura
de clave pblica (PKI).
o quin eres:
o Los rasgos fisiolgicos (por ejemplo, huellas digitales, impresin de la mano,
reconocimiento facial, iris el reconocimiento y exploracin de la retina).
o caractersticas de comportamiento (por ejemplo, el patrn de voz, estilo de la
firma, y dinmica de tecleo).
Tenga en cuenta que algunos de los mecanismos de la arquitectura de
seguridad de autenticacin anterior puede ser usado para aplicar de forma
simultnea tanto la identificacin y autenticacin
requisitos.
No analizar y especificar requirments de autenticacin con los casos de uso.
Una muy requisitos comunes error es especificar el uso de identificadores de
usuario y contraseas asociadas con los casos de uso de inicio de sesin a
nivel de diseo.
Debido a la estrecha relacin entre la identificacin y la autenticacin
requisitos, a veces se agrupan en especificaciones de requisitos.
4 REQUISITOS DE AUTORIZACIN
Un requisito de autorizacin es cualquier requisito de seguridad que especifica
el acceso y privilegios de uso de los usuarios autenticados y las aplicaciones
cliente.
Los objetivos tpicos de un requisito de autorizacin son:
Asegrese de que una o ms personas (que han sido nombrados
correctamente en nombre del la organizacin que posee y controla la
aplicacin o componente) son capaces de autorizar especfica usuarios
autenticados y aplicaciones cliente de acceso especfica aplicacin o
capacidades de los componentes o informacin.

Asegrese de que especfica externos autenticados pueden acceder a


aplicaciones especficas o capacidades o la informacin de componentes si y
slo si han sido explcitamente autorizado para ello por una persona (s)
debidamente designado.
De esta manera prevenir que usuarios no autorizados:
o La obtencin de acceso a los datos inapropiados o confidenciales.
o Solicitud de la prestacin de servicios inadecuados o restringidos.
Ejemplos
"La solicitud deber permitir a cada cliente para obtener acceso a todo su
propia informacin de su cuenta personal. "
"La aplicacin no permitir que cualquier cliente para acceder a cualquier
informacin de la cuenta de cualquier otro cliente ".
"La aplicacin no permitir que los agentes de servicio al cliente para
acceder a la tarjeta de crdito la informacin de los clientes ".
"La solicitud deber permitir a los agentes de servicio al cliente al correo
electrnico de forma automtica una nueva
contrasea de cliente de correo electrnico de ese cliente ". (Tenga en cuenta
que esta autorizacin requisito es cuestionable, ya que contiene una
autenticacin implcita limitacin - el uso de contraseas como otros
mecanismos de autenticacin que se oponen tales como firmas digitales).
"La aplicacin no permitir que los agentes de servicio al cliente para
acceder a cualquiera de los contrasea de cliente original o nuevo cuando
emailing la nueva contrasea del cliente para direccin de correo electrnico
del cliente. "
"La aplicacin no permitir que uno o ms usuarios a utilizar con xito una
negacin de de servicio (DoS) para inundar con solicitudes legtimas de
servicio. "
Directrices
Autorizacin depende tanto de la identificacin y autenticacin.
Requisitos de autorizacin no deben ser especificados en trminos de los
tipos de mecanismos de la arquitectura de seguridad que normalmente se
utilizan para ponerlas en prctica:
o listas de autorizacin o bases de datos.
o Persona frente de rol basado vs. autorizacin basada en grupo.
o sistemas de prevencin de intrusiones de Comercio. llaves electrnicas o
hardware.

o Los controles de acceso fsico (por ejemplo, cerraduras, guardias de


seguridad).
Autorizacin puede concederse a:
o personas individuales o aplicaciones.
o grupos de personas o aplicaciones relacionadas.
Autorizacin debe concederse sobre la base del anlisis de usuario y la
asociada requisitos operacionales.
Slo un nmero limitado de personas (o roles) debe ser designado para
otorgar o cambio
autorizaciones.
Una amenaza comn a la seguridad de una aplicacin es una denegacin de
servicio (DoS) ataque en el que una aplicacin est inundado con solicitudes
legtimas de servicio.
Considerando lo funcional, la disponibilidad operativa y requisitos de fiabilidad
cubierta solicitudes ordinarias de servicio, un requisito de autorizacin
adicional puede ser til porque nadie est autorizado a inundar una aplicacin
con la legtima peticiones. Tenga en cuenta que el estrs y las pruebas de
carga son tiles para validar anti-DoS los requisitos de autorizacin.
5 Requisitos de inmunidad
Un requisito inmunidad es cualquier requisito de seguridad que especifica el
grado en que una aplicacin o componente debern protegerse de la infeccin
por el autorizado programas no deseados (por ejemplo, virus informticos,
gusanos y caballos de Troya).
Los objetivos tpicos de un requisito de la inmunidad son para evitar cualquier
indeseable programas de destruir o daar los datos y las aplicaciones.
Ejemplos
"La solicitud deber protegerse de la infeccin mediante el escaneo de todos
los entrado o datos descargados y software para los virus informticos
conocidos, gusanos, troyanos caballos y otros programas dainos similares ".
"La solicitud deber desinfectar cualquier archivo encontrado que contienen
un programa nocivo en caso de desinfeccin es posible ".
"La solicitud deber notificar al administrador de seguridad y el usuario
asociado (si hay) si detecta un programa daino durante una exploracin ".
"Para protegerse de la infeccin por los nuevos programas infecciosos, ya que
se identifican y publicado, la aplicacin actualizar diariamente sus
definiciones de conocida virus informticos, gusanos, caballos de Troya y otros
programas dainos similares ".

Directrices
Requisitos de inmunidad no deben ser especificados en trminos de los tipos
de seguridad mecanismos de arquitectura que normalmente se utilizan para
ponerlas en prctica:
o programas antivirus comerciales.
o cortafuegos.
o Prohibicin de las lenguas de tipo inseguro (por ejemplo, C) que pueden
permitir desbordamientos de bfer que contienen scripts maliciosos. normas o
de programacin (por ejemplo, para garantizar los lmites de seguridad de tipo
y de la matriz comprobacin).
Las aplicaciones pueden delegar requisitos de inmunidad a sus centros de
datos que contienen, pero slo si esos centros de datos proporcionan (y
seguirn proporcionando) adecuada mecanismos de seguridad para cumplir
con los requisitos. Esto sera una legtima decisin arquitectnica bajo ciertas
circunstancias.
6 requisitos de integridad
Un requisito integridad es ningn requisito de seguridad que especifica el
grado en que una aplicacin o componente se asegurarn de que sus
comunicaciones de datos y no son intencionadamente corrompido a travs de
la creacin no autorizada, modificacin o supresin.
Los objetivos tpicos de un requisito de integridad son para asegurar que las
comunicaciones y los datos se puede confiar.
Ejemplos
"La aplicacin impedir que la corrupcin no autorizada de correos
electrnicos (y su archivos adjuntos, en su caso) que enva a los clientes y
otros usuarios externos. "
"La solicitud deber evitar que la corrupcin no autorizado de los datos
recogidos de clientes y otros usuarios externos ".
"La solicitud deber evitar que la corrupcin no autorizada de todas las
comunicaciones pasando a travs de las redes que son externos a los centros
de datos protegidos ".
Directrices
Requisitos de integridad no deben ser especificados en trminos de los tipos
de seguridad mecanismos de arquitectura que normalmente se utilizan para
ponerlas en prctica:
o criptografa.
o cdigos hash.

7 REQUISITOS deteccin de intrusos


Un requisito de deteccin de intrusos es ningn requisito de seguridad que
especifica en qu medida que una aplicacin o componente debern detectar y
registrar intento de acceso o modificacin por personas no autorizadas.
Los objetivos tpicos de un requisito de deteccin de intrusiones son:
Detectar las personas no autorizadas y los programas que intentan acceder
al aplicacin o componente.
Registre la informacin 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
identificacin, los requisitos de autenticacin o autorizacin. "
"La solicitud deber notificar al da 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 deteccin de intrusiones dependen de identificacin,
autenticacin y los requisitos de autorizacin.
requisitos de deteccin de intrusiones no deben ser especificados en
trminos de los tipos de mecanismos de la arquitectura de seguridad que
normalmente se utilizan para ponerlas en prctica:
o alarmas.
o de informes de eventos.
o Uso de un comercial-off-the-shelf especfico (COTS):
o Sistema de deteccin de intrusiones (IDS).
o Sistema de prevencin de intrusiones (IPS).
8 REQUISITOS no repudio
Un requisito no repudio es ningn requisito de seguridad que especifica en qu
medida que un negocio, aplicacin o componente impedirn que una parte en
una de sus interacciones (por ejemplo, de mensajes, de transaccin) de negar
haber participado en la totalidad o parte de la interaccin.
Los objetivos tpicos de un requisito no repudio son:

Asegrese 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 mnimo 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 manipulacin
de la siguiente informacin 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 manipulacin adecuada se llevan registros. Es insuficiente para
simplemente hacer discos; estos registros debe ser completa y prueba de
manipulaciones.
Los requisitos de no repudio tpicamente implican el almacenamiento de una
cantidad significativa de informacin acerca de cada interaccin incluyendo:
o la identidad de todas las partes involucradas en la transaccin autenticado.
o Fecha y hora en que la interaccin fue enviada, recibida, y confirmados (si
relevante).
o Informacin Significativa que se pasa durante la interaccin.
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 estn relacionados con, pero potencialmente
ms restrictiva que requisitos auditabilidad.
Requisitos de no repudio no debe confundirse con (y especificados en
trminos de) los mecanismos de seguridad que se pueden utilizar para
ponerlas en prctica:

o firmas digitales (para identificar las partes).


o marcas de tiempo (para captar las fechas y horas).
o cifrado y descifrado (para proteger la informacin).
o funciones hash (para asegurar que la informacin 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 tpicos 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 mnimo el potencial mala prensa, la prdida de confianza de los
usuarios, y responsabilidades legales.
Ejemplos
El anonimato.
o "La aplicacin no almacenar ninguna informacin personal sobre los
usuarios."
Comunicaciones de Privacidad.
o "La aplicacin no permitir que personas o programas no autorizados el
acceso a cualquier comunicacin ".
Almacenamiento de privacidad de datos.
o "La aplicacin 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
aplicacin:
o Los datos y comunicaciones especficas que son sensibles, confidenciales, el
comercio secretos, etc.
o Los lugares especficos donde esta comunicacin se lleva a cabo (por
ejemplo, sobre el Internet, fuera de un centro de datos seguro).

Los requisitos de privacidad estn relacionados con, pero van ms all, los
requisitos, porque la gente y las aplicaciones deben tener acceso slo a los
datos y las comunicaciones para que estn autorizados.
Requisitos de privacidad pueden superponerse ciertas restricciones legales,
como las leyes que requerir ciertos datos (por ejemplo, informacin de tarjeta
de crdito) que se le mantenga privado.
Los requisitos de privacidad no deben ser confundidos con (ni especifican en
trminos de) la mecanismos de seguridad arquitectnicos que se pueden
utilizar para ponerlas en prctica:
o cifrado de clave pblica o privada y el descifrado.
o paquetes de criptografa Comercial-off-the-shelf.
Requisitos de privacidad deben ser consistentes con los requisitos de
auditabilidad, los requisitos de identificacin y los requisitos de no rechazo, que
requieren los usuarios para ser identificado y la informacin sobre sus
interacciones para ser almacenados. Por ejemplo, considerar una aplicacin de
mercado electrnico privacidad orientada que acta como intermediario entre
compradores, comerciantes y una puerta de entrada de procesamiento de
autorizacin de tarjeta de crdito.
Los compradores pueden no querer proporcionar informacin personal privada
(por ejemplo, su nombre, direccin de facturacin, nmero de tarjeta de crdito
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 autorizacin de tarjetas de crdito. Tenga en cuenta que electrnico
billeteras socavan la privacidad, ya que hacen que sea fcil para los
compradores de la oferta privada informacin a los comerciantes. En cambio, el
mercado electrnico apoya firmemente la privacidad a travs de:
o Esconder los clientes informacin personal privada de los comerciantes.
o Autorizar la compra de tarjetas de crdito para el comprador (por lo que el
comerciante quiere que la informacin privada).
o Slo abastecer el comerciante con la informacin no privada (por ejemplo, la
entrega direccin y el pago de crdito de informacin, como la aprobacin de
crdito).
o cifrar encarecidamente a todas las comunicaciones y el almacenamiento de
la informacin privada.

10 REQUISITOS auditora de seguridad


Un requisito auditora de seguridad es cualquier requisito de seguridad que
especifica en qu medida que un negocio, aplicaciones, componentes, o el
centro debern permitir que el personal de seguridad a auditar el estado y el
uso de sus mecanismos de seguridad.

Los objetivos tpicos de un requisito de la auditora de seguridad son para


garantizar que el aplicacin o componente recopila, analiza y reporta
informacin 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 modificacin
por la seguridad personal).
Ejemplos
"La solicitud deber recoger, organizar, resumir, e informar peridicamente
el estado de sus mecanismos de seguridad, incluyendo:
o Identificacin, autenticacin y autorizacin.
o inmunidad.
o de privacidad.
o deteccin de intrusiones ".
Directrices
Se debe tener cuidado para evitar la duplicacin innecesaria entre la
seguridad de los de auditora y los requisitos de deteccin de intrusos.
requisitos de auditora de seguridad no se deben confundir con (ni
especifican en trminos de) los mecanismos de seguridad arquitectnicos 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 aplicacin o centro debern sobrevivir a la
prdida intencional o destruccin de un componente.
El objetivo tpico de un requisito de supervivencia es asegurar que una
aplicacin o centro o bien falla con gracia o de lo contrario sigue a la funcin
(posiblemente en un modo degradado), a pesar de que ciertos componentes
han sido intencionalmente daados o destruidos.
Ejemplos
"La aplicacin 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 crticos para aplicaciones


militares.
Evite los requisitos de robustez confusos con los requisitos de supervivencia.
Requisitos Survivabilty ocupan de salvaguardar contra daos o prdida 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
trminos de) los mecanismos de seguridad arquitectnicos que se pueden
utilizar para ponerlas en prctica:
o redundancia de hardware.
o redundancia del centro de datos.
o de conmutacin por error de software.
12 REQUISITOS DE PROTECCIN FSICA
Un requisito de proteccin fsica es cualquier requisito de seguridad que
especifica en qu medida que una aplicacin o centro debern protegerse de
asalto fsico. Los objetivos tpicos de los requisitos de proteccin fsica son para
asegurar que un aplicacin o centro estn protegidos contra los daos fsicos,
destruccin, robo o sustitucin 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
daos fsicos, destruccin, robo, o el reemplazo subrepticia. "
"El centro de datos deber proteger a su personal de la muerte, lesin, y el
secuestro."
Directrices
requisitos de proteccin fsica estn relacionados con los requisitos de
supervivencia.
Requisitos de supervivencia especificar las continuaron funcionando despus
de un ataque, mientras que requisitos de proteccin fsica especifican la
proteccin de los componentes. Fsica los requisitos de proteccin tpicamente
son requisitos previos para requisitos de supervivencia.
Requisitos de proteccin fsica no se deben confundir con (ni especifican en
trminos de) los mecanismos de seguridad arquitectnicos que se pueden
utilizar para implementar ellos:
o puertas cerradas.

o guardias de seguridad.
o de acceso rpido a la Polica. 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 aplicacin, componente, o el
centro impedir autorizado modificaciones (por ejemplo, soluciones a
anomalas, mejoras, actualizaciones) de derrotar accidentalmente su
mecanismos de seguridad.
El objetivo tpico 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 aplicacin no violar sus requisitos de seguridad como resultado de la
mejora de una de datos, hardware o componente de software ".
"La aplicacin no violar sus requisitos de seguridad como resultado de la
sustitucin 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 aplicacin o
componente fuera de lnea durante el mantenimiento y la repeticin de las
pruebas de seguridad.
Requisitos de seguridad de mantenimiento del sistema no debe confundirse
con (ni especifican en trminos de) los mecanismos de seguridad
arquitectnicos que se pueden utilizar para ponerlas en prctica:
o Mantenimiento y procedimientos de mejora.
o la formacin asociada.
o pruebas de regresin de Seguridad.
14 CONCLUSIN
En esta columna se ha abordado la necesidad de analizar y especificar
seguridad real sistemticamente requisitos como parte de los requisitos de
calidad de una empresa, la aplicacin, 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 pblico destinatario. Lo

har tambin proporcionan criterios para evaluar las especificaciones y


requisitos de gestin de herramientas sobre la base de esta necesidad