UNIVERSIDAD TECNOLGICA DE PANAM

FACULTAD DE INGENIERA DE SISTEMAS COMPUTACIONALES

MAESTRA Y POSTGRADO EN AUDITORA DE SISTEMAS

METODOLOGIA Y AUDITORA AL DESARROLLO DE APLICACIONES

CERTIFICACIN CSSLP DEL ISC

CERTIFIED SECURE SOFTWARE LIFECYCLE PROFESSIONAL (CSSLP)

Profesional Certificado en Seguridad del Ciclo de Vida de Software

DOMINIO 1: CONCEPTOS DE SOFTWARE SEGURO

PRESENTADO POR:

ARANDA YOHARA

MIRANDA KATHERINE

PROFESOR:

RAL LEZCANO

FECHA:

20 DE MARZO DE 2017

1
 CONTENIDO

CERTIFIED SECURE SOFTWARE LIFECYCLE PROFESSIONAL (CSSLP).................4

DOMINIO 1: CONCEPTOS DE SOFTWARE SEGURO...................................................4
1.1. Seguridad integral....................................................................................................4
1.1.1. Desafos de implementacin.............................................................................5
Restricciones tringulo del hierro.........................................................................5
Seguridad en el ltimo momento.........................................................................6
Seguridad vs. Usabilidad......................................................................................7
1.1.2. Calidad y Seguridad..........................................................................................7
1.2. Conceptos bsicos de seguridad............................................................................8
Confidencialidad...................................................................................................8
Integridad..............................................................................................................8
Disponibilidad.......................................................................................................8
.......................................................................................................... Autenticacin
9
Autorizacin..........................................................................................................9
Rendicin de cuentas y no repudio......................................................................9
1.3. Conceptos de Diseo de Seguridad......................................................................10
1.4. Gestin de Riesgo.................................................................................................12
1.4.1. Terminologa y definiciones.............................................................................13
1.4.2. Respuestas al riesgo......................................................................................14
1.5. Polticas de Seguridad...........................................................................................15
1.5.1. Alcance de las polticas de seguridad............................................................16
1.6. Normas de Seguridad............................................................................................18
CONCLUSIN.................................................................................................................33
BIBLIOGRAFA................................................................................................................34

2
 INTRODUCCIN

La seguridad de las aplicaciones debe ser una prioridad para las organizaciones, para
proteger su negocio y su reputacin. Es crucial que cualquier persona involucrada en el
ciclo de vida de desarrollo de software (SDLC) est bien informada y tenga experiencia
en la comprensin de cmo construir un software seguro.

Por esta razn, es de vital importancia que los auditores de sistemas estn capacitados
en temas de seguridad en el desarrollo de software, para que puedan detectar errores
en aspectos de seguridad en el desarrollo de aplicaciones y as brindar
recomendaciones que ayuden a que el sistema sea seguro.

El Consorcio Internacional de Certificacin de Seguridad de Sistemas de Informacin

(ISC) es una empresa que educa y certifica a los profesionales de la seguridad de la
informacin, el mismo ofrece diversas certificaciones, una de ellas es la CSSLP que es
la certificacin que otorga el ttulo de Profesional Certificado en Seguridad del Ciclo de
Vida del Software.

El CSSLP es la primera certificacin que cubre todos los aspectos de la seguridad en el

ciclo de vida del desarrollo de software. Este fue creado con el objetivo de cerrar la
brecha entre los profesionales de software y las mejores prcticas de seguridad, para
garantizar que todas las etapas del ciclo de vida de desarrollo de software se basen en
seguridad.

El ISC proporciona una gua oficial para los interesados en obtener la certificacin de
CSSLP, la cual consta de ocho dominios, de los cuales abordaremos en este trabajo
nicamente el dominio uno, sobre Conceptos de Software Seguro; pues, si bien es
cierto, sin una base slida los edificios pueden colapsar, lo mismo sucede cuando se
trata de la creacin de un software. Para que el software sea seguro y resistente contra
los piratas informticos, se debe tener en cuenta ciertos conceptos fundamentales de la
seguridad de la informacin. Algunos de estos aspectos a presentar en esta
investigacin son: Seguridad Integral, Conceptos de Diseo de Seguridad, Gestin de
Riesgo de Software, Polticas de Seguridad y Normas de Seguridad.

3
CERTIFIED SECURE SOFTWARE LIFECYCLE PROFESSIONAL (CSSLP)

El CSSLP es la certificacin emitida por el Consorcio Internacional de Certificacin de

Seguridad de Sistemas de Informacin (ISC), la cual otorga el ttulo de Profesional
Certificado en Seguridad del Ciclo de Vida de Software.

La certificacin CSSLP valida que los profesionales de software tienen la experiencia

necesaria para incorporar prcticas de seguridad, autenticacin, autorizacin y
auditora en cada fase del ciclo de vida de desarrollo de software (SDLC), desde el
diseo e implementacin de software hasta la prueba y el despliegue.

Para que el software sea seguro y resistente contra los piratas informticos, se debe
tener en cuenta ciertos conceptos fundamentales de la seguridad de la informacin;
estos incluyen la confidencialidad, integridad, disponibilidad, autenticacin,
autorizacin, la rendicin de cuentas, la gestin de sesiones, excepciones, errores y
parmetros de configuracin, los cuales deben ser considerados en el diseo,
desarrollo y despliegue del software.

DOMINIO 1: CONCEPTOS DE SOFTWARE SEGURO

1.1. Seguridad integral

Hace algunos aos, la seguridad era acerca de mantener a los malos fuera de su red.
La seguridad de la red se bas en gran medida en las defensas del permetro tales
como cortafuegos, zonas desmilitarizadas (DMZ) y los hosts para proteger aplicaciones
y datos que estaban dentro de la red de la organizacin. Estas defensas perimetrales
son absolutamente necesarias y crticas, pero con la globalizacin y el paisaje
cambiante en la forma de hacer negocios hoy en da, en el que hay una necesidad de
permitir el acceso a nuestros sistemas y aplicaciones internas, los lmites que
demarcan nuestros sistemas internos y aplicaciones de los externos han
desapareciendo lentamente.

4
Por ejemplo, una vulnerabilidad de inyeccin de lenguaje de consulta estructurado
(SQL) en la aplicacin puede permitir que un atacante pueda comprometer el servidor
de base de datos (anfitrin), lo cual afecta a toda la red.

Asegurar la red, los hosts y la capa de aplicacin

1.1.1.Desafos de implementacin

A pesar del reconocimiento del hecho de que la seguridad de redes, sistemas y

