SlideShare ist ein Scribd-Unternehmen logo
1 von 11
Downloaden Sie, um offline zu lesen
CERTIFICACIÓNDESISTEMAS
1
El Libro Naranja
El Departamento de Defensa de Estados Unidos desarrolló la norma Trusted Computer System Evaluation
Criteria(TCSEC),que se utilizópara evaluar los sistemas operativos, aplicaciones y diferentes productos. Estos
criterios de evaluación son publicados en un libro con una cubierta de color naranja, que se llama,
apropiadamente, el Libro Naranja.
Los clientes utilizan la calificación de seguridad que los criterios presentaban como métrica cuando comparan
diferentesproductos.También proporciona orientación a los fabricantes para que sepan que especificaciones
construir,y proporcionaunprocesode evaluación de ventanilla única para que los clientes no necesitan tener
componentes individuales dentro de los sistemas evaluados.
El libronaranja se utilizó para evaluar si un producto contiene las propiedades de seguridad que el proveedor
reclama que tiene y si el producto era apropiado para una aplicación o función específica. El Libro Naranja fue
utilizado para revisar la funcionalidad, eficacia y seguridad de un producto durante su evaluación, y utiliza las
clases que se desarrollaron para abordar los patrones típicos de los requisitos de seguridad.
TCSEC proporcionaunsistemade clasificaciónque se divide endivisiones jerárquicas de los niveles de garantía
de:
A. Protección verificada
B. Protección Obligatoria
C. Protección Discrecional
D. Seguridad Mínima
Clasificación A representa el más alto nivel de seguridad, y D representa el nivel más bajo de seguridad.
Cada divisiónpuede tenerunaomás clases numeradas con un conjunto correspondiente de los requisitos que
se debencumplirparaque un sistemalogre unacalificaciónparticular.Lasclasesconnúmerosmás altos ofrecen
un mayor grado de confianza y seguridad. Así B2 ofrecería más seguridad que B1 y C2 ofrecería más seguridad
que C1.
El criterio se divide en siete áreas diferentes:
• Políticade seguridad. La política debe ser explícita y bien definida y ejecutada por los mecanismos
del sistema.
• Identificación. Sujetos individuales deben ser identificados de forma única.
• Etiquetas. Etiquetas de control de acceso deben estar asociados correctamente con objetos.
• Documentación. La documentación debe ser proporcionada, incluyendo prueba, diseño y
documentos de especificaciones, guías de usuario y manuales.
• Rendiciónde cuentas.Losdatosde auditoría deben ser capturados y protegidos para hacer cumplir
la rendición de cuentas.
CERTIFICACIÓNDESISTEMAS
2
• Aseguramientodel ciclode vida.Software,hardware yfirmware debenser capaces de ser probados
individualmente para garantizar que cada uno hace cumplir la política de seguridad de una manera
efectiva a lo largo de su vida.
• La protección continúa. Los mecanismos de seguridad y el sistema como un todo deben realizar
predecible y aceptablemente en diferentes situaciones continuamente.
Estas categorías sonevaluadasde formaindependiente,perolacalificaciónasignadaal final no especifica estos
diferentes objetivos de forma individual. La calificación es una suma total de estos elementos.
Cada divisiónyclase incorporalosrequisitosde losinferiores. Esto significa que C2 debe cumplir sus requisitos
de criteriosytodos losrequisitos de C1, B3 y tiene sus requisitos para cumplir junto con los de C1, C2, B1, y B2.
Se espera que cada división o clase suba la apuesta en los requisitos de seguridad y para cumplir con los
requisitos de todas las clases y divisiones inferiores.
Así, cuandoun proveedorpresentóunproductoparala evaluación, lopresentóal NCSC. El grupo que supervisó
los procesos de evaluación se llama el Programa de Evaluación de Productos de Confianza (TPEP). Productos
evaluados con éxito fueron colocados en la lista de los productos evaluados (EPL) con su correspondiente
calificación. Cuando los consumidores estén interesados en determinados productos y sistemas, podrán
comprobar el EPL apropiado para conocer sus niveles de seguridad asignados.
División D: Protección Mínima
Sólohay unaclase en laDivisiónD. Se reserva para los sistemas que han sido evaluados, pero dejar de cumplir
con los criterios y requisitos de las divisiones superiores.
División C: Protección Discrecional
La categoría de calificación C tiene dos clasificaciones individuales de aseguramiento dentro de ella. Cuanto
mayor sea el número de la calificación de la garantía, mayor será la protección.
C1: Protección de Seguridad Discrecional. Control de acceso discrecional se basa en las personas y / o grupos.
Se requiere una separación de los usuarios y la información, y la identificación y autenticación de entidades
individuales. Algún tipo de control de acceso es necesario, así los usuarios pueden asegurarse que su
informaciónnoseráaccediday corrompidaporotros. La arquitecturadel sistemadebe proporcionarundominio
de ejecuciónprotegido paraque losprocesosdel sistemaprivilegiados no se ven afectados negativamente por
losprocesosde menorprivilegio.Tiene que haber formas específicas de validación de integridad operativa del
sistema.Losrequisitosde documentaciónincluyendocumentaciónde diseño, lo que demuestra que el sistema
fue construidoparaincluirmecanismosde protección,documentaciónde prueba(plande pruebasyresultados),
un manual de instalación(paraque lasempresassepancómo instalar y configurar el sistema correctamente), y
manuales de usuario.
El tipo de ambiente que requeriría esta calificación es aquel en el que los usuarios están procesando la
información,al mismonivel de sensibilidad;porlotanto,nose requierenmedidasestrictasde control de acceso
y auditoría. Sería un entorno de confianza con las preocupaciones de seguridad bajos.
C2: Protecciónde AccesoControlado. Los usuariosdebenser identificados individualmente para proporcionar
control de acceso más precisoyfuncionalidadde auditoría.Mecanismosde control de acceso lógicos se utilizan
para hacer cumplirla autenticación y el carácter único de identificación de cada individuo. Eventos relevantes
para la seguridad se auditan, y estos registros deben ser protegidos de la modificación no autorizada. La
CERTIFICACIÓNDESISTEMAS
3
arquitectura debe proporcionar el recurso, o un objeto, el aislamiento de protección de modo adecuado se
puede aplicar a los recursos y las acciones tomadas sobre ellos pueden ser adecuadamente auditadas. El
concepto de reutilización de objetos también debe ser invocado, lo que significa que todos los datos de
retenciónmedianodebencontenerrestosde lainformacióndespuésde haberlo publicado para otro objeto de
uso. Si un sujeto utiliza un segmento de la memoria, que el espacio de memoria no debe contener ninguna
información después de que el sujeto se hace usando la misma. Lo mismo es cierto para los medios de
almacenamiento,objetosque estánpoblados,ylosarchivostemporalesque se crean,todoslosdatosdeben ser
borrados de manera eficiente una vez que el sujeto se hace con ese medio.
Esta clase requiere un método más granular de proporcionar control de acceso. El sistema debe cumplir los
procedimientos de inicio de sesión estricta y proporcionar capacidades de toma de decisiones cuando los
sujetos soliciten acceso a objetos. Un sistema C2 no puede garantizar que no se verá comprometida, pero
suministra un nivel de protección que haría que los intentos de comprometer más difícil de lograr.
El tipode ambiente que requeriría de los sistemas con una calificación C2 es uno en el que los usuarios son de
confianza, pero se requiere un cierto nivel de rendición de cuentas. C2, en general, se ve como la clase más
razonable para aplicaciones comerciales, pero el nivel de protección es aun relativamente débil.
División B: Protección obligatoria
Control de acceso obligatorioesimpuesto porel usode lasetiquetasde seguridad.Laarquitectura se basa en el
modelo de seguridad de Bell-LaPadula.
B1: Etiquetado de Seguridad. Cada objeto de datos debe contener una etiqueta de clasificación y cada sujeto
debe tener una etiqueta de autorización. Cuando un sujeto intenta acceder a un objeto, el sistema debe
comparar las etiquetas de seguridad del sujeto y del objeto para garantizar que las acciones solicitadas son
aceptables. Los datos que salen del sistema también deben contener una etiqueta de seguridad precisa. La
política de seguridad se basa en una declaración informal, y las especificaciones de diseño son revisadas y
verificadas.
Esta evaluación de seguridad está diseñado para entornos que requieren sistemas para manejar los datos
clasificados.
B2: Protección estructurada. La política de seguridad está claramente definida y documentada, y el diseño e
implementacióndel sistemase sometenalosprocedimientosde revisión y pruebas más exhaustivas. Esta clase
requiere mecanismos de autenticación más estrictos e interfaces bien definidas entre capas. Sujetos y
dispositivos requieren etiquetas, y el sistema no debe permitir canales encubiertos. Un camino de confianza
para los procesos de inicio de sesión y autenticación debe estar en su lugar, lo que significa que el sujeto se
comunica directamente con la aplicación o el sistema operativo, y no existen trampillas. No hay manera de
evitar o comprometer este canal de comunicación. Las funciones de operador y de administración están
separadosdentrodel sistema para proporcionar más confianza y proteger la funcionalidad operativa. Espacios
de direcciones distintas se deben proporcionar para aislar los procesos, y se lleva a cabo un análisis de canal
encubierto. Esta clase añade aseguramiento mediante la adición de requisitos para el diseño del sistema.
El tipo de ambiente que requeriría sistemas de B2 es uno que procesa los datos sensibles que requieren un
mayor grado de seguridad. Este tipo de ambiente requeriría sistemas que son relativamente resistentes a la
penetración y el compromiso.
CERTIFICACIÓNDESISTEMAS
4
B3: Dominiosde Seguridad. En esta clase,másgranularidadse proporcionaencada mecanismode protección,y
se excluye el código de programación que no es necesario para apoyar la política de seguridad. El diseño e
implementación no deben proporcionar demasiada complejidad, porque a medida que la complejidad de un
sistema aumenta, es necesario que el nivel de habilidad de los individuos aumente para probar, mantener y
configurarlo; por lo tanto, la seguridad general puede ser amenazada. Los componentes del monitor de
referencia deben ser lo suficientemente pequeños para probarlos adecuadamente y estar a prueba de
manipulaciones.Lafunciónde administradorde seguridadestáclaramente definida,yel sistemadebe ser capaz
de recuperarse de fallas sin que su nivel de seguridad se vea comprometido.
Cuandoel sistemase iniciaycarga el sistemaoperativoyloscomponentes,hayque hacerloenunestadoseguro
inicial para asegurar que en cualquier debilidad del sistema no se puede tomar ventaja en esta porción de
tiempo.
El tipode ambiente que requiere sistemas B3 es un entorno de alta seguridad que procesa la información muy
sensible. Se requiere que los sistemas sean altamente resistentes a la penetración.
División A: Protección Verificada
Los métodosformalesse utilizan para garantizar que todos los sujetos y objetos se controlan con los controles
de acceso discrecional yobligatorio.El diseño,desarrollo,implementación, y la documentación son mirados de
una manera formal y detallada. Los mecanismos de seguridad entre B3 y A1 no son muy diferentes, pero la
formaen que el sistemafue diseñadoydesarrolladose evalúa en un procedimiento mucho más estructurado y
riguroso.
A1: Diseño verificado. Las características de la arquitectura y de protección no son muy diferentes de los
sistemas que logren una calificación de B3, pero la seguridad de un sistema A1 es mayor que un sistema B3
debido a la formalidad en el funcionamiento del sistema A1 como fue diseñado, la forma en que se
desarrollaron las especificaciones, y el nivel de detalle en las técnicas de verificación.
Técnicas formales se utilizan para demostrar la equivalencia entre las especificaciones TCB y el modelo de la
política de seguridad. Una configuración de cambio más estricto se puso en marcha con el desarrollo de un
sistemade A1,y el diseñogeneral puede serverificado.En muchos casos, incluso la forma en que el sistema se
entregaal cliente estábajoescrutinioparaasegurarque nohay manerade poneren peligroel sistema antes de
alcanzar su destino.
El tipo de ambiente que requeriría sistemas A1 es el más seguro de los entornos protegidos. Este tipo de
ambiente se ocupa de la información de alto secreto y no se puede confiar en cualquier persona que utilice
adecuadamente los sistemas sin autenticación estricta, restricciones, y la auditoría.
LIBRO BLANCO
La evaluaciónde laseguridadTecnología de la Información Criteria (ITSEC) fue el resultado de la armonización
de los criterios de evaluación de seguridad de cuatro países europeos: Francia, Alemania, los Países Bajos y el
Reino Unido. El ITSEC reemplazado cada uno de sus propios criterios nacionales y se convirtió en una de facto
criterios europeos. El ITSEC ha estado en uso operativo dentro de esquemas de evaluación y certificación
europeos desde julio de 1991.
El ITSEC tenía por objeto la evaluación de los productos y sistemas (que pueden estar compuestos de muchos
productos y componentes seguros). El ITSEC separó la funcionalidad y seguridad. Un producto o sistema fue
CERTIFICACIÓNDESISTEMAS
5
evaluadacontrauna garantía específicadel documento de destino en el que se especificaban las funciones de
seguridad del producto o sistema, así como una evaluación reclamada o nivel de garantía. Un producto o
sistema a evaluar se denomina TOE (Target of Evaluation) y se verifica contra un objetivo de seguridad.
El ITSEC dirigióuna vista ampliada de la confidencialidad, integridad y disponibilidad, con el fin de abordar de
maneramás explícitatantolasnecesidadesmilitaresy comerciales. El ITSEC define la confidencialidad como la
prevenciónde ladivulgaciónnoautorizadade la información;integridadcomolaprevención de la modificación
no autorizada de la información; y, la disponibilidad como la prevención de la retención no autorizada de los
recursos.
Se definen siete niveles de evaluación, denominados E0 a E6, que representan una confianza para alcanzar la
metau objetivode seguridad.E0representa una confianza inadecuada. E1, el punto de entrada por debajo del
cual no cabe la confianza útil, y E6 el nivel de confianza más elevado.
Criterios comunes
En 1990, la OrganizaciónInternacional de Normalización(ISO) identificólanecesidadde criteriosinternacionales
de evaluaciónestándarparaserusados a nivel mundial. El proyecto Common Criteria se inició en 1993, cuando
variasorganizacionesse unieronparacombinary armonizarloscriteriosexistentesyemergentes de evaluación
(TCSEC, ITSEC, Canadian Trusted Computer Product Evaluation Criteria [CTCPEC], y los criterios federales). El
Common Criteria se ha desarrollado a través de una colaboración entre las organizaciones nacionales de
normalizaciónde seguridaddentrode losEstadosUnidos,Canadá,Francia,Alemania,el ReinoUnidoylosPaíses
Bajos.
El beneficio de tener un conjunto de criterios mundialmente reconocidos y aceptados es que ayuda a los
consumidoresmediantelareducciónde lacomplejidadde lascalificaciones y la eliminación de la necesidad de
entenderladefiniciónyel significadode diferentescalificacionesdentro de varios sistemas de evaluación. Esto
tambiénayudaa losvendedores,porque ahora se puede construirsobre unconjuntoespecífico de requisitos si
se quierenvendersusproductos a nivel internacional, en lugar de tener que cumplir con varias clasificaciones
diferentes, con diferentes reglas y requisitos.
El Libro Naranja evaluaba todos los sistemas de la forma en comparación con el modelo Bell-LaPadula. El
CommonCriteriaofrece másflexibilidadmediantelaevaluación de un producto contra un perfil de protección,
el cual se estructurapara hacer frente a la necesidad de seguridad en el mundo real. Así, mientras que el Libro
Naranja dice: "Todo el mundo marcha en esa dirección en esta forma utilizando este camino," los criterios
comunespregunta:"Estábien,¿cuálessonlasamenazasque enfrentamoshoyycuálessonlasmejoresmaneras
de luchar contra ellas?"
Bajo el modelo de Common Criteria, una evaluación se lleva a cabo en un producto y se le asigna un nivel de
garantía de Evaluación(EAL).Las pruebasexhaustivas y rigurosas en tareas detalladas aumentan los niveles de
aseguramiento. El Common Criteria tiene siete niveles de garantía. El rango es de EAL1, donde las pruebas
funcionalidadse llevaacabo, a EAL7, donde se realiza la prueba a fondo y el diseño del sistema se verifica. Los
diferentes paquetes EAL se enumeran a continuación:
• EAL1 Funcionalmente probado
• EAL2 Estructuralmente probado
• EAL3 Metódicamente probado y comprobado
CERTIFICACIÓNDESISTEMAS
6
• EAL4 Metódicamente diseñado, probado y revisado
• EAL5 Semiformalmente diseñado y probado
• EAL6 Semiformalmente verificado diseño y prueba
• EAL7 Formalmente verificado diseño y prueba
El Common Criteria utiliza perfiles de protección en su proceso de evaluación. Este es un mecanismo que se
utilizaparadescribirunanecesidadenel mundoreal paraunproducto que no está actualmente en el mercado.
El perfil de protección contiene el conjunto de requisitos de seguridad, su significado y el razonamiento, y la
calificacióncorrespondienteEALque el productodestinadorequerirá.Enel perfil de protecciónse describen los
supuestosdel entorno,losobjetivosylasexpectativasdel nivelfuncional yde garantía.Cada amenazarelevante
aparece juntocon la formaenque va a sercontroladopor objetivosespecíficos.El perfil de protección también
justifica el nivel de garantía y los requisitos para asegurar cada mecanismo de protección.
El perfil de protección proporciona un medio para un consumidor, u otros, para identificar las necesidades
específicas de seguridad. Si alguien identifica una necesidad de seguridad que actualmente no está siendo
abordado por cualquier producto actual, esa persona puede escribir un perfil de protección que describe el
productoque sería una soluciónparaeste problemadel mundoreal.El perfilde protecciónvaaproporcionarlos
objetivos necesarios y mecanismos de protección para alcanzar el nivel de seguridad requerido, así como una
lista de cosas que podrían salir mal durante este tipo de desarrollo del sistema. Esta lista es utilizada por los
ingenieros que desarrollan el sistema, y luego por los evaluadores para asegurarse de que los ingenieros lo
desarrollaron como se esperaba.
El CommonCriteriafue desarrolladoparapegarse alasclasesde evaluación,perotambiénparaconservarcierto
grado de flexibilidad.Losperfilesde protecciónse handesarrolladoparadescribirlafuncionalidad,lagarantía,la
descripción y justificación de los requisitos del producto.
Al igual que otros criterios de evaluación antes de ella, el Common Criteria trabaja para responder a dos
preguntas básicas acerca de los productos que se están evaluando: ¿qué hacen sus mecanismos de seguridad
(funcionalidad)?, y ¿cómo está seguro de esto (garantía)? Este sistema establece un marco que permite a los
consumidoresespecificarclaramentesusproblemasde seguridad, a los desarrolladores especificar su solución
de seguridad para esos problemas, y a los evaluadores para determinar de manera inequívoca lo que el
producto cumple en realidad.
Un perfil de protección contiene las siguientes cinco secciones:
• Elementos descriptivos. Proporciona el nombre del perfil y una descripción del problema de
seguridad que hay que resolver.
• Justificación.Justificael perfil ydauna descripciónmásdetallada del problema del mundo real que
hay que resolver. El entorno, los supuestos de uso, y las amenazas se ilustran junto con la
orientaciónde laspolíticas de seguridad que pueden ser compatibles con los productos y sistemas
que se ajusten a este perfil.
• Requerimientos funcionales. Establece un límite de protección, es decir, las amenazas o
compromisosdentrode estafronteraparaser contrarrestados.El producto o sistema ha de cumplir
el límite establecido en esta sección.
CERTIFICACIÓNDESISTEMAS
7
• Requisitos de aseguramiento del Desarrollo. Identifica los requisitos específicos del producto o
sistema que se deben cumplir durante las fases de desarrollo, desde el diseño hasta la
implementación.
• Requisitos de aseguramiento de la Evaluación. Establece el tipo y la intensidad de la evaluación.
El procesode evaluación es sólo una etapa de determinación de la funcionalidad y la garantía de un producto.
Una vez que el producto alcanza una calificación específica, sólo se aplica a la versión en particular y sólo a
ciertasconfiguracionesde ese producto.Asíque si una empresa compra un producto de servidor de seguridad,
ya que tiene un alto índice de seguridad, la empresa no tiene ninguna garantía de que la próxima versión del
software tendráesacalificación.Lapróximaversióntendráque ira travésde su propioexamende evaluación.Si
esta misma empresa compra el producto firewall y lo instala con configuraciones que no se recomiendan, el
nivel de seguridad que lacompañía esperaba alcanzar puede irse fácilmente por el desagüe. Por lo tanto, toda
esta calificación es un método formal de revisión de un sistema que está siendo evaluado en un laboratorio.
Cuandoel productose llevaacabo enun entornoreal,factoresdistintosde la calificación deben ser abordados
y evaluados para asegurar que está protegiendo adecuadamente los recursos y el entorno.
ISO/ IEC15408 es el estándarinternacional que se utilizacomolabase para laevaluación de las propiedades de
seguridad de los productos en el marco CC. En realidad, tiene tres partes principales:
• ISO / IEC15408-1 Introducción y modelo de evaluación general.
• ISO / IEC15408-2 Componentes funcionales de seguridad.
• ISO / IEC15408-3 Los componentes de aseguramiento de la Seguridad.
ISO/ IEC 15.408-1 establece losconceptosyprincipiosgeneralesdel modelode evaluaciónCC.Estaparte define
lostérminos,establece el concepto básico de TOE, describe el contexto de evaluación, y el público necesario.
Proporciona los conceptos clave para el PP, los requisitos de seguridad, y las directrices para el objetivo de
seguridad.
ISO / IEC 15.408-2 define los requisitos funcionales de seguridad que serán juzgados durante la evaluación.
Contiene uncatálogode componentesfuncionales de seguridad predefinidos que se asigna a la mayoría de las
necesidades de seguridad. Estos requisitos se organizan en una estructura jerárquica de clase s, familias y
componentes.Tambiénproporcionaorientaciónsobre laespecificaciónde losrequisitosde seguridad a medida
si no existe ningún componente de seguridad predefinido funcional.
ISO/ IEC 15408-3 define losrequisitosde garantía,que también se organizanenunajerarquíade clases,familias
y componentes.Estaparte describe losnivelesde aseguramientode evaluación,que esunaescalapara medir la
seguridadde los TOEs,y proporcionaloscriteriosparala evaluaciónde losperfiles de protección y objetivos de
seguridad.
Así que losvendedoresde productossiguenestasnormasenlaconstrucciónde losproductos que van a poner a
travésdel procesode evaluación CC y los evaluadores de productos sigan estas normas al realizar los procesos
de evaluación.
Seguridad en el Desarrollo de Aplicaciones y Sistemas
Seguridad
CERTIFICACIÓNDESISTEMAS
8
Como se ha comentado anteriormente, la seguridad de la información se basa en los tres siguientes pilares
principales:
 Confidencialidad. Sólo se debe permitir el acceso a los datos a los cuales el usuario está autorizado.
 Integridad. Se debe asegurar que los datos no son manipulados por usuarios no autorizados.
 Disponibilidad.Losdatosdebenestardisponiblesde manera permanenteparalos usuarios autorizados.
