Un perfil de protección ( PP ) es un documento que se utiliza como parte del proceso de certificación según la norma ISO/IEC 15408 y los criterios comunes (CC). Como forma genérica de un objetivo de seguridad (ST), normalmente lo crea un usuario o una comunidad de usuarios y proporciona una especificación independiente de la implementación de los requisitos de seguridad de la información . Un PP es una combinación de amenazas, objetivos de seguridad, suposiciones, requisitos funcionales de seguridad (SFR), requisitos de garantía de seguridad (SAR) y fundamentos.
Un PP especifica criterios genéricos de evaluación de seguridad para fundamentar las afirmaciones de los proveedores sobre una determinada familia de productos de sistemas de información. Entre otras cosas, normalmente especifica el Nivel de Garantía de Evaluación (EAL), un número del 1 al 7 que indica la profundidad y el rigor de la evaluación de seguridad, normalmente en forma de documentación y pruebas de respaldo, de que un producto cumple con los requisitos de seguridad especificados en el PP.
El Instituto Nacional de Estándares y Tecnología (NIST) y la Agencia de Seguridad Nacional (NSA) acordaron cooperar en el desarrollo de PP validados del gobierno de EE. UU .
Un PP establece un problema de seguridad de manera rigurosa para un conjunto determinado de sistemas o productos, conocido como Objetivo de evaluación (TOE), y especifica los requisitos de seguridad para abordar ese problema sin dictar cómo se implementarán dichos requisitos. Un PP puede heredar requisitos de uno o más PP.
Para que un producto sea evaluado y certificado de acuerdo con el CC, el proveedor del producto debe definir un Objetivo de Seguridad (ST) que puede cumplir con uno o más PP. De esta manera, un PP puede servir como plantilla para el ST del producto.
Aunque el EAL es el número más fácil de comparar para los profanos, su simplicidad es engañosa porque este número carece de sentido si no se comprenden las implicaciones de seguridad de los PP y ST utilizados para la evaluación. Técnicamente, comparar productos evaluados requiere evaluar tanto el EAL como los requisitos funcionales. Desafortunadamente, interpretar las implicaciones de seguridad del PP para la aplicación prevista requiere una gran experiencia en seguridad informática. Evaluar un producto es una cosa, pero decidir si la evaluación CC de un producto es adecuada para una aplicación en particular es otra muy distinta. No resulta obvio qué agencia de confianza posee la profundidad de la experiencia en seguridad informática necesaria para evaluar la aplicabilidad de los sistemas de los productos evaluados según Common Criteria.
El problema de la aplicación de evaluaciones no es nuevo. Este problema fue abordado hace décadas por un proyecto de investigación masivo que definió las características del software que podrían proteger la información, evaluó su solidez y trazó un mapa de las características de seguridad necesarias para los riesgos específicos del entorno operativo. Los resultados se documentaron en la Serie Rainbow . En lugar de separar los requisitos funcionales y de EAL, el Libro Naranja siguió un enfoque menos avanzado que definía las capacidades de protección funcional y los requisitos de garantía adecuados como una sola categoría. Se definieron siete de esas categorías de esta manera. Además, el Libro Amarillo definió una matriz de entornos de seguridad y evaluó el riesgo de cada uno. Luego estableció con precisión qué entorno de seguridad era válido para cada una de las categorías del Libro Naranja. Este enfoque produjo un libro de recetas inequívoco para el profano sobre cómo determinar si un producto era utilizable en una aplicación particular. La pérdida de esta tecnología de aplicación parece haber sido una consecuencia no deseada de la sustitución del Libro Naranja por los Criterios Comunes.