seguridad software

7/16/2019 Seguridad Software

http://slidepdf.com/reader/full/seguridad-software 1/9

ITSP

ISC Página 1

INSTITUTO TECNOLÓGICO SUPERIO PROGRESO

INGENIERÍA DE SOFTWARE

MAESTRA:

ING. LIGIA BEATRIZ CHUC US

ALUMNOS:

CANUL KANTUN RODRIGO

CRUZ MENDOZA GAEL

DOMINGUEZ MENESES EDUARDO

INVESTIGACIÓN:

SEGURIDAD EN INGENIERIA DE SOFTWARE

30 DE MAYO DEL 2013



ITSP

ISC Página 2

Contenido

4.1 Seguridad de software .................................................................................................................. 3

4.2 Seguridad en el ciclo de desarrollo del software .......................................................................... 3

4.3 Confiabilidad del software ............................................................................................................ 5

4.4 Ingeniería de seguridad ................................................................................................................. 6

Conclusiones ....................................................................................................................................... 8

Referencias .......................................................................................................................................... 9

Bibliografías........................................................................................................................................ 9



ITSP

ISC Página 3

4.1 Seguridad de software

Es una actividad de garantía de calidad del software que se centra en la identificación y

evaluación de los riesgos potenciales que pueden producir un impacto negativo en el

software y hace que falle el sistema completo. Si se puede identificar pronto los riesgos en

el proceso de ingeniería del software podrán especificarse las características del diseño delsoftware que permitan eliminar o controlar los riesgos potenciales.

Como parte de la seguridad, se puede dirigir un proceso de análisis y modelado. Seidentifican los riesgos y estos se clasifican por su importancia y un grado de riesgo. Cuando

los riesgos en el sistema, se utilizan técnicas de análisis para asignar su gravedad y su

probabilidad de ocurrencia. Para que esto sea efectivo se tiene que analizar el software en elcontexto del sistema completo.

Una vez que se identificado y analizado los riesgos se pueden especificar los requisitosrelacionados con la seguridad para el software. Esto es, la especificación puede contener

una lista de eventos no deseables y las repuestas del sistema a estos eventos.

La seguridad del software examina los modos según los cuales los fallos producen

condiciones que pueden llevar a accidentes. Es decir, los fallos no se consideran en vacío,

sino que se evalúan en el contexto de un completo sistema basado en computadora.

4.2 Seguridad en el ciclo de desarrollo del software

Generalmente, la seguridad en el desarrollo software no está enfocada desde una

perspectiva holística. La razón raíz es que en la mayoría de los casos la seguridad se

establece al final del ciclo del proyecto como consecuencia de la aparición de una nueva

amenaza o de un nuevo riesgo. Por tanto, estas urgencias desembocan en la búsqueda desoluciones que no atienden al sistema en su conjunto (interacción en entre sistemas).

Si tenemos en cuenta que estudios realizados apuntan a que más del 70% de las

vulnerabilidades de seguridad existentes provienen de la capa de aplicaciones, es un motivo

más que suficiente para preocuparse y ponerse manos a la obra.

Por este motivo, se oye cada más de la integración de la seguridad en el ciclo de desarrollo

de software (SDLC). Existen varias metodologías y certificaciones (ASAP, ISECOM,CSSLP, etc.) e incluso hay quien desarrolla sus propios métodos.

Teniendo todos en común, el tener en cuenta todo el ciclo de desarrollo, desde el análisishasta la puesta en servicio, pasando por los test y cerrando el ciclo con la fase de soporte y

mejora del sistema. En cualquier caso, la característica común más importante de todas

ellas, es sin duda alguna, un enfoque sistémico que les permite analizar el sistema en suconjunto.



ITSP

ISC Página 4

Seguridad en el análisis de requerimientos

En esta etapa, se deben identificar aquellos requerimientos funcionales que tendrán impacto

en los aspectos de seguridad de la aplicación. Algunos de ellos son: requerimientos de

compliance con normativas locales o internacionales (ej: PCI, SOX, “A” 4609, etc.), tipo de

información que se transmitirá o procesará (ej.: Información pública o confidencial, datos personales, datos financieros, contra-señas, datos de pago electrónico, etc.) y

requerimientos de registros de auditoría (ej.: Qué debe registrar la aplicación en sus Logs).

Seguridad en el diseño

Antes de comenzar a escribir líneas de código, hay numerosos aspectos de seguridad que

deben ser tenidos en cuenta durante de la aplicación. Algunos de ellos son: diseño de

autorización (ej.: Definir los roles, permisos y privilegios de la aplicación), diseño