software es crtico para las operaciones y la sostenibilidad de una organizacin o
empresa, el entorno informtico, hoy en da parece estar plagado de una gran cantidad
de redes y sistemas inseguros. Algunas de las principales razones de por qu existe
una prevalencia de software inseguro puede ser atribuido a la siguiente:

Restricciones tringulo del hierro

Desde el momento en que nace una solucin para resolver un problema de negocio
utilizando un software, hasta el momento en que esta solucin se ha diseado,

5
desarrollado y desplegado, hay una necesidad de tiempo (horario), recursos (alcance) y
costos (presupuesto).

Adems, se requiere de personas con las habilidades apropiadas y conocimientos

tcnicos lo cual representa elevados costos, es por ello que muchas empresas deciden
no incorporar la seguridad en el software como parte indispensable en el desarrollo del
mismo. Es decir, las limitaciones en el alcance, horario y presupuesto, los cuales son
conocidos como los componentes del tringulo de hierro, a menudo son las razones
por las que los requisitos de seguridad quedan fuera del software.

Seguridad en el ltimo momento

Los desarrolladores tienden a pensar que la seguridad no aade ningn valor para el
negocio ya que no es muy fcil de mostrar un retorno de uno a uno en la inversin en
seguridad.

Es importante que las funciones de seguridad estn integradas en el software, en lugar

de ser aadido en una fase posterior, ya que se ha demostrado que el costo para
arreglar el software inseguro temprano en el ciclo de vida del software de desarrollo
(SDLC) es insignificante si se compara con tener el mismo problema en una etapa
posterior de la SDLC.

6
 Seguridad vs. Usabilidad

Otra razn de por qu es un desafo incorporar funciones de seguridad en el software

es que al hacerlo el software se vuelve ms complejo, restrictivo e inutilizable.

Por ejemplo, recursos humanos le ha pedido al equipo de desarrollo de software una

aplicacin web de intranet a la cual puedan tener acceso. Cuando el equipo de
desarrollo de software consulta con el asesor de seguridad, que es un CSSLP, el
consultor de seguridad recomienda que dicho acceso debe concederse solamente a los
que estn autenticados y autorizados y que todas las solicitudes de acceso deben ser
registradas para fines de revisin. Por otra parte, el consultor de seguridad aconseja al
equipo de software la implementacin de contraseas que sean al menos de quince
caracteres de largo, que requieran maysculas y minsculas y que tengan una mezcla
de caracteres alfanumricos y caracteres especiales, las cuales deban cambiarse cada
treinta das. Una vez que el software es diseado y desarrollado para su uso, existe la
posibilidad que el personal de recursos humanos escriba sus contraseas complejas en
notas adhesivas y las coloque en lugares inseguros como en sus cajones del escritorio
o incluso en sus monitores. Tambin pueden llegar a quejarse de que el software no se
puede utilizar ya que se necesita una gran cantidad de tiempo para cada solicitud de
acceso a procesar.

La seguridad del software debe ser equilibrada con la facilidad de uso y rendimiento.
No hay absolutamente ninguna duda de que la incorporacin de la seguridad viene a
costa de rendimiento y facilidad de uso. Esto es cierto si el diseo de software no tiene
en cuenta el concepto conocido como la aceptabilidad psicolgica.

1.1.2.Calidad y Seguridad

En un mundo que est impulsado por la necesidad y la garanta de calidad de los

productos, es importante reconocer que hay una distincin entre la calidad y la
seguridad, particularmente en lo que se aplica a los productos de software. Casi todos
los productos de software pasan por una fase de control de calidad antes de ser
liberados o desplegados, en el que la funcionalidad del software, como lo requiere el

7
cliente, es validada y verificada. Los controles de calidad son indicativos de que el
software es fiable (buenas condiciones de funcionamiento) y que es funcional (cumple
con los requisitos especificados por el propietario de la empresa).

1.2. Conceptos bsicos de seguridad

Con el fin de desarrollar un software resistente a ataques, es importante incorporar los

conceptos de seguridad en las fases de requisitos, diseo, cdigo, liberacin y
eliminacin del ciclo de vida de desarrollo de software (SDLC).

Los conceptos bsicos de seguridad son:

Confidencialidad

La confidencialidad es el concepto de seguridad que tiene que ver con la proteccin

contra la divulgacin no autorizada de informacin. Tiene que ver con la visualizacin
de los datos. Esto no slo asegura la confidencialidad del secreto de los datos, sino
que tambin puede ayudar en el mantenimiento de la privacidad de datos.

Integridad

Es la propiedad que busca mantener los datos libres de modificaciones no autorizadas.

Es mantener con exactitud la informacin tal cual fue generada, sin ser manipulada ni
alterada por personas o procesos no autorizados.

La integridad del software tiene que ver con dos aspectos. En primer lugar, debe
asegurarse de que los datos que se transmiten, procesan y almacenan son tan
precisos como el autor pretende y en segundo lugar, que el software funciona de
manera confiable, como se pretende.

Disponibilidad

La disponibilidad es la caracterstica, cualidad o condicin de la informacin de

encontrarse a disposicin de quienes deben acceder a ella, ya sean personas,
procesos o aplicaciones. Es el acceso a la informacin y a los sistemas por personas
autorizadas en el momento que as lo requieran.
8
En el caso de los sistemas informticos utilizados para almacenar y procesar la
informacin, los controles de seguridad utilizados para protegerlo, y los canales de
comunicacin protegidos que se utilizan para acceder a ella deben estar funcionando
correctamente. Los sistemas deben estar disponibles en todo momento, evitando
interrupciones del servicio debido a cortes de energa, fallos de hardware, y
actualizaciones del sistema.

La replicacin es un mecanismo que puede utilizarse para asegurar la disponibilidad. El

software tambin puede ser desarrollado con el seguimiento y la funcionalidad de alerta
que puede detectar interrupciones y notificar al personal apropiado para minimizar el
tiempo de inactividad, una vez ms, asegurando la disponibilidad.

Autenticacin

El software es un conducto para las bases de datos internas de la organizacin,

sistemas y redes y por lo que es de vital importancia que el acceso a la informacin
confidencial interna slo se concede a aquellas entidades que son vlidas. La
autenticacin es un concepto de seguridad que responde a la pregunta: Est usted
quien dice ser?

Autorizacin

La autorizacin es el concepto de seguridad en el que el acceso a los objetos se

controla en base a los derechos y privilegios que se otorgan al solicitante por la titular
de los datos o sistema, de acuerdo con una poltica.

Rendicin de cuentas y no repudio

Proporciona proteccin contra la negacin, por parte de alguno de los individuos

autorizados en el sistema, de haber participado en toda o parte de la manipulacin de
datos, en un evento o una transaccin.

Para garantizar la rendicin de cuentas y no repudio deben existir pistas de auditora,

