ALGORITMOS DE

ENCRIPTACION

ING de software.
Algoritmos de encriptacin.

Para poder Encriptar un dato, se pueden utilizar tres procesos matemticos diferentes:
Los algoritmos HASH, los simtricos y los asimtricos.

1. Algoritmo HASH:

Este algoritmo efecta un clculo matemtico sobre los datos que constituyen el documento y da
como resultado un nmero nico llamado MAC. Un mismo documento dar siempre un mismo
MAC.

2. Criptografa de Clave Secreta o Simtrica

Utilizan una clave con la cual se encripta y desencripta el documento. Todo documento encriptado
con una clave, deber desencriptarse, en el proceso inverso, con la misma clave. Es importante
destacar que la clave debera viajar con los datos, lo que hace arriesgada la operacin, imposible
de utilizar en ambientes donde interactan varios interlocutores.

Los criptosistemas de clave secreta se caracterizan porque la clave de cifrado y la de descifrado es
la misma, por tanto la robustez del algoritmo recae en mantener el secreto de la misma.
Sus principales caractersticas son:
rpidos y fciles de implementar
clave de cifrado y descifrado son la misma
cada par de usuarios tiene que tener una clave secreta compartida
una comunicacin en la que intervengan mltiples usuarios requiere muchas claves
secretas distintas
Actualmente existen dos mtodos de cifrado para criptografa de clave secreta, el cifrado de flujo y
el cifrado en bloques.
Cifrado de flujo
El emisor A, con una clave secreta y un algoritmo determinstico (RKG), genera una secuencia
binaria (s) cuyos elementos se suman mdulo 2 con los correspondientes bits de texto claro m,
dando lugar a los bits de texto cifrado c, Esta secuencia (c) es la que se enva a travs del canal. En
recepcin, B, con la misma clave y el mismo algoritmo determinstico, genera la misma secuencia
cifrante (s), que se suma modulo 2 con la secuencia cifrada (c) , dando lugar a los bits de texto
claro m.
Los tamaos de las claves oscilan entre 120 y 250 bits

Cifrado en bloque
Los cifrados en bloque se componen de cuatro elementos:
- Transformacin inicial por permutacin.
- Una funcin criptogrfica dbil (no compleja) iterada r veces o "vueltas".
- Transformacin final para que las operaciones de encriptacin y desencriptacin sean simtricas.
- Uso de un algoritmo de expansin de claves que tiene como objeto convertir la clave de usuario,
normalmente de longitud limitada entre 32 y 256 bits, en un conjunto de subclaves que puedan
estar constituidas por varios cientos de bits en total.
3. Algoritmos Asimtricos (RSA):

Requieren dos Claves, una Privada (nica y personal, solo conocida por su dueo) y la otra llamada
Pblica, ambas relacionadas por una frmula matemtica compleja imposible de reproducir. El
concepto de criptografa de clave pblica fue introducido por Whitfield Diffie y Martin Hellman a
fin de solucionar la distribucin de claves secretas de los sistemas tradicionales, mediante un canal
inseguro. El usuario, ingresando su PIN genera la clave Publica y Privada necesarias. La clave
Publica podr ser distribuida sin ningn inconveniente entre todos los interlocutores. La Privada
deber ser celosamente guardada. Cuando se requiera verificar la autenticidad de un documento
enviado por una persona se utiliza la Clave Publica porque el utiliz su Clave Privada.

Seguridad en los productos de SW.

La mayor parte de las organizaciones desarrolla o contrata el desarrollo de aplicaciones propias
para su gestin de negocio. Como todo software, estas aplicaciones pueden contener fallas de
seguridad y a diferencia del software comercial, no se dispone de actualizaciones o parches
liberados en forma peridica por el fabricante. El tratamiento de las vulnerabilidades en
aplicaciones propias corre por parte de la organizacin que las desarrolla.


SEGURIDAD EN EL ANLISIS DE REQUERIMIENTOS
En esta etapa, se deben identificar aquellos requerimientos funcionales que tendrn impacto en
los aspectos de seguridad de la aplicacin. Algunos de ellos son: requerimientos de compliance
con normativas locales o internacionales (ej: PCI, SOX, A 4609, etc.), tipo de informacin que se
transmitir o procesar (ej: Informacin pblica o confidencial, datos personales, datos
financieros, contraseas, datos de pago electrnico, etc.) y requerimientos de registros de
auditora (ej: Qu debe registrar la aplicacin en sus Logs).



