Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
CERTIFICACIÓNDESISTEMAS
1
El Libro Naranja
El Departamento de Defensa de Estados Unidos desarrolló la norma Trusted Comput...
CERTIFICACIÓNDESISTEMAS
2
• Aseguramientodel ciclode vida.Software,hardware yfirmware debenser capaces de ser probados
ind...
CERTIFICACIÓNDESISTEMAS
3
arquitectura debe proporcionar el recurso, o un objeto, el aislamiento de protección de modo ade...
CERTIFICACIÓNDESISTEMAS
4
B3: Dominiosde Seguridad. En esta clase,másgranularidadse proporcionaencada mecanismode protecci...
CERTIFICACIÓNDESISTEMAS
5
evaluadacontrauna garantía específicadel documento de destino en el que se especificaban las fun...
CERTIFICACIÓNDESISTEMAS
6
• EAL4 Metódicamente diseñado, probado y revisado
• EAL5 Semiformalmente diseñado y probado
• EA...
CERTIFICACIÓNDESISTEMAS
7
• Requisitos de aseguramiento del Desarrollo. Identifica los requisitos específicos del producto...
CERTIFICACIÓNDESISTEMAS
8
Como se ha comentado anteriormente, la seguridad de la información se basa en los tres siguiente...
CERTIFICACIÓNDESISTEMAS
9
Por ejemplo, si una aplicación sólo requiere acceso a la red, permisos de lectura sobre una tabl...
CERTIFICACIÓNDESISTEMAS
10
2.- VERIFICACIÓN
El proceso de verificación de la seguridad de una aplicación puede dividirse e...
CERTIFICACIÓNDESISTEMAS
11
Despuésde que lasamenazashayansidoidentificadas,se deberíadeterminarel riesgo de cada una de el...
Upcoming SlideShare
Loading in …5
×

Certificación de sistemas

seguridad informatica

  • Be the first to comment

  • Be the first to like this

Certificación de sistemas

  1. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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.

×