las cuales incluyen nombre del usuario, accin realizada (operaciones tales como

9
crear, leer, actualizar, eliminar) lugar donde se realiz la accin y cundo (fecha y hora
de la operacin).

1.3. Conceptos de Diseo de Seguridad

Algunos conceptos ms importantes que se deben tomar en cuenta en el diseo son:

Privilegios mnimos: El principio de mnimo privilegio (tambin
conocido como el principio de menor autoridad) requiere que en una
particular capa de un entorno computacional, cada mdulo (como
un proceso, un usuario o un programa) debe ser capaz de acceder solo
a la informacin y recursos que son necesario para su legtimo
propsito.

Separacin de tareas: La segregacin de funciones est orientada a

evitar que una misma persona tenga accesos a dos o ms
responsabilidades dentro del sistema, de tal forma que pueda realizar
acciones o transacciones que lleven a la consumacin de un fraude.

Defensa por capas: Como los riesgos potenciales de Internet se

pueden producir en varios niveles, se debe configurar medidas de
seguridad que ofrezcan mltiples capas de defensa contra los riesgos.
El uso de un enfoque por capas al planificar la estrategia de seguridad
de Internet garantiza que el atacante que logre penetrar en una de las
capas de defensa ser detenido en una capa siguiente.

Prueba de fallos: Es una caracterstica de diseo que en el caso de un

tipo especfico de falla, inherentemente responde de una manera que
no causar ningn dao o mnimo a otros equipos, el medio ambiente o
las personas. Prueba de fallos" significa que el fallo es imposible o
improbable, sino que el diseo del sistema evita o mitiga las
consecuencias inseguras del fallo del sistema.

Economa de los Mecanismos: Al mantener el diseo de software y

detalles de implementacin simple, se reduce la superficie de ataque al

10
 software, pues un mayor nmero de vulnerabilidades aumenta con la
complejidad del diseo de la arquitectura de software y el cdigo. Cuando
ocurren errores, son ms fciles de entender y arreglar.

La mediacin completa: Un principio de seguridad que garantiza que

no se eluda la autoridad en las solicitudes posteriores de un objeto por
un sujeto, mediante la comprobacin de autorizacin (derechos y
privilegios) sobre todas las solicitudes para el objeto.

Diseo Abierto: El principio de seguridad de diseo abierto declara

que los detalles de implementacin del diseo deben ser
independientes del diseo en s, que puede permanecer abierta, al
contrario que en el caso de la seguridad por oscuridad en el que la
seguridad del software depende del oscurecimiento del diseo en s.

Mecanismos mnimo comn: El principio de la seguridad de los

mecanismos menos comunes no permite el intercambio de
mecanismos que son comunes a ms de un usuario o proceso si los
usuarios y los procesos se encuentran en diferentes niveles de
privilegio. Por ejemplo, no se permitir el uso de la misma funcin para
recuperar el importe de la bonificacin de un empleado exento y un
empleado no exento. En este caso el clculo de la bonificacin es el
mecanismo comn.

La aceptabilidad psicolgica: Un principio de seguridad que tiene

como objetivo maximizar el uso y la adopcin de la funcionalidad de
seguridad en el software asegurando que la funcionalidad de seguridad
es fcil de usar y al mismo tiempo transparente para el usuario.

Eslabn ms dbil: Este principio de seguridad establece que la

elasticidad de su software contra los intentos de hackers depender en
gran medida de la proteccin de sus componentes ms dbiles, ya sea el
cdigo, un servicio o una interfaz. Un sistema de seguridad de software es
tan fuerte como su eslabn ms dbil. Los atacantes van tras los objetivos

11
 fciles. Se debe identificar y fortalecer los vnculos dbiles hasta alcanzar
un nivel aceptable de riesgo.

Aprovechando componentes existentes: Este es un principio de

seguridad que se centra en garantizar que la superficie de ataque no se
incrementa y no hay nuevas vulnerabilidades que se introducen
mediante el fomento de la reutilizacin de componentes de software
existentes, cdigo y funcionalidad.

1.4. Gestin de Riesgo

La gestin de riesgos, en el contexto de la seguridad del software, es el acto de

equilibrio entre la proteccin de los activos de TI y el costo de la implementacin de
controles de seguridad del software.

Uno de los aspectos clave de la gestin de la seguridad es la gestin de riesgos. Los

procesos de gestin de riesgos incluyen la evaluacin preliminar de la necesidad de
controles de seguridad, la identificacin, desarrollo, prueba, implementacin y
verificacin (evaluacin) de los controles de seguridad para que el impacto de los
procesos perturbadores estn en un nivel aceptable o riesgo apropiado.

12
1.4.1. Terminologa y definiciones

Activos: Los activos son aquellos artculos que son valiosos para la
organizacin, la prdida de lo que potencialmente puede causar trastornos en la
capacidad de la organizacin para llevar a cabo sus misiones.

En el mbito de la seguridad del software, los datos son el activo tangible ms

importante, y la prdida de la reputacin de la marca de una organizacin puede
ser desastroso y la recuperacin de una prdida tal, puede ser casi imposible.
Podra decirse que la reputacin de marca de empresa es el ms valioso activo
intangible.

Vulnerabilidad: Una debilidad o defecto que se podran accionar accidentalmente

o intencionalmente aprovechada por un atacante, dando como resultado el
incumplimiento o ruptura de la poltica de seguridad que se conoce como una
vulnerabilidad. Las vulnerabilidades pueden ser evidentes en el proceso, el
diseo o en la aplicacin del sistema o software. Algunos ejemplos de
vulnerabilidades de ejecucin son el software acepta los datos proporcionados
por el usuario y lo procesa sin primero validarla, el software revela demasiada
informacin en el caso de un error y no se cierra de forma explcita las
conexiones abiertas.

Amenaza: Una amenaza es simplemente la posibilidad de un evento no deseado,

no deseada o perjudicial que se produzcan. Cuando el evento se produce tras la
manifestacin de la amenaza, da lugar a un incidente.

Ataque: Es una accin intencional, intentar causar dao es la definicin ms

simple de un ataque. El atacante explota una vulnerabilidad haciendo que el
agente de amenaza pueda causar dao.

Probabilidad: Es la mayor o menor posibilidad de que ocurra un determinado

suceso. En otras palabras, su nocin viene de la necesidad de medir o

13
 determinar cuantitativamente la certeza o duda de que un suceso dado ocurra o
no.

Impacto: Es el efecto negativo que queda cuando se materializa un riesgo.

Factor de exposicin: Se define como la oportunidad de una amenaza para

causar prdida.

