apuntesprofesort1
-
Upload
victor-ceron -
Category
Documents
-
view
109 -
download
2
Transcript of apuntesprofesort1
-
El problema de la seguridad en el software
Tema 1
-
Tema 1: El problema de la seguridad en el software
Universidad Internacional de La Rioja (UNIR)
Actualmente las tecnologas de seguridad red pueden ayudar a aliviar los
ciberataques, pero no resuelven el problema de seguridad real ya que una vez que el
ciberatacante consigue vencer esas defensas, por ingeniera social por ejemplo, y
comprometer una mquina del interior, a travs de la misma podr atacar las dems
empezando por las ms vulnerables. Se hace necesario por tanto el disponer de
software seguro que funcione en un entorno agresivo y malicioso. El objetivo del
presente tema es introducir al alumno en los principales conceptos que abarca la
seguridad del software, en cuanto a los beneficios que produce, su importancia en la
seguridad global de un sistema, las propiedades de un software seguro, los ataques a
los que se tiene que enfrentar y las metodologas aplicables a los procesos de desarrollo
seguro de software.
Javier Bermejo Higuera
1.1. Introduccin al problema de la seguridad en el software
Hoy en da, los ataques cibernticos son cada vez ms frecuentes, organizados y
costosos en el dao que infligen a las administraciones pblicas, empresas privadas,
redes de transporte, redes de suministro y otras infraestructuras crticas desde la
energa a las finanzas, hasta el punto de poder llegar a ser una amenaza a la
prosperidad, la seguridad y la estabilidad de un pas.
Figura 1. Incidentes de seguridad
-
Tema 1: El problema de la seguridad en el software
Universidad Internacional de La Rioja (UNIR)
En la figura-1 se puede observar un grfico cualitativo en el que se muestran diversos
incidentes ocurridos a lo largo de los ltimos doce aos en relacin con su nivel de
complejidad. Como se puede observar la amenaza es creciente con los aos y cada
vez su nivel de complejidad es mayor.
La sociedad est cada vez ms vinculada al ciberespacio, un elemento importante del
mismo lo constituyen el software o las aplicaciones que proporcionan los servicios,
utilidades y funcionalidades. Sin embargo estas aplicaciones presentan defectos,
vulnerabilidades o configuraciones inseguras que pueden ser explotadas por
atacantes de diversa ndole desde aficionados hasta organizaciones de cibercrimen o
incluso estados en acciones de ciberguerra, utilizndolas como plataformas de ataque
comprometiendo los sistemas y redes de la organizacin.
Nadie quiere software defectuoso, especialmente los desarrolladores cuyo cdigo
incorrecto es el problema, en un informe de Klocwork [10] se indica que las principales
causas de la aparicin de vulnerabilidades son las siguientes:
Tamao excesivo y complejidad de las aplicaciones.
Mezcla de cdigo proveniente de varios orgenes como compras a otra
compaa, reutilizacin de otros existentes, etc., lo que puede producir
comportamientos e interacciones no esperados de los componentes del software.
Integracin de los componentes del software defectuosa, estableciendo
relaciones de confianza inadecuadas entre ellos, etc.
Debilidades y fallos en la especificacin de requisitos y diseo no basados
en valoraciones de riesgo y amenazas.
Uso entornos de ejecucin con componentes que contienen vulnerabilidades
o cdigo malicioso embebido, como pueden ser capas de middleware, sistema
operativo u otros componentes COTS.
No realizacin de pruebas seguridad basadas en riesgo.
Falta de la herramientas y un entorno de pruebas adecuados que simule
adecuadamente el real de ejecucin.
Cambios de requisitos del proyecto durante la etapa de codificacin.
Mezcla de equipos de desarrolladores, entre los que podemos tener, equipos
propios de desarrollos, asistencias tcnicas, entidades subcontratadas, etc.
Falta de conocimiento de prcticas de programacin segura de los
desarrolladores en el uso de lenguajes de programacin propensos a cometer errores
como C y C++ y utilizacin de herramientas de desarrollo inadecuadas.
-
Tema 1: El problema de la seguridad en el software
Universidad Internacional de La Rioja (UNIR)
No control de la cadena de suministro del software, lo puede dar lugar a la
introduccin de cdigo malicioso en origen.
No seguimiento, por los desarrolladores, de guas de normalizadas de estilo
en la codificacin.
Fechas lmite de entrega de proyectos inamovibles.
Cambio en la codificacin en base al requerimiento de nuevas funcionalidades.
Tolerancia a los defectos.
No tener actualizadas las aplicaciones en produccin con los parches
correspondientes, configuraciones errneas, etc.
Las aplicaciones son amenazadas y atacadas, no solo en su fase de operacin, sino que
tambin en todas las fases de su ciclo de vida [9]:
Desarrollo. Un desarrollador puede alterar de forma intencionada o no el software
bajo desarrollo de forma que se comprometa su fiabilidad futura durante la fase de
operacin.
Distribucin e instalacin. Ocurre cuando no se protege el software evitando
manipulaciones antes de enviarlo o publicarlo. Del mismo modo, si el instalador del
software no bastiona la plataforma en la que lo instala o la configura de forma
insegura, queda vulnerable a merced de los atacantes.
Operacin. Cualquier software que se ejecuta en una plataforma conectada a la red
tiene sus vulnerabilidades expuestas durante su funcionamiento. El nivel de
exposicin variar dependiendo de si la red es privada o pblica, conectada o no a
Internet, y si el entorno de ejecucin del software ha sido configurado para
minimizar sus vulnerabilidades.
Mantenimiento o sostenimiento. No publicacin de parches de las
vulnerabilidades detectadas en el momento oportuno o incluso introduccin de
cdigo malicioso por el personal de mantenimiento en las versiones actualizadas del
cdigo.
Segn el informe 2011 Top Cyber Security Risks Report [3], las vulnerabilidades
detectadas en aplicaciones alcanzaron su punto mximo en el ao 2006 iniciando a
partir de ese ao un lento declive, ver figura 2.
-
Tema 1: El problema de la seguridad en el software
Universidad Internacional de La Rioja (UNIR)
Esta disminucin de vulnerabilidades detectadas no significa que el software sea cada
vez ms seguro, es una sensacin de seguridad falsa, pues el nmero de
vulnerabilidades de alta severidad est creciendo a un ritmo ms rpido que los otros
niveles de vulnerabilidad (CVSS1 8 a 10, clasificacin definida en la OSVDB)2. En la
figura 3 se pone de manifiesto cmo el porcentaje de vulnerabilidades de alta severidad
se ha incrementado en los ltimos 10 aos.
Figura 2. Vulnerabilidades descubiertas por OSVDB3, 20002011
Figura 3. Gravedad de las vulnerabilidades OSVDB en 10 aos
Las vulnerabilidades de alta severidad dan lugar a que un atacante pueda
explotarlas rpidamente y hacerse con el control total del sistema. Su explotacin
requiere un conocimiento poco especializado de la aplicacin al alcance, no solo de
organizaciones cibercriminales, si no de cualquiera con conocimientos de informtica.
En el mismo informe anteriormente referido se incluye un grfico del nmero de
vulnerabilidades por aplicaciones (figura 4) desde el ao 2005 hasta el 2011,
QuickTime es de manera significativa la ms alta, al igual que los navegadores Web
Internet Explorer y Firefox.
1 Common Vulnerability Scoring System (CVSS). Es un sistema que categoriza la severidad de una vulnerabilidad, de manera estricta a travs de frmulas, proporcionando un estndar para comunicar las caractersticas y el impacto de una vulnerabilidad en el software. 2 http://osvdb.org/search/advsearch 3 Vulnerability information from the Open Source Vulnerability Database (OSVDB)
-
Tema 1: El problema de la seguridad en el software
Universidad Internacional de La Rioja (UNIR)
Figura 4. Nmero de vulnerabilidades por aplicaciones desde 2005 hasta 2011
Otros aspectos importantes que influyen en el nmero de vulnerabilidades conocidas
de una aplicacin son: su complejidad, su extensin en lneas de cdigo y el nivel
exposicin a los ataques, en este sentido las aplicaciones web en Internet, son las que
tienen ms probabilidades de ser atacadas y por tanto suelen tener mayor nmero de
vulnerabilidades conocidas.
Adems errneamente, a pesar de los datos convincentes de lo contrario, se sigue
confiando que la implantacin de tecnologas y dispositivos de seguridad de
red como cortafuegos, sistemas de gestin y correlacin de eventos (SIEM4), sistemas
de deteccin de intrusos, sistemas de gestin de acceso y cifrado del trfico, etc., son
medidas suficientes para proteger los sistemas de la organizacin. Los atacantes
buscan el descubrimiento de fallos en el software relacionados con la seguridad del
sistema, que den lugar a una vulnerabilidad con un impacto y riesgo asociado para la
entidad propietaria.
En base a lo expuesto anteriormente, se considera la necesidad que las diferentes
organizaciones pblicas o privadas dispongan de software fiable y resistente a los
ataques, es decir de confianza, con nmero de vulnerabilidades explotables
que sea el mnimo posible.
En respuesta a lo expuesto anteriormente nace la Seguridad del Software, en el
documento de referencia [13] de SAFECode se define como: La confianza que el
software, hardware y servicios estn libres de intencionadas o no intencionadas
vulnerabilidades y que funcionan conforme a lo especificado y deseado.
4 Sistema de Centralizacin y Monitorizacin de la Informacin de Eventos y datos infraestructura como, logs, etc.
-
Tema 1: El problema de la seguridad en el software
Universidad Internacional de La Rioja (UNIR)
El Departamento de Defensa de los Estados Unidos (DoD) [19] la define como El nivel
de confianza de que el software funciona segn lo previsto y est libre de
vulnerabilidades, ya sea intencionada o no diseada o insertada en el marco de la
software.
En este sentido, en base a la definicin anterior y los prrafos anteriores, se puede
definir la seguridad del software como:
El conjunto de principios de diseo y buenas prcticas a implantar en el SDLC, para detectar, prevenir y corregir los defectos de seguridad en el desarrollo y adquisicin de aplicaciones, de forma que se obtenga software de confianza y robusto frente ataques maliciosos, que realice solo las funciones para las que fue diseado, que est libre de vulnerabilidades, ya sean intencionalmente diseadas o accidentalmente insertadas durante su ciclo de vida y se asegure su integridad, disponibilidad y confidencialidad.
Hasta principios de la dcada anterior, la mayora de las aplicaciones se desarrollaban
sin tener en cuenta requisitos y pruebas de seguridad especficos, los desarrolladores de
software no eran conscientes de las vulnerabilidades que se pueden crear al programar
y descuidaban los aspectos de seguridad, dando primaca al cumplimiento de las
especificaciones funcionales, sin tener en cuenta casos en los que el software fuera
maliciosamente atacado. Este proceso de desarrollo de software ofrece, aparte de los
errores no intencionados producidos al codificar anteriormente referidos,
oportunidades de insertar cdigo malicioso en el software en origen.
Como se ha comentado anteriormente la tecnologas de seguridad red pueden ayudar a
aliviar los ataques, pero no resuelven el problema de seguridad real ya que una
vez que el ciberatacante consigue vencer esas defensas, por ingeniera social por
ejemplo, y comprometer una mquina del interior a travs de la misma podr atacar a
otras de la red (pivoting) empezando por las ms vulnerables. Este es el caso de las
Amenazas Avanzadas Persistentes (APT5) uno de los ciberataques ms peligrosos y
dainos de hoy en da. Se hace necesario por tanto el disponer de software seguro
que funcione en un entorno agresivo y malicioso.
5 Tipo sofisticado de ciberataque organizado, de rpida progresin y largo plazo, diseado especficamente para acceder y obtener informacin de los sistemas de la organizacin objetivo.
-
Tema 1: El problema de la seguridad en el software
Universidad Internacional de La Rioja (UNIR)
Un aspecto importante de la seguridad del software es la confianza y garanta de
funcionamiento conforme a su especificacin y diseo y de que es lo
suficientemente robusto para soportar las amenazas que puedan comprometer su
funcionamiento esperado en su entorno de operacin.
Para conseguir lo anterior y minimizar al mximo los ataques en la capa de
aplicacin y por tanto en nmero de vulnerabilidades explotables, es
necesario el incluir la seguridad desde principio en el ciclo de vida de
desarrollo del software (SDLC), incluyendo requisitos, casos de abuso, anlisis de
riesgo, anlisis de cdigo, pruebas de penetracin dinmicas, etc., en este sentido es
importante el aprovechamiento de las buenas prcticas de ingeniera de
software ya existentes.
Un beneficio importante que se obtendra de incluir un proceso sistemtico que
aborde la seguridad desde las primeras etapas del SDLC, sera la reduccin
de los costes de correccin de errores y vulnerabilidades, pues estos son ms
altos conforme ms tarde son detectados. Acorde a lo publicado por NIST (National
Institute of Standards and Technology), el coste que tiene la correccin de cdigo o
vulnerabilidades despus de la publicacin de una versin mediante la publicacin de
un parche, es hasta treinta veces mayor que su deteccin y correccin en etapas
tempranas del desarrollo.
Figura 5. Coste relativo de correccin de vulnerabilidades en funcin de la etapa de desarrollo. Fuente: http://www.microsoft.com/security/sdl/learn/costeffective.aspx
En el informe de Klocwork [10] anteriormente referido, se incluye a su vez una figura
en el coste que tiene la correccin de cdigo o vulnerabilidades despus de la
publicacin de una versin es incluso 100 veces mayor. Se basan en ratios desarrollados
por Barry Boehm de la Universidad del Sur de California.
-
Tema 1: El problema de la seguridad en el software
Universidad Internacional de La Rioja (UNIR)
Figura 6. Efectos de la deteccin de defecto tarda. Fuente: [10]
El objetivo del presente tema es introducir al alumno en los principales conceptos que
abarca la seguridad del software, en cuanto a los beneficios que produce, su
importancia en la seguridad global de un sistema, las propiedades de un software
seguro, sus principios de diseo, los ataques a los que se tiene que enfrentar y los
estndares de seguridad aplicables a los procesos de desarrollo seguro de software.
1.2. El ciclo de vida de una vulnerabilidad
Introduccin
Una vulnerabilidad es un fallo de programacin, configuracin o diseo que permite,
de alguna manera, a los atacantes alterar el comportamiento normal de un programa y
realizar algo malicioso como alterar informacin sensible, interrumpir o destruir una
aplicacin o tomar su control.
Se puede decir que son un subconjunto del fenmeno ms grande que constituyen los
bugs de software.
-
Tema 1: El problema de la seguridad en el software
Universidad Internacional de La Rioja (UNIR)
Sus fuentes se deben a:
Fallos de implementacin. Fallos provenientes de la codificacin de los diseos
del software realizados. Como ejemplos tenemos desbordamientos de bfer,
formato, condiciones de carrera, path traversal, cross-site scripting, inyeccin SQL,
etc.
Fallos de diseo. Los sistemas hardware o software contienen frecuentemente
fallos de diseo que pueden ser utilizados para realizar un ataque. Por ejemplo
TELNET no fue diseado para su uso en entornos hostiles, para eso se implement
SSH.
Fallos de configuracin. La instalacin de software por defecto implica por lo
general la instalacin de servicios que no se usan, pero que pueden presentar
debilidades que comprometan la maquina.
Vulnerabilidades:
Fallos de implementacin
Fallos de diseo
Fallos de configuracin
Figura 7. Tipos de vulnerabilidades del software
Casi todas las vulnerabilidades de seguridad provenientes de fallos de implementacin
y diseo son bugs de software, pero solamente algunos resultan ser vulnerabilidades de
seguridad. Un bug debe tener algn impacto o caractersticas relevantes para ser
considerado un error de seguridad, es decir tiene que permitir a los atacantes la
posibilidad de realizar un exploits6 que les permita hacerse con el control de una
mquina.
6 Es una instancia particular de un ataque a un sistema informtico que aprovecha una vulnerabilidad especfica o un conjunto de ellas.
-
Tema 1: El problema de la seguridad en el software
Universidad Internacional de La Rioja (UNIR)
Una vulnerabilidad se define [4], bsicamente, por cinco factores o parmetros que
deben identificarla.
Producto: productos a los que afecta, versin o conjunto de ellas.
Dnde: Componente o mdulo del programa donde se localiza la vulnerabilidad.
Causa y consecuencia: Fallo tcnico concreto que cometi el programador a la
hora de crear la aplicacin que es el origen de la vulnerabilidad.
Impacto: Define la gravedad de la vulnerabilidad, indica lo que puede conseguir un
atacante que la explotase.
Vector: Tcnica del atacante para aprovechar la vulnerabilidad se le conoce como
vector de ataque.
El ciclo de vida de una vulnerabilidad
El ciclo de vida de una vulnerabilidad consta de las siguientes fases:
Descubrimiento: deteccin de un fallo en el software que puede producirse
durante el desarrollo del mismo o una vez est en produccin.
Utilizacin: Los agentes maliciosos desarrollan el exploit adecuado para poder
lanzar ataques.
Verificacin inicial de la vulnerabilidad: una vez se recibe una notificacin de
error esta ser aceptada para su tratamiento comprobando la veracidad del error, o
bien ser rechazada por un responsable en caso de que no se pueda reproducir la
vulnerabilidad y se compruebe que la vulnerabilidad no existe.
Solucin: los programadores del producto buscan solucin en entornos
controlados.
Difusin: los medios de comunicacin dan publicidad al incidente.
Medidas: si es posible las organizaciones afectadas toman medidas para mitigar las
posibles prdidas.
Correccin y nueva verificacin: el proceso de correccin de la vulnerabilidad,
llevado a cabo por programadores, ser verificado nuevamente de manera iterativa
hasta comprobar la resolucin del error.
Bsqueda. Los tcnicos buscan vulnerabilidades similares (el ciclo vuelve a
comenzar).
Actualizacin: Los sitios no actualizados vuelven a ser vctimas.
-
Tema 1: El problema de la seguridad en el software
Universidad Internacional de La Rioja (UNIR)
Descubrir Utilizacin Verificacin Solucin Difusin Medidas Correccin Bsqueda Actualizar
Figura 8. Ciclo de vida una vulnerabilidad
Gestin de vulnerabilidades
Dada la gran cantidad de vulnerabilidades descubiertas se hace necesario el disponer
de estndares al objeto de poder referenciarlas unvocamente, para conocer su
gravedad de forma objetiva y obtener el conocimiento necesario para mitigarlas.
Existen varios estndares, catlogos o bases de datos, que a continuacin pasamos a
comentar:
Common Vulnerabilities and Exposures (CVE)7 [5]. Es un diccionario o
catlogo pblico de vulnerabilidades, administrado por MITRE8, que normaliza su
descripcin y las organiza desde diferentes tipos de vista (vulnerabilidades Web, de
diseo, implementacin, etc.). Cada identificador CVE incluye:
o Identificador con el siguiente formato:
Nmero de cuatro cifras que identifica la vulnerabilidad en el ao.
CVE, seguido del ao en el que se asign el cdigo a la vulnerabilidad.
CVE-2012-
4212
Figura 9. Identificador CVE
o Brece descripcin de la vulnerabilidad o Referencias
7 http://cve.mitre.org 8 Organizacin sin nimo de lucro, de carcter pblico que trabaja en las reas de ingeniera de
sistemas, tecnologas de la informacin, concepto de operacin y modernizacin de empresas. http://www.mitre.org/about/index.html
-
Tema 1: El problema de la seguridad en el software
Universidad Internacional de La Rioja (UNIR)
Common Vulnerability Scoring System (CVSS)9. Es bsicamente un sistema
que escalona la severidad de una vulnerabilidad, de manera estricta a travs de
frmulas, proporcionando un estndar para comunicar las caractersticas y el
impacto de una vulnerabilidad identificada con su cdigo CVE. Su modelo
cuantitativo asegura una medicin exacta y repetible a la vez que permite ver
caractersticas de vulnerabilidad subyacentes que se usaron para generar su
puntuacin. Permite organizar la priorizacin de las actividades de remediacin o
parcheo de las vulnerabilidades. En la figura se muestra el proceso de clculo de una
severidad:
Figura 10. Clculo puntuacin CVSS
El clculo se realiza en base a tres tipos de mtricas base, temporales y ambientales,
siendo las dos ltimas opcionales. En cuanto a las mtricas base se tienen dos
subconjuntos
o Explotabilidad: vectores de acceso, complejidad de acceso y autenticacin. o Impacto: confidencialidad, integridad y disponibilidad.
Vulnerability information from the Open Source Vulnerability Database
(OSVDB)10. Proporciona una radiografa excelente de las vulnerabilidades
existentes, particularmente para aplicaciones software. Sin embargo, debido a la
naturaleza de los informes vulnerabilidad, OSVDB solo puede contar con las
vulnerabilidades que se hagan pblicas o se hayan insertado directamente en la base
de datos por particulares.
9 http://nvd.nist.gov/cvss.cfm 10 http://osvdb.org
-
Tema 1: El problema de la seguridad en el software
Universidad Internacional de La Rioja (UNIR)
Common Vulnerability Reporting Framework (CVRF). Es un formato XML
que permite compartir informacin crtica sobre vulnerabilidades en un sistema
abierto y legible por cualquier equipo. Hasta el momento no haba ningn estndar
para informar de vulnerabilidades de los sistemas de la Tecnologas de la
Informacin y Comunicaciones (TIC), por lo que CVRF viene a cubrir una necesidad
manifestada por los distintos actores de la industria, organismos de investigacin y
de la administracin en cuanto a un marco comn, ya que hasta ahora, cada
proveedor creaba sus informes segn su criterio. La disponibilidad de CVRF acelera
el intercambio y procesamiento de informacin entre distintas plataformas.
Originalmente deriva del proyecto Incident Object Description Exchange Format
(IODEF), su propsito es el reemplazar los mltiples formatos previamente en uso
no estndar de presentacin de informes, lo que permite acelerar el intercambio de
informacin y proceso.
National Vulnerability Database (NVD)11. Base de datos del gobierno
estadounidense que permite la automatizacin de la gestin vulnerabilidades y la
medicin del nivel seguridad. Incluye bases de datos con listas de comprobacin de
configuraciones de seguridad de productos, defectos de seguridad del software
relacionados, malas configuraciones, los nombres de producto y mtricas de
impacto. Contiene:
o 54337 CVE Vulnerabilidades. o 202 Listas de comprobacin de configuraciones de seguridad de productos. o 8140 Consultas a OVAL.12
11 http://nvd.nist.gov/ 12 Open Vulnerability and Assessment Languajes (OVAL). Esfuerzo de comunidad
internacional para normalizar los informes de seguridad de vulnerabilidades y estado de seguridad de un sistema TIC. Incluye un lenguaje de codificacin de los detalles de sistema. http://oval.mitre.org/
-
Tema 1: El problema de la seguridad en el software
Universidad Internacional de La Rioja (UNIR)
Common Weakness Enumeration (CWE) 13 . Estndar International y de libre
uso que ofrece un conjunto unificado de debilidades o defectos de software
medibles, que permite un anlisis, descripcin, seleccin y uso de herramientas de
auditora de seguridad de software y servicios que pueden encontrar debilidades en
el cdigo fuente y sistemas, as como una mejor comprensin y gestin de los puntos
dbiles de un software relacionados con la arquitectura y el diseo. Sus principales
objetivos son:
o Proporcionar un lenguaje comn para describir los defectos y debilidades de seguridad de software en la arquitectura, el diseo y codificacin.
o Proporcionar un estndar de comparacin de herramientas de auditora seguridad de software.
o Proporcionar una lnea base para la identificacin de vulnerabilidades, su mitigacin y los esfuerzos de prevencin.
En la figura siguiente se puede ver un diagrama de contexto de las diferentes
organizaciones y estndares que usan CWE.
Figura 11. Diagrama de contexto de CWE. Fuente: http://cwe.mitre.org/
13 http://cwe.mitre.org/
-
Tema 1: El problema de la seguridad en el software
Universidad Internacional de La Rioja (UNIR)
Incluye los siguientes tipos de debilidades del software: desbordamientos del bfer,
formato de cadenas, estructura y problemas de validacin, errores de ruta, interfaz
de usuario, autenticacin, gestin de recursos, manipulacin de datos, verificacin
de datos, inyeccin de cdigo, etc.
Cada identificador CWE incluye los siguientes campos de informacin:
Nombre del tipo de debilidadDescripcin del tipoTrminos alternativos para la debilidadDescripcin del comportamiento de la debilidadDescripcin de la debilidadProbabilidad de explotar la debilidadDescripcin de las consecuencias de la explotacinPosibles mitigacionesOtras debilidades relacionadasTaxonomas de las fuentesEjemplos de cdigo para los lenguajes/arquitecturasIdentificadores de vulnerabilidades CVE para las que ese tipo de debilidad existeReferencias
CWE:
Figura 12. Campos de informacin de cada entrada CWE
Clasificacin de las vulnerabilidades
Existen muchas clasificaciones o taxonomas de vulnerabilidades unas se adaptan a
todo tipo de aplicaciones, como son MITRE Top 2514 y SANS Top 2015 y otras solo a
aplicaciones web como son OWASP Top 1016 y WASC Threat Clasification v2.017. A
continuacin describimos algunas de las mencionadas.
14 http://cwe.mitre.org/top25/ 15 http://www.sans.org/top20/ 16 http://www.owasp.org/images/e/e8/OWASP_Top_10_2007.pdf 17 http://www.webappsec.org/projects/threat/
-
Tema 1: El problema de la seguridad en el software
Universidad Internacional de La Rioja (UNIR)
MITRE TOP 25. La lista es el resultado de la colaboracin entre el Instituto SANS,
MITRE y muchos de los mejores expertos en software de EE.UU. y Europa.
Contiene los mayores errores de programacin que pueden causar vulnerabilidades
en el software. Es una herramienta destinada a ayudar a los programadores y
auditores de seguridad del software, para prevenir este tipo de vulnerabilidades que
afectan a la industria de las TIC.
o Todo tipo de aplicaciones Web y no Web. o Dan lugar a vulnerabilidades graves en el software. o Prevencin, mitigacin y principios de programacin seguros.
En la siguiente tabla se pueden consultar las 25 principales vulnerabilidades:
RANK ID NOMBRE
[1] CWE-89 Improper Neutralization of Special Elements used in an SQL Command ('SQL
Injection')
[2] CWE-78 Improper Neutralization of Special Elements used in an OS Command ('OS
Command Injection')
[3] CWE-120 Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')
[4] CWE-79 Improper Neutralization of Input During Web Page Generation ('Cross-site
Scripting')
[5] CWE-306 Missing Authentication for Critical Function
[6] CWE-862 Missing Authorization
[7] CWE-798 Use of Hard-coded Credentials
[8] CWE-311 Missing Encryption of Sensitive Data
[9] CWE-434 Unrestricted Upload of File with Dangerous Type
[10] CWE-807 Reliance on Untrusted Inputs in a Security Decision
[11] CWE-250 Execution with Unnecessary Privileges
[12] CWE-352 Cross-Site Request Forgery (CSRF)
[13] CWE-22 Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
[14] CWE-494 Download of Code Without Integrity Check
[15] CWE-863 Incorrect Authorization
[16] CWE-829 Inclusion of Functionality from Untrusted Control Sphere
[17] CWE-732 Incorrect Permission Assignment for Critical Resource
[18] CWE-676 Use of Potentially Dangerous Function
[19] CWE-327 Use of a Broken or Risky Cryptographic Algorithm
[20] CWE-131 Incorrect Calculation of Buffer Size
[21] CWE-307 Improper Restriction of Excessive Authentication Attempts
[22] CWE-601 URL Redirection to Untrusted Site ('Open Redirect')
[23] CWE-134 Uncontrolled Format String
[24] CWE-190 Integer Overflow or Wraparound
[25] CWE-759 Use of a One-Way Hash without a Salt
Tabla 1 Veinticinco vulnerabilidades MITRE TOP 25. Extrada de [7].
-
Tema 1: El problema de la seguridad en el software
Universidad Internacional de La Rioja (UNIR)
Para cada entrada de la tabla se proporciona la siguiente informacin:
o Clasificacin. La clasificacin de la debilidad CVSS. o Identificador CWE. o Informacin adicional sobre la debilidad que puede ser til para adoptar
decisiones de priorizacin de acciones de mitigacin.
o Breve discusin informal sobre la naturaleza de la debilidad y de sus consecuencias.
o Los pasos que los desarrolladores pueden tomar para mitigar o eliminar las debilidades.
o Otras entradas CWE que estn relacionadas con la debilidad Top 25. o Entradas estndar CAPEC18 sobre los ataques que pueden llevarse a cabo con
xito contra la debilidad.
o Enlaces con ms detalles, incluyendo ejemplos de cdigo fuente que demuestran la debilidad, mtodos de deteccin, etc.
SANS Top 20. Es una lista de vulnerabilidades que requieren solucin inmediata.
Es el resultado de un proceso que reuni a docenas de expertos lderes en seguridad.
Incluye instrucciones paso a paso y notas para informacin adicional tiles para
corregir los defectos de seguridad. Se actualiza la lista y las instrucciones en la
medida que ms amenazas sean identificadas.
o Vulnerabilidades en servidores, aplicaciones Web, aplicaciones comerciales/open-source.
o No tiene en cuenta las aplicaciones propietarias.
Consultar lectura complementaria para ms detalle sobre la clasificacin.
OWASP Top 10. Su objetivo es crear conciencia sobre la seguridad en aplicaciones
mediante la identificacin de algunos de los riesgos ms crticos que enfrentan las
organizaciones.
18 Lista de patrones comunes de ataque junto con un esquema integral y taxonoma de clasificacin.
-
Tema 1: El problema de la seguridad en el software
Universidad Internacional de La Rioja (UNIR)
o Las 10 vulnerabilidades de seguridad ms crticas en aplicaciones Web. o Lista ordenada por criticidad y predominio. o Representa una lista concisa y enfocada sobre los diez riesgos ms crticos sobre
seguridad en aplicaciones.
Figura 13. OWASP TOP 10 diez riesgos ms importantes en aplicaciones WEB.
Extrada de [8].
-
Tema 1: El problema de la seguridad en el software
Universidad Internacional de La Rioja (UNIR)
WASC Threat Clasification v2.0. Es un esfuerzo de cooperacin para aclarar y
organizar las amenazas a la seguridad de un sitio web. Es un proyecto para
desarrollar y promover estndares para la industria y su principal propsito es el
crear un lenguaje consistente y las definiciones de los problemas de seguridad
relacionados con las aplicaciones web.
o Unificacin y organizacin de las amenazas de seguridad Web. o Describe amenazas, debilidades y ataques.
Escneres de vulnerabilidades
Este tipo de herramientas analizan los sistemas en busca de vulnerabilidades
conocidas. Disponen de informacin sobre vulnerabilidades existentes en los sistemas
operativos y aplicaciones mediante actualizadas bases de datos, que utiliza para la
deteccin de las mismas.
La herramienta ms utilizada es Nessus, inicialmente de cdigo abierto y versin
gratuita, y actualmente en dos versiones, la 4.x en la que el nuevo cdigo es cerrado, y
la versin 2.x (www.nessus.org) que contina siendo software libre. A raz de este
cambio se crearon tres proyectos diferentes a partir de la versin libre, Sussen, Porz-
Wahn y OpenVas (inicialmente GNessUs). Actualmente el proyecto Porz-Wahn se uni
con OpenVas19, la cual contina actualizando versiones para las distintas distribuciones
de GNU/Linux. Otras herramientas de extendido uso son ISS Real Secure, Nmap y
Retina.
1.3. Propiedades de un software seguro
Bsicamente se tienen dos conjuntos de propiedades que definen a un software seguro
del que no lo es, las primeras son las esenciales, comunes a la seguridad de cualquier
sistema, cuya ausencia afecta gravemente a la seguridad de una aplicacin y un
segundo conjunto, complementarias a las anteriores que no influyen en su
seguridad, pero que ayudan a mejorarla en gran medida.
19 http://www.openvas.org/
-
Tema 1: El problema de la seguridad en el software
Universidad Internacional de La Rioja (UNIR)
Las principales propiedades esenciales que distinguen al software de confianza
del que no es de confianza son:
Integridad. Capacidad que garantiza que el cdigo, activos manejados,
configuraciones y comportamiento no pueda ser o no haya sido modificado o
alterado por personas, entidades o procesos no autorizados tanto durante la
fase de desarrollo como en la fase de operacin. Entre las modificaciones
que se pueden realizar tenemos sobreescritura, inclusin de puertas traseras,
borrado, corrupcin de datos, etc. Como las tcnicas y mecanismos que se tienen
para salvaguardar la integridad, tenemos por ejemplo:
o Identificacin del modo de trasmisin y procesado de los datos por la aplicacin. o Uso de tcnicas de cifrado para asegurar que los componentes y los datos nos son
alterados o corrompidos.
o Estricta gestin de sesiones. o Uso de sistemas de monitorizacin de la integridad o Uso de firma digital. o Trasmisin cifrada de los datos.
Disponibilidad. Capacidad que garantiza que el software es operativo y
accesible por personas, entidades o procesos autorizados de forma que se pueda
acceder a la informacin y a los recursos o servicios que la manejan, conforme a las
especificaciones de los mismos. Entre las tcnicas y mecanismos que se tienen para
salvaguardar la disponibilidad, tenemos por ejemplo:
o Anlisis de qu servicios e informacin es crtica y el modo de tenerlos disponibles.
o Uso de arquitecturas de alta disponibilidad, con diferentes tipos de redundancias. o Uso de sistemas distribuidos con sistemas de rplica de informacin entre ellos. o Uso de sistemas de recuperacin a travs de imgenes, virtualizacin, etc.
Confidencialidad. Capacidad de preservar que cualquiera de sus caractersticas,
activos manejados estn ocultos a usuarios no autorizados, de forma que se
garantice que solo las personas, entidades o procesos autorizados pueden acceder a
la informacin.
-
Tema 1: El problema de la seguridad en el software
Universidad Internacional de La Rioja (UNIR)
Entre las tcnicas y mecanismos que se tienen para salvaguardar la
confidencialidad, tenemos por ejemplo:
o Clasificacin de las aplicaciones y servicios en base a su criticidad. o Trfico de relleno. o Tcnicas de control de acceso a los sistemas basado en roles. o El cifrado de la informacin y de las comunicaciones.
Figura 14. Propiedades esenciales de la seguridad del software
Un ejemplo de ataque podra ser uno de desbordamiento del buffer (buffer overflow)
consiguiendo el control total de la mquina, pudiendo violar las tres propiedades
anteriores al poder robar informacin del sistema, cuantas de usuario, corromper
ficheros del sistema e incluso apagar la mquina y borrar los ficheros necesarios
para que no vuelva a arrancar.
Estas tres primeras seran las propiedades fundamentales esenciales mnimas que
debera disponer todo software, a las que habra que aadir las siguientes
complementarias:
Fiabilidad. Capacidad del software de funcionar de la forma esperada en
todas las situaciones a la que estar expuesto en su entorno de
funcionamiento, es decir que la posibilidad de que un agente malicioso pueda
alterar la ejecucin o resultado de una manera favorable para el atacante est
significativamente reducida o eliminada.
-
Tema 1: El problema de la seguridad en el software
Universidad Internacional de La Rioja (UNIR)
En este sentido en el documento de referencia [12], se indica la necesidad de
comprobar el comportamiento del software bajo una gran variedad de condiciones
entre las que al menos deben ser las siguientes:
o Batera de ataques lanzados contra el software. o Entradas y salidas del software (seales, ficheros de datos, texto, etc.) que hayan
sido comprometidas.
o Interfaces del software a otras entidades que hayan sido comprometidas. o Ejecucin del software en un ambiente donde es atacado.
Autenticacin. Capacidad que permite a un software garantizar que una
persona, entidad o proceso es quien dice ser o bien que garantiza la
fuente de la que proceden los datos.
Trazabilidad. Capacidad que garantiza la posibilidad de imputar las acciones
relacionadas en un software a la persona, entidad o proceso que la ha
originado.
Robustez. Capacidad de resistencia y tolerancia a los ataques realizados por
los agentes maliciosos (malware, hackers, etc.).
Resiliencia. Capacidad del software de aislar, contener y limitar los daos
ocasionados por fallos causados por ataques de vulnerabilidades explotable del
mismo, recuperarse lo ms rpido posible de ellos y reanudar su
operacin en o por encima de cierto nivel mnimo predefinido de servicio
aceptable en un tiempo oportuno.
Tolerancia. Capacidad del software para tolerar los errores y fallos que resultan
de ataques con xito y seguir funcionando como si los ataques no se hubieran
producido.
Las propiedades que distinguen al software de confianza se ilustran en la figura
siguiente.
-
Tema 1: El problema de la seguridad en el software
Universidad Internacional de La Rioja (UNIR)
Figura 15. Propiedades seguridad del software
Existen una serie de factores [13] influyen en la probabilidad de que un software sea
consistente con la propiedades anteriormente mostradas, probable es exponer
sistemticamente con estas propiedades en todas las condiciones. Estos incluyen:
Principios de diseo y buenas prcticas de desarrollo. Las prcticas
utilizadas para desarrollar el software y los principios de diseo que lo rigen. En el
apartado posterior se desarrolla ampliamente este punto.
Herramientas de desarrollo. El lenguaje de programacin, bibliotecas y
herramientas de desarrollo utilizadas para disear, implementar y probar el
software, y la forma en que fueron utilizados por los desarrolladores.
Componentes adquiridos. Tanto los componentes de software comercial como
libre en cuanto como fueron evaluados, seleccionados, e integrados.
Configuraciones desplegadas. Cmo el software se configur durante la
instalacin en su entorno de produccin.
Ambiente de operacin. La naturaleza y configuracin de las protecciones
proporcionadas por el entorno de ejecucin o produccin.
-
Tema 1: El problema de la seguridad en el software
Universidad Internacional de La Rioja (UNIR)
Conocimiento Profesional. El nivel de concienciacin y conocimiento de
seguridad que los analistas, diseadores, desarrolladores, probadores y
mantenedores del software, o su falta del mismo.
1.4. Principios de diseo seguridad del software
Introduccin
Existe una gran cantidad de bibliografa relativa a temas de seguridad en los que se
suele comentar los principios de seguridad que han de regir todo diseo, algunos de
ellos estn ms enfocados a las configuraciones de los dispositivos de seguridad de red,
la mayora de ellos se solapan y normalmente coinciden generalmente siendo por tanto
anlogos, en este sentido se selecciona como referencia para la realizacin de este
apartado los documentos Enhancing the Development Life Cycle to Produce Secure
Software [13] y Writing Secure Code [14].
La adopcin de estos principios de diseo constituye una base fundamental de las
tcnicas de programacin segura que se vern ms adelante en el tema 3, tanto
para la proteccin de aplicaciones Web, normalmente ms expuestas a los ciberataques
al estar desplegadas masivamente en Internet, como otras ms tradicionales del tipo
cliente-servidor. Las principales prcticas y principios de diseo tener en cuenta seran:
Defensa en profundidad.
Simplicidad del diseo.
Mnimo privilegio.
Separacin de privilegios.
Separacin de dominios.
Separacin cdigo, ejecutables y datos configuracin y programa.
Entorno de produccin o ejecucin inseguro.
Registro de eventos de seguridad.
Fallar de forma segura.
Diseo de software resistente.
La seguridad por oscuridad es un error.
Seguridad por defecto.
-
Tema 1: El problema de la seguridad en el software
Universidad Internacional de La Rioja (UNIR)
Defensa en profundidad
Uno de los principios ms importantes de una estrategia defensiva efectiva es la
Defensa en Profundidad, se define en la gua CCN-STIC-400 [18] como: Estrategia
de proteccin consistente en introducir mltiples capas de seguridad, que permitan
reducir la probabilidad de compromiso en caso de que una de las capas falle y en el
peor de los casos minimizar el impacto.
La arquitectura del software y hardware de base que constituir el entorno de
ejecucin donde la aplicacin vaya a ser instalada debera contar con una variedad de
servicios de seguridad y protecciones que reduzcan y dificulten la probabilidad de que
una accin maliciosa alcance el software, ya que se minimiza la exposicin de las
propias vulnerabilidades al mundo exterior, se reduce la visibilidad externa de los
componentes confiables principales y se aslan los componentes no confiables de
forma que su ejecucin se vea limitada y sus malos comportamientos no afecten o
amenacen la operacin confiable de los dems.
El aislamiento significa que el software o componente no confiable dispone de recursos
especficos para su ejecucin como memoria, espacio en disco duro, interfaz de red
virtual, etc., en un entorno aislado. Para su implementacin se suelen utilizar mquinas
virtuales que adems pueden proporcionar otras caractersticas que ayudan a mejorar
la fiabilidad, confiabilidad y resistencia como el balanceo de carga, soporte para la
restauracin de imgenes, etc.
Objetivo: introducir mltiples capas de seguridad para reducir la probabilidad de
compromiso del sistema.
Este principio, propone un enfoque defensivo, que implanta protecciones o
mecanismos de seguridad en todos los niveles del sistema o capas del modelo Open
Systems Interconnection (OSI).
-
Tema 1: El problema de la seguridad en el software
Universidad Internacional de La Rioja (UNIR)
Las medidas de seguridad a implementar en cada capa podrn variar en funcin del
entorno de operacin del sistema, sin embargo el principio base o general permanece
inalterable, por ejemplo para las capas siguientes tendramos:
Capa de aplicacin: Dispositivos de nivel de aplicacin como
cortafuegos, proxy reverso, y sistemas de prevencin de intrusiones de
host que bloqueen las entradas maliciosas conocidas y problemticas antes de que
llegue al software. Otros mecanismos son mtodos de encriptacin, control de
acceso, autenticacin, bastionados de aplicaciones, etc.
Capa de transporte: Mecanismos de cifrado como Socket Secure Layer (SSL) o
Transport Layer Security (TLS).
Capa de red: Dispositivos de seguridad de red como cortafuegos, sistemas de
proteccin de intrusiones (IDS/IPS) a nivel de red, sistemas de gestin y correlacin
de eventos de infraestructura (SIEM), etc. que protejan y dificulten las
acciones de los ciberatacantes.
Capa fsica: Plataformas virtuales sandboxes que proporcionan un entorno
aislado de ejecucin para los componentes no confiables evitando que sus
malos comportamientos posibles de afectar a los componentes confiables. As
mismo pueden proporcionar arquitecturas de alta disponibilidad y sistemas de
recuperacin completa de las mquinas. Mantenimiento de los equipos de
comunicaciones y proceso de datos en salas construidas en base a requisitos de
seguridad estructural para evitar intrusiones y emanaciones, sistemas de extincin
automtica de incendios, sensores de humedad, sistemas de control de accesos, etc.
Cortafuegos de aplicacinProxy reverso
Mtodos CriptogrficosControl de Acceso Autenticacin Bastionado de las aplicaciones
Bastionado del sistema operativo
AplicacinDatos
Presentacin Datos
Presentacin Datos
SSL/TLSTransporte Segment
-
Tema 1: El problema de la seguridad en el software
Universidad Internacional de La Rioja (UNIR)
Segmentos de redFirewall/IDS/IPSEC/VPN
Red Paquetes
Enlace Tramas
Prevencin Intrusiones Seguridad Fsica Procedimientos seguridad
Plataforma virtualizacinFsico Bits
Figura 16. Propiedades seguridad del software
El principio fundamental detrs de este concepto, es el de dificultar las acciones
del atacante a travs de las diferentes medidas de seguridad aplicadas a cada una de
las capas de forma que los diferentes sensores que tengan nuestro sistema detecten
las actividades maliciosas. Cuando una capa se vea comprometida, las medidas de
deteccin, de reaccin y de recuperacin nos permitirn reaccionar, disminuyendo
la probabilidad de que otras capas se vean comprometidas, evitando as, que la
seguridad del servicio en su conjunto se vea burlada, disminuyendo por tanto el
riesgo.
Otro aspecto importante es la verificacin de la cadena de suministros mediante la
comprobacin de los hash20, cdigo de firma, aplicados al cdigo ejecutable
mediante la validacin de la integridad de la misma en el momento de la
entrega, la instalacin o en tiempo de ejecucin, para determinar:
o Si el cdigo se origin a partir de una fuente de confianza. o Si la integridad del cdigo de se ha visto comprometida.
En la figura siguiente se puede observar un ejemplo del uso de arquitecturas de
proteccin.
20 Prueba de la integridad de contenidos. Por ejemplo cuando se distribuye un contenido por la red, y se quiere estar seguro de que lo que le llega al receptor es lo que se est emitiendo, se proporciona un valor hash del contenido de forma que ese valor tiene que obtenerse al aplicar la funcin hash sobre el contenido distribuido asegurando as la integridad. A esto se le suele llamar checksum criptogrfico debido a que es un checksum que requiere el uso de funciones hash criptogrficas para que sea difcil generar otros ficheros falsos que tengan el mismo valor hash. Otro ejemplo de uso esta tecnologa para verificar la integridad es calcular y guardar el valor hash de archivos para poder verificar posteriormente que nadie (Ej. un virus) los ha modificado. http://es.wikipedia.org
-
Tema 1: El problema de la seguridad en el software
Universidad Internacional de La Rioja (UNIR)
Ataques exteriores, identificar problemas
de configuracin
No trfico cifrado, gran volumen
Elevado n falsos positivos
Amenaza real,
Figura 17. Uso de arquitecturas de proteccin
Simplicidad del diseo
La realizacin de un diseo tan simple como sea posible y la redaccin de unas
especificaciones del mismo fcilmente comprensibles y simples es una forma de
obtener un nivel de seguridad mayor pues ser menos probable que el desarrollador
incluya debilidades y vulnerabilidades e incluso se haga ms fcil el anlisis de su
descubrimiento y su verificacin y validacin.
Algunas de las opciones especficas de diseo del software que lo simplifican son [13]:
Limitar el nmero de estados posibles en el software.
Favorecer procesos deterministas sobre los no deterministas.
Utilice una sola tarea en lugar de realizar mltiples tareas siempre que sea
prctico.
El uso de tcnicas de sondeo en lugar de interrupciones.
Disear los componentes del software con el conjunto mnimo de
caractersticas y capacidades que se requieran para realizar sus tareas en el
sistema.
La descomposicin en subsistemas o componentes de un programa debera
adaptarse a su descomposicin funcional, permitiendo una asignacin uno a
uno de los segmentos de programa a sus fines previstos.
Desacoplar los componentes y procesos para minimizar las
interdependencias entre ellos, impedir que un fallo o anomala en un
componente o proceso afecte a los estados de otros.
-
Tema 1: El problema de la seguridad en el software
Universidad Internacional de La Rioja (UNIR)
Este desacoplamiento se logra:
o Implementando funcionalidades modulares en el programa en unidades discretas de procesamiento autnomas.
o Establecer barreras para impedir la comunicacin de entre los componentes que no deben interactuar por diseo.
o Asignar espacio de memoria restringido a solo lectura o solo escritura para los procesos, para evitar que todos los componentes, menos los explcitamente
autorizados, cambien los valores de los datos.
o Favorecer el uso de funciones dbilmente acopladas frente a las fuertemente acopladas.
o Evitar las dependencias de los procesos con el tiempo (establecer un marco de tiempo
o Evitar secuencias invariantes de procesamiento que permitan un solo un camino de ejecucin para la realizacin de su tarea. Dichas secuencias pueden ser
explotadas por un ciberatacante para provocar inesperados eventos e
interacciones (que no sean los definidos en la secuencia de procesamiento
invariable).
No implementar caractersticas o funciones innecesarias. Si el diseo
incluye componentes COTS o del software libre con trozos de cdigo latente o
muerto, funciones innecesarias o no documentadas, el diseo debe incluir
contenedores para aislar los segmentos de cdigo no utilizados para prevenir el
acceso a los mismos durante su ejecucin.
Otro aspecto importante en la simplicidad del diseo es que la especificacin del mismo
debe ser totalmente trazable para determinar si el diseo fcilmente satisface todas sus
necesidades, incluyendo las relativas a los requisitos de seguridad. Esta
trazabilidad debe ser atrs hacia adelante y viceversa, es decir:
Trazabilidad hacia adelante un requisito y su correspondencia en el diseo.
Trazabilidad hacia atrs desde el diseo al requisito origen.
Trazabilidad hacia adelante desde el diseo y su correspondencia en el cdigo
implementado.
Trazabilidad hacia atrs desde el cdigo a la parte del diseo correspondiente.
Como podemos ver el implementar arquitecturas complejas, cuando se puede
resolver el diseo de forma simple, puede afectar negativamente a la
seguridad del sistema.
-
Tema 1: El problema de la seguridad en el software
Universidad Internacional de La Rioja (UNIR)
Objetivo: Reducir la complejidad del diseo para minimizar el nmero de
vulnerabilidades explotables por el atacante y debilidades en el sistema.
Mnimo privilegio
De acuerdo con el Software Assurance CBK [18] se define el mnimo privilegio como:
Mnimo privilegio es un principio segn el cual se concede a cada entidad (usuario, proceso o dispositivo) el conjunto ms restrictivo de privilegios necesarios para el desempeo de sus tareas autorizadas. La aplicacin de este principio limita el dao que puede resultar de un accidente, error o el uso no autorizado de un sistema. Tambin reduce el nmero de interacciones potenciales entre los procesos privilegiados o programas, por lo que se minimiza la probabilidad de ocurrencia de usos maliciosos de privilegios, no deseados o inapropiados.
Una de la principales razones por la que es necesario que una entidad se ejecute con los
mnimos privilegios posibles, es debido a que si un ciberatacante consigue
comprometer una mquina o es capaz de inyectar cdigo malicioso en un proceso del
sistema este se debera ejecutar con los mismos privilegios que tuviera el usuario en la
mquina o el proceso.
Este principio requiere que el diseador realice una lista de las entidades de software
con los recursos que utiliza y las tareas que debe realizar en el sistema, de forma que
especifique para cada uno los privilegios reales estrictamente necesarios.
Normalmente se suele asignar un usuario general con conjunto de privilegios que le
permitir realizar todas las tareas, incluidas las no necesarias. Ejemplos de errores
comunes son:
Aplicacin de derechos de administrador. Por ejemplo una conexin de
lectura a una base de datos con derechos de administrador.
Instalacin de aplicaciones y servicios con el usuario de administrador.
Puede implicar que si un ciberatacante explota una vulnerabilidad de la aplicacin,
obtendra los privilegios de administrador.
-
Tema 1: El problema de la seguridad en el software
Universidad Internacional de La Rioja (UNIR)
Usuarios con derechos de administrador. Se debe planificar para cada
usuario del sistema que aplicaciones, servicios, ficheros van a acceder y con qu
derechos (escritura, lectura, borrado ejecucin, etc.).
Servicios y procesos con privilegios por tiempo indefinido. Cada entidad
debe tener el privilegio necesario para realizar una tarea determinada slo el tiempo
necesario para completarla, ejecutndose normalmente con una cuenta de usuario
restringido.
Objetivo: lo que no est expresamente permitido est prohibido.
Separacin de privilegios
Es un principio relacionado con el anterior mnimo privilegio que esto implica la
asignacin a las diferentes entidades de un rol, que bsicamente implica lo siguiente:
Asignacin de un subconjunto de funciones o tareas de todas las que ofrece el
sistema.
Acceso a los datos necesarios que debe gestionar para llevar a cabo su funcin
en base a una serie de roles definidos.
Se evita as que todas las entidades sean capaces de acceder a la totalidad o
llevar a cabo todas las funciones del sistema con privilegios de superusuario y
por tanto que ninguna entidad tenga todos los privilegios necesarios para modificar,
sobrescribir, borrar o destruir todos los componentes y recursos que lo integran o el
sistema como un todo. Como ejemplo tenemos:
Servidor Web: el usuario final solo requiere la capacidad de leer el contenido
publicado e introducir datos en los formularios HTML. El administrador por el
contrario, tiene que ser capaz de leer, escribir y eliminar contenido y modificar el
cdigo de los formularios HTML.
-
Tema 1: El problema de la seguridad en el software
Universidad Internacional de La Rioja (UNIR)
Objetivo: asignacin a las diferentes entidades de un rol que implique el acceso a un
subconjunto de funciones o tareas y a los datos necesarios.
Separacin de dominios
Es un principio que en unin con los dos anteriores, mnimo privilegio y separacin
de privilegios y roles, que permite minimizar la probabilidad de que actores
maliciosos obtengan fcilmente acceso a las ubicaciones de memoria u objetos de datos
del sistema, mediante la utilizacin de tcnicas de compartimentacin de los usuarios,
procesos y datos de forma que las entidades:
Solo deben ser capaces de realizar las tareas que son absolutamente necesarias.
Llevarlas a cabo solamente con los datos que tenga permiso de acceso.
Utilizar el espacio de memoria y disco que tenga asignado para la ejecucin de esas
funciones.
Objetivo: minimizar la probabilidad de que actores maliciosos obtengan fcilmente
acceso a las ubicaciones de memoria u objetos de datos del sistema.
El aislar las entidades de confianza en su rea propia de ejecucin (con recursos
dedicados a esa rea de ejecucin) de otras menos confiables (procesadores de texto,
software de descarga, etc.), permite reducir al mnimo su exposicin a otras entidades e
interfaces externas susceptibles de ser atacadas por agentes maliciosos.
Las tcnicas que tenemos para llevar a cabo lo anterior:
Sistema operativo confiable.
Mquinas virtuales. Adems pueden proporcionar otras caractersticas que ayudan a
mejorar la fiabilidad, confiabilidad y resistencia como el balanceo de carga, soporte
para la restauracin de imgenes, etc.
Funciones sandboxing de lenguajes de programacin como Java, Perl, .NET (Code
Access Security), etc.
Sistemas Unix: chroot jails.
Trusted processor modules (TPM)21.
21 Es el nombre de una especificacin publicada que detalla un criptoprocesador seguro que puede almacenar claves criptogrficas que protejan la informacin y las implementaciones de esta especificacin, a menudo llamado el chip TPM o dispositivo de seguridad TPM. http://en.wikipedia.org
-
Tema 1: El problema de la seguridad en el software
Universidad Internacional de La Rioja (UNIR)
Separacin cdigo, ejecutables y datos configuracin y programa
Este principio pretende reducir la probabilidad de que un ciberatacante que
haya accedido a los datos del programa fcilmente pueda localizar y
acceder a los archivos ejecutables y datos de configuracin del mismo, lo
que le dara la posibilidad de manipular el funcionamiento del sistema a su inters e
incluso el escalado de privilegios.
La mayora de las tcnicas de separacin de los datos de programa y configuracin y
archivos ejecutables se realizan en la plataforma de ejecucin (procesador ms sistema
operativo). A continuacin vemos las ms principales [13]:
Utilizar plataformas con arquitectura Harvard22. Asegura que los datos de
programa y datos de control se almacenan en dos segmentos de
memoria fsicamente separados.
Establecer permisos de escritura y lectura de los datos de programa y sus
metadatos al programa que los cre a menos que exista una necesidad
explcita de otros programas o entidades para poder leerlos.
Los datos de configuracin del programa solo deben poder ser ledos y
modificados por el administrador. Excepcin de configuracin de una
aplicacin cliente o un navegador web donde los datos de preferencias del usuario
estn expresamente destinados a ser configurados por l. En este caso, al usuario
debe permitrsele leer y escribir dichos datos a travs de interfaz de preferencias con
una configuracin especialmente diseada.
Los datos utilizados por un script en un servidor Web deben ser
colocados fuera de rbol de documentos del mismo. La mezcla de datos
HTML y cdigo JavaScript puede constituir una vulnerabilidad explotable mediante
tcnicas de ataque como Cross Site Scripting (XSS).
Prohibir a los programas y scripts escribir archivos en directorios
escribibles como el de UNIX/TMP. Todos los directorios que los programas
necesitan escribir deben configurarse para que solo lo sean por ellos mismos.
22 Arquitectura Harvard hace referencia a las arquitecturas de computadoras que utilizaban dispositivos de almacenamiento fsicamente separados para las instrucciones y para los datos (en oposicin a la Arquitectura de von Neumann). http://es.wikipedia.org
-
Tema 1: El problema de la seguridad en el software
Universidad Internacional de La Rioja (UNIR)
Almacenar los archivos de datos, configuracin y programas ejecutables
en los directorios separados del sistema de archivos.
o Un programa ejecutable o script no debe ser escribible por nadie excepto el administrador (y el instalador si es necesario).
o Un archivo en un entorno de produccin no debe ser ledo por cualquier persona. o Los usuarios solo deben tener concedidos privilegios de ejecutar el programa.
Los programas y scripts que estn configurados para ejecutarse como servidor Web
de usuario nobody (debe suprimirse) deben ser modificados para funcionar bajo un nombre de usuario especfico.
Cifrar todos los archivos ejecutables e implementar un mdulo de
decodificacin que se ejecute como parte del inicio del programa para
desencriptarlos al iniciar su funcionamiento.
Incluir tcnicas de cifrado de archivos y la firma digital o
almacenamiento en un servidor de datos externos con conexin cifrada (por
ejemplo mediante SSL o TLS23) para aislar los datos de configuracin del software
de la manipulacin y eliminacin, si las tcnicas de control de acceso al sistema no
son lo suficientemente fuertes. Ello requerir que el software incluya la lgica de
cifrado para descifrar y validar la firma del archivo de configuracin al inicio del
programa.
Implantar clonado de sistemas como medida de recuperacin, desde un
servidor remoto (que guardara las imgenes y los datos de configuracin) mediante
una red de comunicaciones fuera de banda especfica y cifrada.
Objetivo: reducir la probabilidad de que un ciberatacante que haya accedido a los
datos del programa fcilmente pueda localizar y acceder a los archivos ejecutables y
datos de configuracin del programa.
23 Secure Sockets Layer (SSL) o Transport Layer Security (TLS)
-
Tema 1: El problema de la seguridad en el software
Universidad Internacional de La Rioja (UNIR)
Entorno de produccin o ejecucin inseguro
Asumir que todos los componentes del entorno de produccin y sistemas externos son
inseguros o no confiables, con ello se pretende reducir la exposicin de los
componentes del software a agentes potencialmente maliciosos que hayan podido
penetrar en el permetro de defensa (los lmites lo constituyen los cortafuegos) de la
organizacin y comprometer una mquina desde la que puedan expandirse e iniciar
otros ataques a otras pertenecientes a la red (pivoting).
El software debe ser diseado con una mnima dependencia de los datos
externos, se debe tener control completo sobre cualquier fuente de entrada de datos,
tanto los proporcionados por la plataforma de ejecucin como de sistemas externos,
debiendo validar todos los datos provenientes de las diferentes fuentes del
entorno antes de utilizarlos, pues implican una posibilidad de ataque.
Hay que realizar una descomposicin del sistema en sus componentes principales y
realizar una lista de las diferentes fuentes de datos externas, entre las que
podemos tener las siguientes:
Llamadas a sistema operativo. Se deben evitar realizndolas a travs de
middleware o APIs.
Llamadas a otros programas en la capa de aplicacin.
Llamadas a una capa de middleware intermedia.
APIs a los recursos del sistema. Las aplicaciones que utilizan las API no
deberan ser utilizados por usuarios humanos.
Referencias a objetos del sistema. Por ejemplo, las recuperaciones y referencias
a nombre de archivo se deben realizar con la ruta completa del recurso del sistema
para eliminar la posibilidad de ser redireccionado a otro directorio en el que se
almacena un caballo de Troya.
En aplicaciones cliente-servidor, el flujo de datos entre los mismos.
En aplicaciones Web el flujo de datos ente el cliente y el servidor.
Gran parte de los ataques a los sistemas TIC actualmente se deben a fallos o
carencias en la validacin de los datos de entrada, el confiar en la fuente que las
origin hace a la aplicacin vulnerable a ataques originados en el cliente al modificar
los datos en el origen o durante su transporte. Los atacantes pueden manipular
diferentes tipos de datos de entrada con el propsito de encontrar vas de compromiso
de la aplicacin.
-
Tema 1: El problema de la seguridad en el software
Universidad Internacional de La Rioja (UNIR)
Todos los tipos de entrada deber ser validados y verificados mediante
pruebas especficas. Entre los diferentes tipos de entradas a las aplicaciones
tenemos [13]:
Parmetros de lnea de comandos.
Variables de entorno.
Localizadores de recursos universales (direcciones URL) e identificadores (URI).
Referencias a nombres de archivo.
Subida contenido de archivos.
Importaciones de archivos planos.
Cabeceras Hyper Text Transfer Protocol (HTTP).
Parmetros HTTP GET.
Campos de formulario (especialmente los ocultos).
Las listas de seleccin, listas desplegables.
Cookies.
Comunicaciones mediante Java applets.
Los tipo de aplicaciones mas mas probabilidad presenten de sufrir este tipo de ataques
son las del tipo cliente-servidor, portales web y agentes proxy. Entre los tipos
de ataques que se pueden dar por la carencia de comprobacin de los datos de entrada,
la mayora para aplicaciones Web, tenemos:
Desbordamientos de Bfer (buffer overflow): heap, stack, entero y off-by-one.
Revelacin de informacin: indexacin de directorio, fuga de
informacin, path trasversal, localizacin de recursos predecibles.
Inyeccin de comandos: ataques de formato de cadena, comandos de sistema
operativo, cross-site scripting (XSS).
Inyeccin de cdigo SSI inyeccin SQL, HTTP splitting.
Contenidos mal formados.
Servicios Web: aparte de los anteriores tenemos, inyeccin XML, explotacin de
interfaces de administracin no protegidos.
-
Tema 1: El problema de la seguridad en el software
Universidad Internacional de La Rioja (UNIR)
Para evitar este tipo de vulnerabilidades se deben aplicar una serie de principios de
validacin de las entradas, entre los que tenemos [13]:
Centralizar la lgica de validacin de las entradas.
Asegrese que la validacin de la entrada no puede ser evitada.
Confiar en listas blancas24 validadas y filtrar las listas de negras.
Utilice las "listas negras" para filtrado preliminares al objeto de reducir la cantidad
de datos que deben someterse a validacin.
Validar todas las entradas de usuario incluidas las realizadas a travs de
proxies y agentes que acten en nombre de los usuarios. Se debe validar al menos
longitud correcta, el formato y la sintaxis. Ejemplo si se trata de un DNI contenga
slo ocho caracteres numricos, cualquier otra entrada deber ser rechazada.
Rechazar todos los contenidos ejecutables en las entradas provenientes de
fuentes no autorizadas.
Verificar que los programas que solicitan las llamadas tienen derecho (por la
poltica) a emitirlas.
Definir reacciones significativas a errores de validacin de entrada. El
rechazo a entradas mal formadas o fallidas es uno de los ms frecuentes.
Validar los datos de de salida de la aplicacin antes de mostrarlos al usuario o
redirigirlos a otro sistema.
Objetivo: evitar vulnerabilidades aplicando una serie de principios de validacin de las
entradas.
Registro de eventos de seguridad
Tradicionalmente los sistemas de auditora se dedicaban solo a grabar las acciones
realizadas por los usuarios del mismo. Sin embargo actualmente es necesario dotar a
las aplicaciones o sistemas de la capacidad de generar eventos (logs) de seguridad, para
garantizar que todas las acciones realizadas por un ciberatacante se observan y
registran, contribuyendo a la capacidad de reconocer patrones y aislar o bloquear la
fuente del ataque de modo que se evite su xito, en definitiva el dotarle de cierta
capacidad de deteccin de intrusiones.
24 Una lista blanca, lista de aprobacin whitelist en Ingls es una lista o registro de
entidades que, por una razn u otra, pueden obtener algn privilegio particular, servicio, movilidad, acceso o reconocimiento. Por el contrario la lista negra o blacklisting es la compilacin que identifica a quienes sern denegados, no reconocidos u obstaculizados. http://es.wikipedia.org
-
Tema 1: El problema de la seguridad en el software
Universidad Internacional de La Rioja (UNIR)
Las principales diferencias que distinguen los sistemas con registros de auditora de
seguridad de registro de los registros de eventos estndar son:
El tipo de informacin capturada en el registro de auditora: eventos de
seguridad.
Capacidad de gestin de los incidentes relacionados con los eventos de
seguridad.
Posibilidad de que los eventos de seguridad registrados en la aplicacin o sistema,
puedan ser utilizados en procesos reactivos despus de la ocurrencia de un
incidente.
El nivel de proteccin de integridad aplicado a los registros de auditora, para
evitar que sean intencionadamente o inadvertidamente eliminados, daados o
alterados. Suelen incluirse las siguientes medidas:
o Medidas de autenticacin de los actores que interactan con el sistema sea humano o de cualquier otro tipo, preferentemente de tipo fuerte mediante
certificados.
o Medidas de no repudio, basadas normalmente en firma digital. o Comprobacin de integridad mediante, aplicaciones de algoritmos de hash.
Objetivo: generar eventos (logs) de seguridad, para garantizar las acciones realizadas
por un ciberatacante se observan y registran.
Fallar de forma segura
El propsito de este principio es el reducir la probabilidad de que un fallo en el
software, pueda saltarse los mecanismos de seguridad de la aplicacin, dejndolo en un
estado de fallo inseguro vulnerable a los ataques. Es imposible implementar una
aplicacin perfecta que nunca falle, la solucin consiste en saber en todo momento cul
es su estado y tener implementado un mecanismo en caso que falle.
-
Tema 1: El problema de la seguridad en el software
Universidad Internacional de La Rioja (UNIR)
Algunas de las caractersticas especficas del diseo que minimizan la probabilidad de
que el software pase a un estado inseguro son:
Implementar temporizadores tipo watchdog que comprueben el estado de
los procesos sujetos a errores, como conexiones y operaciones a bases de datos,
llamadas a funciones, componentes distribuidos, etc.
Implementar una lgica de control de excepciones, para cuando la
aplicacin falle, registre un evento con error (que no proporcione al atacante
informacin sensible del sistema y le posibilite buscar otros fallos parecidos para
obtener ms informacin), implemente un umbral en el que se establezca un punto
de no retorno del cual no es posible recuperarse pues se estara en un estado
vulnerable de fallo seguro e intente tomar acciones correctivas antes de que el fallo
ocurra. El registro del error permitir al personal de mantenimiento investigar sus
causas y mostrar un mensaje al usuario con instrucciones a realizar sin desvelar
informacin tcnica que pudiera ser utilizada por un ciberatacante.
El software siempre debe comenzar y terminar su ejecucin en un
estado seguro. Los cambios de estado siempre deben ser deliberados y nunca
accidentales, sobre todo a estados vulnerables.
Evitar problemas de sincronizacin y secuenciacin, causados por el uso
compartido de informacin de estado (sobre todo en tiempo real). Usar para ello
enclavamientos (secciones crticas, mecanismos de sincronizacin) para hacer
cumplir las secuencias de acciones o eventos, de modo que no pueda ocurrir
accidentalmente o exista una condicin indeseable o fuera de secuencia.
Objetivo: reducir la probabilidad de que un fallo en el software, pueda saltarse los
mecanismos de seguridad de la aplicacin, dejndolo en un modo de fallo inseguro
vulnerable a los ataques.
Diseo de software resistente
Dos propiedades importantes del software seguro es la robustez y la resiliencia, el
siguiente principio pretende aumentar la resistencia de las aplicaciones reduciendo
al mnimo la cantidad de tiempo que un componente de software
defectuoso o fallido sigue siendo incapaz de protegerse de los ataques.
-
Tema 1: El problema de la seguridad en el software
Universidad Internacional de La Rioja (UNIR)
Algunas de las caractersticas de diseo que aumentarn la resistencia del software
incluyen [13]:
Capacidad de autocontrol y de limitar el uso de los recursos.
Uso de tcnicas de monitorizacin que permita al software detectar cualquier
anomala y error antes de crear una vulnerabilidad explotable.
Deteccin de estados anmalos cuando ocurra un error, el controlador de
excepciones debe devolver al software a un estado seguro conocido.
Proporcionar una realimentacin que permita que todos los supuestos y modelos
en los que el programa tome decisiones sean validados antes de ejecutarlas.
Aprovechar cualquier redundancia y funciones de recuperacin rpida a nivel
sistema, como copias de seguridad automticas, arquitecturas de alta disponibilidad
y almacenamiento y restauracin de imgenes.
Uso de plataformas virtuales que proporcionan ayuda a mejorar la fiabilidad,
confiabilidad y resistencia, con tcnicas como balanceo de carga, soporte para la
restauracin de imgenes, etc.
Uso de tcnicas de recuperacin que incluyan el uso de estructuras de datos
robustos, alteracin dinmica de los controles de flujo y tolerancia al error para que
pueda seguir funcionando de forma fiable en presencia de un nmero bastante
grande de errores de entrada del usuario.
Determinar la cantidad de informacin a proporcionar en los mensajes
de error para ayudar a los usuarios a corregir sus propios errores, frente a la
amenaza del ciberatacantes capaces de aprovechar el conocimiento que obtienen de
un error informativo.
Objetivo: reducir al mnimo la cantidad de tiempo que el componente de un software
defectuoso o fallido sigue siendo incapaz de protegerse de los ataques.
-
Tema 1: El problema de la seguridad en el software
Universidad Internacional de La Rioja (UNIR)
La seguridad por oscuridad: error
Una de las asunciones que se debe realizar a la hora de disear una aplicacin, es que el
atacante obtendr con el tiempo acceso a todos los diseos y todo el cdigo
fuente de la misma. La seguridad por oscuridad es un mecanismo de defensa
que consiste en ocultar en la aplicacin informacin sobre la misma para
sea difcil de obtener, pero que en poder de un atacante puede proporcionarle un
medio para comprometerla.
Howard y LeBlanc en el documento de referencia [14], no aconsejan que nunca se
dependa de la seguridad por oscuridad solamente indican que es vlido usarla como
una pequea parte de una estrategia general de defensa en profundidad
para confundir y dificultar las actividades de ataque de un intruso. A continuacin se
muestran algunos ejemplos de seguridad por oscuridad, que pueden constituir un
error:
Guardar informacin en archivos binarios. Un ciberatacante con
conocimientos de ingeniera inversa podra obtener dicha informacin.
Capetas ocultas en un servidor Web, con herramientas de anlisis forense se
podra acceder a ellas fcilmente. Incluso podra tener activado por error la opcin
de listado de directorios del servidor, con lo que un ciberatacante podra
visualizarlos completamente.
Falsa sensacin de seguridad de que el software que se ejecuta en un servidor
en una red dedicada pueda guardar secretos o no ser comprometido. Actualmente se
han dado casos de intrusiones en este tipo de redes como el caso Stuxnet.
Criptografa privada. No es conveniente confiar en cualquier algoritmo que no es
de conocimiento pblico y no ha sido analizado ampliamente, dado que al no haber
una verdadera prueba matemtica slida de la seguridad de la mayora de los
algoritmos criptogrficos, se consideran de confianza cuando un nmero suficiente
de personas han pasado mucho tiempo tratando de romperlo y no lo han logrado.
Ejemplo la criptografa de GSM, al principio era secreta pero cuando se supo el
algoritmo que utilizaba se lleg a romper.
Cambio del nombre del usuario administrador en un servidor con sistema
operativo de Microsoft para evitar que sea atacado. Existen herramientas que
pueden obtener el nombre de usuario del administrador directamente del
identificador.
-
Tema 1: El problema de la seguridad en el software
Universidad Internacional de La Rioja (UNIR)
Objetivo: concienciarse de que la seguridad por oscuridad es un mecanismo de
defensa que puede proporcionar a un atacante informacin para comprometer la
seguridad de una aplicacin.
Seguridad por defecto
Uno de los principios de seguridad cuyo cumplimiento exige el Real Decreto 3/2010
[22], de 8 de enero, por el que se regula el Esquema Nacional de Seguridad en el mbito
de la Administracin Electrnica, es el de la seguridad por defecto. En su artculo 19
indica lo siguiente:
Los sistemas deben disearse y configurarse de forma que garanticen la seguridad por defecto:
a. El sistema proporcionar la mnima funcionalidad requerida para que la organizacin solo alcance sus objetivos, y no alcance ninguna otra funcionalidad adicional.
b. Las funciones de operacin, administracin y registro de actividad sern las
mnimas necesarias, y se asegurar que solo son accesibles por las personas, o desde emplazamientos o equipos, autorizados, pudiendo exigirse en su caso restricciones de horario y puntos de acceso facultados.
c. En un sistema de explotacin se eliminarn o desactivarn, mediante el
control de la configuracin, las funciones que no sean de inters, sean innecesarias e, incluso, aquellas que sean inadecuadas al fin que se persigue.
d. El uso ordinario del sistema ha de ser sencillo y seguro, de forma que una
utilizacin insegura requiera de un acto consciente por parte del usuario.
De la lectura del artculo anterior se desprende que el principal objetivo del principio de
seguridad por defecto es el de minimizar la superficie de ataque de cualquier
aplicacin o sistema TIC, deshabilitando aquellos servicios y elementos no necesarios y
activando solo los necesarios.
-
Tema 1: El problema de la seguridad en el software
Universidad Internacional de La Rioja (UNIR)
Normalmente cuando se instala o pone en produccin una aplicacin o servicio, se
activan o instalan servicios que no se usan normalmente que pueden suponer un punto
potencial de entrada para los atacantes. Se debe elegir los componentes que van a ser
utilizados de forma explcita por los usuarios e instalarlos y configurarlos de forma
segura. Hay que minimizar los puntos vulnerables de la aplicacin o sistemas pues
amenazan su seguridad global por muy securizado que se tenga el resto. Por la tanto
hay que controlar los puntos de entrada que:
Entradas y salidas de red.
Nmero de puertos abiertos.
Puntos de entrada a la aplicacin, autenticados o no autenticados, locales o remotos
y privilegios administrativos necesarios.
Nmero de servicios. Desactivar los instalados por defectos no usados.
Nmero de servicios con privilegios elevados.
Nmero de cuentas de usuario administrador.
Estado de las listas de control de acceso a directorios y ficheros.
Control de cuentas de usuario y claves de acceso por defecto a servicios.
Contenido dinmico de pginas Web.
Varias organizaciones, como el National Institute of Standards and Technology (NIST),
la Agencia de Seguridad Nacional (NSA) y el Centro Criptolgico Nacional (CCN), han
publicado guas de seguridad de configuracin y scripts para productos COTS
populares y de software libre que incluye la eliminacin o restriccin de servicios,
usuarios, permisos y software innecesario.
El bastionado de sistemas es un proceso necesario en el marco de
cualquier proyecto que contemple la aplicacin de controles de seguridad
sobre los sistemas TIC que tiene como principio implementar todas las medidas de
seguridad a nivel tcnico posibles para proteger un sistema sin que pierda la
funcionalidad para la que fue destinado. Habr casos, en los que surjan conflictos que
no se puedan superar, estos deben ser cuidadosamente documentados para
proporcionar una justificacin de la renuncia a los requisitos de configuracin de
seguridad que impidan el correcto funcionamiento del software.
Objetivo: reducir la superficie de ataque de una aplicacin o sistema.
-
Tema 1: El problema de la seguridad en el software
Universidad Internacional de La Rioja (UNIR)
Resumen
En el presente apartado se ha realizado un estudio de los diferentes principios de
seguridad a tener en cuenta en el diseo y desarrollo de aplicaciones seguras, que nos
ayudaran a proteger y disponer de aplicaciones seguras con un mnimo de
vulnerabilidades. Como resumen se muestra un grfico que sintetiza el objetivo de cada
principio.
Principio Objetivo
Defensa en
profundidad
Introducir mltiples capas de seguridad para reducir la
probabilidad de compromiso del sistema.
Simplicidad del diseo
Reducir la complejidad del diseo para minimizar el nmero de
vulnerabilidades explotables por el atacante y debilidades en el
sistema.
Mnimo privilegio Lo que no est expresamente permitido est prohibido.
Separacin de
privilegios
Asignacin a las diferentes entidades de un rol que implique el
acceso a un subconjunto de funciones o tareas y a los datos
necesarios.
Separacin de
dominios
Minimizar la probabilidad de que actores maliciosos obtengan
fcilmente acceso a las ubicaciones de memoria u objetos de
datos en el sistema.
Separacin cdigo,
ejecutables y datos
configuracin y
programa
Reducir la probabilidad de que un ciberatacante que haya
accedido a los datos del programa fcilmente pueda localizar y
acceder a los archivos ejecutables y datos de configuracin del
programa.
Entorno de
produccin o
ejecucin inseguro
Evitar vulnerabilidades aplicando una serie de principios de
validacin de las entradas.
Registro de eventos de
seguridad
Generar eventos (logs) de seguridad, para garantizar las acciones
realizadas por un ciberatacante se observan y registran
Fallar de forma segura
Reducir la probabilidad de que un fallo en el software, pueda
saltarse los mecanismos de seguridad de la aplicacin, dejndolo
en un modo de fallo inseguro vulnerable a los ataques.
Diseo de software
resistente
Reducir al mnimo la cantidad de tiempo que un componente de
un software defectuoso o fallido sigue siendo incapaz de
protegerse de los ataques.
La seguridad por
oscuridad: error
Concienciarse de que la seguridad por oscuridad es un
mecanismo de defensa que puede proporcionar a un atacante
informacin para comprometer la seguridad de una aplicacin.
Seguridad por defecto Reducir la superficie de ataque de una aplicacin o sistema.
Tabla 2 Objetivos Principios de seguridad
-
Tema 1: El problema de la seguridad en el software
Universidad Internacional de La Rioja (UNIR)
1.5. Amenazas a la seguridad del software
Introduccin
Las aplicaciones, tal y como se expuso en la introduccin del presente tema, son
amenazadas y atacadas, no solo en su fase de operacin, sino que tambin en todas las
fases de su ciclo de vida.
El principal objetivo de la seguridad del software es el mantener sus propiedades
de seguridad frente a los ataques realizados por personal malicioso sobre
sus componentes y poseer el mnimo posible de vulnerabilidades
explotables. Para conseguir que el desarrollo de una aplicacin posea las propiedades
y principios de diseo del software seguro presentados en los apartados anteriores, se
necesita que el personal de diseo y desarrollo desarrollen dos perspectivas:
Defensor
El equipo trabaja para construir