autenticación (aquí se debe diseñar el modo en el que los usuarios se van a autenticar,contemplando aspectos tales como los mecanismos o factores de autenticación con

contraseñas, tokens, certificados, etc. posibilidades de integrar la autenticación conservicios externos como LDAP, Radius o Active Directory y los mecanismos que tendrá la

aplicación para evitar ataques de diccionario o de fuerza bruta (ej.: bloqueo de cuentas,implementación de “captchas”, etc.), diseño de los mensajes de error y advertencia, para

evitar que los mismos brinden demasiada información y que ésta sea utilizada por atacantes

y diseño de los mecanismos de protección de datos (aquí se debe contemplar el modo en elque se protegerá la información sensible en tránsito o almacenada; según el caso, se puede

definir la implementación de encripción, hashes o truncamiento de la información).Una vez

que se cuenta con el diseño detallado de la aplicación, una práctica interesante es la de

realizar sobre el mismo un análisis de riesgo orientado a software. Existen técnicasdocumentadas al res-pecto, tales como Threat Modeling. Estas técnicas permiten definir un

marco para identificar debilidades de seguridad en el software, antes de la etapa decodificación. Como valor agregado, del análisis de riesgo orientado a software se puedenobtener casos de prueba para ser utilizados en la etapa de Testing/QA.

Seguridad en la codificación

Una vez concluido el diseño, le toca a los desarrolladores el turno de codificar los distintoscomponentes de la aplicación. Es en este punto en donde suelen incorporarse, por error u

omisión, distintos tipos de vulnerabilidades. Estas vulnerabilidades podríamos dividirlas en

dos grandes grupos a saber: vulnerabilidades clásicas y vulnerabilidades funcionales. Las

primeras son bien conocidas y categorizadas. Como así también otras vulnerabilidades no

ligadas directamente con las aplicaciones WEB, como desbordamiento de buffer,denegación de servicio.

Los Frameworks de desarrollo de aplicaciones son una buena ayuda en este punto, ya que

ofician de intermediario entre el programador y el código, y permiten prevenir la mayoría

de las vulnerabilidades conocidas. Vulnerabilidades funcionales son aquellas ligadasespecíficamente a la funcionalidad de negocio que posee la aplicación, por lo que no están

previamente categorizadas.



ITSP

ISC Página 5

En la etapa de codificación, una de las reglas de oro es verificar todos los valores de entrada

y de salida. Esto es, asumir siempre que el valor pudo haber sido manipulado o ingresado

maliciosamente antes de ser procesado.

Testing / QA de seguridad

Tradicionalmente, la labor del equipo de Testing/QA fue la de encontrar y reportar errores

funcionales de la aplicación. Para esto, se desarrollan casos de test basados en la

funcionalidad esperada. A esto denominamos testing funcional y básicamente consiste envalidar que la aplicación haga lo que se esperaba que hiciera. Sucede que habitualmente

hay un desfasaje entre el diseño original de la aplicación (lo que se espera que haga) y la

implementación real (lo que realmente hace).

Aquí surgen 3 áreas bien definidas: lo que fue definido y la aplicación hace, lo que fue

definido y la aplicación no hace (errores funcionales) y lo que no fue definido pero laaplicación hace. Es en este último grupo, en donde habitualmente están las

vulnerabilidades, y el testing funcional clásico no es capaz de encontrarlas. Por este motivose necesitan nuevas técnicas para explorar lo desconocido.

El testing de seguridad se basa principalmente en probar la aplicación con escenarios no

planificados, incluyendo valores mutados, fuera de rango, de tipo incorrecto omalformados, acciones fuera de orden, etc. Existen herramientas automáticas que pueden

ayudar al analista de QA en la búsqueda de errores. Las mismas son útiles por su velocidad

y capacidad de automatización, pero pueden causar falsos positivos, y por lo general no son buenas detectando vulnerabilidades funcionales. Es por esto que los mejores resultados

resultan de la combinación de técnicas automáticas y manuales.

Implementación / Puesta en producción

Una mala configuración al momento de implementar la aplicación podría echar por tierratoda la seguridad de las capas anteriores. Tanto la aplicación como el software de base

deben configurarse de manera segura al momento de poner el software en producción. En

este punto se deben contemplar tareas tales como: cambio de usuarios y contraseñas

iniciales o por defecto, borrado de datos de prueba y cambio de permisos de acceso. Estambién importante mantener una correcta separación de los ambientes de desarrollo,

testing y producción y procedimientos de traspaso seguro de uno a otro de estos ambientes.

4.3 Confiabilidad del software

La confiabilidad es un atributo que mide el grado en que un producto opera sin fallas bajocondiciones establecidas por un periodo de tiempo determinado. La confiabilidad es un

atributo cuantitativo que ha sido ampliamente analizado, estudiado y usado en otras

industrias para caracterizar la calidad de los productos o servicios.



ITSP

ISC Página 6

En su concepción más general, la confiabilidad es un atributo que mide el grado en que un

producto opera sin fallas bajo condiciones establecidas por un periodo de tiempo

determinado. Una falla es la manifestación percibida por el cliente de que algo no funcionacorrectamente e impacta su percepción de la calidad. Un defecto es el problema en el

producto de software que genera una falla.

La confiabilidad de software significa que un programa particular debe de seguir

funcionando en la presencia de errores. Los errores pueden ser relacionados al diseño, a la

implementación, a la programación, o el uso de errores. Así como los sistemas llegan a ser cada vez más complejos, aumenta la probabilidad de errores. Como mencionamos, es

increíblemente difícil demonstrar que un sistema sea seguro. Ross Anderson dice que la

seguridad de computación es como programar la computadora del Satan. Software segurodebe de funcionar abajo de un ataque. Aunque casi todos los software tengan errores, la

mayoría de los errores nunca serán revelados debajo de circunstancias normales. Un

atacante busca esta debilidad para atacar un sistema.

4.4 Ingeniería de seguridad

Auditorías en seguridad:

Las auditoriías en seguridad son una evaluación del conjunto de elementos relativos a la

seguridad de un sitio o de una organización. La auditoría se concentra en el análisis integral

del dispositivo de seguridad existente. Permite construir un diagnóstico y formular

recomendaciones con el fin de elevar el nivel de seguridad. Puede referirse a la localidad

física de la empresa (o de sus filiales) así como a sus sucursales, almacenes, obras,

localidades de estancia en el extranjero de ejecutivos y personal.

Generalmente limitado a la seguridad física (infraestructura, control de acceso, servicio deguardias, video vigilancia, etc.), el rango de la auditoría puede extenderse a la organización

y a la administración de la seguridad en el seno de la empresa.

Plan general de seguridad:

El plan general de seguridad es el documento que especifica todos los elementos relativos a

la seguridad de un sitio o de una organización. Se trata de un documento metodológico con

una estructura didáctica que brinda al director de la empresa una visión integral de su

dispositivo de seguridad. Además, retoma el conjunto de procedimientos de seguridad y

organización general del sitio.

Plan de gestión de crisis:

El plan de gestión de crisis reúne los procedimientos a seguir por parte de la dirección de la

empresa en el caso de que se desencadene una crisis. Este plan define de manera precisa las

acciones que se deben llevar a cabo para manejar cada etapa de las crisis en sus tres

dimensiones (administrativa, operacional y de comunicación).



ITSP

ISC Página 7

Plan de continuación de las actividades:

Este documento complementario al plan de gestión de crisis establece los procedimientos a

aplicar con para preservar la actividad y el funcionamiento de la empresa en condiciones de

crisis. El plan de continuación de actividades, que establece una organización y

procedimientos específicos, funge como guía para que la dirección de la empresa puedaasegurar su retorno a un funcionamiento normal.



ITSP

ISC Página 8

Conclusiones

Rodrigo Canul

LA seguridad se debe aplicar en todo momento ya que con ello podemos ahorrar muchosrecursos en vez de desperdiciarlos hay que tomar en en cuenta en todo momento los que

nos puede causar muchos problemas.

Gael Cruz

La seguridad en las aplicaciones de software debe abordarse desde el primer día del proceso

de desarrollo y a lo largo de todas las etapas del mismo. En cada una de estas etapas, se

pueden realizar diversas actividades que en su conjunto ayudarán a aumentar la seguridad

de la aplicación de software que se está desarrollando.

Eduardo Domínguez

La seguridad no siempre debe tomarse en cuenta ya que es indispensable en todo el

proyecto del software se debe sacar todo lo que puede ocasionar problemas al a software y

atacarlo cuando aún hay tiempo.



ITSP

ISC Página 9

Referencias

http://www.softwareseguridad.com/queesunsoftwaredeseguridad.html

http://www.slideshare.net/injcristianrojas/seguridad-de-software-una-introduccin-13414276

http://www.indracompany.com/sostenibilidad-e-innovacion/neo/blog/articulo/ingenieria-

de-software-seguro

http://www.prensariotila.com/pdf/TutorialCybsec_0710.pdf

http://www.equipom45.es/m45blog/25-seguridad/144-seguridad-en-el-ciclo-de-desarrollo-

software.html

http://grupoirena.com/index.php?option=com_content&view=article&id=72&Itemid=215

http://sg.com.mx/content/view/271

Bibliografías

Nombre: Ingeniería del software un ejemplo practico

Edición: Quinta edición

Autor: Roger S. PressmanCasa editorial: McGrawHill

Número de páginas: 601 paginas

Año de edición: 2002

Nombre: Ingeniería del software un ejemplo practico

Edición: séptima edición

Autor: Roger S. PressmanCasa editorial: McGrawHill

Número de páginas: 756 paginas

Año de edición: 2005





http://www.indracompany.com/sostenibilidad-e-innovacion/neo/blog/articulo/ingenieria-de-software-seguro





http://www.equipom45.es/m45blog/25-seguridad/144-seguridad-en-el-ciclo-de-desarrollo-software.html
















seguridad software

Documents