Controles: Los controles de seguridad son mecanismos por los que las
amenazas a los sistemas de software y pueden ser mitigados. Los controles de
seguridad se pueden clasificar a grandes rasgos en las contramedidas y las
salvaguardas. Las contramedidas son los controles de seguridad que se aplican
despus de una amenaza se ha materializado, lo que implica la naturaleza
reactiva de este tipo de controles de seguridad. Por otro lado, las salvaguardias
son los controles de seguridad que son ms proactivo en la naturaleza. Los
controles de seguridad no eliminan la amenaza en s, sino que estn integradas
en el software o sistema para reducir la probabilidad de que una amenaza se
materializ.

1.4.2. Respuestas al riesgo

Ignorar el riesgo: Se puede optar por no manejar el riesgo y no hacer nada,

dejando el software como es.

Evitar el riesgo: El riesgo puede evitarse, pero nunca debe ser ignorado.

Mitigar el riesgo: El equipo de desarrollo opta por implementar controles de

seguridad (salvaguardias y contramedidas) para reducir el riesgo.

Aceptar el riesgo: La administracin puede optar por esta aceptar el riesgo

residual que queda y continuar las operaciones comerciales o pueden optar
por seguir mitigndolo al no almacenar la informacin de titular de la tarjeta
no permitida. Cuando el costo de la implementacin de controles de

14
 seguridad es mayor que el impacto potencial del riesgo en s mismo, uno
puede aceptar el riesgo.

Transferir el riesgo: Un mtodo adicional por el cual la administracin puede

optar por hacer frente al riesgo es simplemente transferirlo. Las formas ms
comunes para transferir el riesgo estn comprando un seguro y el uso de
renuncias.

1.5. Polticas de Seguridad

El "qu" y "por qu" para la seguridad

Contrariamente a lo que uno puede pensar que es, una poltica de seguridad es ms
que un simple documento escrito. Es el instrumento por el cual los activos digitales que
requieren proteccin pueden ser identificados. Especifica a un alto nivel lo que debe ser
protegido y las posibles repercusiones del incumplimiento.

Adems de definir los activos que la organizacin considera valiosos, las polticas de
seguridad identifican las metas y objetivos de la organizacin y comunican las metas y
los objetivos de la organizacin para la organizacin.

Con un claro entendimiento de las expectativas de la gerencia, la probabilidad de

interpretaciones personales y la afirmacin de la ignorancia se reduce, especialmente
cuando los auditores encontrar brechas entre los procesos de la organizacin y los
requisitos de cumplimiento. Protege a la organizacin de cualquier "empresa"
proporcionando una base consistente para interpretar o resolver los problemas que
surjan.

La poltica de seguridad proporciona el marco y el punto de referencia que puede

usarse para medir la postura de seguridad de una organizacin. Las brechas que se
identifican cuando se miden frente a una poltica de seguridad, un punto de referencia

15
coherente, pueden utilizarse para determinar la estrategia y las decisiones ejecutivas
efectivas.

1.5.1.Alcance de las polticas de seguridad

El mbito de aplicacin de la poltica de seguridad de la informacin puede

ser organizativo o funcional. La poltica de organizacin es universalmente aplicable y
todos los que forman parte de la organizacin deben cumplirlo, a diferencia de una
poltica funcional que se limita a una unidad funcional especfica o una cuestin
especfica.

Un ejemplo de poltica organizacional es la poltica de acceso remoto que es aplicable

a todos los empleados y no empleados que requieren acceso remoto a la red
organizativa.

Un ejemplo de una poltica de seguridad funcional es la poltica de confidencialidad de

datos que especifica las unidades funcionales que estn permitidas para ver
informacin sensible o personal.

En algunos casos, stos incluso pueden definir los derechos que el personal tiene
dentro de estas unidades funcionales. Por ejemplo, no todos los miembros del equipo
de recursos humanos pueden ver los datos de nmina de los ejecutivos.

Puede ser un solo documento completo o puede estar compuesto de muchos

documentos especficos de poltica de seguridad de la informacin.

1.5.2. Requisitos previos para el desarrollo de polticas de seguridad

Las polticas de seguridad proporcionan un marco para un programa de seguridad de la

informacin completo y eficaz.

El xito de un programa de seguridad de la informacin y ms especficamente las

iniciativas de seguridad de software dentro de ese programa est directamente
relacionado con la exigibilidad de los controles de seguridad que deben determinarse e
incorporarse al ciclo de vida de desarrollo de software.

16
Una poltica de seguridad es el instrumento que puede proporcionar esta obligatoriedad
necesaria. Sin polticas de seguridad, se puede razonablemente argumentar que no
hay dientes en las iniciativas de software seguro que un apasionado CSSLP o
profesional de la seguridad gustara tener en su lugar. Aquellos que son o han sido
responsables de incorporar controles de seguridad y actividades dentro del SDLC
saben que un programa de seguridad a menudo enfrenta inicialmente resistencia.

Sin embargo, el desarrollo de las polticas de seguridad es ms que un simple acto de

anotar unas pocas reglas de "Thou shall" o "Thou shall not"(es decir o es decir no) en
papel. Para que las polticas de seguridad sean efectivamente desarrolladas y
ejecutables requiere el apoyo de la direccin ejecutiva (soporte de nivel superior). Sin el
apoyo de la direccin ejecutiva, incluso si las polticas de seguridad se desarrollan con
xito, su implementacin probablemente fracasar.

1.5.3.Proceso de desarrollo de polticas de seguridad

El desarrollo de polticas de seguridad no es una actividad nica. Debe ser una
actividad perenne, es decir, las polticas de seguridad deben ser evaluadas
peridicamente para que sean contextualmente correctas y relevantes para enfrentar
las amenazas actuales.

Un ejemplo de una poltica de seguridad que no es contextualmente correcta es una

poltica impuesta o adoptada que impone la autenticacin de varios factores en su
software para todas las transacciones financieras, pero su organizacin ya no est
configurada para tener la infraestructura como lectores de fichas o datos biomtricos
Dispositivos para admitir la autenticacin de mltiples factores.

Un ejemplo de una poltica de seguridad que no es relevante es aquel en el que la

poltica requiere que utilice tecnologa criptogrfica obsoleta e insegura como el Data
Encryption Standard (DES) para la proteccin de datos. DES ha demostrado ser
fcilmente roto con la tecnologa moderna, aunque puede haber sido el estndar de

17
facto cuando se desarroll la poltica. Con la estandarizacin del Advanced Encryption
Standard (AES), DES se considera ahora como una tecnologa obsoleta.

Las polticas que han ordenado explcitamente el DES ya no son relevantes y por lo
tanto deben ser revisadas y revisadas. Los requisitos contextualmente incorrectos,
obsoletos e inseguros de las polticas se marcan a menudo como problemas no
conformes durante una auditora. Este problema se puede evitar mediante revisiones
peridicas y revisiones de las polticas de seguridad en vigor.

