Source: http://docplayer.es/801172-Avenida-de-la-vega-1-legato-road-suite-1100-28108-alcobendas-fairfax-22033-tel-34-91-490-29-00-tel-1-888-877-9506.html
Timestamp: 2018-11-13 23:46:36+00:00

Document:
Avenida de la Vega, 1, Legato Road, Suite , Alcobendas Fairfax, Tel. (+34) Tel. (+1) - PDF
Avenida de la Vega, 1, Legato Road, Suite , Alcobendas Fairfax, Tel. (+34) Tel. (+1)
Download "Avenida de la Vega, 1, Legato Road, Suite 1100 28108, Alcobendas Fairfax, 22033. Tel. (+34) 91 490 29 00 Tel. (+1) 888-877-9506"
Manuela Quintana Villalba
1 Instrucción técnica para la homologación del material de apuestas y verificación del cumplimiento de los requisitos técnicos aplicables a los medios informáticos. Epoche and Espri S.L. Epoche and Espri Corporation Edificion Veganova Fairfax Business Center Avenida de la Vega, 1, Legato Road, Suite , Alcobendas Fairfax, Madrid, España Virginia, USA Tel. (+34) Tel. (+1)
2 PREÁMBULO CAPÍTULO I. DE LOS REQUISITOS DE SEGURIDAD ARTÍCULO ARTÍCULO DISPOSICIÓN ADICIONAL... 6 ANEJO I. PERFIL DE PROTECCIÓN DEL SISTEMA DE INFORMACIÓN... 7 REFERENCIAS... 7 DEFINICIONES... 8 ABREVIATURAS... 8 IDENTIFICACIÓN... 9 OBJETO DEL PERFIL DE PROTECCIÓN... 9 RESUMEN DEL STOE... 9 USO DEL STOE TIPO DE STOE INTERFACES CON OTROS SISTEMAS REQUERIDOS POR EL STOE ORGANIZACIÓN DE DOMINIOS DECLARACIÓN DE CONFORMIDAD CON RESPECTO A LA NORMA [ISO19791] Y [CC31P2] CONFORMIDAD DE OTROS PP DEFINICIÓN DEL PROBLEMA DE SEGURIDAD ACTIVOS DEL STOE DEFINICIÓN DEL RIESGO POLÍTICAS ORGANIZATIVAS OBJETIVOS DE SEGURIDAD OBJETIVOS DE SEGURIDAD FUNCIONALES DEL STOE OBJETIVOS DE SEGURIDAD FUNCIONALES DE SISTEMAS OPERACIONALES EXTERNOS OBJETIVOS DE SEGURIDAD DE GARANTÍA DEL STOE JUSTIFICACIÓN DE LOS OBJETIVOS DE SEGURIDAD DEFINICIÓN DE COMPONENTES EXTENDIDOS REQUISITOS DE SEGURIDAD DEL STOE REQUISITOS QUE APLICAN A LOS TRES DOMINIOS REQUISITOS FUNCIONALES DE CONTROL OPERACIONAL AUDITORÍA PROTECCIÓN DE DATOS DOMINIO CLIENTES REQUISITOS FUNCIONALES TÉCNICOS REQUISITOS DE IDENTIFICACIÓN Y AUTENTICACIÓN REQUISITOS DE PROTECCIÓN DE DATOS DE USUARIO FUNCIONES DE GESTIÓN DE LA SEGURIDAD COMUNICACIONES PASARELAS DE PAGO AUDITORÍA REQUISITOS FUNCIONALES DE CONTROL OPERACIONAL DOMINIO OPERADORES INTERNOS REQUISITOS FUNCIONALES TÉCNICOS REQUISITOS DE IDENTIFICACIÓN Y AUTENTICACIÓN REQUISITOS DE PROTECCIÓN DE DATOS DE USUARIO FUNCIONES DE GESTIÓN DE LA SEGURIDAD FUNCIONES CRIPTOGRÁFICAS V 1.1 Página 2 de 119
3 INTEGRIDAD, NO REPUDIO DE LAS APUESTAS Y BOLETOS ESTABLECIMIENTO DE CRITERIOS DE ALEATORIEDAD EN AQUELLAS APUESTAS EN QUE ASÍ SE PRECISE COMUNICACIONES COMUNICACIONES CON LOS CLIENTES U OTRAS ENTIDADES EXTERNAS COMUNICACIONES CON LAS MÁQUINAS DE APUESTAS AUDITORÍA REQUISITOS FUNCIONALES DE CONTROL OPERACIONAL DOMINIO SOPORTE REQUISITOS FUNCIONALES TÉCNICOS REQUISITOS DE IDENTIFICACIÓN Y AUTENTICACIÓN REQUISITOS DE PROTECCIÓN DE DATOS DE USUARIO. POLÍTICA DE CONTROL DE ACCESO FUNCIONES DE GESTIÓN DE LA SEGURIDAD TOLERANCIA A FALLOS Y RECUPERACIÓN FUNCIONES CRIPTOGRÁFICAS CIFRADO DE LOS DISCOS DE LOS SERVIDORES CIFRADO DE LOS BACKUPS BORRADO SEGURO DE BACKUPS FUENTE DE TIEMPO AUDITORÍA Y DETECCIÓN DE INTRUSOS REQUISITOS FUNCIONALES DE CONTROL OPERACIONAL POLÍTICA DE SEGURIDAD PERSONAL GESTIÓN DE RIESGOS GESTIÓN DE LOS ACTIVOS GESTIÓN DE LA SEGURIDAD GESTIÓN DE SISTEMAS TI GESTIÓN DE ACTUALIZACIONES POLÍTICA ANTI-MALWARE COPIAS DE SEGURIDAD REGISTRO Y NOTIFICACIÓN DE INCIDENCIAS DE SEGURIDAD PLAN DE CONTINUIDAD DEL SERVICIO INSTALACIONES Y EQUIPAMIENTO REQUISITOS DE GARANTÍA DE SEGURIDAD REQUISITOS DE GARANTÍA ASOCIADOS A LA EVALUACIÓN DE SST REQUISITOS DE GARANTÍA ASOCIADOS A LA EVALUACIÓN DE STOE DESARROLLO/ FASE DE INTEGRACIÓN FASE DE INSTALACIÓN FASE DE OPERACIÓN FASE DE MODIFICACIÓN JUSTIFICACIÓN DE LOS REQUISITOS DE SEGURIDAD CUMPLIMIENTO DEL REGLAMENTO DE APUESTAS DE LA CIUDAD DE CEUTA JUSTIFICACIÓN DE LOS REQUISITOS FUNCIONALES DE SEGURIDAD JUSTIFICACIÓN DE LOS REQUISITOS DE GARANTÍA DE SEGURIDAD ANEJO II. AUDITORÍA DE LA SEGURIDAD V 1.1 Página 3 de 119
4 Preámbulo. Establece el Reglamento de Apuestas de la Ciudad de Ceuta, en su Artículo 23, los requisitos aplicables a los sistemas técnicos en el caso de apuestas que se formalicen por medios informáticos o electrónicos interactivos. El Capítulo II del citado reglamento, en su Artículo 7, establece la necesidad de acreditar la solvencia técnica, en particular, la necesidad de disponer de unos medios informáticos seguros para la organización y comercialización de las apuestas que garanticen el correcto funcionamiento de las mismas, requiriendo en su Artículo 8 de un informe de auditoría que avale tal extremo. En primer lugar, dada la complejidad de garantizar la seguridad de tales medios informáticos, se hace necesario desarrollar con mayor detalle técnico del indicado en el Reglamento de Apuestas de la Ciudad de Ceuta las características, funcionalidad y prestaciones que, en materia de seguridad y garantías a los usuarios de los servicios de apuestas autorizados por la Ciudad de Ceuta se deben prestar y mantener. Adicionalmente, y dado que la certificación del cumplimiento de unos requisitos de seguridad determinados es función y competencia ya desarrolladas en la Administración General del Estado, en virtud de la ORDEN PRE/2740/2007, de 19 de septiembre, por la que se aprueba el Reglamento de Evaluación y Certificación de la Seguridad de las Tecnologías de la Información, resulta conveniente y aconsejable la remisión a la autoridad técnica y administrativa en estas cuestiones la cuestión del cumplimiento de los requisitos técnicos de seguridad exigibles a las personas jurídicas a las que la Ciudad de Ceuta pueda conceder la autorización de organización y comercialización de apuestas. Esta instrucción técnica desarrolla, por tanto, los requisitos de seguridad exigibles a los sistemas informáticos regulados por el Reglamento de Apuestas de la Ciudad de Ceuta, sometiendo la certificación de su cumplimiento a la correspondiente resolución de certificación que el Centro Criptológico Nacional puede otorgar conforme a lo establecido en la ORDEN PRE/2740/2007, de 19 de septiembre, por la que se aprueba el Reglamento de Evaluación y Certificación de la Seguridad de las Tecnologías de la Información. V 1.1 Página 4 de 119
5 Capítulo I. De los requisitos de seguridad. Artículo 1. Los requisitos de seguridad detallados exigibles a los medios informáticos empleados en la organización y comercialización de las apuestas son los indicados en el Anejo I, "Perfil de Protección del Sistema de Información". Tales requisitos de seguridad se expresan conforme a los formalismos y conceptos de la norma ISO/IEC "Common Criteria", ampliados en su aplicación a un sistema de apuestas informático por lo establecido en ISO/IEC TR "Information technology Security techniques Security assessment of operational systems". Artículo 2. A los efectos de lo indicado en los artículos 8, 9 y 49.5 del vigente Reglamento de Apuestas de la Ciudad de Ceuta, el único informe de auditoría que se admitirá como prueba de cumplimiento de los requisitos de seguridad indicados en el anterior artículo será el certificado de conformidad emitido por el Centro Criptológico Nacional, a instancias de la empresa autorizada, a través de la correspondiente publicación en el Boletín Oficial del Estado de la resolución estimatoria de certificación. V 1.1 Página 5 de 119
6 Disposición adicional La exigencia de la certificación concedida por el Centro Criptológico Nacional entrará en vigor a los dos meses de la publicación de esta instrucción técnica en el Boletín Oficial de la Ciudad de Ceuta. Hasta tal fecha, se admite como medio de acreditación de la conformidad de los requisitos de seguridad un informe de una empresa auditora, con personal acreditado en auditorías de seguridad informática, sobre la solvencia técnica del sistema informático previsto para la organización y comercialización de las apuestas, conforme al programa de auditoría detallado en el Anejo II. V 1.1 Página 6 de 119
7 Anejo I. Perfil de Protección del Sistema de Información Referencias [ISO19791] ISO/IEC TR Information technology Security techniques Security assessment of operational systems [CC31p2] [LOPD] [RMS] [RACC] [RECSTI] Common Criteria for Information Technology Security Evaluation. Part 2: Security Functional Components Version 3.1 R3 Jul 2009 Ley Orgánica 15/1999, de 13 de diciembre, de Protección de Datos de Carácter Personal Real Decreto 1720/2007, de 21 de diciembre, por el que se aprueba el Reglamento de desarrollo de la Ley Orgánica 15/1999 de 13 de diciembre, de Protección de Datos de Carácter Personal. REGLAMENTO DE APUESTAS DE LA CIUDAD DE CEUTA, B. O. C. CE Martes 18 de Mayo de 2010 ORDEN PRE/2740/2007, de 19 de septiembre, por la que se aprueba el Reglamento de Evaluación y Certificación de la Seguridad de las Tecnologías de la Información. V 1.1 Página 7 de 119
8 Definiciones 1 Son de aplicación las definiciones incluidas en el REGLAMENTO DE APUESTAS DE LA CIUDAD DE CEUTA, B. O. C. CE Martes 18 de Mayo de Sistema operacional: sistema de información que incluye sus aspectos organizativos (no de las tecnologías de la información - TI), considerado en el contexto de su entorno de operacional. Incluye la combinación de procesos, procedimientos y personas, integrados con funciones y mecanismos de las TIs, aplicados juntos para establecer un nivel aceptable de riesgo residual en un entorno operacional definido. 3 Dominio de seguridad. Partes de un sistema operacional (subsistemas y componentes) que están bajo el mismo conjunto de políticas de seguridad. Abreviaturas CC IDS I&A OSF SPP SSA SSF SST STOE TOE Common Criteria Intrusion Detection System Identificación y Autenticación Operacional Security Function System Protection Profile System Security Assurance System Security Functionality System Security Target System Target of Evaluation Target of Evaluation TSF TOE Security Functionality (*) (*) En [CC31p2] el acrónimo TSF significa TOE Security Functionality. Sin embargo en [ISO19791], TSF hace referencia a Technical Security Function. A menos que se indique lo contrario, el significado de TSF será este último, tal y como se identifica en [ISO19791]. V 1.1 Página 8 de 119
9 Identificación Título Perfil de Protección. Sistema de Formalización de Apuestas. Versión 1.1 Fecha de Publicación 13 de septiembre de 2010 Autor Ayuntamiento de la Ciudad Autónoma de Ceuta 4 Este documento es un Perfil de Protección de Sistema (SPP), en el que se especifican los requisitos de seguridad funcionales (técnicos y de control) y de garantía para un sistema de formalización de apuestas on-line, conforme a la norma [ISO19791]. Objeto del Perfil de Protección 5 Este perfil de protección contiene las exigencias que deben cumplir los sistemas informáticos e interactivos así como las medidas de seguridad y organización de las empresas solicitantes de autorización para la organización y comercialización de apuestas, entendidas éstas como la actividad por la que se arriesga una cantidad de dinero sobre los resultados de un acontecimiento o un juego previamente determinado, de desenlace incierto y que pueden ser ajenos a las partes intervinientes en dicha apuesta, o bien, dependientes de la habilidad de los apostantes en juego. Resumen del STOE 6 El STOE proporciona una gestión integral de apuestas online sobre sucesos, cuya resolución final determinará un resultado concreto, hecho que sucede, por ejemplo, en eventos deportivos. En definitiva, el STOE actúa a modo de casa de apuestas, y para ello, distribuye la funcionalidad y su acceso en diferentes partes. 7 El sistema lleva a cabo una gestión de los mercados de eventos sobre los que se pueden realizar apuestas, junto con las tasas asociadas a cada resultado posible, de modo que presenta dicha información a los apostantes. 8 Cada apuesta realizada por un apostante queda debidamente registrada, y este registro emplea métodos que garantizan la integridad de la apuesta, así como el no repudio por parte del apostante. El recuento total de apuestas y la gestión monetaria asociado a las mismas se lleva a cabo de forma íntegra por el sistema. V 1.1 Página 9 de 119
10 9 El sistema posee una fuente confiable de tiempo externa que garantiza la integridad del tiempo, de modo que cada apuesta, así como cada evento del sistema se registra con la referencia correcta de tiempo en el que sucede. 10 Es responsabilidad del sistema garantizar la seguridad en las comunicaciones entre las entidades externas como clientes, medios de pago, entidades con derecho legal de acceso a la información de las apuestas de los clientes y distribuidores de información sobre los mercados. 11 Las capacidades de seguridad del sistema se centran en la protección de los datos de carácter personal de los clientes y de las garantías de las apuestas. Para ello, se definen controles o medidas técnicas de seguridad, entre otras: Registro de clientes mediante DNI o formulario; Política de I&A y control de acceso de clientes; Establecimiento de canales seguros en las comunicaciones; Uso de mecanismos criptográficos para garantizar la confidencialidad, integridad y no repudio de las apuestas; Uso de mecanismos criptográficos para garantizar la confidencialidad de los datos de los clientes; y controles o medidas operacionales, entre otras: gestión integral de la seguridad a nivel de sistema con políticas de contratación de operadores internos, copias de respaldo y recuperación del sistema, configuraciones seguras de los componentes de base o que dan soporte a la operación de la aplicación de formalización de las apuestas, cortafuegos e IDS, etc.; cumplimiento de la legalidad en el tratamiento de ficheros con información de carácter personal; Uso del STOE plan de continuidad del negocio; medidas de seguridad física de los locales en los que se ubica el STOE. 12 El uso del sistema se basa en la funcionalidad asociada a cada tipo de usuario. Se proporcionan diferentes tipos de acceso al sistema: Acceso de Clientes: Los clientes son los usuarios que realizan apuestas y deben estar registrados en el sistema. Los clientes tienen acceso a los mercados donde se publican eventos, junto con sus tasas, de modo que pueden apostar, siempre y cuando tengan un saldo en cuenta mayor al V 1.1 Página 10 de 119
11 importe de la apuesta a realizar. El cliente firma cada apuesta que hace, de modo que garantiza su autenticidad. Adicionalmente, cada cliente tiene acceso a su saldo, y puede tanto realizar recargas a través de medios de pago, como solicitar reintegros a una cuneta bancaria del total o parte del saldo disponible. Cada cliente puede ver la totalidad de las apuestas que ha realizado. Acceso de máquinas de apuestas. En caso de aplicar una arquitectura del sistema de juego basada en la existencia de máquinas de apuestas en las que el cliente final realice la apuesta, existirán medidas de seguridad adicionales respecto al canal de comunicaciones y al mecanismo de firma de las apuestas y boletos. En ambos casos, para garantizar la identidad de la máquina de apuestas se hará uso de un certificado reconocido expedido por el proveedor de servicios de certificación correspondiente. Acceso de Operarios internos: Existen usuarios operadores que tienen acceso a la gestión funcional de las apuestas (visualización de apuestas, gestión de riesgos) que se han realizado en el sistema, y a funcionalidad de seguridad asociada a la verificación de la integridad de las apuestas. Administradores internos: Los usuarios administradores pueden acceder a los datos de los usuarios del sistema, y pueden crear nuevos usuarios (excepto clientes). 13 Cualquier acceso al sistema es debidamente registrado, y se realiza un control de acceso para cualquier tipo de usuario. Tipo de STOE 14 El STOE es un sistema operacional cuyo propósito es implantar las capacidades de seguridad necesarias para realizar la gestión integral y formalización de apuestas online, protegiendo los datos de los clientes y las garantías de las apuestas. Interfaces con otros sistemas requeridos por el STOE 15 La figura representa el diagrama de contexto del sistema, proporcionando los límites en base a las entidades con las que interactúa: V 1.1 Página 11 de 119
12 16 El sistema, en su operativa normal, tiene interfaces con las siguientes entidades: Clientes o usuarios del sistema. Máquinas de apuestas. Consejería concreta de la comunidad autónoma correspondiente, que tiene acceso legal a los datos de clientes y apuestas. Mercados de eventos, que proporcionan información sobre los eventos activos. Medios de pago, a través de los cuales, los clientes pueden recargar el saldo de sus cuentas. 17 La totalidad de los accesos externos se realiza a través de canal seguro. Organización de dominios 18 La arquitectura de los sistemas operacionales, desde un punto de vista lógico, se estructura en dominios de seguridad o partes (subsistemas y componentes) que están bajo el mismo conjunto de políticas de seguridad. 19 Los requisitos funcionales (técnicos y operacionales) y de garantía se identifican por dominios de seguridad. Cada uno de los dominios que se especifican a continuación implementa sus propias medidas de seguridad bajo una política y contiene su propia política de retribuye a la resolución de una problema de seguridad que se presenta como global en este SPP. V 1.1 Página 12 de 119
13 20 Cada dominio tiene sus requisitos de garantía basados en el grado de confianza necesario para ese dominio y su contribución al sistema global. En este SPP, se requiere el mismo grado de confianza en cada uno de los dominios en los que se estructura el sistema, por lo que el conjunto de requisitos de garantía es común para todos ellos. 21 Los dominios presentan interdependencias entre si: existen servicios de seguridad asociados a un dominio, necesarios para ejercitar las capacidades de seguridad de otros. La seguridad se analiza por dominios de seguridad. 22 La arquitectura técnica del sistema que da soporte a los interfaces con las distintas entidades externas, así como la funcionalidad interna de gestión de la seguridad de las apuestas y componentes base, determinan la existencia de aspectos operativos del sistema que se encuentran bajo el paraguas de distintas políticas de seguridad, en concreto, relativas a su funcionalidad y política de control de acceso. Este hecho hace que se establezca una estructura de tres dominios, sin que se puedan considerar estancos: 23 Dos de los dominios, como se puede observar en la figura, operan en el ámbito de la aplicación que proporciona la funcionalidad de formalización de las apuestas: CLIENTES y OPERADORES INTERNOS. El tercer dominio opera en el contexto del soporte lógico, físico y procedimental, que conforma la plataforma base en la operativa del sistema global. 24 Cada dominio incluye sus propios requisitos funcionales técnicos y de control operacional, existiendo para todos ellos un conjunto común de requisitos de control operacional que se detallan en la sección de requisitos de seguridad. V 1.1 Página 13 de 119
14 Dominio CLIENTES (y máquinas de apuestas) 25 El dominio CLIENTES opera en el contexto de la aplicación de formalización de las apuestas. Se rige por la política de control de acceso asociada a los clientes y presenta capacidades técnicas de seguridad relacionadas con el registro de los clientes, mecanismo técnicos de I&A y control de acceso, funcionalidad que permite a los clientes la gestión de sus datos y sus apuestas, comunicaciones con las pasarelas de pago, un otras entidades externas, etc. 26 Las medidas de seguridad que garantizan la integridad y no repudio de las apuestas realizadas, se basan en la verificación del hash y la firma electrónica de la apuesta. Esta funcionalidad se realiza en el contexto del dominio de OPERADORES INTERNOS. La creación de la firma de la apuesta no se incluye en el dominio de la aplicación, sino que este SPP deja a elección del autor de la SST y desarrollador del STOE, la posibilidad de implementar dentro del mismo la funcionalidad de firma de las apuestas, o que sea el propio cliente del sistema el que proporcione la clave pública y la apuesta firmada al sistema para su verificación. 27 Se encuentran encuadradas en este dominio, las máquinas de apuestas desde las que un cliente final puede realizar la apuesta (a diferencia del cliente que accede desde su ordenador formalpara formalizarla). Aplican los mismos requisitos explicados en el párrafo anterior, con la salvedad de que tanto para el establecimiento del canal seguro (verificación de identidad de la máquina), como para la firma de apuestas y boletos, es obligado el uso de un certificado reconocido, conforme a la Ley 59/2003, de Firma Electrónica, y cuya expedición corresponderá al órgano competente, que podrá externalizar este servicio en un Prestador de Servicios de Certificación. Dominio OPERADORES INTERNOS 28 El dominio OPERADORES INTERNOS opera en el contexto de la aplicación de formalización de las apuestas. Se rige por la política de control de acceso asociada a los operadores internos (operarios de gestión del sistema de apuestas y administradores de seguridad de la aplicación) y presenta capacidades técnicas de seguridad relacionadas con el la administración de clientes, gestión de riesgos, validación de apuestas, comunicaciones seguras con los clientes, garantía de integridad de las apuestas validadas y almacenadas por el sistema, administración de seguridad de la aplicación y auditoría. Dominio SOPORTE 29 El dominio SOPORTE opera en el contexto del soporte lógico, físico y procedimental, que conforma la plataforma base en la operativa del sistema global. Se rige por su política de control de acceso que incluye, para su implementación, medidas tanto lógicas, como físicas o procedimentales, ya V 1.1 Página 14 de 119
15 que, los usuarios en este contexto será todo el personal laboral de la entidad. Presenta capacidades técnicas y de control operacional de seguridad relacionadas con la administración de la seguridad en la plataforma de base de la operativa de la aplicación (instalación segura y mantenimiento de sistemas operativos, bases de datos, cortafuegos, IDS, anti-virus), copias de respaldo y recuperación del sistema, protección de la información almacenada en los sistemas de ficheros y soportes externos, medidas procedimentales relativas al personal, etc. V 1.1 Página 15 de 119
16 Declaración de conformidad con respecto a la norma [ISO19791] y [CC31p2] 30 Este SPP declara conformidad con: La norma ISO/IEC TR Information technology Security techniques Security assessment of operational systems. Se declara conformidad funcional y de garantía (no extendidas). Common Criteria for Information Technology Security Evaluation, versión 3.1 R3 Jul Conformidad de otros PP 31 No se declara conformidad con ningún SPP. V 1.1 Página 16 de 119
17 Definición del problema de seguridad 32 La definición del problema de seguridad detallada en esta sección, es común para los tres dominios declarados en la sección Organización de dominios. Activos del STOE 33 El sistema operacional deberá proteger los datos de carácter personal de los clientes y las garantías de sus las apuestas. Los activos que protege el sistema son: ACTIVOS DATOS-CLIENTES DESCRIPCIÓN Datos de los clientes registrados en el sistema, entre otros: o Nombre. o Apellidos. o Fecha de nacimiento. o DNI/NIF o Dirección postal. o Código Postal. o País. o . o Teléfono móvil. o Nombre de usuario. o Pregunta de seguridad. o Número de Cuenta Bancaria. Datos de clientes potenciales para llevar a cabo nuevas acciones comerciales y prospección comercial. Datos pertenecientes a los clientes obtenidos a través de la relación comercial y que están almacenados el sistema. DATOS-APUESTAS Datos de las apuestas realizadas por los clientes, entre otros: o Identificación de la apuesta. V 1.1 Página 17 de 119
18 o Usuario que realiza la apuesta. o Nombre del resultado de la apuesta. o Nombre del mercado de la apuesta (+ identidad de la entidad tercera parte). o Cuota de la apuesta en el portal. o Cuota de la apuesta en la entidad tercera parte. o Cantidad de la apuesta en el portal. o Cantidad de la apuesta en en la entidad tercera parte. o Ganancia obtenida por la apuesta. o Fecha de realización de la apuesta. o Fecha de realización del evento. o Estado de la apuesta. o Identificador Resultado del Gestor de Riesgos. o Identificador del Libro del Gestor de Riesgos. o Identificador del Mercado del Gestor de Riesgos. o Apuesta premiada o no. o Identificador de resultado devuelto por en la entidad tercera parte. o Parámetro de resultado de en la entidad tercera parte. o Identificador del deporte de la apuesta. o Descripción del deporte de la apuesta. o Identificador del mercado de la apuesta. o Fecha de cancelación de la apuesta. o Ruta de mercado de la apuesta. o Nombre del resultado de la apuesta. Estos datos permiten que el sistema operacional realice la gestión de las apuestas realizadas por los clientes en la plataforma de juego, resolución y resultados, transacciones, formas de pago, etc. DATOS-BOLETOS Datos del boleto asociado a la apuesta formalizada y que se envía al cliente, entre otros: V 1.1 Página 18 de 119
19 o Identificación de la empresa autorizada. o Acontecimiento sobre el que se apuesta y fecha del mismo. o Modalidad e importe de la apuesta realizada. o Coeficiente de la apuesta, en su caso. o Pronóstico realizado. o Hora, día, mes y año de formalización de la apuesta. o Número o combinación alfanumérica que permita identificarlo con carácter exclusivo y único. o Identificación del medio de formalización de las apuestas utilizado. SERVICIO Se corresponde con el servicio que el sistema operacional proporciona a los clientes para la gestión de sus datos personales y de sus apuestas. Los DATOS-CLIENTES se recogen en el sistema con el fin de gestionar las apuestas que realicen los clientes. 34 Como se deriva de los ejemplos de contenido de los activos DATOS-CLIENTES y DATOS-APUESTAS de la tabla anterior, parte de la información se corresponde con datos de carácter personal que están sujetos a las medidas de seguridad especificadas en [RMS] para un nivel de seguridad BÁSICO según se define en [LOPD]. 35 Por lo tanto, se considera dicha información, como activos que debe proteger el sistema. El valor de los activos se centra en la confidencialidad (excepto boletos), integridad y disponibilidad de los mismos. 36 En el caso de las apuestas y boletos, también se considera el no repudio como valor que debe garantizarse. 37 Así mismo, el propio SERVICIO de apuestas es un activo para el que debe garantizarse su disponibilidad. 38 La siguiente tabla resume los activos y el valor del mismo que se desea proteger: Activo DATOS-CLIENTES DATOS-APUESTAS Valor Confidencialidad, Integridad, Disponibilidad Confidencialidad, Integridad, Disponibilidad, V 1.1 Página 19 de 119
20 No repudio DATOS-BOLETOS SERVICIO Integridad, Disponibilidad, No repudio Disponibilidad Definición del riesgo 39 En esta sección se define el riesgo (aceptable / no-aceptable) en términos de las amenazas sobre los activos, definiendo el agente de la amenaza (experiencia, recursos, oportunidad y motivación), activos afectados y acción adversa o vulnerabilidad. Las amenazas tienen como objeto eliminar el valor del activo, por lo que se supone: Activo Estado del riesgo Valor Comprometido DATOS-CLIENTES riesgo no-aceptable Confidencialidad riesgo no-aceptable riesgo no-aceptable Integridad Disponibilidad DATOS-APUESTAS riesgo no-aceptable Confidencialidad riesgo no-aceptable riesgo no-aceptable riesgo no-aceptable Integridad Disponibilidad No repudio DATOS-BOLETOS riesgo no-aceptable Integridad riesgo no-aceptable riesgo no-aceptable No repudio Disponibilidad SERVICIO riesgo no-aceptable Disponibilidad 40 En la tabla anterior, para el riesgo asociado a la disponibilidad de los DATOS-CLIENTES, DATOS-APUESTAS, DATOS-BOLETOS y SERVICIO, se dan ciertos escenarios de ataque, por ejemplo, el robo de los servidores que almacenan los datos y proporcionan el servicio o un incendio en las V 1.1 Página 20 de 119
21 instalaciones, en los que la materialización u ocurrencia del ataque y eliminación del valor del activo, se contrarresta con una combinación de medidas técnicas y operacionales implementadas a posteriori del incidente de seguridad. Es decir, se implementan medidas correctivas que, combinadas con medidas preventivas, disminuyen el efecto final (no evitan el suceso) y que tienen como objetivo, la recuperación del sistema en un tiempo breve y sin pérdida de datos. 41 En todos los escenarios, se supone un riesgo no-aceptable, en la medida en que se espera que sistema implemente controles técnicos y operacionales de carácter preventivo (y correctivo) que eliminen las amenazas definidas. 42 Los agentes de la amenaza, en función del origen del ataque podrán ser: (AG1) Agentes que realizan ataques remotos a través del cable y que podrán ser tanto clientes registrados, como usuarios no registrados. En dichos ataques, el punto de entrada es siempre el interface exterior. Estos atacantes pueden tener alta motivación ya que la posible manipulación de apuestas podría proporcionar grandes beneficios monetarios, por lo que aumenta la probabilidad de existencia del ataque. Esta alta motivación podría suponer el acceso a recursos tanto técnicos como personales de alta cualificación. La oportunidad se podría clasificar como de acceso ilimitado, ya que el acceso remoto al sistema se realiza a través de redes públicas. (AG2) Agentes que realizan ataques que implican un acceso físico a los locales donde se ubica el sistema operacional con el objeto de robar o destruir la información. Estos atacantes pueden tener alta motivación ya que la posible manipulación de apuestas o reclamaciones fraudulentas podrían proporcionar grandes beneficios monetarios, por lo que aumenta la probabilidad de existencia del ataque. Esta alta motivación podría suponer el acceso a recursos tanto técnicos como personales de alta cualificación. La oportunidad se podría clasificar como de acceso moderado ya que existe un acceso único para realizar el acto de robo o de sabotaje. (AG3) Agentes naturales cuyo efecto sería la destrucción de la información (por ejemplo, incendios no provocados, inundaciones no provocadas, terremotos, etc ). No es aplicable la determinación de motivación, recursos, experiencia u oportunidad al ser en evento natural. Sí se considera de interés que el autor de la SST y desarrollador del sistema, realicen un estudio de la probabilidad de existencia de eventos naturales en función de la localización del local. 43 A continuación se detallan las amenazas definiendo la acción adversa, los activos comprometidos, su valor y el agente que la realiza. V 1.1 Página 21 de 119
REF: 2012-11-INF-1062 v1 Difusión: Interno esquema (inc. laboratorios) Fecha: 11.10.2012 Creado: CERT8 Revisado: CALIDAD Aprobado: TECNICO INFORME DE CERTIFICACIÓN Expediente: 2012-11 CONTROLADOR JAVA

References: Artículo 23
 Artículo 7
 Artículo 8
 resolución 
 Artículo 1
 Artículo 2
 resolución 
 Real Decreto 
 resolución 
 resolución 
 resolución