Para garantizar el cumplimiento de estos tres fundamentos, durante el desarrollo de las aplicaciones deben
implementarse distintos controles de seguridad. En general, pueden encajarse en los siguientes grupos en
función del objeto para el cual se construyan:
 Controles de prevención de accesos no autorizados.
 Controles sobre las entradas de datos en la aplicación, para evitar que ciertos datos provoquen que la
aplicación no se comporte de la manera deseada.
 Controles para asegurar el funcionamiento correcto de la aplicación cuando está siendo directamente
atacada.
 Controlesde gestiónde lapropiaaplicaciónparamonitorizarlaactividadde laaplicacióny configurar su
comportamiento.
1.- PRINCIPIOS DE DESARROLLO SEGURO
Independientemente dellenguaje ylaarquitecturautilizados,el desarrollode laaplicacióny de los controles de
seguridadnecesariosdebenllevarse acaboteniendoencuentaunaserie de principios de seguridad que traten
de reducir la probabilidad de la realización de amenazas y el impacto de éstas en el caso de que se hayan
producido ya.
Minimizar la superficie de ataque
Por ejemplo, si una aplicación implementa un módulo de ayuda con una funcionalidad de búsqueda, dicha
funcionalidad puede ser vulnerable a inyección SQL. Si la ayuda está limitada a usuarios autorizados, la
posibilidad de ataque se reduce. Si además la funcionalidad de búsqueda utiliza rutinas de validación de los
datosde entrada,laposibilidadde inyecciónSQLdisminuye drásticamente.Sinembargo,si laayuda se rediseña
y se eliminalaposibilidadde búsqueda(proporcionando como alternativa una mejor interfaz de usuario), esto
prácticamente elimina la superficie de ataque del módulo de ayuda, incluso si la ayuda fuese accesible desde
Internet.
Seguridad por defecto
Cuandouna aplicaciónse despliegaensuentornode producción,utilizaunaserie de opciones de configuración
que se establecen por defecto. Estas opciones por defecto deben ser tales que la aplicación sea segura. Es
responsabilidad del usuario modificar dichas opciones aún a costa de disminuir la seguridad.
Por ejemplo,pordefectounaaplicacióndebería tener habilitada la expiración de contraseñas y una política de
complejidadde clavesadecuada.Unavez desplegada,losusuariospodrían deshabilitar estas opciones o relajar
las restricciones aún a costa de aumentar el riesgo, pero siempre bajo su responsabilidad.
Ejecución con los mínimos privilegios
El principiode mínimosprivilegiosestablece que las cuentas deben tener el menor nivel de privilegios posible
para realizar las tareas de negocio. Este nivel de privilegios abarca tanto permisos de usuarios como permisos
sobre recursos como CPU, memoria, red, sistema de ficheros, etc.
CERTIFICACIÓNDESISTEMAS
9
Por ejemplo, si una aplicación sólo requiere acceso a la red, permisos de lectura sobre una tabla de la base de
datos y la posibilidad de escribir en un fichero de log, estos deben ser los únicos permisos que debe tener la
cuenta bajo la que se ejecute la aplicación. Bajo ningún concepto la aplicación debe tener permisos
administrativos.
Defensa en profundidad
El principiode defensa en profundidad sugiere que donde un único control de seguridad podría ser asumible,
sería mejor utilizar varios controles que afronten el riesgo desde distintos puntos de vista. Los controles de
seguridad, cuando se utilizan con el enfoque de defensa en profundidad, hacen que vulnerabilidades que
pueden ser muy graves, sean tremendamente difíciles de explotar.
Por ejemplo, siguiendo este principio, una aplicación implementaría distintas medidas en varias capas para
prevenir inyecciones SQL: rutinas de validación de datos para comprobar las entradas del usuario, consultas
parametrizadas a la hora de ejecutar las sentencias SQL y establecimiento adecuado de permisos a nivel de
tablas y procedimientos almacenados en la base de datos.
Fallar de forma segura
En muchas ocasionesse producenerrorescuandolas aplicaciones realizan una transacción. El estado en que la
aplicación queda cuando se produce dicho error, determina si la aplicación es segura o no.
Detección de intrusos
La detección de intrusiones requiere la existencia de tres elementos:
• Capacidad para incluir en el log eventos relevantes de seguridad.
• Procedimientos que aseguren que los logs son monitorizados con regularidad.
• Procedimientos para responder adecuadamente a una intrusión una vez ha sido detectada
Toda la informaciónde seguridad relevante debe ser registrada en un log. Es posible que un problema que no
pudo ser detectado en tiempo de ejecución, pueda serlo gracias a la revisión de los logs.
Evitar la seguridad por ocultación
La seguridadporocultaciónesunmecanismode seguridaddébil ygeneralmente fallacuandoesel únicocontrol
existente. Por ejemplo, la seguridad de una aplicación no puede depender de mantener en secreto el código
fuente.Unejemplopodríaserel sistemaoperativoLinux;sucódigofuenteestádisponible,sinembargo,cuando
está correctamente configurado, es un sistema seguro.
Mantener la simplicidad
Cuando el código fuente es muy complejo es más complicado hacerlo seguro. Es mejor mantenerlo simple.
Solucionar correctamente los problemas de seguridad
Una vez que se ha detectadounproblemade seguridad,esfundamental desarrollarpruebasparareproducirlo y
detectar la causa raíz. Una vez que se desarrolla una solución válida es clave garantizar que no se introducen
problemas de regresión.
Por ejemplo, un usuario descubre que puede ver datos de otro usuario modificando un valor en una cookie.
Perodebidoaque el mecanismode gestiónde cookies es compartido por todas las aplicaciones, un cambio en
el código de este control afecta no sólo a la aplicación en la que se detectó el problema, sino a todas. Por lo
tanto, la solución debe ser probada en todas las aplicaciones.
CERTIFICACIÓNDESISTEMAS
10
2.- VERIFICACIÓN
El proceso de verificación de la seguridad de una aplicación puede dividirse en tres etapas principales:
A.- Preparación
A la hora de llevar a cabo una verificación efectiva de la seguridad de una aplicación es crítico que el equipo
encargado de realizar esta tarea:
• Entienda el propósito de la aplicación y qué puntos dentro de ella son más críticos.
• Identifique las principales amenazas, su motivación y cómo podrían atacar la aplicación.
Para ello,antesde comenzarel procesode verificación,el equipo deberá estar familiarizado con los siguientes
aspectos:
• Código fuente: El equipo deberá tener conocimientos del lenguaje utilizado en la codificación y de las
características de ese lenguaje desde la perspectiva de seguridad.
• Contexto:Se debe conocerel funcionamientode laaplicaciónque estásiendorevisada,el tipode datosque se
procesa y el daño que supondría que estos datos fueran comprometidos.
• Audiencia: Los usuarios a los que va destinada la aplicación.
• Importancia: ¿Hasta qué punto es relevante para la aplicación que quede inactiva durante un periodo de
tiempo significativo o no?
Además, el equipo de verificación necesitará información formal de la aplicación. Ésta puede obtenerse
revisandodocumentosde especificaciónde requisitos,especificacionesfuncionales,resultados de pruebas, etc.
Sin embargo, en muchos casos esta documentación está obsoleta y no contiene la información de seguridad
apropiada. Por ello, es muy recomendable mantener alguna conversación con el equipo de desarrollo para
compartir información básica sobre las consideraciones y controles clave de seguridad y adquirir una idea
general sobre la estructura base del código y las librerías que se están utilizando.
B.- Priorización
Una vez que se haya recopilado esta información, el equipo de verificación deberá desarrollar un “modelo de
amenazas” a alto nivel con el objetivo de establecer la prioridad a la hora de llevar a cabo el proceso de
verificación.
• Descomponer la aplicación: El objetivo de este paso es adquirir un conocimiento más profundo de la
aplicación. Se obtendrá información acerca de cómo interactúa la aplicación con entidades externas, cómo es
utilizada, qué puntos de entrada posee con los que un atacante podría interactuar, en qué áreas o elementos
podría estar más interesado un atacante y qué nivel de privilegios poseen las entidades externas con las que
interactúa la aplicación.
Determinar y priorizar las amenazas: A la hora de identificar las amenazas, se recomienda establecer una
metodología de categorización, ya sea propia o existente. Es aconsejable que la metodología que se adopte
tenga en cuenta:
• El punto de vista del atacante, es decir, se valoren los distintos exploits que puedan ser utilizados
por un usuario malicioso.
• La perspectivadefensivade laaplicación,esdecir,se tendránen cuenta las posibles debilidades en
los controles de seguridad implementados.
CERTIFICACIÓNDESISTEMAS
11
Despuésde que lasamenazashayansidoidentificadas,se deberíadeterminarel riesgo de cada una de ellas. De
la misma manera que en el caso anterior, se recomienda el uso de un modelo, ya sea propio o existente. Por
ejemplo, podría utilizarse un modelo basado en factores generales de riesgo como probabilidad – impacto.
• Establecercontramedidasymitigación: Lafaltade protecciónde unaamenazaindica una vulnerabilidad, cuya
exposición al riesgo podría ser mitigada con la implementación de una contramedida. A la hora de identificar
estascontramedidaspuedenutilizarse listas de mapeo amenaza-contramedida: después de haber asignado el
riesgoa cada una de las amenazas, es posible ordenarlas de mayor a menor riesgo, y priorizar el esfuerzo para
mitigar cada una de ellas.
Ejecución
Una vez que el equipode verificaciónhaobtenidoel conocimientosuficiente sobrelaaplicaciónyhaestablecido
la prioridadque debe establecerse en el proceso de verificación en base a las amenazas detectadas y el riesgo
de cada una de ellas, es recomendable que realice las siguientes tareas que garanticen que los controles de
seguridadestablecidossonadecuadosyque lasrecomendacionesde codificaciónanterioreshansidotenidasen
cuenta:
• Realización de pruebas de “hacking ético” periódicas sobre las aplicaciones en ejecución, mostrando
evidencias de las vulnerabilidades explotadas.
Estas pruebasse realizaránenentornosde pre-producción. Si en algún caso esto no fuera posible se llevarán a
cabo enproducciónde forma controlada,teniendopresente que en este supuesto NUNCA deberán explotarse
las vulnerabilidades detectadas para no afectar al funcionamiento normal de la aplicación.
• Ejecuciónde pruebasestáticasde códigofuenteperiódicassobre lasdistintasversionesdel software,incluidas
revisiones manuales del código siempre que se considere necesario para completar el análisis.
Estas pruebas se realizarán en entornos de desarrollo y se reportarán los resultados de las mismas en un
informe.
Para llevar a cabo los análisis anteriores, tanto a nivel estático como de hacking ético, se recomienda:
• Establecer metodologías propias o existentes (por ejemplo: CEH- Certified Ethical Hacker, para pruebas de
“hacking ético”).
• Hacer usode herramientasautomatizadasque faciliten la detección de vulnerabilidades en las aplicaciones.
Los resultados de todas las actividades realizadas durante esta verificación, serán recogidos en un informe de
resultados, dirigido al gestor de la comunidad de desarrollo.
3.- VALORACIÓN DE LA SEGURIDAD DE LAS APLICACIONES
En base al informe de resultados, el gestor de la comunidad valorará si los controles de seguridad
implementados son correctos y cumplen las recomendaciones de seguridad especificadas con el objetivo de
establecer acciones correctivas si es necesario. Si fuera así, una vez propuestas las acciones correctivas e
implementadas, se deberá volver a ejecutar el proceso de verificación para comprobar si se han corregido los
defectos detectados en la revisión anterior.