Mantener las polticas de seguridad de alto nivel e independientes de la tecnologa

alivia la necesidad de revisiones frecuentes. Tambin es importante vigilar la eficacia de
las polticas de seguridad y abordar las cuestiones que se identifican como parte de las
lecciones aprendidas.

1.6. Normas de Seguridad

Las normas de seguridad de alto nivel son compatibles con normas de seguridad ms
detalladas.

Debido a estndares ms granulares y especficos. Al igual que las polticas de

seguridad, los estndares organizacionales se consideran elementos obligatorios de un
programa de seguridad y deben seguirse en toda la empresa, a menos que se conceda
especficamente una excepcin para una funcin determinada.

Tipos de normas de seguridad

Las normas internas suelen ser especficas. La norma de codificacin es un ejemplo de

un estndar interno de seguridad de software.

Las normas externas pueden clasificarse adems en funcin del emisor y del
reconocimiento. Dependiendo de quin ha emitido el estndar, los estndares de

18
seguridad externos pueden clasificarse en estndares de la industria o estndares
gubernamentales.

Un ejemplo de un estndar emitido por la industria es el estndar de seguridad de

datos de la industria de tarjetas de pago (PCI DSS). Ejemplos de estndares emitidos
por el gobierno incluyen los generados por el Instituto Nacional de Estndares y
Tecnologa (NIST).

No todas las normas son geogrficamente reconocidas y aplicables en todas las

regiones de manera uniforme. Dependiendo del grado de reconocimiento, las normas
de seguridad externa pueden clasificarse en normas nacionales e internacionales de
seguridad.

Si bien las normas nacionales de seguridad a menudo estn ms centradas e incluyen

las costumbres y prcticas locales, las normas internacionales suelen ser ms amplias
y genricas, abarcando diversas normas con el objetivo de interoperabilidad. El ejemplo
ms frecuente de normas internacionalmente reconocidas es la ISO (Organizacin
Internacional de Normalizacin), mientras que los ejemplos de normas reconocidas a
nivel nacional son el Sistema Federal de Informacin

(FIPS) y los del American National Standards Institute (ANSI), en los Estados Unidos
de Amrica. Tambin es digno de mencin reconocer que con la globalizacin que
impacta el mnimo de operaciones en el panorama global, la mayora de las
organizaciones se inclinan ms hacia la adopcin de estndares internacionales sobre
los nacionales.

Clasificacin de las Normas de Seguridad

19
Normas internas de codificacin a los profesionales de la seguridad aplicables al
software.
1. Instituto Nacional de Estndares y Tecnologa (NIST) Publicaciones
Especiales
2. Normas Federales de Procesamiento de Informacin (FIPS)
3. Organizacin Internacional de Normalizacin (ISO)
4. Industria de tarjetas de pago (PCI)
5. Organizacin para el Avance de la Informacin Estructurada Normas
(OASIS)

Normas internas de codificacin

Uno de los estndares internos ms importantes que tiene un tremendo impacto en la
seguridad del software es el estndar de codificacin. La norma de codificacin
especifica los requisitos que estn permitidos y que deben ser adoptados por la
organizacin o equipo de desarrollo al escribir cdigo (software de construccin).

Los estndares de codificacin no necesitan desarrollarse para cada lenguaje de

programacin o sintaxis, pero pueden incluir varios idiomas en uno. Las organizaciones
que no tienen un estndar de codificacin deben planear tener uno creado y adoptado.

La norma de codificacin no slo trae consigo muchas ventajas de seguridad, sino que
tambin proporciona beneficios no relacionados con la seguridad. La consistencia en el
20
estilo, la mejora de la legibilidad del cdigo y la facilidad de mantenimiento son algunos
de los beneficios no relacionados con la seguridad que uno obtiene cuando siguen un
estndar de codificacin.

Estndares del NIST

Fundado en el inicio de la revolucin industrial en 1901 por el Congreso con el objetivo
de prevenir las disputas comerciales y alentar la estandarizacin, el Instituto Nacional
de Estndares y Tecnologa (NIST) desarrolla tecnologas, mtodos de medicin y
normas para ayudar a las empresas estadounidenses en el mercado global. Aunque
NIST es especfico de los Estados Unidos, en las situaciones de outsourcing, la
empresa a la que se subcontrata el desarrollo de software puede tener que cumplir con
estas normas. Esto suele hacerse cumplir contractualmente.

Los programas del NIST ayudan a mejorar la calidad y las capacidades del software
utilizado por las empresas, las instituciones de investigacin y los
consumidores. Ayudan a asegurar los datos electrnicos y mantener la disponibilidad
de servicios electrnicos crticos mediante la identificacin de vulnerabilidades y
medidas de seguridad rentables.

Una de las competencias bsicas del NIST es el desarrollo y uso de estndares. Tienen
la responsabilidad legal de establecer normas y directrices de seguridad para los
sistemas federales sensibles, pero estas normas son adoptadas y utilizadas
selectivamente por el sector privado sobre una base voluntaria tambin.

Diversas publicaciones de la serie SP 800 que tienen implicaciones

considerables para la seguridad del software.

SP 800-12: Una Introduccin a la seguridad informtica: El Manual

NIST
Este manual ofrece una amplia visin general de la seguridad informtica,
proporcionando orientacin para asegurar hardware, software y recursos de

21
informacin. Explica los conceptos relacionados con la seguridad informtica, las
consideraciones de costos y las interrelaciones de los controles de seguridad. Los
controles de seguridad se clasifican en controles de gestin, controles operativos y
controles de tecnologa.

SP 800-14: Generalmente Aceptados Principios y

Prcticas para los sistemas de seguridad de TI
Al igual que el manual SP 800-12 de su organizacin, el documento SP 800-14
proporciona una lnea de base que las organizaciones pueden usar para establecer y
revisar sus programas de seguridad de TI. A diferencia de SP 800-12, este documento
ofrece una visin de los requisitos bsicos de seguridad que la mayora de los sistemas
de TI deben contener, a varios interesados, incluyendo la administracin, auditores
internos, usuarios, desarrolladores de sistemas y profesionales de la
seguridad. Proporciona una base que puede utilizarse como punto de referencia.

SP 800-18: Gua para el desarrollo de la Seguridad Planes para Sistemas