SEGURIDAD EN EL DISEO
Antes de comenzar a escribir lneas de cdigo, hay numerosos aspectos de seguridad que deben
ser tenidos en cuenta durante el diseo de la aplicacin. Algunos de ellos son: diseo de
autorizacin

(ej: Definir los roles, permisos y privilegios de la aplicacin), diseo de autenticacin (aqu se debe
disear el modo en el que los usuarios se van a autenticar, contemplando aspectos tales como los
mecanismos o factores de autenticacin con contraseas, tokens, certificados, etc. posibilidades
de integrar la autenticacin con servicios externos como LDAP, Radius o Active Directory y los
mecanismos que tendrla aplicacin para evitar ataques de diccionario o de fuerza bruta
(ej:bloqueo de cuentas, implementacin de captchas, etc.), diseo de losmensajes de error y
advertencia, para evitar que los mismos brinden demasiada informacin y que sta sea utilizada
por atacantes y diseo de los mecanismos de proteccin de datos (aqu se debe contemplar el
modo en el que se proteger la informacin sensible en trnsito o almacenada; segn el caso, se
puede definir la implementacin de encripcin, hashes o truncamiento de la informacin).

Una vez que se cuenta con el diseo detallado de la aplicacin, una prctica interesante es la de
realizar sobre el mismo un anlisis de riesgo orientado a software. Existen tcnicas documentadas
al respecto, tales como Threat Modeling. Estas tcnicas permiten definir un marco para identificar
debilidades de seguridad en el software, antes de la etapa de codificacin. Como valor agregado,
del anlisis de riesgo orientado a software se pueden obtener casos de prueba para ser utilizados
en la etapa de Testing/QA.

SEGURIDAD EN LA CODIFICACIN

Una vez concluido el diseo, le toca a los desarrolladores el turno de codificar los distintos
componentes de la aplicacin. Es en este punto en donde suelen incorporarse, por error u
omisin, distintos Por Pablo Milano,Consultor Cybsec 64Tutorial 65 tipos de vulnerabilidades.
Estas vulnerabilidades podramos dividirlas en dos grandes grupos a saber: vulnerabilidades
clsicas y vulnerabilidades funcionales. Las primeras son bien conocidas y categorizadas.

Ejemplo de estas vulnerabilidades son las presentes en el OWASP




Top 10 (Vulnerabilidades de inyeccin, Cross Site Scripting, errores en manejo de sesiones, etc.)

como as tambin otras vulnerabilidades no ligadas directamente con las aplicaciones WEB, como
desbordamiento de buffer, denegacin de servicio, etc. Los Frameworks de desarrollo de
aplicaciones son una buena ayuda en este punto, ya que ofician de intermediario entre el
programador y el cdigo, y permiten prevenir la mayora de las vulnerabilidades conocidas.
Ejemplos de estos frameworks son Struts, Ruby on Rails y Zope.

Vulnerabilidades funcionales son aquellas ligadas especficamente a la funcionalidad de negocio
que posee la aplicacin, por lo que no estn previamente categorizadas. Algunos ejemplos
ilustrativosde este tipo de vulnerabilidad son los siguientes: una aplicacin de banca electrnica
que permite realizar transferencias con valores negativos, un sistema de subastas que permite ver
los valores de otros oferentes, un sistema de venta de entradas para espectculos que no impone
lmites adecuados a la cantidad de reservas que un usuario puede hacer.
En la etapa de codificacin, 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 aplicacin. Para esto, se desarrollan casos de test basados en la funcionalidad
esperada.

A esto denominamos testing funcional y bsicamente consiste en validar que la aplicacin haga
lo que se esperaba que hiciera. Sucede que habitualmente hay un desfasaje entre el diseo
original

De la aplicacin (lo que se espera que haga) y la implementacin real (lo que realmente hace).
Aqu surgen 3 reas bien definidas: lo que fue definido y la aplicacin hace, lo que fue definido y la

Aplicacin no hace (errores funcionales) y lo que no fue definido pero la aplicacin hace.

Es en este ltimo grupo, en donde habitualmente estn las vulnerabilidades, y el testing funcional
clsico no es capaz de encontrarlas.

Por este motivo se necesitan nuevas tcnicas para explorarlo desconocido. El testing de seguridad
se basa principalmente en probar la aplicacin con escenarios no planificados, incluyendo valores
mutados, fuera de rango, de tipo incorrecto o mal formados, acciones fuera de orden, etc.

Existen herramientas automticas que pueden ayudar al analista de QA en la bsqueda de errores.
Las mismas son tiles por su velocidad y capacidad de automatizacin, 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 combinacin de tcnicas automticas y
manuales.

IMPLEMENTACIN / PUESTA EN PRODUCCIN
Una mala configuracin al momento de implementar la aplicacin podra echar por tierra toda la
seguridad de las capas anteriores.

Tanto la aplicacin como el software de base deben configurarse de manera segura al momento
de poner el software en produccin.
Concepto de riesgo SW

*mapa mental.
Funcin de un Arquitecto de SW.

Arquitectura: Definicin de arquitectura de los sistemas, vista fsica, vista lgica, principios
de arquitectura, seguridad, etc.
Seleccin de Software: Pilas de aplicaciones, bases de datos, libreras, frameworks,
estndares tecnolgicos, etc.
Seleccin de Infraestructura: Sistemas Operativos, hardware, redes, sistemas de
recuperacin, etc.
Requisitos no Funcionales: Rendimiento, escalabilidad, seguridad, etc.
Liderazgo: Liderazgo Tcnico, responsabilidad y autoridad, direccin de equipos, etc.
Coaching y Mentoring: Ayuda sobre problemas tcnicos, ayuda en la evolucin
profesional, etc.
Metodologa de Proyectos: Estructura de Proyectos, Metodologas (Waterfall, Scrum, RUP,
XP...).
Procesos de Desarrollo: Control de versiones de cdigo fuente, procesos de construccin,
integracin continua, automatizacin de pruebas y otros procesos y herramientas de
desarrollo.
Prcticas y Estndares: Estndares de codificacin y libros blancos, seleccin de
herramientas, etc.
Diseo, Desarrollo y Pruebas: Diagramas UML, codificacin, pruebas unitarias, etc.
Experiencia: Conocimiento sobre tecnologas y arquitecturas.
Estar al da en cuanto a tendencias tecnolgicas: Agile, Web 2.0, SOA, Lightweight Java EE,
etc.


Riesgos en el desarrollo de SW.


Aunque ha habido amplios debates sobre la definicin adecuada para riesgo de sw, hay acuerdo
comn en que el riesgo siempre implica dos caractersticas:
1. Incertidumbre: El acontecimiento que caracteriza al riesgo puede o no puede ocurrir; por
ejemplo, no hay riesgos de un 100% de probabilidad (ya que un riesgo del 100% es una
limitacin del proyecto).

2. Prdida: Si el riesgo se convierte en una realidad, ocurrirn consecuencias no deseadas o
prdidas.
Riesgos del Proyecto
Amenazan al plan del proyecto, es decir, si los riesgos del proyecto se hacen realidad, es probable
que la planificacin temporal del proyecto se retrase y que los costos aumenten. Los riesgos del
proyecto identifican:
Problemas potenciales de presupuesto
Planificacin temporal
Personas (Asignacin y organizacin)
Recursos
Cliente, requerimientos y su impacto en el proyecto software
La complejidad del proyecto
Tamao y grado de incertidumbre estructural




Riesgos Tcnicos

Amenazan la calidad y la planificacin temporal del sw que hay que producir. Si un riesgo se
convierte en realidad, la implementacin puede llegar a ser difcil o imposible. Los riesgos tcnicos
identifican problemas potenciales de:
Diseo
Implementacin
De interfaz
Verificacin
Mantenimiento
Las ambigedades de especificaciones
Tecnologas
Los riesgos tcnicos ocurren porque el problema es ms difcil de resolver de lo que pensbamos.

Riesgos del Negocio

Amenazan la viabilidad del software a construir. Los riesgos del negocio a menudo ponen en
peligro el proyecto o producto. Los candidatos para los cinco principales riesgos del negocio son:
Construir un producto o sistema excelente que no quiere nadie en realidad (Riesgo de
Mercado).
Construir un producto que no encaja en la estrategia comercial general de la compaa
(Riesgo Estratgico).
Construir un producto que el departamento de ventas no sabe cmo vender.
Perder el apoyo de una gestin experta debida a cambios de enfoque o a cambios de
personal (Riesgo de Direccin).
Perder presupuesto o personal asignado (Riesgo de Presupuesto).
Es extremadamente importante recalcar que no siempre funciona una categorizacin tan sencilla.
Algunos riesgos pueden pertenecer a ms de una categora o simplemente imposibles de predecir.







La identificacin del riesgo es un intento sistemtico para especificar las amenazas al plan de
proyecto (estimaciones, planificacin temporal, cargo de recursos, etc.). Identificando los riesgos
conocidos y predecibles, el gestor del proyecto da un paso adelante para evitarlos cuando sea
posible y controlarlos cuando sea necesario.
Existen dos tipos diferenciados de riesgos para cada categora:
1. Riesgos Genricos: Son una amenaza potencial para todos los proyectos de software.
2. Riesgos especficos: Los riesgos especficos de producto slo los pueden identificar los que
tienen una clara visin de la tecnologa, el personal y el entorno especfico del proyecto en
cuestin, entre los que estn:

Tamao del producto: Riesgos asociados con el tamao general del software a construir o
a modificar.
Impacto en el negocio: Riesgos asociados con las limitaciones impuestas por la gestin o
por el mercado.
Caractersticas del cliente: Riesgos asociados con la sofisticacin del cliente y la habilidad
del desarrollador para comunicarse con el cliente en los momentos oportunos.
Definicin del proceso: Riesgos asociados con el grado de definicin del proceso del
software y su seguimiento para la organizacin de desarrollo.
Entorno de desarrollo: riesgos asociados con la disponibilidad y calidad de las herramientas
que se van a emplear en la construccin del producto.
Tecnologa a construir: Riesgos asociados con la complejidad del sistema a construir y la
tecnologa de punta que contiene el sistema.
Tamao y experiencia de la plantilla: Riesgos asociados con la experiencia tcnica y de
proyectos de los ingenieros de sw que van a realizar el trabajo.


Componentes y controladores del riesgo
En el contexto de este estudio, los componentes del riesgo se definen de la siguiente
manera:
Riesgo de rendimiento: el grado de incertidumbre con el que el producto encontrar sus
requerimientos y se adecue para su empleo pretendido.
Riesgo de costo: El grado de incertidumbre que mantendr el presupuesto del proyecto.
Riesgo de soporte: El grado de incertidumbre de la facilidad del sw. para corregirse,
adaptarse y ser mejorado.
Riesgo de la planificacin temporal: El grado de incertidumbre con que se podr mantener
la planificacin temporal y de que el producto se entregue a tiempo.
El impacto de cada controlador de riesgo en el componente de riesgo se divide en cuatro
categoras de impacto:


1.- Despreciable 2.- Marginal 3.- Crtico 4.- Catastrfico

La siguiente figura indica las consecuencias potenciales de errores (filas etiquetadas con 1) o la
imposibilidad de conseguir el producto deseado (filas etiquetadas con 2). La categora de impacto
es elegida basndose en la caracterizacin que mejor encaja con la descripcin de la tabla

Figura: Categora versus componentes
Rendimiento Soporte Costo Planificacin
Temporal
Catastrfico
1
Dejar de cumplir los
requerimientos provocara fracaso
de la misin.
Malos resultados en un aumento de
costos y retrasos de la planificacin
temporal con cifras que superan los
US$500.000.
2
Degradacin
significativa para
no poder
alcanzar el
rendimiento
tcnico.
El software no
responde o no
admite
soporte.
Recortes
financieros
significativos,
presupuestos
excedidos.
Fecha de entrega
inalcanzable.
Crtico
1
Dejar de cumplir los
requerimientos degradara el
rendimiento del sistema hasta un
punto donde el xito de la misin
es cuestionable.
Malos resultados en retrasos
operativos y/o aumento de costo con
valor esperado de US$100.000 a
US$500.000.
2
Alguna
disminucin en
el rendimiento
tcnico.
Pequeos
retrasos en
modificaciones
de sw.
Algunos recortes
de los recursos
financieros,
posibles excesos
del presupuesto.
Posibles retrasos
de la fecha de
entrega.
Marginal
1
Dejar de cumplir los
requerimientos provocara la
degradacin de la misin
secundaria.
Los costos, impactos y/o retrasos
recuperables de la planificacin
temporal con un valor estimado de
US$1000 a US$100.000.
2
De mnima a
pequea
reduccin en el
EL soporte del
software no
responde.
Recursos
financieros
suficientes.
Planificacin
temporal realista,
alcanzable.
rendimiento
tcnico.
Despreciable
1
Dejar de cumplir los
requerimientos provocara
inconvenientes o impactos no
operativos.
Los errores provocan impactos
mnimos en el costo y/o planificacin
temporal con un valor esperado de
menos de US$1000.
2
No hay reduccin en
el rendimiento
tcnico.
Software
fcil de
dar
soporte.
Posible supervit
de presupuesto.
Fecha de entrega
fcilmente
alcanzable.



Seguridad y fiabilidad.

Seguridad (Safety): ausencia de situaciones que puedan causar muertes, heridas, enfermedades
o daos en los equipos y en el medio ambiente.
O la mayora de los sistemas que tienen algn elemento de riesgo asociado a su uso son inseguros
(unsafe). O Un accidente (mishap) es un suceso imprevisto que puede producir daos
inadmisibles
Fiabilidad (reliability) una medida del xito con el cual un sistema se ajusta a alguna
especificacin autorizada de su comportamiento.
Medidas de seguridad en un proyecto de SW.
Las mltiples dimensiones de la seguridad son:
- Autenticacin: el proceso de verificar la identidad de una entidad.
- Control de acceso: el proceso de regular las clases de acceso que una entidad tiene sobre los
recursos.
- Auditoria: un registro cronolgico de los eventos relevantes a la seguridad de un sistema. Este
registro puede luego examinarse para reconstruir un escenario en particular.
- Confidencialidad: la propiedad de que cierta informacin no est disponible a ciertas entidades.
- Integridad: la propiedad de que la informacin no sea modificada en el trayecto fuente-destino.
- Disponibilidad: la propiedad de que el sistema sea accesible a las entidades autorizadas.
- No repudio: la propiedad que ubica la confianza respecto al desenvolvimiento de una entidad
en una comunicacin.
La seguridad puede tener diferentes significados en distintos escenarios.
En general, cuando se habla de seguridad implica referirse a ms de una de las dimensiones
mencionadas anteriormente.
Por ejemplo:
- Seguridad en correo electrnico: involucra confidencialidad, no repudio e integridad.
- Seguridad en compras online: implica autentificacin, confidencialidad, integridad y no repudio.
Bajo este punto de vista, se define un ataque a la seguridad como un intento de afectar en forma
negativa una o ms de las dimensiones del concepto de seguridad.
Una vez definido el concepto de seguridad, se pueden establecer objetivos bsicos para un
software seguro:
- Independencia de la seguridad: la seguridad debe construirse y utilizarse de manera
independiente de la aplicacin.
- Independencia de la aplicacin: la aplicacin no debe depender del sistema de seguridad usado,
debe ser desarrollada y mantenida en forma separada.
- Uniformidad: la seguridad debe aplicarse de manera correcta y consistente a travs de toda la
aplicacin y del proceso que desarrolla la misma.
- Modularidad: mantener la seguridad separada. Entre otras ventajas, esto nos brindar mayor
flexibilidad y menor costo de mantenimiento.
- Ambiente seguro: se debe partir de un entorno confiable. Es decir, las herramientas de desarrollo
y lenguajes de programacin no deben contener agujeros de seguridad.
- Seguridad desde el comienzo: la seguridad debe ser considerada como un requerimiento desde el
inicio del diseo.