Weitere ähnliche Inhalte

Was ist angesagt?

Auditoria h beltran
Auditoria h beltranAuditoria h beltran
Auditoria h beltranCation1510
 
Capitulo 10 auditoria en base de datos
Capitulo 10 auditoria en base de datosCapitulo 10 auditoria en base de datos
Capitulo 10 auditoria en base de datosoamz
 
Curso: Control de acceso y seguridad: 07 Controles de la ISO/IEC 27002
Curso: Control de acceso y seguridad: 07 Controles de la ISO/IEC 27002Curso: Control de acceso y seguridad: 07 Controles de la ISO/IEC 27002
Curso: Control de acceso y seguridad: 07 Controles de la ISO/IEC 27002Jack Daniel Cáceres Meza
 
Evaluacion De La Seguridad De Los Sistemas Informaticos
Evaluacion De La Seguridad De Los Sistemas InformaticosEvaluacion De La Seguridad De Los Sistemas Informaticos
Evaluacion De La Seguridad De Los Sistemas InformaticosVidal Oved
 
Semana 11 controles y auditoría de la seguridad física
Semana 11   controles y auditoría de la seguridad físicaSemana 11   controles y auditoría de la seguridad física
Semana 11 controles y auditoría de la seguridad físicaedithua
 
Adquisiciones e implementacion
Adquisiciones e implementacionAdquisiciones e implementacion
Adquisiciones e implementacionChikita Patty
 