Federales
Sin la documentacin apropiada de los requisitos de proteccin de sistemas de
informacin y controles de seguridad (en el lugar o planeado), en un plan de seguridad
de la informacin, la penetracin en el estado organizacional de seguridad puede ser
un desafo. El objetivo principal de la planificacin de la seguridad de la informacin es
mejorar la proteccin de los recursos del sistema de informacin. Contiene un marco
para clasificar los activos de informacin basados en el impacto en los tres objetivos
principales de seguridad, es decir, confidencialidad, integridad y disponibilidad.

SP 800-27: Principios de Ingeniera de Seguridad de la tecnologa de la

informacin
La publicacin especial 800-27 del NIST, que se titula, "Principios de ingeniera para la
seguridad de la tecnologa de la informacin (una lnea de base para lograr la
seguridad)", en la Seccin 3.3 proporciona varios principios de seguridad de TI que se
enumeran a continuacin. Algunos de estos principios estn orientados a las personas,

22
mientras que otros estn vinculados al proceso de diseo de la seguridad en los
sistemas de TI.
1 Establecer una poltica de seguridad de sonido como la "fundacin" para el
diseo.
2 Trate la seguridad como una parte integral del diseo general del sistema.
3 Delimite claramente los lmites de seguridad fsica y lgica Regidos por
polticas de seguridad asociadas.
4 Reducir el riesgo a un nivel aceptable.
5 Suponga que los sistemas externos son inseguros.
6 Implementar medidas personalizadas de seguridad del sistema para
cumplir con los objetivos de seguridad.
7 Utilizar mecanismos de lmites para separar los sistemas
de Infraestructuras de red.
8 Cuando sea posible, base la seguridad en estndares abiertos para la
portabilidad y la interoperabilidad.

SP 800-30: Gua de gestin de riesgos para TI

Como se mencion anteriormente, uno de los aspectos clave de la gestin de la
seguridad es la gestin de riesgos, que desempea un papel fundamental en la
proteccin de los activos de informacin de una organizacin y su misin de los riesgos
relacionados con TI.

SP 800-64: Consideraciones de seguridad en el

Ciclo de vida del desarrollo de sistemas de informacin

Construir la seguridad en lugar de prenderla en una etapa posterior permite a las

organizaciones maximizar su retorno sobre la inversin en seguridad (ROSI) por
1 Identificar y mitigar vulnerabilidades de seguridad y Errores en el SDLC
donde el costo para implementar controles de seguridad es
considerablemente menor.

23
2 Destacar cualquier problema de ingeniera o diseo que pueda
requerir Rediseo en una etapa posterior del SDLC, si la seguridad no se ha
considerado temprano, pero ahora se requiere.
3 Identificacin de servicios de seguridad compartidos que pueden
aprovecharse Reduce el costo y el tiempo de desarrollo.
4 La gestin integral del riesgo y la facilitacin de la Tomar decisiones
informadas sobre el riesgo de ir / no ir y el manejo del riesgo (aceptar /
transferir / mitigar o evitar) decisiones.

Normas federales de procesamiento de informacin (FIPS)

Las Normas Federales de Procesamiento de Informacin (FIPS). Las publicaciones de

FIPS se desarrollan para abordar los requisitos federales para:
1 Interoperabilidad de los sistemas dispares
2 Portabilidad de datos y software
3 La seguridad informtica

Algunas de las conocidas publicaciones de FIPS que estn estrechamente

relacionadas con la seguridad del software son
1 FIPS 140: Requisitos de seguridad para mdulos criptogrficos
2 FIPS 186: Estndar de firma digital
3 FIPS 197: Estndar de cifrado avanzado
4 FIPS 201: Verificacin de Identidad Personal (PIV) de Empleados y
Contratistas.

FIPS 140: Requisitos de seguridad para mdulos criptogrficos

El FIPS 140 es el estndar que especifica los requisitos que necesitarn ser
satisfechos por un mdulo criptogrfico. Proporciona cuatro niveles cualitativos
crecientes (Nivel 1 a Nivel 4) destinados a cubrir una amplia gama de aplicaciones y
entornos potenciales.

24
FIPS 186: Digital Signature Standard (DSS)
FIPS 186: Digital Signature Standard (DSS) especifica un conjunto de algoritmos que
se pueden utilizar para generar una firma digital.

FIPS 197: Advanced Encryption Standard

FIPS197: AdvancedEncryptionSecurity (AES) especifica un algoritmo de criptografa
aprobado para garantizar la confidencialidad de los datos electrnicos. El algoritmo
AES es un cifrado simtrico de bloques que se puede utilizar para cifrar (convertir el
texto claro humanamente inteligible en una forma inteligible llamada texto cifrado) y
descifrar (convertir texto cifrado en texto claro)

FIPS 201: verificacin de identidad personal (PIV) de los empleados federales y

contratistas
El estndar FIPS 201 de Verificacin de Identidad Personal (PIV) fue desarrollado en
respuesta a la necesidad de asegurar que la identidad reclamada del personal
(empleados y contratistas) que requieran acceso fsico o electrnico a instalaciones y
datos seguros y sensibles sea verificada apropiadamente.
NORMAS ISO
La Organizacin Internacional de Normalizacin (ISO) es el principal organismo que
desarrolla Normas Internacionales para todos los sectores de la industria, excepto la
electrotcnica y las telecomunicaciones.

Las normas de electrotecnia son desarrolladas por la Comisin Electrotcnica

Internacional (CEI) y las normas de telecomunicaciones son desarrolladas por la Unin
Internacional de Telecomunicaciones (UIT), que es la misma organizacin que
establece las versiones de certificados digitales X.509. ISO junto con IEC (prefijada
como ISO / IEC) ha desarrollado varias Normas Internacionales que estn directamente
relacionadas con la seguridad de la informacin.

25
A diferencia de muchas otras normas que son amplias en su orientacin, la mayora de
las normas ISO son muy especficas. Con el fin de garantizar que las normas se
ajusten a los cambios en la tecnologa, la revisin peridica de cada norma despus de
su publicacin (al menos cada cinco aos) es parte del proceso de elaboracin de
normas ISO.
Las normas ISO relacionadas con la seguridad de la informacin y la ingeniera de
software:

ISO / IEC 15408 "Criterios para la evaluacin de

Seguridad de TI (Criterios Comunes)

La norma ISO / IEC 15408 es ms comnmente conocida como los criterios comunes y
es una serie de conjunto internacionalmente reconocido de directrices que definen un
marco comn para la evaluacin de las caractersticas de seguridad y capacidades de
los productos de seguridad de tecnologa de la informacin.

ISO / IEC 21827: 2008 " Ingeniera de Sistemas de Seguridad

Madurez de la Capacidad Modelo (SSE-CMM)

El estndar reconocido internacionalmente SSE-CMM proporciona directrices para