Development of Secure Applications
Development of Secure ApplicationsDevelopment of Secure Applications
Development of Secure ApplicationsRoger CARHUATOCTO
 
Presentacion seguridad en redes
Presentacion seguridad en redesPresentacion seguridad en redes
Presentacion seguridad en redesalexa1rodriguez
 
Veronica cansigña
Veronica cansigñaVeronica cansigña
Veronica cansigñaflaquitauce
 
Introducción a la certificación Common Criteria
Introducción a la certificación Common CriteriaIntroducción a la certificación Common Criteria
Introducción a la certificación Common CriteriaJavier Tallón
 

Was ist angesagt? (13)

Auditoria h beltran
Auditoria h beltranAuditoria h beltran
Auditoria h beltran
 
Capitulo 10 auditoria en base de datos
Capitulo 10 auditoria en base de datosCapitulo 10 auditoria en base de datos
Capitulo 10 auditoria en base de datos
 
Curso: Control de acceso y seguridad: 07 Controles de la ISO/IEC 27002
Curso: Control de acceso y seguridad: 07 Controles de la ISO/IEC 27002Curso: Control de acceso y seguridad: 07 Controles de la ISO/IEC 27002
Curso: Control de acceso y seguridad: 07 Controles de la ISO/IEC 27002
 
Evaluacion De La Seguridad De Los Sistemas Informaticos
Evaluacion De La Seguridad De Los Sistemas InformaticosEvaluacion De La Seguridad De Los Sistemas Informaticos
Evaluacion De La Seguridad De Los Sistemas Informaticos
 
Semana 11 controles y auditoría de la seguridad física
Semana 11   controles y auditoría de la seguridad físicaSemana 11   controles y auditoría de la seguridad física
Semana 11 controles y auditoría de la seguridad física
 
Adquisiciones e implementacion
Adquisiciones e implementacionAdquisiciones e implementacion
Adquisiciones e implementacion
 
Development of Secure Applications
Development of Secure ApplicationsDevelopment of Secure Applications
Development of Secure Applications
 
Newtech brochure
Newtech brochureNewtech brochure
Newtech brochure
 
Prueba dominioc1karla
Prueba dominioc1karlaPrueba dominioc1karla
Prueba dominioc1karla
 
Presentacion seguridad en redes
Presentacion seguridad en redesPresentacion seguridad en redes
Presentacion seguridad en redes
 
Veronica cansigña
Veronica cansigñaVeronica cansigña
Veronica cansigña
 
Planificacion y organizacion
Planificacion y organizacionPlanificacion y organizacion
Planificacion y organizacion
 
Introducción a la certificación Common Criteria
Introducción a la certificación Common CriteriaIntroducción a la certificación Common Criteria
Introducción a la certificación Common Criteria
 

Andere mochten auch

Andere mochten auch (20)

Guias11
Guias11Guias11
Guias11
 
Aaa
AaaAaa
Aaa
 
Power point..
Power point..Power point..
Power point..
 
Base de datos
Base de datosBase de datos
Base de datos
 
Proyecto de vida kk
Proyecto de vida kkProyecto de vida kk
Proyecto de vida kk
 
Como crear un blog
Como crear un blogComo crear un blog
Como crear un blog
 
Erik gonzalez actividad 3
Erik gonzalez actividad 3Erik gonzalez actividad 3
Erik gonzalez actividad 3
 
Revista Aguilas marzo 2015
Revista Aguilas marzo 2015Revista Aguilas marzo 2015
Revista Aguilas marzo 2015
 
Proyecto de Aula Jorge Enrique Montejo Hernández
Proyecto de Aula Jorge Enrique Montejo HernándezProyecto de Aula Jorge Enrique Montejo Hernández
Proyecto de Aula Jorge Enrique Montejo Hernández
 
Metodo de cuencas presentacion
Metodo de cuencas presentacionMetodo de cuencas presentacion
Metodo de cuencas presentacion
 
Presentacion ensayo con voz en algunas diapositivas
Presentacion ensayo con voz en algunas diapositivasPresentacion ensayo con voz en algunas diapositivas
Presentacion ensayo con voz en algunas diapositivas
 
Actividad física clase 4
Actividad física clase 4Actividad física clase 4
Actividad física clase 4
 
Abús de l'alcohol. teoria de l'acció raonada
Abús de l'alcohol. teoria de l'acció raonadaAbús de l'alcohol. teoria de l'acció raonada
Abús de l'alcohol. teoria de l'acció raonada
 
Icaza ma. fernanda
Icaza ma. fernanda Icaza ma. fernanda
Icaza ma. fernanda
 
Sessió prochaska
Sessió prochaskaSessió prochaska
Sessió prochaska
 
Revista Aguilas Junio 2014
Revista Aguilas Junio 2014Revista Aguilas Junio 2014
Revista Aguilas Junio 2014
 
Renacimiento karen
Renacimiento karenRenacimiento karen
Renacimiento karen
 
Identificación de elementos manieristas
Identificación de elementos manieristasIdentificación de elementos manieristas
Identificación de elementos manieristas
 
The lastest newz ubj copia
The lastest newz ubj   copiaThe lastest newz ubj   copia
The lastest newz ubj copia
 
Identificación de elementos neoclasicos karen
Identificación de elementos neoclasicos karenIdentificación de elementos neoclasicos karen
Identificación de elementos neoclasicos karen
 

Ähnlich wie Certificación de sistemas

Seguridad en sitios web
Seguridad en sitios webSeguridad en sitios web
Seguridad en sitios webUTPL
 
2.2 Conceptos básicos del libro naranja.pptx
2.2 Conceptos básicos del libro naranja.pptx2.2 Conceptos básicos del libro naranja.pptx
2.2 Conceptos básicos del libro naranja.pptxMelinaPAREDESACOSTA
 
Metodologias de control interno
Metodologias de control internoMetodologias de control interno
Metodologias de control internoRolando Arguello
 
Curso: Control de acceso y seguridad: 08 Controles de la ISO/IEC 27002 relaci...
Curso: Control de acceso y seguridad: 08 Controles de la ISO/IEC 27002 relaci...Curso: Control de acceso y seguridad: 08 Controles de la ISO/IEC 27002 relaci...
Curso: Control de acceso y seguridad: 08 Controles de la ISO/IEC 27002 relaci...Jack Daniel Cáceres Meza
 
Seguridad en redes informáticas
Seguridad en redes informáticasSeguridad en redes informáticas
Seguridad en redes informáticaschanel-bullicolor
 
Lexi herrera fundamentos del diseno de software
Lexi herrera  fundamentos del diseno de softwareLexi herrera  fundamentos del diseno de software
Lexi herrera fundamentos del diseno de softwarelexiherrera
 
Auditoriade sistemas controles
Auditoriade sistemas controlesAuditoriade sistemas controles
Auditoriade sistemas controlesEliecer Espinosa
 
Adquisicion e implementacion
Adquisicion e  implementacionAdquisicion e  implementacion
Adquisicion e implementacionAndres_84
 
Adquisicion e implementacion mjsl
Adquisicion e implementacion mjslAdquisicion e implementacion mjsl
Adquisicion e implementacion mjslMariaSalazarLopez
 
UDA-Anexo gestión de seguridad
UDA-Anexo gestión de seguridadUDA-Anexo gestión de seguridad
UDA-Anexo gestión de seguridadAnder Martinez
 
Fundamentos del software
Fundamentos del softwareFundamentos del software
Fundamentos del softwareJophrz
 
mecanismo de control y seguridad.pptx
mecanismo de control y seguridad.pptxmecanismo de control y seguridad.pptx
mecanismo de control y seguridad.pptxJeisonCapera1
 
Seguridad y proteccion
Seguridad y proteccionSeguridad y proteccion
Seguridad y proteccionvagusska
 
Sistemas i ultimo trabajo
Sistemas i ultimo trabajoSistemas i ultimo trabajo
Sistemas i ultimo trabajoAlejandross1
 
Diseã±os de planes_de_pruebas_de_software1
Diseã±os de planes_de_pruebas_de_software1Diseã±os de planes_de_pruebas_de_software1
Diseã±os de planes_de_pruebas_de_software1naviwz
 

Ähnlich wie Certificación de sistemas (20)

Seguridad en sitios web
Seguridad en sitios webSeguridad en sitios web
Seguridad en sitios web
 
2.2 Conceptos básicos del libro naranja.pptx
2.2 Conceptos básicos del libro naranja.pptx2.2 Conceptos básicos del libro naranja.pptx
2.2 Conceptos básicos del libro naranja.pptx
 
Metodologias de control interno
Metodologias de control internoMetodologias de control interno
Metodologias de control interno
 
Curso: Control de acceso y seguridad: 08 Controles de la ISO/IEC 27002 relaci...
Curso: Control de acceso y seguridad: 08 Controles de la ISO/IEC 27002 relaci...Curso: Control de acceso y seguridad: 08 Controles de la ISO/IEC 27002 relaci...
Curso: Control de acceso y seguridad: 08 Controles de la ISO/IEC 27002 relaci...
 
Seguridad en redes informáticas
Seguridad en redes informáticasSeguridad en redes informáticas
Seguridad en redes informáticas
 
Lexi herrera fundamentos del diseno de software
Lexi herrera  fundamentos del diseno de softwareLexi herrera  fundamentos del diseno de software
Lexi herrera fundamentos del diseno de software
 
Auditoriade sistemas controles
Auditoriade sistemas controlesAuditoriade sistemas controles
Auditoriade sistemas controles
 
Adquisicion e implementacion
Adquisicion e  implementacionAdquisicion e  implementacion
Adquisicion e implementacion
 
Adquisicion e implementacion mjsl
Adquisicion e implementacion mjslAdquisicion e implementacion mjsl
Adquisicion e implementacion mjsl
 
UDA-Anexo gestión de seguridad
UDA-Anexo gestión de seguridadUDA-Anexo gestión de seguridad
UDA-Anexo gestión de seguridad
 
Fundamentos del software
Fundamentos del softwareFundamentos del software
Fundamentos del software
 
Trabajo final maricarmen
Trabajo final maricarmenTrabajo final maricarmen
Trabajo final maricarmen
 
mecanismo de control y seguridad.pptx
mecanismo de control y seguridad.pptxmecanismo de control y seguridad.pptx
mecanismo de control y seguridad.pptx
 
Seguridad y proteccion
Seguridad y proteccionSeguridad y proteccion
Seguridad y proteccion
 
Sistemas i ultimo trabajo
Sistemas i ultimo trabajoSistemas i ultimo trabajo
Sistemas i ultimo trabajo
 
Guia 1ra parte
Guia 1ra parteGuia 1ra parte
Guia 1ra parte
 
Diseã±os de planes_de_pruebas_de_software1
Diseã±os de planes_de_pruebas_de_software1Diseã±os de planes_de_pruebas_de_software1
Diseã±os de planes_de_pruebas_de_software1
 
Ejemplo de auditoria
Ejemplo de auditoriaEjemplo de auditoria
Ejemplo de auditoria
 
Sgsi
SgsiSgsi
Sgsi
 
Sgsi
SgsiSgsi
Sgsi
 

Kürzlich hochgeladen

PRESENTACION DE "CASO NOKIA" // PDF.EDU.
PRESENTACION DE "CASO NOKIA" // PDF.EDU.PRESENTACION DE "CASO NOKIA" // PDF.EDU.
PRESENTACION DE "CASO NOKIA" // PDF.EDU.SARA BUENDIA RIOJA
 
La electricidad y la electrónica.pdf.iluw
La electricidad y la electrónica.pdf.iluwLa electricidad y la electrónica.pdf.iluw
La electricidad y la electrónica.pdf.iluwDanielaEspaa3
 
Perspectivas en ciberseguridad para el año 2024
Perspectivas en ciberseguridad para el año 2024Perspectivas en ciberseguridad para el año 2024
Perspectivas en ciberseguridad para el año 2024Educática
 
Taller Evaluativo Tecnologías Web 2.0.docx
Taller Evaluativo Tecnologías Web 2.0.docxTaller Evaluativo Tecnologías Web 2.0.docx
Taller Evaluativo Tecnologías Web 2.0.docxSANTIAGOREYES92
 
Cuadernillo de Comunicación 1. Primer grado de Primaria.pdf
Cuadernillo de Comunicación 1. Primer grado de Primaria.pdfCuadernillo de Comunicación 1. Primer grado de Primaria.pdf
Cuadernillo de Comunicación 1. Primer grado de Primaria.pdfRosaAmeliaLlacsahuan
 
Violencia sexual a través de Internet [ICAS 2024]
Violencia sexual a través de Internet [ICAS 2024]Violencia sexual a través de Internet [ICAS 2024]
Violencia sexual a través de Internet [ICAS 2024]QuantiKa14
 
Charla eCommerce Day Bolivia 2024 - Comercio Electrónico en Bolivia 2024
Charla eCommerce Day Bolivia 2024 - Comercio Electrónico en Bolivia 2024Charla eCommerce Day Bolivia 2024 - Comercio Electrónico en Bolivia 2024
Charla eCommerce Day Bolivia 2024 - Comercio Electrónico en Bolivia 2024Mariano Cabrera Lanfranconi
 

Kürzlich hochgeladen (7)

PRESENTACION DE "CASO NOKIA" // PDF.EDU.
PRESENTACION DE "CASO NOKIA" // PDF.EDU.PRESENTACION DE "CASO NOKIA" // PDF.EDU.
PRESENTACION DE "CASO NOKIA" // PDF.EDU.
 
La electricidad y la electrónica.pdf.iluw
La electricidad y la electrónica.pdf.iluwLa electricidad y la electrónica.pdf.iluw
La electricidad y la electrónica.pdf.iluw
 
Perspectivas en ciberseguridad para el año 2024
Perspectivas en ciberseguridad para el año 2024Perspectivas en ciberseguridad para el año 2024
Perspectivas en ciberseguridad para el año 2024
 
Taller Evaluativo Tecnologías Web 2.0.docx
Taller Evaluativo Tecnologías Web 2.0.docxTaller Evaluativo Tecnologías Web 2.0.docx
Taller Evaluativo Tecnologías Web 2.0.docx
 
Cuadernillo de Comunicación 1. Primer grado de Primaria.pdf
Cuadernillo de Comunicación 1. Primer grado de Primaria.pdfCuadernillo de Comunicación 1. Primer grado de Primaria.pdf
Cuadernillo de Comunicación 1. Primer grado de Primaria.pdf
 
Violencia sexual a través de Internet [ICAS 2024]
Violencia sexual a través de Internet [ICAS 2024]Violencia sexual a través de Internet [ICAS 2024]
Violencia sexual a través de Internet [ICAS 2024]
 
Charla eCommerce Day Bolivia 2024 - Comercio Electrónico en Bolivia 2024
Charla eCommerce Day Bolivia 2024 - Comercio Electrónico en Bolivia 2024Charla eCommerce Day Bolivia 2024 - Comercio Electrónico en Bolivia 2024
Charla eCommerce Day Bolivia 2024 - Comercio Electrónico en Bolivia 2024
 