asegurar la ingeniera seguro de los sistemas (y software) mediante el aumento de las
reas de proceso de organizacin de proyectos y existentes y que abarca todas las
fases del SDLC en su mbito de aplicacin de los conceptos definicin, anlisis de
requerimientos, diseo, desarrollo, prueba, implementacin, operaciones,
mantenimiento y eliminacin. Tambin incluye orientacin sobre las mejores prcticas
para la interaccin con otras organizaciones, adquisiciones y certificacin y acreditacin
(C & A)

26
ISO / IEC 25000: 2005 " Calidad de Producto Ingeniera de Software
La norma ISO / IEC 25000: 2005 proporciona recomendaciones y una gua normativa
para el uso de la nueva serie de estndares internacionales de calidad indicada
software Requisitos de calidad del producto y Evaluacin (cuadrados).

ISO / IEC 27000: 2009 " Gestin de Seguridad de la Informacin del Sistema
(ISMS) Descripcin y Vocabulario
Esta norma tiene como objetivo proporcionar un glosario comn de trminos y
definiciones. Tambin proporciona una visin general e introduccin a la familia de
normas de SGSI que cubre
1 definicin de los requisitos para un SGSI
2 una gua detallada para interpretar el Plan-Do-Check-Act (PDCA) Procesos
3 directrices especficas del sector y las evaluaciones de conformidad ISMS.

ISO / IEC 27001: 2005 " Seguridad de la Informacin

Requisitos de los sistemas de gestin

ISO / IEC 27001: 2005 especifica los requisitos para establecer, implementar, operar,
monitorear, revisar, mantener y mejorar un SGSI documentado. Se puede utilizar para
ayudar en:
1 la formulacin de los requisitos de seguridad,
2 garantizar el cumplimiento legal, regulatorios y de cumplimiento
externas requisitos y con las polticas internas, directivas y normas,
3 gestin de riesgos de seguridad de manera rentable,
4 generar y seleccionar los requisitos de los controles de seguridad que va
a abordar de manera adecuada los riesgos de seguridad.
5 identificar procesos ISMS existentes y definir otros nuevos

ISO / IEC 27002: 2005 / Cor1: 2007 " Cdigo de buenas

prcticas para la Gestin de Seguridad de la Informacin

27
Podra decirse que este es el estndar de seguridad ms conocida y tiene por objeto
proporcionar una base comn y pautas prcticas para el desarrollo de estndares de
seguridad de la organizacin y de seguridad eficaz Prcticas de manejo.

Esta norma establece las directrices y principios generales para iniciar, implementar,
mantener y mejorar la gestin de seguridad de la informacin en una organizacin.

En l se esbozan varias de las mejores prcticas de los objetivos de control y controles

en diversas reas de gestin de seguridad de la informacin, que van desde la poltica
de seguridad, la organizacin de seguridad de la informacin, gestin de activos,
recursos humanos, fsicos y la seguridad del medio ambiente, control de acceso,
gestin de las comunicaciones y operaciones, la gestin de la continuidad del negocio,

ISO / IEC 27006: 2007 " Requisitos para

rganos de auditora y certificacin de
Sistemas de Gestin de Seguridad de la Informacin

Este objetivo principal de esta norma es apoyar acreditacin y certificacin de que los
cuerpos de auditora y certificacin de sistemas de gestin de seguridad de
informacin.

Incluye en ella los requisitos de competencia y fiabilidad que una auditora y

certificacin deben demostrar y tambin proporciona orientacin sobre cmo interpretar
los requisitos que contiene para asegurar una certificacin fiable y consistente de los
Sistemas de Gestin de Seguridad de la Informacin.

Normas pci

Industria de Tarjetas de Pago Estndar de Seguridad de Datos (PCI DSS)

Con el predominio del comercio electrnico y la computacin web en este da y edad,
es muy poco probable que aquellos que estn comprometidos con el negocio que

28
transmite y procesa la informacin de las tarjetas de pago ya no han sido inundados
con los requisitos de PCI, ms en particular la norma PCI DSS. Originalmente
desarrollado por American Express, Discover Financial Services, JCB International,
MasterCard

Construir y mantener una red segura

Proteger a los Titulares de Tarjeta
Mantener un programa de gestin de vulnerabilidades
Implementar medidas de control de acceso Fuertes
Regularmente Monitorear y redes de prueba
Mantener una poltica de seguridad de la informacin

Requisitos de las PCI DSS 6: Desarrollar y mantener sistemas y aplicaciones seguras

1 De que todos los componentes y el software del sistema tienen los ltimos
parches de seguridad instalados vendedor
suministrado. Instalar crtico seguridad parches dentro uno mes de la
liberacin.

2 Establecer un proceso para identificar las vulnerabilidades de seguridad

recientemente descubiertas (por ejemplo, suscripciones de alerta) y normas de
configuracin de actualizacin para solucionar otro problema de
vulnerabilidad.

3 Desarrollar aplicaciones de software de acuerdo con las mejores prcticas de

la industria (por ejemplo, la validacin de entrada, el control de errores de
autenticacin seguro, seguro, seguro de criptografa, comunicaciones seguras,
de registro, etc.), e incorporar seguridad de la informacin en todo el ciclo de
vida del software de desarrollo.

4 Siga los procedimientos de control de cambios para todos los cambios en los
componentes del sistema.

29
5 Desarrollar todas las aplicaciones web basadas en las directrices de
codificacin segura (como OWASP) para cubrir las vulnerabilidades de
codificacin comunes en el desarrollo de software.

6 Para las aplicaciones web pblicas, frente a las nuevas amenazas y

vulnerabilidades de forma continua y asegurar que estas aplicaciones estn
protegidas contra ataques conocidos por cualquiera de la revisin de estas
aplicaciones al ao o en el momento del cambio, el uso de herramientas de
evaluacin de seguridad manuales o automatizados o mtodos, o mediante la
instalacin de una red firewall de aplicaciones frente a la aplicacin web de
cara al pblico.

Aplicaciones de Pago Estndar de Seguridad de Datos (PA-DSS)

El PA-DSS fue creado por la Tarjeta de Pago Security Standards Council Industria para
ayudar a los Asesores de Seguridad Calificados (QSA) cuando se realizan exmenes
de la aplicacin de pago. QSA puede utilizar el PA-DSS para validar que su solicitud de
pago que estn evaluando es compatible con la norma PCI DSS, ya que sirve como
una plantilla para crear el informe de validacin. Lo que sola ser conocido
anteriormente como las mejores prcticas de aplicacin de pago (PABP).