Certificación de sistemas

  • 1. CERTIFICACIÓNDESISTEMAS 1 El Libro Naranja El Departamento de Defensa de Estados Unidos desarrolló la norma Trusted Computer System Evaluation Criteria(TCSEC),que se utilizópara evaluar los sistemas operativos, aplicaciones y diferentes productos. Estos criterios de evaluación son publicados en un libro con una cubierta de color naranja, que se llama, apropiadamente, el Libro Naranja. Los clientes utilizan la calificación de seguridad que los criterios presentaban como métrica cuando comparan diferentesproductos.También proporciona orientación a los fabricantes para que sepan que especificaciones construir,y proporcionaunprocesode evaluación de ventanilla única para que los clientes no necesitan tener componentes individuales dentro de los sistemas evaluados. El libronaranja se utilizó para evaluar si un producto contiene las propiedades de seguridad que el proveedor reclama que tiene y si el producto era apropiado para una aplicación o función específica. El Libro Naranja fue utilizado para revisar la funcionalidad, eficacia y seguridad de un producto durante su evaluación, y utiliza las clases que se desarrollaron para abordar los patrones típicos de los requisitos de seguridad. TCSEC proporcionaunsistemade clasificaciónque se divide endivisiones jerárquicas de los niveles de garantía de: A. Protección verificada B. Protección Obligatoria C. Protección Discrecional D. Seguridad Mínima Clasificación A representa el más alto nivel de seguridad, y D representa el nivel más bajo de seguridad. Cada divisiónpuede tenerunaomás clases numeradas con un conjunto correspondiente de los requisitos que se debencumplirparaque un sistemalogre unacalificaciónparticular.Lasclasesconnúmerosmás altos ofrecen un mayor grado de confianza y seguridad. Así B2 ofrecería más seguridad que B1 y C2 ofrecería más seguridad que C1. El criterio se divide en siete áreas diferentes: • Políticade seguridad. La política debe ser explícita y bien definida y ejecutada por los mecanismos del sistema. • Identificación. Sujetos individuales deben ser identificados de forma única. • Etiquetas. Etiquetas de control de acceso deben estar asociados correctamente con objetos. • Documentación. La documentación debe ser proporcionada, incluyendo prueba, diseño y documentos de especificaciones, guías de usuario y manuales. • Rendiciónde cuentas.Losdatosde auditoría deben ser capturados y protegidos para hacer cumplir la rendición de cuentas.
  • 2. CERTIFICACIÓNDESISTEMAS 2 • Aseguramientodel ciclode vida.Software,hardware yfirmware debenser capaces de ser probados individualmente para garantizar que cada uno hace cumplir la política de seguridad de una manera efectiva a lo largo de su vida. • La protección continúa. Los mecanismos de seguridad y el sistema como un todo deben realizar predecible y aceptablemente en diferentes situaciones continuamente. Estas categorías sonevaluadasde formaindependiente,perolacalificaciónasignadaal final no especifica estos diferentes objetivos de forma individual. La calificación es una suma total de estos elementos. Cada divisiónyclase incorporalosrequisitosde losinferiores. Esto significa que C2 debe cumplir sus requisitos de criteriosytodos losrequisitos de C1, B3 y tiene sus requisitos para cumplir junto con los de C1, C2, B1, y B2. Se espera que cada división o clase suba la apuesta en los requisitos de seguridad y para cumplir con los requisitos de todas las clases y divisiones inferiores. Así, cuandoun proveedorpresentóunproductoparala evaluación, lopresentóal NCSC. El grupo que supervisó los procesos de evaluación se llama el Programa de Evaluación de Productos de Confianza (TPEP). Productos evaluados con éxito fueron colocados en la lista de los productos evaluados (EPL) con su correspondiente calificación. Cuando los consumidores estén interesados en determinados productos y sistemas, podrán comprobar el EPL apropiado para conocer sus niveles de seguridad asignados. División D: Protección Mínima Sólohay unaclase en laDivisiónD. Se reserva para los sistemas que han sido evaluados, pero dejar de cumplir con los criterios y requisitos de las divisiones superiores. División C: Protección Discrecional La categoría de calificación C tiene dos clasificaciones individuales de aseguramiento dentro de ella. Cuanto mayor sea el número de la calificación de la garantía, mayor será la protección. C1: Protección de Seguridad Discrecional. Control de acceso discrecional se basa en las personas y / o grupos. Se requiere una separación de los usuarios y la información, y la identificación y autenticación de entidades individuales. Algún tipo de control de acceso es necesario, así los usuarios pueden asegurarse que su informaciónnoseráaccediday corrompidaporotros. La arquitecturadel sistemadebe proporcionarundominio de ejecuciónprotegido paraque losprocesosdel sistemaprivilegiados no se ven afectados negativamente por losprocesosde menorprivilegio.Tiene que haber formas específicas de validación de integridad operativa del sistema.Losrequisitosde documentaciónincluyendocumentaciónde diseño, lo que demuestra que el sistema fue construidoparaincluirmecanismosde protección,documentaciónde prueba(plande pruebasyresultados), un manual de instalación(paraque lasempresassepancómo instalar y configurar el sistema correctamente), y manuales de usuario. El tipo de ambiente que requeriría esta calificación es aquel en el que los usuarios están procesando la información,al mismonivel de sensibilidad;porlotanto,nose requierenmedidasestrictasde control de acceso y auditoría. Sería un entorno de confianza con las preocupaciones de seguridad bajos. C2: Protecciónde AccesoControlado. Los usuariosdebenser identificados individualmente para proporcionar control de acceso más precisoyfuncionalidadde auditoría.Mecanismosde control de acceso lógicos se utilizan para hacer cumplirla autenticación y el carácter único de identificación de cada individuo. Eventos relevantes para la seguridad se auditan, y estos registros deben ser protegidos de la modificación no autorizada. La
  • 3. CERTIFICACIÓNDESISTEMAS 3 arquitectura debe proporcionar el recurso, o un objeto, el aislamiento de protección de modo adecuado se puede aplicar a los recursos y las acciones tomadas sobre ellos pueden ser adecuadamente auditadas. El concepto de reutilización de objetos también debe ser invocado, lo que significa que todos los datos de retenciónmedianodebencontenerrestosde lainformacióndespuésde haberlo publicado para otro objeto de uso. Si un sujeto utiliza un segmento de la memoria, que el espacio de memoria no debe contener ninguna información después de que el sujeto se hace usando la misma. Lo mismo es cierto para los medios de almacenamiento,objetosque estánpoblados,ylosarchivostemporalesque se crean,todoslosdatosdeben ser borrados de manera eficiente una vez que el sujeto se hace con ese medio. Esta clase requiere un método más granular de proporcionar control de acceso. El sistema debe cumplir los procedimientos de inicio de sesión estricta y proporcionar capacidades de toma de decisiones cuando los sujetos soliciten acceso a objetos. Un sistema C2 no puede garantizar que no se verá comprometida, pero suministra un nivel de protección que haría que los intentos de comprometer más difícil de lograr. El tipode ambiente que requeriría de los sistemas con una calificación C2 es uno en el que los usuarios son de confianza, pero se requiere un cierto nivel de rendición de cuentas. C2, en general, se ve como la clase más razonable para aplicaciones comerciales, pero el nivel de protección es aun relativamente débil. División B: Protección obligatoria Control de acceso obligatorioesimpuesto porel usode lasetiquetasde seguridad.Laarquitectura se basa en el modelo de seguridad de Bell-LaPadula. B1: Etiquetado de Seguridad. Cada objeto de datos debe contener una etiqueta de clasificación y cada sujeto debe tener una etiqueta de autorización. Cuando un sujeto intenta acceder a un objeto, el sistema debe comparar las etiquetas de seguridad del sujeto y del objeto para garantizar que las acciones solicitadas son aceptables. Los datos que salen del sistema también deben contener una etiqueta de seguridad precisa. La política de seguridad se basa en una declaración informal, y las especificaciones de diseño son revisadas y verificadas. Esta evaluación de seguridad está diseñado para entornos que requieren sistemas para manejar los datos clasificados. B2: Protección estructurada. La política de seguridad está claramente definida y documentada, y el diseño e implementacióndel sistemase sometenalosprocedimientosde revisión y pruebas más exhaustivas. Esta clase requiere mecanismos de autenticación más estrictos e interfaces bien definidas entre capas. Sujetos y dispositivos requieren etiquetas, y el sistema no debe permitir canales encubiertos. Un camino de confianza para los procesos de inicio de sesión y autenticación debe estar en su lugar, lo que significa que el sujeto se comunica directamente con la aplicación o el sistema operativo, y no existen trampillas. No hay manera de evitar o comprometer este canal de comunicación. Las funciones de operador y de administración están separadosdentrodel sistema para proporcionar más confianza y proteger la funcionalidad operativa. Espacios de direcciones distintas se deben proporcionar para aislar los procesos, y se lleva a cabo un análisis de canal encubierto. Esta clase añade aseguramiento mediante la adición de requisitos para el diseño del sistema. El tipo de ambiente que requeriría sistemas de B2 es uno que procesa los datos sensibles que requieren un mayor grado de seguridad. Este tipo de ambiente requeriría sistemas que son relativamente resistentes a la penetración y el compromiso.
  • 4. CERTIFICACIÓNDESISTEMAS 4 B3: Dominiosde Seguridad. En esta clase,másgranularidadse proporcionaencada mecanismode protección,y se excluye el código de programación que no es necesario para apoyar la política de seguridad. El diseño e implementación no deben proporcionar demasiada complejidad, porque a medida que la complejidad de un sistema aumenta, es necesario que el nivel de habilidad de los individuos aumente para probar, mantener y configurarlo; por lo tanto, la seguridad general puede ser amenazada. Los componentes del monitor de referencia deben ser lo suficientemente pequeños para probarlos adecuadamente y estar a prueba de manipulaciones.Lafunciónde administradorde seguridadestáclaramente definida,yel sistemadebe ser capaz de recuperarse de fallas sin que su nivel de seguridad se vea comprometido. Cuandoel sistemase iniciaycarga el sistemaoperativoyloscomponentes,hayque hacerloenunestadoseguro inicial para asegurar que en cualquier debilidad del sistema no se puede tomar ventaja en esta porción de tiempo. El tipode ambiente que requiere sistemas B3 es un entorno de alta seguridad que procesa la información muy sensible. Se requiere que los sistemas sean altamente resistentes a la penetración. División A: Protección Verificada Los métodosformalesse utilizan para garantizar que todos los sujetos y objetos se controlan con los controles de acceso discrecional yobligatorio.El diseño,desarrollo,implementación, y la documentación son mirados de una manera formal y detallada. Los mecanismos de seguridad entre B3 y A1 no son muy diferentes, pero la formaen que el sistemafue diseñadoydesarrolladose evalúa en un procedimiento mucho más estructurado y riguroso. A1: Diseño verificado. Las características de la arquitectura y de protección no son muy diferentes de los sistemas que logren una calificación de B3, pero la seguridad de un sistema A1 es mayor que un sistema B3 debido a la formalidad en el funcionamiento del sistema A1 como fue diseñado, la forma en que se desarrollaron las especificaciones, y el nivel de detalle en las técnicas de verificación. Técnicas formales se utilizan para demostrar la equivalencia entre las especificaciones TCB y el modelo de la política de seguridad. Una configuración de cambio más estricto se puso en marcha con el desarrollo de un sistemade A1,y el diseñogeneral puede serverificado.En muchos casos, incluso la forma en que el sistema se entregaal cliente estábajoescrutinioparaasegurarque nohay manerade poneren peligroel sistema antes de alcanzar su destino. El tipo de ambiente que requeriría sistemas A1 es el más seguro de los entornos protegidos. Este tipo de ambiente se ocupa de la información de alto secreto y no se puede confiar en cualquier persona que utilice adecuadamente los sistemas sin autenticación estricta, restricciones, y la auditoría. LIBRO BLANCO La evaluaciónde laseguridadTecnología de la Información Criteria (ITSEC) fue el resultado de la armonización de los criterios de evaluación de seguridad de cuatro países europeos: Francia, Alemania, los Países Bajos y el Reino Unido. El ITSEC reemplazado cada uno de sus propios criterios nacionales y se convirtió en una de facto criterios europeos. El ITSEC ha estado en uso operativo dentro de esquemas de evaluación y certificación europeos desde julio de 1991. El ITSEC tenía por objeto la evaluación de los productos y sistemas (que pueden estar compuestos de muchos productos y componentes seguros). El ITSEC separó la funcionalidad y seguridad. Un producto o sistema fue
  • 5. CERTIFICACIÓNDESISTEMAS 5 evaluadacontrauna garantía específicadel documento de destino en el que se especificaban las funciones de seguridad del producto o sistema, así como una evaluación reclamada o nivel de garantía. Un producto o sistema a evaluar se denomina TOE (Target of Evaluation) y se verifica contra un objetivo de seguridad. El ITSEC dirigióuna vista ampliada de la confidencialidad, integridad y disponibilidad, con el fin de abordar de maneramás explícitatantolasnecesidadesmilitaresy comerciales. El ITSEC define la confidencialidad como la prevenciónde ladivulgaciónnoautorizadade la información;integridadcomolaprevención de la modificación no autorizada de la información; y, la disponibilidad como la prevención de la retención no autorizada de los recursos. Se definen siete niveles de evaluación, denominados E0 a E6, que representan una confianza para alcanzar la metau objetivode seguridad.E0representa una confianza inadecuada. E1, el punto de entrada por debajo del cual no cabe la confianza útil, y E6 el nivel de confianza más elevado. Criterios comunes En 1990, la OrganizaciónInternacional de Normalización(ISO) identificólanecesidadde criteriosinternacionales de evaluaciónestándarparaserusados a nivel mundial. El proyecto Common Criteria se inició en 1993, cuando variasorganizacionesse unieronparacombinary armonizarloscriteriosexistentesyemergentes de evaluación (TCSEC, ITSEC, Canadian Trusted Computer Product Evaluation Criteria [CTCPEC], y los criterios federales). El Common Criteria se ha desarrollado a través de una colaboración entre las organizaciones nacionales de normalizaciónde seguridaddentrode losEstadosUnidos,Canadá,Francia,Alemania,el ReinoUnidoylosPaíses Bajos. El beneficio de tener un conjunto de criterios mundialmente reconocidos y aceptados es que ayuda a los consumidoresmediantelareducciónde lacomplejidadde lascalificaciones y la eliminación de la necesidad de entenderladefiniciónyel significadode diferentescalificacionesdentro de varios sistemas de evaluación. Esto tambiénayudaa losvendedores,porque ahora se puede construirsobre unconjuntoespecífico de requisitos si se quierenvendersusproductos a nivel internacional, en lugar de tener que cumplir con varias clasificaciones diferentes, con diferentes reglas y requisitos. El Libro Naranja evaluaba todos los sistemas de la forma en comparación con el modelo Bell-LaPadula. El CommonCriteriaofrece másflexibilidadmediantelaevaluación de un producto contra un perfil de protección, el cual se estructurapara hacer frente a la necesidad de seguridad en el mundo real. Así, mientras que el Libro Naranja dice: "Todo el mundo marcha en esa dirección en esta forma utilizando este camino," los criterios comunespregunta:"Estábien,¿cuálessonlasamenazasque enfrentamoshoyycuálessonlasmejoresmaneras de luchar contra ellas?" Bajo el modelo de Common Criteria, una evaluación se lleva a cabo en un producto y se le asigna un nivel de garantía de Evaluación(EAL).Las pruebasexhaustivas y rigurosas en tareas detalladas aumentan los niveles de aseguramiento. El Common Criteria tiene siete niveles de garantía. El rango es de EAL1, donde las pruebas funcionalidadse llevaacabo, a EAL7, donde se realiza la prueba a fondo y el diseño del sistema se verifica. Los diferentes paquetes EAL se enumeran a continuación: • EAL1 Funcionalmente probado • EAL2 Estructuralmente probado • EAL3 Metódicamente probado y comprobado
  • 6. CERTIFICACIÓNDESISTEMAS 6 • EAL4 Metódicamente diseñado, probado y revisado • EAL5 Semiformalmente diseñado y probado • EAL6 Semiformalmente verificado diseño y prueba • EAL7 Formalmente verificado diseño y prueba El Common Criteria utiliza perfiles de protección en su proceso de evaluación. Este es un mecanismo que se utilizaparadescribirunanecesidadenel mundoreal paraunproducto que no está actualmente en el mercado. El perfil de protección contiene el conjunto de requisitos de seguridad, su significado y el razonamiento, y la calificacióncorrespondienteEALque el productodestinadorequerirá.Enel perfil de protecciónse describen los supuestosdel entorno,losobjetivosylasexpectativasdel nivelfuncional yde garantía.Cada amenazarelevante aparece juntocon la formaenque va a sercontroladopor objetivosespecíficos.El perfil de protección también justifica el nivel de garantía y los requisitos para asegurar cada mecanismo de protección. El perfil de protección proporciona un medio para un consumidor, u otros, para identificar las necesidades específicas de seguridad. Si alguien identifica una necesidad de seguridad que actualmente no está siendo abordado por cualquier producto actual, esa persona puede escribir un perfil de protección que describe el productoque sería una soluciónparaeste problemadel mundoreal.El perfilde protecciónvaaproporcionarlos objetivos necesarios y mecanismos de protección para alcanzar el nivel de seguridad requerido, así como una lista de cosas que podrían salir mal durante este tipo de desarrollo del sistema. Esta lista es utilizada por los ingenieros que desarrollan el sistema, y luego por los evaluadores para asegurarse de que los ingenieros lo desarrollaron como se esperaba. El CommonCriteriafue desarrolladoparapegarse alasclasesde evaluación,perotambiénparaconservarcierto grado de flexibilidad.Losperfilesde protecciónse handesarrolladoparadescribirlafuncionalidad,lagarantía,la descripción y justificación de los requisitos del producto. Al igual que otros criterios de evaluación antes de ella, el Common Criteria trabaja para responder a dos preguntas básicas acerca de los productos que se están evaluando: ¿qué hacen sus mecanismos de seguridad (funcionalidad)?, y ¿cómo está seguro de esto (garantía)? Este sistema establece un marco que permite a los consumidoresespecificarclaramentesusproblemasde seguridad, a los desarrolladores especificar su solución de seguridad para esos problemas, y a los evaluadores para determinar de manera inequívoca lo que el producto cumple en realidad. Un perfil de protección contiene las siguientes cinco secciones: • Elementos descriptivos. Proporciona el nombre del perfil y una descripción del problema de seguridad que hay que resolver. • Justificación.Justificael perfil ydauna descripciónmásdetallada del problema del mundo real que hay que resolver. El entorno, los supuestos de uso, y las amenazas se ilustran junto con la orientaciónde laspolíticas de seguridad que pueden ser compatibles con los productos y sistemas que se ajusten a este perfil. • Requerimientos funcionales. Establece un límite de protección, es decir, las amenazas o compromisosdentrode estafronteraparaser contrarrestados.El producto o sistema ha de cumplir el límite establecido en esta sección.
  • 7. CERTIFICACIÓNDESISTEMAS 7 • Requisitos de aseguramiento del Desarrollo. Identifica los requisitos específicos del producto o sistema que se deben cumplir durante las fases de desarrollo, desde el diseño hasta la implementación. • Requisitos de aseguramiento de la Evaluación. Establece el tipo y la intensidad de la evaluación. El procesode evaluación es sólo una etapa de determinación de la funcionalidad y la garantía de un producto. Una vez que el producto alcanza una calificación específica, sólo se aplica a la versión en particular y sólo a ciertasconfiguracionesde ese producto.Asíque si una empresa compra un producto de servidor de seguridad, ya que tiene un alto índice de seguridad, la empresa no tiene ninguna garantía de que la próxima versión del software tendráesacalificación.Lapróximaversióntendráque ira travésde su propioexamende evaluación.Si esta misma empresa compra el producto firewall y lo instala con configuraciones que no se recomiendan, el nivel de seguridad que lacompañía esperaba alcanzar puede irse fácilmente por el desagüe. Por lo tanto, toda esta calificación es un método formal de revisión de un sistema que está siendo evaluado en un laboratorio. Cuandoel productose llevaacabo enun entornoreal,factoresdistintosde la calificación deben ser abordados y evaluados para asegurar que está protegiendo adecuadamente los recursos y el entorno. ISO/ IEC15408 es el estándarinternacional que se utilizacomolabase para laevaluación de las propiedades de seguridad de los productos en el marco CC. En realidad, tiene tres partes principales: • ISO / IEC15408-1 Introducción y modelo de evaluación general. • ISO / IEC15408-2 Componentes funcionales de seguridad. • ISO / IEC15408-3 Los componentes de aseguramiento de la Seguridad. ISO/ IEC 15.408-1 establece losconceptosyprincipiosgeneralesdel modelode evaluaciónCC.Estaparte define lostérminos,establece el concepto básico de TOE, describe el contexto de evaluación, y el público necesario. Proporciona los conceptos clave para el PP, los requisitos de seguridad, y las directrices para el objetivo de seguridad. ISO / IEC 15.408-2 define los requisitos funcionales de seguridad que serán juzgados durante la evaluación. Contiene uncatálogode componentesfuncionales de seguridad predefinidos que se asigna a la mayoría de las necesidades de seguridad. Estos requisitos se organizan en una estructura jerárquica de clase s, familias y componentes.Tambiénproporcionaorientaciónsobre laespecificaciónde losrequisitosde seguridad a medida si no existe ningún componente de seguridad predefinido funcional. ISO/ IEC 15408-3 define losrequisitosde garantía,que también se organizanenunajerarquíade clases,familias y componentes.Estaparte describe losnivelesde aseguramientode evaluación,que esunaescalapara medir la seguridadde los TOEs,y proporcionaloscriteriosparala evaluaciónde losperfiles de protección y objetivos de seguridad. Así que losvendedoresde productossiguenestasnormasenlaconstrucciónde losproductos que van a poner a travésdel procesode evaluación CC y los evaluadores de productos sigan estas normas al realizar los procesos de evaluación. Seguridad en el Desarrollo de Aplicaciones y Sistemas Seguridad
  • 8. CERTIFICACIÓNDESISTEMAS 8 Como se ha comentado anteriormente, la seguridad de la información se basa en los tres siguientes pilares principales:  Confidencialidad. Sólo se debe permitir el acceso a los datos a los cuales el usuario está autorizado.  Integridad. Se debe asegurar que los datos no son manipulados por usuarios no autorizados.  Disponibilidad.Losdatosdebenestardisponiblesde manera permanenteparalos usuarios autorizados. Para garantizar el cumplimiento de estos tres fundamentos, durante el desarrollo de las aplicaciones deben implementarse distintos controles de seguridad. En general, pueden encajarse en los siguientes grupos en función del objeto para el cual se construyan:  Controles de prevención de accesos no autorizados.  Controles sobre las entradas de datos en la aplicación, para evitar que ciertos datos provoquen que la aplicación no se comporte de la manera deseada.  Controles para asegurar el funcionamiento correcto de la aplicación cuando está siendo directamente atacada.  Controlesde gestiónde lapropiaaplicaciónparamonitorizarlaactividadde laaplicacióny configurar su comportamiento. 1.- PRINCIPIOS DE DESARROLLO SEGURO Independientemente dellenguaje ylaarquitecturautilizados,el desarrollode laaplicacióny de los controles de seguridadnecesariosdebenllevarse acaboteniendoencuentaunaserie de principios de seguridad que traten de reducir la probabilidad de la realización de amenazas y el impacto de éstas en el caso de que se hayan producido ya. Minimizar la superficie de ataque Por ejemplo, si una aplicación implementa un módulo de ayuda con una funcionalidad de búsqueda, dicha funcionalidad puede ser vulnerable a inyección SQL. Si la ayuda está limitada a usuarios autorizados, la posibilidad de ataque se reduce. Si además la funcionalidad de búsqueda utiliza rutinas de validación de los datosde entrada,laposibilidadde inyecciónSQLdisminuye drásticamente.Sinembargo,si laayuda se rediseña y se eliminalaposibilidadde búsqueda(proporcionando como alternativa una mejor interfaz de usuario), esto prácticamente elimina la superficie de ataque del módulo de ayuda, incluso si la ayuda fuese accesible desde Internet. Seguridad por defecto Cuandouna aplicaciónse despliegaensuentornode producción,utilizaunaserie de opciones de configuración que se establecen por defecto. Estas opciones por defecto deben ser tales que la aplicación sea segura. Es responsabilidad del usuario modificar dichas opciones aún a costa de disminuir la seguridad. Por ejemplo,pordefectounaaplicacióndebería tener habilitada la expiración de contraseñas y una política de complejidadde clavesadecuada.Unavez desplegada,losusuariospodrían deshabilitar estas opciones o relajar las restricciones aún a costa de aumentar el riesgo, pero siempre bajo su responsabilidad. Ejecución con los mínimos privilegios El principiode mínimosprivilegiosestablece que las cuentas deben tener el menor nivel de privilegios posible para realizar las tareas de negocio. Este nivel de privilegios abarca tanto permisos de usuarios como permisos sobre recursos como CPU, memoria, red, sistema de ficheros, etc.
  • 9. CERTIFICACIÓNDESISTEMAS 9 Por ejemplo, si una aplicación sólo requiere acceso a la red, permisos de lectura sobre una tabla de la base de datos y la posibilidad de escribir en un fichero de log, estos deben ser los únicos permisos que debe tener la cuenta bajo la que se ejecute la aplicación. Bajo ningún concepto la aplicación debe tener permisos administrativos. Defensa en profundidad El principiode defensa en profundidad sugiere que donde un único control de seguridad podría ser asumible, sería mejor utilizar varios controles que afronten el riesgo desde distintos puntos de vista. Los controles de seguridad, cuando se utilizan con el enfoque de defensa en profundidad, hacen que vulnerabilidades que pueden ser muy graves, sean tremendamente difíciles de explotar. Por ejemplo, siguiendo este principio, una aplicación implementaría distintas medidas en varias capas para prevenir inyecciones SQL: rutinas de validación de datos para comprobar las entradas del usuario, consultas parametrizadas a la hora de ejecutar las sentencias SQL y establecimiento adecuado de permisos a nivel de tablas y procedimientos almacenados en la base de datos. Fallar de forma segura En muchas ocasionesse producenerrorescuandolas aplicaciones realizan una transacción. El estado en que la aplicación queda cuando se produce dicho error, determina si la aplicación es segura o no. Detección de intrusos La detección de intrusiones requiere la existencia de tres elementos: • Capacidad para incluir en el log eventos relevantes de seguridad. • Procedimientos que aseguren que los logs son monitorizados con regularidad. • Procedimientos para responder adecuadamente a una intrusión una vez ha sido detectada Toda la informaciónde seguridad relevante debe ser registrada en un log. Es posible que un problema que no pudo ser detectado en tiempo de ejecución, pueda serlo gracias a la revisión de los logs. Evitar la seguridad por ocultación La seguridadporocultaciónesunmecanismode seguridaddébil ygeneralmente fallacuandoesel únicocontrol existente. Por ejemplo, la seguridad de una aplicación no puede depender de mantener en secreto el código fuente.Unejemplopodríaserel sistemaoperativoLinux;sucódigofuenteestádisponible,sinembargo,cuando está correctamente configurado, es un sistema seguro. Mantener la simplicidad Cuando el código fuente es muy complejo es más complicado hacerlo seguro. Es mejor mantenerlo simple. Solucionar correctamente los problemas de seguridad Una vez que se ha detectadounproblemade seguridad,esfundamental desarrollarpruebasparareproducirlo y detectar la causa raíz. Una vez que se desarrolla una solución válida es clave garantizar que no se introducen problemas de regresión. Por ejemplo, un usuario descubre que puede ver datos de otro usuario modificando un valor en una cookie. Perodebidoaque el mecanismode gestiónde cookies es compartido por todas las aplicaciones, un cambio en el código de este control afecta no sólo a la aplicación en la que se detectó el problema, sino a todas. Por lo tanto, la solución debe ser probada en todas las aplicaciones.
  • 10. CERTIFICACIÓNDESISTEMAS 10 2.- VERIFICACIÓN El proceso de verificación de la seguridad de una aplicación puede dividirse en tres etapas principales: A.- Preparación A la hora de llevar a cabo una verificación efectiva de la seguridad de una aplicación es crítico que el equipo encargado de realizar esta tarea: • Entienda el propósito de la aplicación y qué puntos dentro de ella son más críticos. • Identifique las principales amenazas, su motivación y cómo podrían atacar la aplicación. Para ello,antesde comenzarel procesode verificación,el equipo deberá estar familiarizado con los siguientes aspectos: • Código fuente: El equipo deberá tener conocimientos del lenguaje utilizado en la codificación y de las características de ese lenguaje desde la perspectiva de seguridad. • Contexto:Se debe conocerel funcionamientode laaplicaciónque estásiendorevisada,el tipode datosque se procesa y el daño que supondría que estos datos fueran comprometidos. • Audiencia: Los usuarios a los que va destinada la aplicación. • Importancia: ¿Hasta qué punto es relevante para la aplicación que quede inactiva durante un periodo de tiempo significativo o no? Además, el equipo de verificación necesitará información formal de la aplicación. Ésta puede obtenerse revisandodocumentosde especificaciónde requisitos,especificacionesfuncionales,resultados de pruebas, etc. Sin embargo, en muchos casos esta documentación está obsoleta y no contiene la información de seguridad apropiada. Por ello, es muy recomendable mantener alguna conversación con el equipo de desarrollo para compartir información básica sobre las consideraciones y controles clave de seguridad y adquirir una idea general sobre la estructura base del código y las librerías que se están utilizando. B.- Priorización Una vez que se haya recopilado esta información, el equipo de verificación deberá desarrollar un “modelo de amenazas” a alto nivel con el objetivo de establecer la prioridad a la hora de llevar a cabo el proceso de verificación. • Descomponer la aplicación: El objetivo de este paso es adquirir un conocimiento más profundo de la aplicación. Se obtendrá información acerca de cómo interactúa la aplicación con entidades externas, cómo es utilizada, qué puntos de entrada posee con los que un atacante podría interactuar, en qué áreas o elementos podría estar más interesado un atacante y qué nivel de privilegios poseen las entidades externas con las que interactúa la aplicación. Determinar y priorizar las amenazas: A la hora de identificar las amenazas, se recomienda establecer una metodología de categorización, ya sea propia o existente. Es aconsejable que la metodología que se adopte tenga en cuenta: • El punto de vista del atacante, es decir, se valoren los distintos exploits que puedan ser utilizados por un usuario malicioso. • La perspectivadefensivade laaplicación,esdecir,se tendránen cuenta las posibles debilidades en los controles de seguridad implementados.
  • 11. CERTIFICACIÓNDESISTEMAS 11 Despuésde que lasamenazashayansidoidentificadas,se deberíadeterminarel riesgo de cada una de ellas. De la misma manera que en el caso anterior, se recomienda el uso de un modelo, ya sea propio o existente. Por ejemplo, podría utilizarse un modelo basado en factores generales de riesgo como probabilidad – impacto. • Establecercontramedidasymitigación: Lafaltade protecciónde unaamenazaindica una vulnerabilidad, cuya exposición al riesgo podría ser mitigada con la implementación de una contramedida. A la hora de identificar estascontramedidaspuedenutilizarse listas de mapeo amenaza-contramedida: después de haber asignado el riesgoa cada una de las amenazas, es posible ordenarlas de mayor a menor riesgo, y priorizar el esfuerzo para mitigar cada una de ellas. Ejecución Una vez que el equipode verificaciónhaobtenidoel conocimientosuficiente sobrelaaplicaciónyhaestablecido la prioridadque debe establecerse en el proceso de verificación en base a las amenazas detectadas y el riesgo de cada una de ellas, es recomendable que realice las siguientes tareas que garanticen que los controles de seguridadestablecidossonadecuadosyque lasrecomendacionesde codificaciónanterioreshansidotenidasen cuenta: • Realización de pruebas de “hacking ético” periódicas sobre las aplicaciones en ejecución, mostrando evidencias de las vulnerabilidades explotadas. Estas pruebasse realizaránenentornosde pre-producción. Si en algún caso esto no fuera posible se llevarán a cabo enproducciónde forma controlada,teniendopresente que en este supuesto NUNCA deberán explotarse las vulnerabilidades detectadas para no afectar al funcionamiento normal de la aplicación. • Ejecuciónde pruebasestáticasde códigofuenteperiódicassobre lasdistintasversionesdel software,incluidas revisiones manuales del código siempre que se considere necesario para completar el análisis. Estas pruebas se realizarán en entornos de desarrollo y se reportarán los resultados de las mismas en un informe. Para llevar a cabo los análisis anteriores, tanto a nivel estático como de hacking ético, se recomienda: • Establecer metodologías propias o existentes (por ejemplo: CEH- Certified Ethical Hacker, para pruebas de “hacking ético”). • Hacer usode herramientasautomatizadasque faciliten la detección de vulnerabilidades en las aplicaciones. Los resultados de todas las actividades realizadas durante esta verificación, serán recogidos en un informe de resultados, dirigido al gestor de la comunidad de desarrollo. 3.- VALORACIÓN DE LA SEGURIDAD DE LAS APLICACIONES En base al informe de resultados, el gestor de la comunidad valorará si los controles de seguridad implementados son correctos y cumplen las recomendaciones de seguridad especificadas con el objetivo de establecer acciones correctivas si es necesario. Si fuera así, una vez propuestas las acciones correctivas e implementadas, se deberá volver a ejecutar el proceso de verificación para comprobar si se han corregido los defectos detectados en la revisión anterior.