Algunas de las formas en que una aplicacin de pago puede impedir el cumplimiento
del cliente es si la aplicacin de pago requiere que el cliente:
1 almacenar los datos de banda magntica y / o datos equivalentes en el chip
en la red y despus de la autorizacin.
2 desactivar las funciones de proteccin, tales como el software antivirus o
cortafuegos con el fin de conseguir la aplicacin de pago puede trabajar.
Organizacin para el Avance de Estndares de Informacin Estructurada (OASIS)

La Organizacin para el Avance de consorcio Estructurado Normas de Informacin

(OASIS) impulsa el desarrollo, la convergencia y la adopcin de estndares abiertos
para la sociedad global de la informacin.
30
Promueve consenso de la industria y produce estndares para la seguridad, el cloud
computing, las arquitecturas orientadas a servicios (SOA), servicios Web, la red
inteligente, etc.

Beneficios de Estndares de Seguridad

Normas de seguridad proporcionan una base comn y coherente para la construccin y
mantenimiento de software seguro, ya que permiten la eficiencia operativa y la agilidad
de la organizacin.

Dicen que todo el software desarrollado en su organizacin se ha desarrollado

utilizando el entonces estndar para la funcin de cifrado DES y que era ahora su
organizacin requiere la totalidad de su software para utilizar el AES. En tal escenario,
el esfuerzo para cambiar sobre puede ser abordado de manera consistente y eficiente
a travs de diversos equipos de software en su organizacin, ya que no hay software
propietario o no estndar que requiere atencin especializada.

Mejores prcticas
Adems de las normas, existen varias de las mejores prcticas para la seguridad de la
informacin que son importantes para un profesional de seguridad a tener en cuenta.

Abrir Web Application Security Project (OWASP)

El Proyecto Open Web Application Security es una comunidad libre y abierto en todo el
mundo que se centra en la seguridad de aplicaciones y seguridad de las aplicaciones
web en su mayor parte.

Puede ser considerada como la mejor prctica que conduce a la seguridad de

aplicaciones web.

La gua de desarrollo OWASP

31
Este es un manual completo para el diseo, desarrollo y despliegue de aplicaciones y
servicios web seguros. El pblico objetivo de esta gua son los arquitectos,
desarrolladores, consultores y auditores.

Esta gua cubre los diversos controles de seguridad que los desarrolladores de
software deben construir en el software que disean y se desarrollan.

La Gua para la evaluacin Cdigo de OWASP

Este es un manual completo para la comprensin de la forma de detectar
vulnerabilidades de las aplicaciones web en el cdigo y qu garantas se pueden tomar
para abordarlos. La gua dice en voz alta que para un proceso de revisin de cdigo
con xito, el revisor debe estar familiarizado con la siguiente
1 Lenguaje de Programacin (Cdigo)
2 conocimiento de software (Contexto) Trabajar
3 Los usuarios finales (la audiencia) y
4 Impacto de la disponibilidad del software para el negocio o la falta del mismo
(Importancia)

La realizacin de revisiones de cdigo para verificar la seguridad de aplicaciones es

mucho ms rentable que tener que probar el software de vulnerabilidades de
seguridad.
Information Technology Infrastructure Library (ITIL)
A pesar de la Biblioteca de Infraestructura de TI (ITIL) ha existido desde hace casi dos
dcadas, se est ganando aceptacin y popularidad y es considerado como el estndar
de facto para la gestin del servicio. Fue desarrollado por la Agencia Central de
Informtica y de Telecomunicacin (ACTC) en el Reino Unido. Para una organizacin
que sea eficaz, debe ser capaz de entregar a la empresa, el nivel esperado de servicio,
haciendo funcionar dentro de las limitaciones de alcance, cronograma y
presupuesto. Entregar valor de negocio mediante el cumplimiento de la empresa

32
Acuerdos de nivel de servicio (SLA) se ve reforzada cuando la organizacin adopte un
marco que incluye las mejores prcticas y estndares en la gestin del servicio. La ITIL
es un marco de mejores prcticas de cohesin que se desarroll originalmente en
alineacin con la norma continuacin del Reino Unido.

Metodologas de desarrollo de software

El desarrollo de software es un proceso estructurado y metdico que requiere la

interaccin de las personas conocimientos, procesos y tecnologas. El Ciclo de Vida de
Desarrollo de Software (SDLC) a menudo se divide en varias fases que son o bien
secuencial o en paralelo.
1 modelo de cascada
Modelo cascada
El modelo de cascada es uno de los ms tradicionales de modelos de desarrollo de
software todava est en uso hoy en da. Es un muy estructurado, proceso lineal y
secuencial en fase caracterizada por fases predefinidas, cada una de las cuales se
deben completar antes de poder pasar a la siguiente fase. As como el agua puede fluir
en una sola direccin por una cascada, una vez a la fase en el modelo de cascada se
ha completado, no se puede volver a esa fase

El modelo de cascada es til para proyectos de software a gran escala, ya que aporta
estructura por fases en el proceso de desarrollo de software. El Instituto Nacional de
Estndares y Tecnologa (NIST) Publicacin Especial 800-64 1d REV, que cubre un
Consideraciones Seguridad en el Desarrollo de Sistemas de Informacin ciclo de vida ,
rompe el modelo de cascada SDLC lineal en cinco fases genricas: iniciacin,
adquisicin / desarrollo , implementacin / evaluacin, las operaciones / mantenimiento
y la puesta del sol.

CONCLUSIN

33
Al concluir con este trabajo esperamos haber dejado de forma clara y especifica la
importancia de contar con software seguros.

Un programa de seguridad no solo ayuda a prevenir los accidentes que puedan ocurrir
en la organizacin si no que protege a la organizacin de una serie de consecuencias a
mediano y largo plazo derivadas de los accidentes.

Una empresa debe contar con un programa de seguridad no por los daos futuros que
le podran ocasionar o por las prdidas econmicas sino ms bien porque toda
empresa cuanta con una responsabilidad social es decir se sienten responsables por la
seguridad de sus trabajadores.

Siempre considerando y poniendo en prcticas las normas, guas y estndares que

deben seguirse para conservar la integridad, confiabilidad etc. del desarrollo de
software.

La poltica de seguridad proporciona el marco y el punto de referencia que puede

usarse para medir la postura de seguridad de una organizacin. Las brechas que se
identifican cuando se miden frente a una poltica de seguridad, un punto de referencia
coherente, pueden utilizarse para determinar la estrategia y las decisiones ejecutivas
efectivas

34
 BIBLIOGRAFA

https://es.wikipedia.org/wiki/Seguridad_de_la_informaci%C3%B3n seguridad de
informacin

https://translate.google.com/translate?hl=es-
419&sl=en&u=https://www.isc2.org/csslp&prev=search

Libro: Gua Oficial para CSSLP (CBK). (ISC). Mano Paul. Segunda Edicin. Ao
2014.

35