Source: http://legal.legis.com.co/document.legis/document.legis?fn=content&docid=legcol&bookmark=bf1a5e5c91465a045a7a023baff5f8cc444nf9&viewid=STD-PC
Timestamp: 2019-10-16 09:52:59+00:00

Document:
CIRCULAR EXTERNA 2 DE 24 DE ENERO DE 2013
CONTENIDO:PROVEEDORES DE SERVICIOS DE COMUNICACIONES Y OPERADORES DE SERVICIOS POSTALES. CIRCULAR EXTERNA 10 DE 2001 – CIRCULAR ÚNICA. FIJA EL CRONOGRAMA PARA LA ASIGNACIÓN DEL CÓDIGO ÚNICO NUMÉRICO (CUN) Y, LA IMPLEMENTACIÓN DE LOS MECANISMOS DE CONSULTA INTERACTIVA ENTRE LOS SISTEMAS DE LOS PROVEEDORES DE SERVICIOS DE COMUNICACIONES U OPERADORES POSTALES Y LOS SISTEMAS DE LA SUPERINTENDENCIA DE INDUSTRIA Y COMERCIO.
TEMAS ESPECÍFICOS:EMPRESA DE SERVICIOS PÚBLICOS, SUPERINTENDENCIA DE INDUSTRIA Y COMERCIO, SERVICIOS POSTALES, EMPRESA DE SERVICIO PÚBLICO DE TELECOMUNICACIONES
Asunto: Fijación del cronograma para la asignación del código único numérico (CUN), la implementación de los mecanismos de consulta interactiva y, la modificación del anexo técnico del título III de la Circular Única de la Superintendencia de Industria y Comercio.
Fijar el cronograma para asignación del código único numérico (CUN), la implementación de los mecanismos de consulta interactiva de las peticiones, quejas, recursos o solicitudes de indemnización presentadas por los usuarios, desde el portal de los proveedores de servicios de comunicaciones y operadores postales o desde el portal de la Superintendencia de Industria y Comercio.
De igual manera, se modifica el anexo técnico del título III de la Circular Única que contiene los requerimientos que deberán tener en cuenta los proveedores de comunicaciones y operadores postales para la implementación del código único numérico (CUN) y el reporte de apelaciones por medios electrónicos.
La Resolución 3066 del 18 de mayo de 2011, proferida por la Comisión de Regulación de Comunicaciones, CRC, por medio de la cual se establece el régimen integral de protección de los derechos de los usuarios de comunicaciones, señaló en el parágrafo 2º del artículo 41 que “Los rangos de numeración de los códigos numéricos de que trata el presente artículo, serán administrados y asignados a los proveedores de servicios de comunicaciones por parte de la Superintendencia de Industria y Comercio, SIC, de conformidad con los términos que dicha entidad establezca”.
De igual forma, la Resolución 3038 del 4 de abril de 2011, proferida por la Comisión de Regulación de Comunicaciones, CRC, por medio de la cual se expide el régimen de protección de los derechos de los usuarios de los servicios postales, estableció en el parágrafo 2º del artículo 26 que “Los rangos de numeración de los códigos únicos numéricos, serán administrados y asignados a los operadores postales por la Superintendencia de Industria y Comercio, de conformidad con los términos que dicha entidad establezca”.
En el capítulo tercero del título III de la Circular Única de esta superintendencia, se impartieron instrucciones a los proveedores de servicios de comunicaciones y los operadores postales acerca de la forma en que deben implementar y asignar el código único numérico (CUN).
Mediante Resolución 3986 del 23 de octubre de 2012, expedida por la Comisión de Regulación de Comunicaciones, CRC, se modificó el artículo 42 de la Resolución CRC 3038 de 2011 y el 113 de la Resolución CRC 3066 de 2011, estableciendo que la implementación del código único numérico (CUN), por parte de los proveedores de servicios de comunicaciones y operadores postales, deberá cumplirse a más tardar el 1º de mayo de 2013.
Así mismo, en virtud de lo establecido en el Decreto 4886 de 2011, le corresponde a esta superintendencia velar en los términos establecidos en la ley y en la regulación expedida por la Comisión de Regulación de Comunicaciones, por la observancia de las disposiciones sobre los usuarios de los servicios de telecomunicaciones y servicios postales, así como impartir las instrucciones y fijar los criterios que faciliten su cumplimiento.
3.1. Fijar el siguiente cronograma para la asignación del código único numérico (CUN) y, la implementación de los mecanismos de consulta interactiva entre los sistemas de los proveedores de servicios de comunicaciones u operadores postales y los sistemas de la Superintendencia de Industria y Comercio, los cuales se componen de las siguientes actividades a saber:
3.1.1. Asignación del CUN y seguimiento del estado de la PQR en los sistemas de gestión de PQR del proveedor u operador.
Ítem Actividad Plazo máximo
3.2.1. Visitas de acompañamiento de la SIC a proveedores y operadores (en sitio) para verificación de condiciones de asignación del CUN y seguimiento del estado de la PQR en los sistemas de gestión de PQR. Desde el 04/02/2013 hasta el 28/02/2013
3.2.2. Pruebas piloto internas de asignación del CUN y seguimiento del estado de la PQR en los sistemas de gestión de PQR del proveedor u operador. Del 11/02/2013 al 15/03/2013
3.2.3. Informe de resultados de las pruebas piloto realizados por parte de los proveedores/operadores. 22/03/2013
3.2.4. Realización de ajustes resultantes de incidentes evaluados durante las pruebas piloto. Del 1/04/2013 al 31/05/2013
3.2.5. Puesta en producción final de los sistemas de asignación de CUN y seguimiento del estado de la PQR en los sistemas de gestión de PQR del proveedor u operador. 30/04/2013
3.2.6. Inicio asignación formal de CUN y seguimiento del estado de la PQR en los sistemas de gestión de PQR del proveedor u operador. 1/05/2013
3.1.2. Implementación para los mecanismos de consulta interactiva entre los sistemas del proveedor u operador y los sistemas de la superintendencia.
3.1.1. Ejecución de las actividades técnicas por parte de los proveedores y operadores para implementar los mecanismos de consulta interactiva entre sus sistemas y los sistemas de la Superintendencia de Industria y Comercio. Desde el 1/02/2013 al 05/04/2013
3.1.2. Informe de avance sobre la ejecución de las actividades técnicas por parte de los proveedores y operadores para implementar los mecanismos de consulta interactiva entre sus sistemas y los sistemas de la Superintendencia de Industria y Comercio. 1er Informe: 14/03/2013
2º Informe: 5/04/2013
3.1.3. Visitas de acompañamiento de la SIC a proveedores y operadores (en sitio) para verificación de condiciones de los mecanismos de consulta interactiva entre sus sistemas y los sistemas de la Superintendencia de Industria y Comercio. Desde el 01/03/2013 hasta el 04/04/2013
3.1.4. Pruebas piloto de los mecanismos de consulta interactiva entre los sistemas de proveedores y operadores y los sistemas de la Superintendencia de Industria y Comercio. Del 08/04/2013 al 19/04/2013
3.1.5. Informe de resultados de las pruebas piloto de los mecanismos de consulta interactiva entre los sistemas de proveedores y operadores y los sistemas de la Superintendencia de Industria y Comercio. 22/04/2013
3.1.6. Realización de ajustes resultantes de incidentes evaluados durante las pruebas piloto. Del 22/04/2013 al 30/04/2013
3.1.7. Puesta en producción final de los mecanismos de consulta interactiva entre los sistemas de proveedores y operadores y los sistemas de la Superintendencia de Industria y Comercio. 30/04/2013
3.1.8. Inicio de la operación de los mecanismos de consulta interactiva entre los sistemas de proveedores y operadores y los sistemas de la Superintendencia de Industria y Comercio. 1/05/2013
3.2. Modificar el anexo técnico del título III de la Circular Única de la Superintendencia de Industria y Comercio, conforme con las especificaciones técnicas requeridas para la implementación del código único numérico (CUN) y el reporte de apelaciones por medios electrónicos, contenidos en el documento anexo a la presente circular.
Requerimientos para la implementación del CUN, consulta de PQR y reporte de apelaciones por medios electrónicos
Las instrucciones que trata el presente anexo técnico deberán ser adoptadas por todos los proveedores de servicios de comunicaciones y operadores de servicios postales sometidos a la inspección, vigilancia y control de la Superintendencia de Industria y Comercio, de conformidad con lo establecido en el capítulo tercero del título III de la Circular Única.
En todo caso los vigilados destinatarios de las instrucciones del presente numeral, deberán implementar los requerimientos que sean de carácter obligatorios aquí exigidos.
Cabe señalar que estas instrucciones no aplican a los casos a los que se refiere el parágrafo del artículo 1º de la Resolución CRC 3066 de 2011, por medio de la cual se establece el régimen integral de protección de los derechos de los usuarios de los servicios de comunicaciones (en adelante RPU) y de la Resolución CRC 3038 del 2011, por medio de la cual se establece el régimen de protección de los usuarios de los servicios postales (en adelante RPUSP).
1.2. Propósito.
El propósito de este documento es definir las especificaciones técnicas que deben considerar los proveedores de servicios de comunicaciones y operadores de servicios postales, tanto para la asignación del código único numérico (CUN) a las peticiones, quejas, recursos (en adelante PQRs) y a las solicitudes de indemnización que así lo requieren, como para el reporte de expedientes de apelaciones ante la Superintendencia de Industria y Comercio a través de los mecanismos dispuestos para ello.
De igual manera, se define el método de invocación y datos resultantes que se origina desde la Superintendencia de Industria y Comercio frente al estado del trámite de las PQRs presentadas ante los proveedores de servicios de comunicaciones y, las peticiones, quejas, recursos o solicitudes de indemnización presentados ante los operadores de servicios postales.
Así como también, el método de invocación del web service de la Superintendencia de Industria y Comercio cuando la consulta de las PQRs o las solicitudes de indemnización se origina desde el portal web del proveedor de servicios de comunicaciones u operador postal.
El alcance de este documento incluye los requerimientos técnicos que deben atender los proveedores de servicios de comunicaciones y operadores de servicios postales para la implementación del CUN al interior de sus organizaciones, así como las especificaciones para el reporte de expedientes de apelaciones ante la Superintendencia de Industria y Comercio y, el mecanismo para la consulta de las PQRs o solicitudes de indemnización presentadas por los usuarios, ya sea desde el portal de los proveedores de servicios de comunicaciones y operadores de servicios postales o desde el portal de la SIC.
De igual manera se describe las actividades que deberán ser desarrolladas tanto por la superintendencia como por los operadores/proveedores para llevar a cabo la implementación de la asignación, consulta de CUN y reporte de expedientes de apelaciones ante la SIC.
1.4. Estrategia para la implementación del CUN.
En relación con las actividades para implementar el código único numérico se establecen dos etapas principales a saber:
1) Asignación del CUN y seguimiento del estado de la PQR o solicitud de indemnización en los sistemas de gestión del proveedor u operador.
2) Implementación para los mecanismos de consulta interactiva entre los sistemas del proveedor u operador y los sistemas de la Superintendencia de Industria y Comercio, para facilitar la consulta del estado del trámite (independientemente de la ubicación del mismo).
Para la primera etapa las actividades que se van a surtir son:
1) Se efectuarán visitas de acompañamiento de la SIC a proveedores/operadores (en sitio) para verificarlas condiciones de asignación del CUN y el seguimiento del estado de las PQRs y solicitudes de indemnización en los sistemas de gestión.
2) Los operadores/proveedores deberán efectuar pruebas piloto internas de asignación del CUN y seguimiento del estado de las PQRs y solicitudes de indemnización en los sistemas de gestión de estos. Las pruebas deberán obedecer a un plan de pruebas establecidos por el proveedor/operador.
3) Los operadores/proveedores deberán presentar un informe de resultados de las pruebas piloto a la SIC, el cual debe contener como mínimo la siguiente información:
a. Fecha de realización de la prueba.
b. Casos a probar.
c. Parámetros (parámetros de entrada requeridos para realizar la prueba).
d. Persona(s) que realiza(n) la prueba.
e. Datos del ambiente de pruebas (motor base de datos, sistema operativo del servidor de aplicación y del servidor de base de datos).
f. Resultado de la prueba (exitoso/no exitoso).
g. Nombre y versión del sistema a probar (Ej. Sistema PQR v.1.0).
4) Los operadores/proveedores deberán efectuar ajustes resultantes de los incidentes detectados durante las pruebas piloto.
5) Los operadores/proveedores deberán realizar la puesta en producción final de los sistemas de asignación del CUN y seguimiento del estado de las PQRs y solicitudes de indemnización en sus sistemas de gestión.
Para la segunda etapa se deben llevar a cabo las siguientes actividades:
1) Efectuar las actividades técnicas por parte de los proveedores/operadores para implementar los mecanismos de consulta interactiva entre sus sistemas y los sistemas de la Superintendencia de Industria y Comercio.
2) Presentar informes de avance sobre la ejecución de las actividades técnicas por parte de los proveedores y operadores para implementar los mecanismos de consulta interactiva. Estos informes deben contener la siguiente información como mínima:
a. Fecha generación del informe.
b. Fecha inicial y final del periodo a reportar.
c. Cronograma de actividades (actividad, descripción, fecha inicial, fecha final, porcentaje avance, resultado de la actividad).
3) (sic).
4) Realizar visitas de acompañamiento por parte de la SIC a los proveedores/operadores (en sitio), para verificar las condiciones de los mecanismos de consulta interactiva entre sus sistemas y los sistemas de la Superintendencia de Industria y Comercio.
5) Los operadores/proveedores deberán realizar pruebas piloto de los mecanismos de consulta interactiva entre sus sistemas y los sistemas de la Superintendencia de Industria y Comercio. Para ello se debe coordinar con esta entidad la fecha de realización de dichas pruebas.
6) Los operadores/proveedores deberán presentar un informe de los resultados de las pruebas piloto de los mecanismos de consulta interactiva de los que viene hacerse(sic) referencia, el cual debe contener como mínimo la siguiente información:
a.(sic) Datos del ambiente de pruebas (motor base de datos, sistema operativo del servidor de aplicación y del servidor de base de datos).
e. Resultado de la prueba (exitoso/no exitoso).
b.(sic) Nombre y versión del sistema a probar (Ej. Consulta PQR v.1.0).
f.(sic).
7) Los operadores/proveedores deberán realizar los ajustes resultantes de los incidentes detectados durante las pruebas piloto.
8) Los operadores/proveedores deberán efectuar la puesta en producción final de los mecanismos de consulta interactiva entre sus sistemas y los sistemas de la Superintendencia de Industria y Comercio.
Respecto al reporte de apelaciones por medio electrónico a la Superintendencia de Industria y Comercio el proveedor/operador deberá informar por escrito a la SIC su intención de utilizar este mecanismo y aplicará para ello las siguientes actividades:
1) Los operadores/proveedores deberán realizar pruebas piloto de los mecanismos de reporte de expedientes de apelaciones ante la SIC. Para ello se deberá coordinar con esta entidad la fecha de realización de dichas pruebas.
2) Los operadores/proveedores deberán presentar un informe de los resultados de las pruebas piloto de los mecanismos de reporte de expedientes de apelaciones ante la SIC, el cual debe contener como mínimo la siguiente información:
g. Nombre y versión del sistema a probar (Ej. Consulta PQR v.1.0).
3) Los operadores/proveedores deberán realizar los ajustes resultantes de los incidentes detectados durante las pruebas piloto.
4) Los operadores/proveedores deberán efectuar la puesta en producción final de los mecanismos de reporte de expedientes de apelaciones ante la SIC, previa habilitación por parte de la SIC, una vez culminada exitosamente la etapa de pruebas.
2.2. Definiciones de criterios de seguridad y calidad que deberá cumplir la asignación del CUN y su consulta.
2.1.1. Confidencialidad.
La información asociada a la asignación y consulta del CUN debe ser asegurada. Los proveedores de servicios de comunicaciones y operadores de servicios postales deben garantizar la confidencialidad de la información tanto en la fase de transmisión de los datos, como en la fase de almacenamiento, sin importar el canal por el cual se transmita o el lugar donde se encuentre almacenada. Solo debe ser accedida por los sistemas de información o personas a las cuales sea destinada la misma.
Para asegurar la confidencialidad de la información a nivel de transporte, los proveedores/operadores deberán implementar el protocolo TLS (transport layer security) v. 1.0 o superior, en los canales de comunicación de los sistemas de información y aplicaciones que reciban o transmitan datos entre la infraestructura del proveedor u operador y la SIC.
Cuando la transmisión se realice entre los sistemas de información, es necesario generar un esquema de autenticación mutua, basada en certificados digitales de sitio seguro, emitidos por una entidad de certificación abierta debidamente autorizada o acreditada en Colombia, propios de cada entidad (proveedor/operador - SIC). El cifrado del certificado digital debe ser mínimo de 256 bits.
2.1.2. Integridad.
La información asociada a la asignación del CUN debe ser precisa, coherente y completa. El sistema deberá tener los mecanismos que sean necesarios para garantizar la trazabilidad de los códigos asignados y que los mismos no puedan ser alterados posteriormente.
Como consecuencia de lo anterior, los operadores/proveedores deberán garantizar la integridad de información de los paquetes mediante la utilización de XML signature, usando un certificado digital de persona jurídica, emitido por una entidad de certificación abierta debidamente autorizada o acreditada en Colombia, en los siguientes campos:
• Número CUN asignado(1)
• Fecha y hora de la asignación del CUN(2)
La firma debe configurarse bajo la especificación RSA-SHA1 y el resumen de los mensajes para la firma se debe realizar con SHA1.
La información asociada a la asignación del CUN, así como su consulta deberá estar disponible en el momento que la SIC lo requiera, al igual que los recursos tecnológicos empleados por el operador y/o proveedor.
Teniendo en cuenta que el módulo de asignación del CUN y el de su consulta son sistemas de alto impacto en la gestión de las PQRs y solicitudes de indemnización que realizan los usuarios ante los proveedores de servicios de comunicaciones y operadores de servicios postales, se debe garantizar la disponibilidad de tales servicios a efecto de que no se afecte la continuidad y la secuencia en la asignación y consulta del CUN.
Para ello cada proveedor de servicios de comunicaciones y operador de servicios postales deberá disponer de las herramientas necesarias que le permitan alcanzar los niveles de disponibilidad requeridos.
Las métricas para medir la disponibilidad de la infraestructura tecnológica que soporta el sistema de asignación del CUN, así como su consulta (a través de los servicios web que sean implementados), se deberá sujetar a las siguientes metas periódicas:
Tabla 1. Metas periódicas
Periodo mayo a jun.-13 Jul. a dic.-13 Ene.-14 a jun.-14 Jul.-14 en adelante
Metas 91% +- 4% 93% +- 3% 95% +- 2% 98% +- 2%
Para el cálculo, se tendrá exclusivamente en cuenta la disponibilidad del sistema de asignación y los servicios web de consulta, durante el período de análisis, previendo operación continua.
Los proveedores/operadores deberán tener disponibles los indicadores aquí señalados, con los cortes asociados a las metas establecidas y con corte trimestral a partir del año 2014. Los soportes de estos indicadores deberán estar a disposición cuando la Superintendencia de Industria y Comercio así lo requiera. En todo caso, el informe del período deberá consolidarse dentro de los diez (10) días hábiles siguientes al vencimiento del mismo.
2.1.4. Auditoría.
Es necesario dentro del esquema de seguridad generar mecanismos de auditoría, que permitan entender una cadena de eventos con los cuales se pueda determinar la causa de cualquier problema, por lo tanto, es obligatoria la generación de logs, que permitan la trazabilidad de objetos dentro de la aplicación, los accesos de usuario y los eventos propios del sistema.
Con el fin de contar con mecanismos de seguridad técnica y de validez jurídica, que garantice la fecha y hora de creación de los datos en tránsito, los proveedores y operadores deberán implementar el estampado cronológico en la cabecera del paquete, para tal fin, el servicio de estampado cronológico debe ser suministrado por una entidad de certificación abierta que cuente con la autorización y/o acreditación para prestar dicho servicio de conformidad con lo establecido por la Ley 527 de 1999, el Decreto 1747 de 2000 y las normas que resulten aplicables.
Los logs de auditoría, asociados a la asignación del CUN, deben ser parte de cada uno de los aspectos de seguridad aquí tratados, con el fin de conocer los posibles aspectos de falla en los controles generados por las aplicaciones.
En el log se debe registrar como mínimo, lo siguiente:
• Número CUN asignado
• Fecha y hora de la asignación del CUN
• Identificación del usuario (tipo y número de identificación)
• Resultado de la transacción (éxito o fallo)
El proveedor de comunicaciones u operador de servicios postales podrá implementar mecanismos de auditoría adicionales, como por ejemplo, llevar una bitácora de consultas efectuadas por los servicios web dispuestos por la SIC.
2.1.5. No repudio.
Se debe asegurar a fin de que no sea posible aludir repudio por acciones generadas de manera válida dentro del sistema, el control debe ser establecido bajo la implementación de XML signature, firmando digitalmente utilizando certificados emitidos por entidades de certificación abierta debidamente autorizadas o acreditadas en Colombia.
2.2.1. Efectividad.
La información asociada al CUN debe ser pertinente y su entrega oportuna, correcta y consistente. El sistema debe garantizar que para cada PQRs o solicitud de indemnización a la que aplique la tipología definida en el capítulo tercero del título III de la Circular Única, el CUN asignado sea acorde con la estructura definida, asignado cronológicamente y sea único por cada asignación que realice el proveedor de servicios de comunicaciones u operador de servicios postales.
Para tal efecto, en relación con la fecha y hora de asignación del CUN, el mecanismo que se implemente para ello deberá estar sincronizado con el servidor de la hora legal para la República de Colombia, el cual podrá ser accedido a través del sitio web de la Superintendencia de Industria y Comercio.
El número del CUN asignado deberá ser reportado al usuario en el momento de la presentación de la PQR o solicitud de indemnización.
2.2.2. Eficiencia.
Entendida como la capacidad que tiene el proveedor de servicios de comunicaciones u operador postal para lograr la asignación del CUN haciendo uso de los medios que tiene disponible, de forma tal que se eviten situaciones tales como reprocesos que terminen afectando la atención al usuario. En este sentido deberá ser asignado el CUN conforme a la tipología asignada.
2.2.3. Confiabilidad.
Se refiere a que la información asociada debe ser íntegra, es decir, que esté implementada bajo un esquema que permita que la información sea exacta y completa.
3. Definiciones de criterios de seguridad y calidad que deberá cumplir el envío de expedientes de apelación a la SIC por medios electrónicos.
En relación con la confidencialidad de la información, se deberá cumplir con lo relacionado en el numeral 2.1.1 del presente anexo, es decir, que los proveedores de servicios de comunicaciones y operadores de servicios postales deberán implementar el protocolo TLS (Transport Layer Security) v. 1.0 o superior.
Para asegurar la confidencialidad mientras se transmiten a la SIC los archivos correspondiente a los expedientes de apelaciones, se recomienda utilizar una conexión SSH con una protección de puerto mediante una secuencia preestablecida de intentos de conexión que se encuentran cerrados (Port Knocking), con el fin de prevenir un escaneo de los puertos por parte de un atacante, debido a que este solo se abre ante una secuencia de golpeteo de puertos correctos. Dicha implementación se encuentra descrita en el numeral 8.3 del presente anexo.
Para realizar la conexión a un puerto determinado los proveedores u operadores deberán establecer de común acuerdo con la Superintendencia de Industria y Comercio la secuencia que permitirá realizar de manera válida la apertura del mismo, por medio de la configuración del demonio que espera dicha secuencia. Esta misma secuencia será utilizada por la SIC, para cerrar el puerto cuando la transmisión de información necesaria sea completada.
Los operadores/proveedores deberán aplicar lo indicado en el numeral 2.1.2 del presente anexo técnico y garantizar la integridad de información de los paquetes mediante la utilización de XML signature. Para asegurar que los datos transmitidos sean íntegros, deberán generarse archivos comprimidos con su respectivo hash calculado, nombrado de la misma forma que el archivo que contiene los documentos anexos de la PQR o solicitud de indemnización.
El hash debe ser calculado sobre el archivo comprimido que contenga la información completa necesaria para el estudio de la reclamación. Debe ser usada la función SHA-2 la cual genera una salida de hash de 256 bits. Esta especificación se encuentra desarrollada en el numeral 8.3 del presente anexo.
La Superintendencia de Industria y Comercio realizará la comprobación del hash después de la transmisión para asegurar la integridad de la información enviada, igualmente se debe garantizar la información almacenada realizando el cálculo del hash cada vez que vaya a ser usado, realizando un cálculo del mismo sobre el archivo almacenado.
3.3. Auditoría.
En relación con la transmisión de archivos a la SIC, se deben habilitar los logs de auditoría del servidor SSH, con el fin de determinar posibles intentos de autenticación fallidas. También se debe realizar la auditoría de transmisión de archivos por medio del protocolo SCP entre los servidores de los proveedores u operadores y los servidores de la Superintendencia de Industria y Comercio. Se debe asegurar que se generen logs a nivel de SSH y SCP en los servidores, con el fin de realizar seguimiento a cualquier actividad de autenticación y transmisión de archivos.
• Operador o proveedor que realiza la transmisión
3.4. No repudio.
El no repudio, se mitigará a nivel de autenticación contra el servicio SSH, por medio de un certificado, asegurando que el único usuario permitido para acceder a los archivos que contienen información sensible con información relacionada a las PQRs sea la SIC.
3.5. Control de acceso.
El control de acceso se realizará con una doble autenticación, generada en una primera etapa por el demonio de port knocking, que debe ser configurado por los proveedores u operadores para que el puerto no se encuentre público en todo momento. Posteriormente el proceso de autenticación se terminará con el intercambio de credenciales generado entre los servidores de los proveedores u operadores y la Superintendencia de Industria y Comercio, haciendo uso de un certificado generado por el operador/proveedor.
4. Obligaciones generales.
En desarrollo de lo dispuesto en el presente anexo técnico, los proveedores de servicios de comunicaciones y operadores de servicios postales deberán incluir en sus políticas y procedimientos relativos a la administración de la información asociada a la asignación del CUN y a su consulta, los criterios de que trata el numeral 2º del presente anexo.
Adicionalmente, para dar aplicación a dichos criterios los proveedores/operadores deberán adoptar, al menos, las medidas que se relacionan a continuación:
4.1. Seguridad y calidad.
En desarrollo de los criterios de seguridad y calidad, y considerando los canales para la asignación del CUN, los proveedores de servicios de comunicaciones y operadores de servicios postales deberán cumplir, como mínimo, con los siguientes requerimientos:
• Disponer de la infraestructura tecnológica necesaria, así como de los procedimientos y controles requeridos, que permitan realizar la asignación del CUN y la gestión de la información conforme a las condiciones derivadas de los criterios de seguridad y calidad ya señalados.
• Velar porque la información remitida a los usuarios esté libre de software malicioso (por ejemplo la página de consulta en el sitio web del operador o proveedor).
• Tener en operación la infraestructura tecnológica y aspectos asociados (protocolos, servicios, aplicaciones, usuarios, equipos, entre otros) requeridos para el adecuado desarrollo de las actividades necesarias para la implementación y operación del CUN.
• El proveedor de comunicaciones y el operador de servicios postales procurará utilizarlas mejores prácticas sobre los estándares mínimos de seguridad dispuestos en la norma colombiana NTC-ISO/IEC 27001.
Estas mejores prácticas deberán ser implementadas por los proveedores de servicios de comunicaciones y operadores de servicios postales teniendo en cuenta su infraestructura. Para ello se sugiere, por ejemplo, mecanismos de monitoreo de disponibilidad de la base de datos que accede el servicio de asignación del CUN, mecanismos de monitoreo de disponibilidad del servidor de aplicaciones donde reside dicho servicio, mecanismos de monitoreo de disponibilidad del servidor de aplicaciones donde reside el servicio de consulta del CUN, entre otros.
• Disponer de planes de contingencia y continuidad debidamente documentados que garanticen la disponibilidad del servicio de asignación del CUN. Los planes de contingencia y continuidad deben tener al menos los siguientes componentes:
a. Análisis y evaluación de riesgos: Se trata de obtener un conocimiento de la plataforma tecnológica de la organización que soportará la asignación del CUN y de los procesos que se consideran críticos para el funcionamiento de este sistema. Una vez identificados los mismos, se analizarán cuáles son los riesgos asociados para identificar las causas potenciales que pueden llegar a interrumpir la asignación del CUN.
b. Selección de estrategias: El operador/proveedor deberá valorar las diferentes alternativas y estrategias de respaldo en función de los resultados obtenidos en la fase anterior, para seleccionar la estrategia más adecuada que garantice la disponibilidad del servicio, además, se deben corregir las vulnerabilidades detectadas en los procesos críticos identificadas en el análisis de riesgos.
c. Desarrollo del plan: Una vez que se ha seleccionado la estrategia de respaldo hay que desarrollarla e implantarla para el sistema de generación del CUN. En esta fase se desarrollan los procedimientos y planes de acción que permitan la ejecución del plan de contingencia.
Las tres fases del plan de contingencia deben estar debidamente documentadas y sustentadas. Debe hacerse una prueba a este plan de contingencia para demostrar su efectividad generando un informe con los resultados obtenidos.
El plan de contingencia debe revisarse y actualizarse por lo menos una vez al año, verificando nuevos riesgos en la plataforma tecnológica que soporta el sistema y tomando las acciones necesarias que permitan la continuidad y disponibilidad de la asignación del CUN.
En materia de documentación los proveedores de servicios de comunicaciones y operadores de servicios postales deben cumplir con los siguientes requerimientos:
• Un registro detallado de los códigos asignados, que deberán contener como mínimo la siguiente información:
- Número del CUN asignado.
- Fecha y hora de radicación de la PQR o solicitud de indemnización.
- Estado, para este caso se tendrán en cuenta los indicados en el artículo 52 de la Resolución CRC 3066 de 2011 (para el caso de proveedores de comunicaciones) y las normas que la modifiquen o la adicione; así como los previstos en el título III capítulo tercero de la Circular Única de la SIC.
- Datos básicos del quejoso que solicita el trámite. Se entenderán por datos básicos, el tipo y número de identificación del usuario.
- Datos del proveedor de servicios de comunicaciones u operador postal frente al cual se interpuso el trámite. Se entenderán por datos básicos, el tipo y número de identificación.
• Procedimientos que describan la disponibilidad, mecanismo de asignación, control y registro de los números CUN asignados, para garantizar que se cumpla lo establecido en los criterios de seguridad y calidad ya indicados.
• Procedimientos que describan la disponibilidad de la consulta de CUN, para garantizar que se cumpla lo establecido en los criterios de seguridad y calidad ya indicados.
Mantener a disposición de la Superintendencia de Industria y Comercio, estadísticas anuales con corte a 31 de diciembre de cada año respecto de la asignación del CUN que contemplen: la bitácora de asignación del CUN, bitácora de anulación, bitácora del nivel de disponibilidad del servicio, tipo de PQR. La información estadística que anualmente se consolide, deberá ser conservada por un término de tres (3) años(3).
Así mismo, deberán llevar estadísticas mensuales de acceso a la consulta del CUN indicando entre otros los siguientes datos: número de consultas realizadas, número de consultas exitosas, número de consultas fallidas y tiempo de respuesta promedio.
• En relación con los datos estadísticos, los datos que debe contener la bitácora de asignación son:
- Operador: Código base (identificador del operador)
- CUN: Número de CUN asignado
- Fecha asignación: Corresponde a la fecha de generación de CUN, en formato AAAA-MM-DD HH:MM:SS
- Tipo de PQR: De acuerdo con la tipología de petición, queja, recurso y solicitud de indemnización establecida en la Circular Única en el titulo III capitulo tercero.
• En relación con los datos estadísticos, las anulaciones del CUN, la bitácora que se debe registrar es:
- Fecha Incidente: Corresponde a la fecha de ocurrencia de la incidencia, en formato AAAA-MM-DD HH:MM:SS
- Motivo incidencia: Corresponde al tipo de situación que generó la incidencia, la cual puede ser: Tipología exenta, error de transcripción, entre otros
- Tipo y número de identificación: Asociado a la persona que registra el reporte del incidente
- Nombre de la persona: Apellidos y nombres de la persona que registra el reporte del incidente
- Fecha reporte: Fecha en que se reporta la incidencia en formato AAAA-MM-DD HH:MM:SS
• En relación los datos estadísticos, con incidentes que afecten la disponibilidad del módulo de asignación del CUN, así como la consulta del mismo, por motivos técnicos, deben ser registrados en una bitácora y la información que se debe consignar es:
- Fecha y hora inicio incidente: Corresponde a la fecha de ocurrencia de la incidencia, en formato AAAA-MM-DD HH:MM:SS
- Fecha y hora recuperación del incidente: Corresponde a la fecha en la que se logró recuperar de la incidencia, en formato AAAA-MM-DD HH:MM:SS
- Motivo incidencia: Corresponde al tipo de situación que generó la incidencia, la cual puede ser: Mantenimiento, falla en servidor, problemas de fluido eléctrico, falla de software, otros
- Nombre de la persona: Apellidos y nombres de la persona que registra reporte del incidente
• En relación con los datos estadísticos asociados al tipo de PQR, se deberá registrar, el tipo de PQR y la cantidad de solicitudes recibidas por el operador de comunicaciones o proveedor de servicios postales asociadas a ese tipo.
En materia de divulgación de información los proveedores de servicios de comunicaciones y operadores de servicios postales deberán cumplir, como mínimo, con los siguientes requerimientos:
• Suministrar a los usuarios, información clara, completa y oportuna sobre el CUN asignado, de conformidad con lo establecido en el numeral 3.4 “Mecanismos para informar o comunicar la asignación de un código único numérico (CUN)” del capítulo tercero del título III de la Circular Única.
• Dar a conocer a los usuarios de manera oportuna los traslados de las PQRs o solicitudes de indemnización entre proveedores de servicios de comunicaciones u operadores de servicios postales y la asignación del CUN. En el caso de servicios de comunicaciones empaquetados o interconectados, se deberá tener en cuenta los procedimientos establecidos para asignación y reportes del CUN señalados en los numerales 3.5 y 3.6 del capítulo tercero del título III de la Circular Única.
• Cuando no se pueda realizar la asignación del CUN o no se pueda acceder a la consulta del mismo, se deberá advertir previamente al usuario de esta situación y se seguirá el procedimiento señalado en el numeral 3.11 “Procedimiento a seguir cuando el sistema no se encuentre disponible por fallas o mantenimientos” del capítulo tercero del título III de la Circular Única.
• Los proveedores u operadores deberán suministrar al usuario por cualquier medio idóneo la constancia de la presentación de la PQR o solicitud de indemnización, la cual contendrá como mínimo la siguiente información: fecha y hora, el CUN asignado y datos del solicitante (usuario).
• Informar y mantener debidamente actualizados, los procedimientos necesarios para atender de manera segura y eficiente a los usuarios en todo momento, en particular cuando se presenten situaciones especiales tales como: fallas en los sistemas, restricciones en los servicios o mantenimientos programados, entre otros.
5. Aspectos técnicos y funcionales que debe cumplir la implementación del CUN.
Para la implementación de aspectos técnicos y funcionales deberá seguir de manera estricta la estructura definida para el CUN, la cual deberá ser informada y divulgada al usuario.
A continuación se describe el formato definido:
IO, identificador operador: Corresponde a los 4 primeros dígitos que identifican al operador. Es el número que la SIC asignó e informó a los proveedores de comunicaciones y operadores de servicios postales.
AA, año de radicación: Corresponde a los 2 últimos dígitos del año en el que se registra en el sistema de PQR del operador, la primera radicación de la solicitud.
CR, consecutivo de radicación: Es un número secuencial ascendente de diez (10) dígitos dado por el sistema de PQR de cada operador a cada asunto nuevo originado en el año en que se radicó la primera comunicación. Se inicia en 0000000001 el primer día hábil de cada año.
Los proveedores de servicios de comunicaciones y operadores de servicios postales deberán cumplir adicionalmente con los siguientes aspectos técnicos y funcionales para la implementación del CUN:
• El código único numérico deberá mantenerse durante todo el trámite de la PQR o solicitud de indemnización, incluido el trámite del recurso de apelación ante esta superintendencia.
• El número CUN a asignar, corresponde a la conjunción del código base, año y un consecutivo numérico ascendente de diez (10) dígitos (que inicia cada año), de conformidad con lo previsto en el capítulo tercero del título III de la Circular Única de esta superintendencia. El proveedor de servicios de comunicaciones u operador de servicios postales deberá implementar los mecanismos que garanticen su unicidad, integridad, disponibilidad y autenticidad.
El consecutivo de diez (10) dígitos permite recibir anualmente hasta 9.999.999.999 peticiones, quejas, recursos y solicitudes de indemnización, cantidad suficiente para la asignación del CUN a las tipologías previstas por parte de cualquier proveedor de servicios de comunicaciones u operador de servicios postales objeto de esta obligación, a nivel nacional.
• Una vez asignado un CUN, este no podrá ser objeto de nuevas asignaciones o ser reutilizado en trámites posteriores. Para ello deberán implementarse los mecanismos técnicos necesarios que impidan su utilización.
• Cuando exista más de un código único numérico (CUN) asignado a una misma petición, queja, recurso y solicitud de indemnización que verse sobre los mismos hechos y pretensiones, el proveedor de servicios de comunicaciones u operador postal, deberá acumular la PQR y solicitud de indemnización al primer CUN asignado, de conformidad con lo señalado en el numeral 3.9 “Acumulación de CUN” del capítulo tercero del título III de la Circular Única.
En todo caso la acumulación de la que se hace referencia no podrá superar el término de los quince (15) días hábiles siguientes a la fecha en que se presentó la primera petición, queja, recurso y solicitud de indemnización.
• La anulación de los CUN solo se admitirá en los casos señalados en el numeral 3.10 “Anulación de código único numérico (CUN)” del capítulo tercero del título III de la Circular Única. En todo caso, se deberá almacenar con el respectivo soporte en las bitácoras de registro de asignación de CUN, el cual deberá estar disponible para cuando sea requerido, en ejercicio de las facultades conferidas a la Superintendencia de Industria y Comercio.
• Mensajes de contingencia cuando el sistema presente fallas o se den ventanas de mantenimiento programadas.
Los mensajes de contingencia o de errores en caso de fallas de los sistemas internos de cada empresa, serán definidos por cada proveedor de servicios de comunicaciones u operador postal, por ejemplo así:
- Mensaje de contingencia para la asignación del CUN de las PQRs que se presentan a través de oficinas virtuales de atención al usuario:
“Apreciado usuario: El sistema de asignación del CUN se encuentra temporalmente fuera de servicio.
Lo invitamos a que se comunique a nuestras líneas de atención del usuario xxxxxxxx o se acerque a la oficina más cercana para efectos de recepcionar su PQR. Agradecemos su comprensión”.
- Mensaje de contingencia cuando la consulta del CUN se realiza a través de oficinas virtuales de atención al usuario:
*Apreciado usuario: El sistema de consulta del CUN se encuentra temporalmente fuera de servicio.
Lo invitamos a que se comunique a nuestras líneas de atención del usuario xxxxxxxx o se acerque a la oficina más cercana. Agradecemos su comprensión”.
En todo caso, los mismos deberán ser totalmente claros para el usuario.
• Procedimiento a seguir cuando el sistema de asignación de CUN y su consulta no se encuentre disponible por fallas o mantenimientos:
i) Cuando el sistema no se encuentre disponible, el proveedor de servicios de comunicaciones u operador de servicios postales deberá garantizar la recepción de las peticiones, quejas, recursos y solicitudes de indemnización que presenten los usuarios. Una vez el sistema se encuentre disponible, se procederá a asignar el CUN y a comunicarle al usuario de conformidad con las condiciones establecidas en el numeral 3.4 del capítulo tercero del título III de la Circular Única, acerca de la asignación efectuada. Para los casos que sean procesados por esta excepción, la fecha que se registrará y asignará a cada petición, queja, recurso o solicitud de indemnización, corresponderá a la del momento en que el usuario presentó su solicitud. En este sentido, se debe registrar en la base de datos la fecha de presentación de la PQR o solicitud de indemnización y la fecha de asignación del CUN. Los términos de atención de la PQR no se extenderán con ocasión de la falla o no disponibilidad del sistema de asignación. La fecha que se tomará para efectos legales de dar atención a la misma, es la fecha de presentación por parte del usuario.
En todo caso la fecha en que se realice el reproceso no afectará los términos legales en que deba darse la respuesta al usuario.
De igual manera, cuando el sistema que permita realizar la consulta de CUN dispuesta en el sitio web de cada operador, no se encuentre disponible ya sea por mantenimiento programado o por fallas en la infraestructura tecnológica por parte del operador o proveedor, se deberá proceder así:
Cuando el sistema de consulta del CUN no se encuentre disponible, el proveedor de servicios de comunicaciones u operador de servicios postales deberá informar dicha situación dentro de las veinticuatro (24) horas siguientes a la falla del sistema a la dirección de protección a usuarios de servicios de comunicaciones de la Superintendencia de Industria y Comercio, indicando además la causa de la falla, la duración de la misma y la hora en que fue restablecido el sistema de consulta.
ii) Para el caso en el cual, la interrupción obedezca a mantenimientos programados, deberá informarse con al menos dos (2) días de antelación a la fecha prevista de realización, mediante aviso publicado en un sitio visible en las instalaciones del proveedor de servicios de comunicaciones u operador de servicios postales. En todo caso, se informará expresamente en el aviso, que la situación no afecta el derecho que les asiste a los usuarios de radicar sus peticiones, quejas, recursos y solicitudes de indemnización.
• Para el caso en el cual, el usuario no recuerde el CUN asignado, el proveedor de servicios de comunicaciones u operador de servicios postales, deberá proporcionar el mecanismo a través del cual pueda consultar el estado del trámite de su PQR ingresando el tipo y número de identificación del quejoso.
6. Especificaciones técnicas de los mecanismos de reporte de apelaciones.
En desarrollo de las políticas de eficiencia administrativa y en especial, de la reciente directiva presidencial relacionada con “cero papel”, la superintendencia ofrece mecanismos de reporte de apelaciones por medio virtuales, como alternativa a la radicación del mismo de manera física en la entidad.
Para los efectos del presente anexo son mecanismos alternos de reporte de apelaciones ante la Superintendencia de Industria y Comercio, los que se describen a continuación:
a) Formulario web.
b) Web service.
6.1. Formulario web.
El formulario web es un mecanismo a través del cual los proveedores/operadores podrán remitir los recursos de apelación a la Superintendencia de Industria y Comercio. Dicho mecanismo podrá ser accedido utilizando los datos de registro (usuario y contraseña) que fueron remitidos en las comunicaciones de notificación de CUN a cada uno de los proveedores de comunicaciones y operadores de servicios postales. Esta opción estará disponible en la página web de la Superintendencia de Industria y Comercio a partir del 1º de mayo de 2013.
Para el caso en el cual no se cuente con dicha información, se deberá remitir una comunicación formal por escrito a la dirección de protección a usuarios de servicios de comunicaciones de la Superintendencia de Industria y Comercio, la cual deberá estar suscrita por el representante legal.
Las especificaciones técnicas del formulario web están basadas en las reglas de validación que se desarrollaron en cada campo del formulario, las cuales hacen referencia a la interacción del operador o prestador de servicio, frente al formulario.
A continuación se muestra el diseño del formulario web para realizar el proceso de reporte de apelaciones por parte de los operadores de comunicaciones y servicios postales.
El primer paso, es el acceso al sistema, en el cual es necesario digitar los datos que fueron remitidos con anterioridad por la SIC. Esta sección adicionalmente tiene la funcionalidad de realizar el proceso de recuperación de contraseña la cual será remitida a la cuenta de correo electrónico asociada a cada proveedor de comunicaciones y operador de servicios postales que haya registrado ante la SIC.
6.1.1. Acceso al sistema formulario web.
Figura 1. Acceso al sistema formulario web
La siguiente imagen corresponde al formulario web desarrollado para que los proveedores de comunicaciones y operadores de servicios postales realicen el proceso de reporte de apelaciones ante la SIC.
Este formulario está compuesto por dos pasos, los cuales deben ser diligenciados en su totalidad, la confirmación de la remisión de la información es presentada en una ventana emergente, para lo cual es necesario que en cada computador se habiliten las ventanas emergentes con el fin de poder visualizar la confirmación que constituyen constancia de radicación ante la Superintendencia de Industria y Comercio.
6.1.2. Formulario de reporte.
Figura 2. Formulario de reporte.
Figura 3. Formulario de reporte de expediente de apelaciones
A continuación se especifican las reglas implementadas en el formulario.
6.1.3. Validaciones de los campos del reporte de apelaciones.
Tabla 2. Validaciones de los campos de reporte de apelaciones.
Nombre del campo Descripción del campo Tipo Longitud Validaciones Observaciones
IO Corresponde a los 4 primeros dígitos que identifican al operador. Entero 4 • Campo de texto.
•Campo requerido.
• Campo protegido contra escritura. • El campo se auto diligencia con los datos del operador en sesión.
AA Corresponde a los 2 últimos dígitos del año en el que se registra en el sistema de PQR del operador, la primera radicación de la solicitud. Entero 2 • Campo de texto.
• Campo requerido.
• El campo debe permitir digitar solo números. • La longitud debe ser de 2 caracteres el máximo de escritura.
• Debe de auto diligenciar y sugerir el año actual de la apelación que se desea ingresar.
• No debe de permitir un año mayor al actual
CR Es un número secuencial ascendente de diez dígitos dado por el sistema de PQR de cada operador a cada asunto nuevo originado en el año en que se radicó la primera comunicación. Se inicia en 0000000001 el primer día hábil de cada año. Entero 10 • Campo de texto.
• El campo debe permitir digitar solo números. • La longitud debe ser máximo de 10 dígitos
• Al momento de digitar el número correspondiente a este campo se debe generar una alertar al usuario o consumidor en el caso de que existe una apelación con ese número CUN (IO-AA-CR) ya registrado en la SIC, no tiene que dejarlo pasar al siguiente paso del formulario.
Fecha de asignación Es la fecha de asignación del CUN, esta fecha nace en el momento que nace la PQR. DateTi me • Campo requerido • La fecha debe ser la misma fecha de creación del CUN con horas, minutos y segundo que genero el sistema.
Tipo de documento Corresponde tipo de documento asociado al usuario que presentó la PQR. String 2 • Lista de selección única.
• Campo requerido. • Las opciones que debe contener son las siguientes:
• NIT => NI
• Cédula de ciudadanía => CC
• Cédula de extranjería => CE
• Al momento de seleccionar cualquiera de las diferentes opciones se debe habilitar el campo número de documento para escritura, de lo contrario todo el campo debe de permanecer de solo lectura.
Número de documento Corresponde al número de documento asociado al usuario que presentó la PQR. Entero 11 • Campo de texto.
• Campo numérico
• Campo requerido. • Una vez que se digite la información de este campo, buscará si existe información en la base de datos de la SIC.
• Si encuentra datos, se deben mostrar la información en los respectivos campos “nombre, dirección, teléfono, email, etc.” los cuales quedarán protegidos contra escritura, no obstante, se activará un botón que permitirá al operador tener un formulario alterno que le permitirá actualizar datos del ciudadano como dirección, teléfono, email.
• En caso de no encontrar información, se debe habilitar los campos para su respectivo registro.
Primer nombre Corresponde al primer nombre asociado al usuario que presentó la PQR. String 20 • Campo de texto
• Campo requerido
• Campo alfabético • No se debe permitir escribir espacios al inicio del campo ni al final
Segundo nombre Corresponde al segundo nombre asociado al usuario que presentó la PQR. String 20 • Campo de texto
Primer apellido Corresponde al primer apellido asociado al usuario que presentó la PQR. String 20 • Campo de texto
Segundo apellido Corresponde al segundo apellido asociado al usuario que presentó la PQR. String 20 • Campo de texto • Campo requerido. • Campo alfabético • No se debe permitir escribir espacios al inicio del campo ni al final
Dirección Corresponde a la dirección física de notificación asociado al usuario que presentó la PQR. String 60 • Campo de texto
Teléfono fijo Corresponde al número de teléfono fijo asociado al usuario que presentó la PQR. Entero 12 • Campo de texto
• Campo numérico • No se debe permitir escribir espacios al inicio del campo ni al final
Teléfono celular Corresponde al número telefónico celular asociado al usuario que presentó la PQR. Entero 10 • Campo de texto
Fax Corresponde al número de fax asociado al usuario que presentó la PQR. Entero 10 • Campo de texto
País Corresponde al país asociado al usuario que presentó la PQR. String 2 • Campo lista de selección única
• Campo requerido. • Este campo debe de estar prediligenciado en la opción Colombia.
Departamento Corresponde al departamento asociado al usuario que presentó la PQR. Entero 10 • Campo lista de selección única
• Campo deshabilitado • Este campo traerá la lista de departamentos pertenecientes a cada país
Ciudad Corresponde a la ciudad asociado al usuario que presentó la PQR. Entero 10 • Campo lista de selección única
• Campo deshabilitado • Este campo traerá la lista de ciudades pertenecientes a la llave país y departamento.
Correo electrónico Corresponde a la dirección de correo electrónico asociado al usuario que presentó la PQR. String 40 • Campo texto
• Campo de escritura de correo electrónico
• Campo alfanumérico. • Este campo no debe escribir caracteres especiales, solo el carácter del @ debe estar permitido
• El campo permitirá cuentas de correo electrónico
Trámite Corresponde al tipo de servicio que hace referencia a la PQR (telefonía móvil, Internet/otros servicios no domiciliarios, telefonía fija) Entero 10 • Campo lista de selección única
• Campo requerido. • Es campo obligatorio
Tipo de PQR y solicitud de indemnización Corresponde al tipo de queja relacionada para los servicios del CUN y asociada a cada PQR o solicitud de indemnización. Entero 10 • Campo lista de selección única
• Campo requerido. La tipología que debe tenerse en cuenta es la detallada en la tabla 14 del presente anexo.
Descripción de la queja Descripción de la queja asociada a la PQR. String 500 • Campo de texto
• Campo mínimo de 20 caracteres. • Es campo obligatorio
Adjunto Son cada uno de los archivos que contiene el expediente de apelaciones. Archivo • Campo requerido. • Archivos que contiene que conforma el expediente de apelaciones en forma digital, este expediente es cargado por web uno a uno para complementar el trámite
• Es campo obligatorio
6.2. Web service.
6.2.1. Diagrama de interacción entre operadores/proveedores y SIC.
La integración por medio de servicios entre sistemas de información requiere la definición del modelo de datos o estructura de datos a ser usada como paquete de transmisión tanto desde la SIC como del operador o proveedor, para tal efecto, se ha definido un único esquema de transmisión de tal manera que la integración de servicios sea transparente.
Figura 4. Diagrama de interacción.
De acuerdo al diagrama anterior se evidencia que las partes, tanto el operador como la SIC en la integración, realizan su función por medio de la exposición de Servicios WEB SOAP XML lo cual implica una organización de interoperabilidad que requiere tanto contratos para los servicios como estructuras de información para el intercambio de los mensajes.
Los servicios y métodos serán tratados más adelante en la presente sección; sin embargo, es importante definir de manera técnica cómo se va a realizar el intercambio de la información y cómo se van a garantizar los principios de seguridad de la información.
En la radicación de una apelación se debe tener en cuenta los siguientes aspectos dentro del proceso:
• Se asegurará el canal de transferencia de los archivos adjuntos al expediente de apelación bajo el protocolo SSH, teniendo en cuenta el certificado digital (generado por software openSSL), el copiado con seguridad siguiendo el protocolo SCP, response y request por XML y, por último, un SSH de logout para lograr garantizar el cierre y finalización de dicho servicio.
• Se utilizará el framework WSO2 message broker para el manejo de colas, el cual permitirá realizar el encolado de los archivos en un repositorio temporal que puede ser descargado según la disponibilidad del canal y el tráfico en horarios no pico para garantizar el flujo correcto y atención a la ciudadanía de manera permanente, sin que se interrumpa o sature el canal.
• El esquema detallado de la transmisión será el siguiente: La transmisión de archivos recoge la tarea. Se inicia sesión SSH (con certificado) en el proveedor de comunicaciones de telefonía móvil/telefonía fija/Internet u operadores de servicios postales, según sea el caso, se copia los archivos adjuntos vía SCP. Finalmente, la Superintendencia de Industria y Comercio - SIC recibe el XML y genera el trabajo en la cola de mensajes (publish).
• Se implementarán ciertos estados a tener en cuenta para el manejo y gestión de la conexión de transferencia de archivos de conformidad con lo que se acuerde en la historia de usuario. Se generarán alertas por correo electrónico cuando se presente alguna situación inesperada.
• Al momento de transferir los archivos se invoca el servicio y envía el XML del expediente.
Se recomienda utilizar para mayor seguridad de la información y transferencia de archivos, lo siguiente:
• El proveedor de comunicaciones (telefonía móvil/telefonía fija/Internet) u operador de servicios postales podrá contar con un software tipo port knocking de tal manera que se garantice la transferencia de los archivos adjuntos a los expedientes de las apelaciones que se radican ante la Superintendencia de Industria y Comercio - SIC y que exista una demanda de peticiones por puertos, sin que se exponga la información para posibles accesos malintencionados.
6.2.2. Estructura de datos de transmisión.
El siguiente esquema define la estructura a ser implementada por el operador o proveedor para el reporte de apelaciones a la SIC, así como la consulta que realizan los usuarios del CUN.
El resultado de la operación de los servicios estará conformado por una cadena de texto que contenga un documento XML en el cual se evidencie el uso del esquema, esto permitirá hacer la correspondiente traducción con los objetos de negocio del sistema.
La estructura de datos se ve reflejada por medio de esquemas XSD(4), los cuales permiten definir el orden, forma y conformación de los datos a ser transmitidos a través de un web service. Se debe aclarar, que para efectos de una integración en la que los participantes no cuentan con una tecnología homogénea se deben conformar servicios web basados en SOAP cuyo resultado sea una cadena de texto, esto con el fin de facilitar la integración. Sin embargo, la cadena de texto de retorno debe cumplir con un documento XML válido que cumpla con el esquema que se define a continuación.
En el siguiente esquema se exponen de igual manera que los elementos XML los conforman. Ver el cuadro a continuación.
Figura 5. Estructura de datos para el intercambio de información del CUN.
6.2.3. Ejemplo de contenido de transmisión.
El siguiente texto muestra un caso en el que se evidencia un documento XML que cuenta con la estructura establecida en la sección anterior. El objetivo es poder ver cómo estaría conformada la cadena de texto retornada por los servicios tanto del operador/proveedor como de la SIC.
6.2.3.1. Ejemplo de contenido de trasmisión de retorno de la consulta operador/proveedor.
Figura 6. Ejemplo de contenido de trasmisión de retorno de la consulta operador/proveedor.
6.2.3.2. Ejemplo de contenido de trasmisión de retorno de la consulta de la SIC.
Figura 7. Ejemplo de contenido de trasmisión de retorno de la consulta de la SIC
6.2.3.3. Ejemplo de contenido de trasmisión de retorno del reporte de apelaciones de la SIC.
Figura 8. Ejemplo de contenido de trasmisión de retorno del reporte de apelaciones de la SI.
6.2.4. Tipología de mensajes y errores.
Con el fin de que el sistema pueda cumplir con los requerimientos no funcionales de seguridad, registro y bitácora de sucesos para diagnóstico y calidad, se hace necesario implementar un manejo estructurado de errores que sea informado, registrable y permita a las partes integradas (SIC, operador/proveedor, usuario) poder evidenciar los datos ante las posibles incidencias.
Teniendo en cuenta esto, se ha dispuesto de un espacio dentro del objeto de intercambio de información entre el operador y la SIC.
El tipo de dato “MensajeServicio” representa un conjunto de datos de control de flujo de información que permitirá identificar si existió algún problema con la ejecución de los métodos, si hubo algún error y, adicionalmente, establecer una marca de tiempo para identificar la historia de los datos transmitidos.
Los detalles de este dato son los siguientes:
• CodigoError: Código de identificación del error del operador o de la SIC según sea el caso.
• Descripción: Descripción textual del error.
• Opcional: Cadena con datos adicionales que describan el error.
• TimeStamp: Marca de tiempo en formato de fecha larga que incluye la hora, minutos y segundos. La tipología de código de errores es la siguiente:
Tabla 3. Tipología de código errores.
Error/mensaje Capa Número
1 Error 1 Acceso a Datos 0 -9
2 Aplicación 0 -9
2 Mensaje 1 OK 0
2 Diagnóstico 0 -9
Las anteriores tipologías incluyen manejo de errores y mensajes, que permitirán que la parte que recibe una respuesta pueda tener la información necesaria para tomar medidas pertinentes en caso de un error.
A continuación se muestra el listado del uso de la codificación de errores:
Tabla 4. Listado del uso de la codificación de errores.
110 Error a nivel de base de datos, la base de datos no está disponible.
111 No se puede realizar actualización de los datos en la base de datos, es de solo lectura.
112 Se esperaba una sentencia de actualización de datos.
113 Error general, no es posible la conexión con la base de datos.
114 La tabla “tbl” está bloqueada por el usuario “user”.
115 Error en los parámetros enviados, no coincide con el esquema de la tabla de la base de datos.
116 El campo de búsqueda no existe en la base de datos.
117 Error general de integridad referencial.
120 Error de procesamiento en la capa de acceso a datos.
121 Error de procesamiento de datos en la lógica de negocios
122 Error en la transformación de datos en la lógica de negocios.
123 Error general de componentes lógicos del sistema.
124 Error no se cuenta con la información suficiente para generar una respuesta.
125 Error de referencia al llamado de la capa de servicios.
126 Error de traducción de objetos en la capa de servicios.
127 Error en el envío de la respuesta a nivel de servicios.
210 OK - Éxito.
220 El sistema cuenta con información desactualizada.
221 Los datos de la respuesta pueden estar corruptos.
222 Los datos de la respuesta no están completos.
223 El proveedor no cuenta con la información suficiente para enviar una respuesta.
224 El servicio estará disponible hasta la fecha —fecha: hora—.
225 El tiempo de espera es excesivo, se sugiere revisar el comportamiento de las métricas del sistema por parte del administrador.
226 Se sugiere realizar la solicitud más tarde.
227 El sistema se encuentra en línea para recibir solicitudes “Mensaje de eco”
Todo objeto de intercambio debe estar acompañado por el elemento “MensajeServicio” como se ha visto en el esquema de transmisión. Un ejemplo de este sería:
Figura 9. Ejemplo esquema de transmisión.
Nótese que los dos últimos dígitos del mensaje de error se han dejado abiertos para manejo interno de los sistemas, esto, debido a que no se conocen los detalles internos de implementación de las partes y las tecnologías usadas en los desarrollos particulares para la construcción de los componentes de servicio e integración.
6.3. Contratos de servicio.
Los contratos de servicio definen la interfaz de comunicación entre servicios web, por lo tanto, describen las firmas de los métodos que se deben ejecutar para llevar a cabo las respuestas a las solicitudes o peticiones de servicios que se envían de un sistema a otro.
Para la integración de servicios entre la SIC y los operadores/proveedores se han definido dos servicios web que son implementados respectivamente.
La siguiente tabla describe los contratos de servicio, detallando los métodos, tipos de dato de retorno y los parámetros de entrada a ser implementados para lograr el objetivo de integración.
6.3.1. Métodos públicos web services operador/proveedor.
Tabla 5. Métodos públicos web services operador/proveedor.
Nombre Parámetros de entrada Parámetros de salida
ConsultaCUN • CUN (cadena de caracteres)
- IO (Identificador del operador)
- AA (Año actual del CR)
- CR (Consecutivo de radicación)
• Tipo de identificación (tipo identificación)
• Número de identificación (cadena de caracteres) • Cadena de caracteres XML-String (ver esquema).
6.3.2. Métodos públicos web services SIC.
Tabla 6. Métodos públicos web services SIC.
• Número de Identificación (cadena de caracteres) Cadena de caracteres XML-String (ver esquema).
RadicarCUNParaApelacion • Cadena de caracteres XML-String Cadena de caracteres XML-String (ver esquema).
A continuación se presentan un ejemplo de los archivos WSDL, en el que se expone el contrato de servicio base tanto para el servicio de la SIC como del operador/proveedor:
6.3.3. Servicio SIC.
Corresponde al contrato de servicios que expone la SIC para que el operador/proveedor lo consuma. Incluye el WSDL correspondiente a los dos métodos expuestos por la SIC.
Figura 10. Servicio SIC.
6.3.4. Servicio operador/proveedor.
Corresponde al servicio que debe exponer el operador/proveedor para que la SIC lo consuma. Incluye el método para la consulta del CUN.
Figura 11. Servicio operador/proveedor.
6.4. Aspectos a tener en cuenta para la transmisión de archivos en el envío de expedientes de apelación por medios electrónicos.
El operador/proveedor deberá comprimir todos los soportes asociados a la apelación en un archivo comprimido en formato ZIP, la ubicación del archivo serán potestad de este, pero deberán ser accesibles temporalmente solo por la Superintendencia de Industria y Comercio mediante la URL publicada por parte del operador/proveedor dentro del elemento archivoAdjunto del objeto único de transporte.
La URL definida en el contrato deberá permitir a la Superintendencia de Industria y Comercio copiar el archivo comprimido .ZIP siempre y cuando se den las garantías de conectividad y seguridad definidas en este mismo documento.
Todo archivo de tipo texto debe estar en formato PDF y los demás archivos que hacen parte de los expedientes de apelaciones serán en formato que no requieran software especializado para abrirse o reproducirse.
El orden en el cual se realizará la radicación de apelaciones incluida la transferencia de archivos deberá ser la siguiente:
1. El operador/proveedor invoca el servicio WSConsultaSIC dispuesto por la Superintendencia de Industria y Comercio, SIC.
2. El operador/proveedor ejecuta la operación radicarCUNParaApelacion establecido en el contrato de servicio (Ver esquema XML del servicio SIC).
3. La SIC recibirá el mensaje XML producto de la ejecución de la operación radicarCUNParaApelacion, que contendrá los datos de la radicación de apelaciones enviada por el operador/proveedor.
4. La SIC realiza la petición al puerto dispuesto por el operador/proveedor para iniciar la copia del archivo comprimido .ZIP.
5. Una vez el puerto este habilitado por parte del operador/proveedor, la SIC inicia la tarea de descarga del archivo comprimido .ZIP mediante sesión SSH (file transfer protocol), autenticada a través de certificados digitales con el operador/proveedor por el puerto habilitado y dispuesto por este último.
6. La SIC realiza la copia del archivo comprimido .ZIP a través del protocolo SCP (simple communication protocol) una vez el proceso de autenticación ha sido satisfactorio.
7. Una vez finalizada la copia del archivo comprimido .ZIP, Los puertos de conexión habilitados por las partes se cierran, y la sesión SSH termina.
8. La SIC iniciará el proceso de validación de la integridad del archivo cuyas excepciones generadas en caso de invalidarse el proceso se citan a continuación:
- Error de validación por archivo corrupto: si el archivo se encuentra corrupto (tamaño inválido), la operación retornará el mensaje de error correspondiente desde el elemento MensajeServicio dispuesto en el contrato de servicio WSDL.
- Error de validación por contenido corrupto: si el contenido del archivo se encuentra corrupto (tamaño inválido, no contiene archivos), la operación retornará el mensaje de error correspondiente desde el elemento MensajeServicio dispuesto en el contrato de servicio WSDL.
- Error de validación por soporte PDF inexistente: si el contenido del archivo no contiene al menos un archivo en formato PDF, la operación retornará el mensaje de error correspondiente desde el elemento MensajeServicio dispuesto en el contrato de servicio WSDL.
9. Si el proceso de validación ha sido satisfactorio, la SIC inicia la etapa de radicación de la apelación a partir de los datos enviados por el proveedor de comunicaciones u operador de servicios postales.
El proveedor de comunicaciones y operador de servicios postales deberá tener en cuenta el tiempo que tomará en llevarse a cabo la transferencia del archivo comprimido ZIP al momento de radicar la apelación, debido a que la fecha y hora de la radicación de la apelación será la generada por el sistema CUN una vez haya finalizado la copia del archivo y las operaciones a que haya lugar.
10. Finalizada la radicación de la apelación, el método radicarCUNParaApelacion retorna como respuesta el número de la radicación por medio de correo electrónico la constancia de radicación a las diferentes partes (usuario, operador/proveedor y SIC).
7. Especificaciones técnicas consulta de CUN.
Los proveedores de servicios de comunicaciones y operadores de servicios postales deben establecer el siguiente mecanismo que permita la consulta del CUN, la cual debe estar accesible desde su página web.
En todo caso, cuando el usuario realice una consulta sobre el estado de su PQR o solicitud de indemnización a través de la página web del proveedor de servicios de comunicaciones u operador de servicios postales o de la página web de la SIC (según aplique), podrá obtener la siguiente información presentada en una grilla en los siguientes escenarios:
Caso 1. La PQR o solicitud de indemnización se encuentra en trámite o resuelta ante el operador/proveedor y el usuario ingresa a la página web de este.
Caso 2. La PQR o solicitud de indemnización se encuentra en trámite o resuelta ante el operador y el usuario ingresa a la página web de la SIC.
Caso 3. La apelación se encuentra en trámite o resuelta ante la SIC y el usuario ingresa a la página web del operador.
Caso 4. La apelación se encuentra en trámite o resuelta ante la SIC y el usuario ingresa a la página web de la SIC.
7.1.1. Parámetros de invocación caso 1. La PQR o solicitud de indemnización se encuentra en trámite o resuelta ante el operador/proveedor y el usuario ingresa a la página web de este.
El operador o proveedor deberán implementar una consulta en su página web, la cual deberá ser de fácil acceso, donde el usuario tenga la opción de consultar su trámite con los siguientes parámetros:
• CUN asignado.
• Tipo de identificación.
La información que se suministre al usuario debe contener como mínimo los siguientes parámetros:
Tabla 7. Parámetros de invocación caso 1.
Nombre del quejoso Tipo de identificación Número de identificación Código único numérico (CUN) Fecha asignación Tipo de queja Estado del trámite Fecha de respuesta
• Nombre del quejoso: Debe visualizarse los nombres y apellidos completos del usuario.
• Código único numérico (CUN): Es el código único que identifica el trámite ante el operador/proveedor y se debe mostrar al usuario con la máscara establecida en la Circular 29 de la SIC, cuya estructura está contenida en este documento en el numeral 5º.
• Fecha de asignación: Es la fecha cuando se le asignó el CUN al usuario, esta fecha debe ser de tipo datetime (2012-10-28 09:03:55).
• Tipo de queja: Es la tipología de petición, queja, recurso o solicitud de indemnización a la cual debe asignársele un código único numérico de acuerdo a lo establecido en la tabla 14 del presente anexo.
• Estado del trámite: Es el estado que describe en qué etapa del proceso está el trámite de la PQR o solicitud de indemnización ante el operador/proveedor, estos estados son los que están previstos en el capítulo III título III de la Circular Única de esta entidad y en la Resolución 3066 de la CRC artículo 52.
• Fecha de respuesta: Esta fecha es de tipo date (2012-10-28) que informa al usuario la fecha que darán respuesta a su PQR o solicitud de indemnización.
7.1.2. Parámetros de invocación caso 2. La PQR o solicitud de indemnización se encuentra en trámite o resuelta ante el operador/proveedor y el usuario ingresa a la página web de la SIC.
La SIC implementará un esquema para la obtención de la información del operador/proveedor, la cual se desplegará en la página web de la SIC.
Los parámetros que serán remitidos al operador o proveedor son los definidos en el numeral 6.3.2 métodos públicos web services operador - consultaCUN - Parámetros de entrada.
Los parámetros de retorno que debe devolver el operador o proveedor a la SIC son los definidos en el numeral 6.3.2 métodos públicos web services operador - consultaCUN - Parámetros de salida.
La información que se desplegará será la siguiente:
Tabla 8. Parámetros de invocación caso 2.
7.1.3. Parámetros de invocación caso 3. La apelación se encuentra en trámite o resuelta ante la SIC y el usuario ingresa a la página web del operador/proveedor.
• Datos mínimos del usuario (natural o jurídico según aplique).
• Código único numérico (CUN).
• Estado actual de trámite de su PQR.
• Tipo de queja.
• Link (ver detalle): Este link será suministrado por la SIC para que el usuario cuando realice el evento de click sobre el enlace puede dirigirse a la página de la SIC para ver la trazabilidad de su trámite ante la entidad.
“Resultado de información originada de la SIC”.
Tabla 9. Parámetros de invocación caso 3.
Los parámetros de entrada que debe interactuar cada servicio se encuentran consignados en el literal 6.3 contratos de servicio del presente documento.
7.1.4. Caso 4. La apelación se encuentra en trámite o resuelta ante la SIC y el usuario ingresa a la página web de la SIC.
El usuario podrá realizar la consulta del estado de su trámite, ingresando para ello el CUN o tipo y número de identificación.
La presentación de la información por parte de la SIC, será de la siguiente manera:
Tabla 10. Parámetros de invocación caso 4.
Nombre del Quejoso Tipo de identificación Número de identificación Código único numérico (CUN) Fecha asignación Estado del trámite Tipo de queja Ver detalle del trámite
8. Modelo integración SIC - operador/proveedor.
Para llevar a cabo la implementación de la consulta interactiva entre la superintendencia y los operadores/proveedores, así como la transmisión de expedientes apelación por medios electrónicos, es necesario tener en cuenta los aspectos que se describen a continuación:
8.1. Descripción modelo de integración.
El modelo de integración CUN describe todas las actividades relacionadas en el flujo de información entre los operadores/proveedores, usuarios y la SIC, haciendo la abstracción de los procesos de front-end de tal manera que se pueda detallar la estructura de envío y recepción de mensajes entre las partes, sus adaptaciones y la naturaleza de servicios que esté alineado a una arquitectura en la misma naturaleza.
El siguiente diagrama establece un modelo propuesto a nivel de negocio para la integración entre operadores/proveedores y la SIC, el cual establece un orden de responsabilidades entre las partes que permite la generación de una arquitectura de integración electrónica factible, confiable y documentada.
Figura 12. Modelo de integración CUN.
8.2. Descripción del modelo.
En la figura anterior se plasma un bosquejo de la relación de interoperabilidad entre el operador/proveedor y la SIC en términos de operatividad de negocio cada uno en su pool respectivamente. Nótese que la comunicación entre las partes es a través de mensajes.
El uso de mensajes bajo una arquitectura basada en servicios establece de manera asíncrona la comunicación entre las partes.
El modelo de integración que adopte el proveedor de servicios de comunicaciones y operador de servicios postales debe contemplar como mínimo lo siguiente:
• Enviar solicitud de radicación: Es el conjunto de tareas que se procesan de manera continua, con el envío de un mensaje por medio electrónico que contenga la información de una solicitud que se debe radicar para apelación.
• Procesar solicitudes de soportes: Es el conjunto de tareas que procesan la información de forma iterativa para agrupar y enviar los archivos electrónicos de soporte de una apelación requerida por la SIC.
• Solicitar información CUN: Es una tarea por demanda en la cual el operador/proveedor solicita un mensaje de la SIC que contenga toda la información y el estado del CUN.
• Resolver solicitudes de información PQR: Contempla el conjunto de tareas que se requieren para poder enviar un mensaje con la información actualizada de una PQR o solicitud de indemnización que solicite la SIC por medio de un mensaje.
El pool del proceso interno de la SIC lleva a cabo actividades asíncronas y dependientes de eventos de recepción de mensajes, el proceso nunca termina a menos que interiormente se presente un evento de terminación y se especifica a continuación:
• Realizar validaciones de radicación: Es una tarea que inicia con la llegada previa de un mensaje de operador con la información de solicitud de radicación de una apelación, esta tarea encapsula toda labor y esfuerzo que se realiza en la SIC para hacer la validación de los datos en la que intervienen personas, sistemas y datos. Esta tarea puede tener como resultado un error de procesamiento o negocio el cual es notificado al operador, en caso contrario da inicio a la actividad de recopilar los archivos de los documentos de soporte del caso, para esto, la SIC envía un mensaje de solicitud de los archivos al operador.
• Radicar solicitud de apelación: Tarea que inicia con la llegada de los archivos de soporte de una de apelación, este se llevan a cabo todas las actividades en las que intervienen personas y sistemas durante la radicación, esto incluye actualizar la información, almacenarla, registrarla y hacer seguimiento. El proceso, termina con el envío de un mensaje al operador en el cual se detalla el éxito o fracaso de la operación.
• Resolver solicitudes de información CUN apelación: Tarea iterativa que resuelve todas solicitudes de consulta de información de apelaciones ya sean internas o externas a la SIC al repositorio de información del CUN de la SIC.
• Solicitar información CUN/PQR: Es una tarea que se ejecuta cuando se una consulta desde el portal de la SIC y se requiere obtener la información de un CUN/PQR que está siendo procesado por un operador/proveedor y que aún no está definido como en proceso de apelación. Esta actividad al igual que la anterior es independiente del proceso de radicación, y para este, solo se involucran sistemas de información.
En la sección “Especificaciones técnicas de los mecanismos de reporte de apelaciones” del presente documento se encuentra la información técnica que se debe tener en cuenta para lograr la realización del proceso anteriormente descrito, se tendrá por lo tanto un lenguaje más técnico y menos funcional que el usado en esta sección.
8.3. Transferencia de archivos - Port knocking.
El concepto de port knocking se refiere a una forma de comunicación de equipo a equipo en el cual la información fluye a través de puertos cerrados. Existen diferentes variantes para la implementación de port knocking, la información puede transmitirse realizando una secuencia de puertos o generando paquetes específicos que permitan el flujo de la información.
Port knocking se refiere a un método de comunicación entre dos equipos (arbitrariamente llamados cliente y servidor) en los cuales la información es codificada y posiblemente cifrada, en una secuencia de números de puerto. Esta secuencia es llamada knock. Inicialmente, en el servidor no se pueden observar puertos abiertos hacia el público y siempre se está realizando un monitoreo de todos los intentos de conexión. El cliente inicia intentos de conexión hacia el servidor enviando paquetes especificados dentro de la secuencia de knock. El servidor como tal no genera una respuesta al cliente en la fase de autenticación, cuando el servidor decodifica la secuencia válida, desencadena un proceso del lado del servidor.
Este método a nivel de autenticación permite ventajas enumeradas a continuación:
1. Apertura y cierre de puertos de manera arbitraria desde cual dirección IP en espacios predeterminados de tiempo.
2. Los puertos solamente se encuentran disponibles para el cliente que genera la secuencia de port knocking.
3. Minimiza la posibilidad de ataques de repetición a nivel de autenticación.
4. Se genera una comunicación específica de secuencia que genera un alto estándar de seguridad.
Este mecanismo de autenticación puede ser usado para transferencia de información a través de puertos cerrados. El demonio de port knocking se puede implementar para responder en cualquier necesidad de autenticación a nivel de puertos.
Las versiones de implementación se encuentran disponibles dentro de diferentes lenguajes de programación en scripts ejecutables en lenguajes interpretables. Las implementaciones incluyen soluciones generadas en C, Perl, Java, Python y BASH entre otras.
Las diferentes implementaciones y su documentación oficial, pueden encontrarse en el sitio oficial del proyecto de port knocking http://www.portknocking.org/view/implementations, las implementaciones se encuentran disponibles para todos los sistemas operativos y en lenguajes interpretados.
Por medio de la implementación de port knocking, la SIC busca la protección de los servidores y servicios de los operadores/proveedores, de la misma manera que la protección de los archivos correspondientes a las PQR generadas por los usuarios.
A continuación se presentan de manera general las actividades que deben ser realizadas por parte de los operadores, con el fin de proteger la información necesaria por la SIC, referente a PQR.
Figura 13. Actividades operador/proveedor.
La implementación de la solución de port knocking debe asegurar el uso de single packet authentication (SPA) en la solución implementada por parte de los operadores, con el fin de asegurar el proceso de autenticación de parte de la Superintendencia de Industria y Comercio a los servicios destinados para la transferencia de paquetes.
El servidor SSH, será el encargado de permitir la transferencia de archivos por medio de SCP (secure copy), con el fin de asegurar la integridad de la información transmitidas, además de permitir la auditoría de los usuarios que se conectan al servicio, con el fin de que solamente la Superintendencia de Industria y Comercio pueda generar autenticación en el servicio, después de que el puerto se encuentre disponible, se ha establecido que la autenticación debe ser realizada por medio del uso de un certificado que será generado por los operadores en el servidor SSH y será transmitido a la Superintendencia de Industria y Comercio.
El operador debe asegurar que la información solicitada se encuentre disponible en las rutas predefinidas para tal fin. La información se debe encontrar contenida dentro de un archivo comprimido con el formato ZIP y para garantizar su integridad, se debe generar un hash del archivo, que también debe encontrarse en la ruta determinada. La solución definida para el demonio de port knocking es knock.
8.3.1. Instalación.
• Distribución basada Linux basada en “redhat” o “debian”.
• Instalar el knockd como: “apt-get install knockd” o “yum install knock-server” o “yum install knockd” según sea la distribución.
• Firewall iptables.
2. Instalación del servicio para el cliente y servidor:
• Knockd: Es el paquete que permite realizar este método de port knocking, el paquete knockd se debe instalar tanto en el cliente como en el servidor.
i. La descarga del paquete knockd se puede ejecutar bajo el siguiente comando:
wget li.nux.ro/download/nux/misc/el6/i386/knock-server-0.5-7.el6.nux.i686.rpm.
ii. Una vez descargado el paquete, se procede a la instalación del knockd tanto en el cliente como en el servidor, bajo el mismo comando:
yum knock-server-0.5-7.el6.nux.i686.rpm.
• Firewall iptables: Este servicio no es necesario instalarlo, ya que viene instalado por defecto para las distintas distribuciones de Linux.
• Webmin (opcional): Es una herramienta de gestión de sistemas, que se accede vía web, y permite administrar un sistema desde el mismo servidor o de forma remota. A través de esta herramienta es posible realizar la configuración del firewall del lado del servidor de port knocking de una forma más amigable, la instalación de la herramienta es opcional, sin embargo, se describe la instalación de la misma:
- Se descarga el archivo RPM desde la siguiente URL:
http://sourceforge.net/projects/webadmin/files/webmin/1.610/webmin-1.610- 1.noarch.rpm/download?use_mirror=ufpr
- Una vez que se descarga el archivo se procede a la instalación del paquete bajo el siguiente comando:
rpm -vih webmin-1.610-1.noarch.rpm
Finalizada la instalación del paquete webmin, es posible acceder a la herramienta a través de la URL https://IP:10000 bajo las siguientes credenciales: Usuario: root y password root.
El proceso de configuración del servidor de knocking, requiere en primera instancia el inicio de su servicio, para que así, el paquete cree el archivo knockd.conf, requerido para la configuración del paquete.
Se procede entonces a dar inicio al servicio de knocking desde el servidor, a través del siguiente comando:
“/etc/init.d/knockd start”.
Si se desea, es posible programar un script de autoarranque del servicio, de la siguiente manera:
“update-rc.d -f knockd defaults”.
Una vez se instala exitosamente el paquete knockd, procedemos a editar el archivo de configuración de knockd.conf ubicado en /etc/knockd.conf. El contenido del archivo se encuentra de la siguiente forma:
A continuación se explican los parámetros de relevancia para la configuración de knockd que se deben ser tenidos en cuenta:
• sequence: Este parámetro define la secuencia de puertos que debe realizar el cliente knocking para que así se ejecute lo definido en el parámetro command. Es decir, si la secuencia de puertos realizada por el cliente knocking es 7000, 8000 9000, el servidor knocking ejecutará el comando:
/usr/sbin/iptables -A INPUT -s %IP% -p tcp --dport 22 -j ACCEPT
• command: Este parámetro contiene la instrucción que se ejecuta una vez se recibe la secuencia de golpes por parte del cliente knocking. La instrucción requerida para ocultar o ver el puerto SSH, se define de la siguiente manera:
- Adición de la regla de firewall que permite acceder al puerto del servidor desde la IP especificada, (suponiendo que el puerto de conexión a SSH sea el puerto 22): /usr/sbin/iptables -A INPUT -s %IP% -p tcp --dport 22 -j ACCEPT
- Eliminación de la anterior regla de firewall del servidor, /usr/sbin/iptables -D INPUT -s %IP% -p tcp --dport 22 -j ACCEPT
Como conclusión el archivo knockd.conf define dos reglas de golpeteo: en la primera se define la secuencia de golpes que agrega la regla de firewall que permite que una IP específica pueda acceder a través del puerto configurado.
En la segunda, se define la secuencia de golpes que elimina la regla de firewall que permite que una IP específica pueda acceder a través del puerto configurado.
Finalizada la configuración del archivo knockd.conf y almacenado los cambios, se procede a reiniciar el servicio de la siguiente manera:
- “service knockd restart”.
Posteriormente, es necesario modificar las reglas del firewall a nivel del servidor, colocando las dos siguientes reglas a través del servicio de iptables:
-A INPUT ! -i lo -j DROP
Estas reglas permiten conexiones ya establecidas y deniegan el establecimiento de nuevas.
4. Configuración del cliente:
Una vez instalado el paquete knockd, solo bastará ejecutar el golpeteo sobre el servidor pasado como parámetro de la siguiente manera:
- “knock -v ip-servidor 7000 8000 9000”.
Para comprobar el buen funcionamiento realizar pruebas de golpeteo sobre el servidor knocking configurado.
- knock -v 100.123.34.32 7000 8000 9000 >> para abrir puerto
- knock -v 100.123.34.32 9000 8000 7000 >> para cerrar puerto
5. Configuración de las reglas del firewall:
Primero se debe borrar la configuración actual del firewall con los siguientes comandos:
iptables –L >> este comando es para ver las reglas actuales del firewall
iptables –F >> este comando es para realizar flush, elimina cualquier definición existente
iptables –Z >> este comando reinicia los contadores de paquetes
iptables –X >> este comando borra las reglas definidas por el usuario
El segundo paso es definir las reglas del firewall, para eso es necesario digitar los siguientes comandos:
#permitimos acceso al apache (si lo tenemos) o algún servicio crítico
Y por último el tercer paso es guardar los cambios del firewall y reiniciarlo, con los siguientes comandos:
6. Conexión al servidor:
Para generar la conexión solamente es necesario correr en el cliente los siguientes comandos:
knock -v ip_servidor puerto1 puerto2 puerto3 >> comando para abrir puerto
knock -v ip_servidor puerto1 puerto2 puerto3 >> comando para cerrar puerto
Donde puerto1, puerto2, puerto3 son los puertos definidos en la secuencia establecida en el archivo /etc/knockd.conf con anterioridad.
El diagrama general de lo que busca la implementación de esta solución se presenta a continuación:
Figura 14. Diagrama general.
El certificado creado en el servidor del operador o proveedor debe ser un certificado RSA con una llave de 2048 bits de longitud, el cual debe ser compartido con la SIC de manera segura, generando la relación de toda la información de autenticación entregada (información específica del servidor de port knocking y certificado de autenticación del servidor SSH).
El hash para comprobar la integridad de los archivos que se quieren compartir con la Superintendencia de Industria y Comercio debe estar calculado con SHA-256.
En el caso de no ser exitoso el proceso de transferencia de archivos, es decir, no hay transferencia y/o la integridad del archivo no se pueda comprobar, el operador o proveedor será notificado vía mensaje electrónico con los detalles del evento.
9. Valores de referencia.
A continuación se describen los valores de referencia que deberán ser empleados por los proveedores de servicios de comunicaciones y operadores de servicios postales para los tipos de datos que se enuncian a continuación. Esta información al igual que la documentación de los campos señalados en el numeral anterior, se encuentran disponibles en http://lenguaje.intranet.gov.co para su consulta en el diccionario de elementos de datos del lenguaje.
Este componente, dentro del proceso de intercambio de información, es de gran importancia debido a que permite unificar el significado y la estructura de los conceptos a intercambiar, evitando que un mismo concepto tenga diferentes interpretaciones.
A continuación se indicarán los nombres de estos elementos para su búsqueda:
Tipo identificación nacional persona (Aplicación de uso: tipoIdNacionalPersona):
Tabla 11. Tipo identificación nacional persona.
Código tipo identificación nacional persona alfanumérico 2 Nombre tipo identificación nacional persona
RE Registro civil
TI Tarjeta identidad
CC Cédula ciudadanía
CE Cédula extranjería
AS Adulto sin identificar
MS Menor sin identificar
DE Documento extranjero
NI Número identificación tributaria
ND No definido
TE Tarjeta de extranjería
OD Otro documento
Tipo trámite de la Superintendencia de Industria y Comercio (Aplicación de uso: tipoTramiteSic):
Tabla 12. Tipo trámite SIC.
Código trámite Nombre trámite
228 Telefonía móvil celular
328 Otros servicios telecomunicaciones no domiciliarias
383 Telefonía fija
391 Servicios postales
Tipo queja Superintendencia de Industria y Comercio (Aplicación de uso: tipoQuejaSic):
Tabla 13. Tipo queja SIC.
Código tipo queja Nombre tipo queja
3 Cláusula de permanencia mínima
4 Terminación de contrato
5 Plan tarifario
6 Modificación del condiciones del contrato
7 Reconocimiento de subsidio
8 Diferencias entre el estrato aplicado por la autoridad territorial y el aplicado en la facturación
9 Corte, suspensión, activación, restablecimiento, reanudación, desconexión, desactivación, interrupción y bloqueo del servicio.
10 Plazos para el inicio de la prestación del servicio
11 Cesión de contrato
12 Relación contractual
13 Cobertura en la prestación del servicio
14 Portabilidad numérica
15 Apertura de bandas de equipo terminal.
16 Disponibilidad del servicio por las fallas en el equipo terminal suministrado por el proveedor
17 Disponibilidad del servicio por falla técnica
18 Disponibilidad del servicio en áreas de cubrimiento informada por el proveedor
20 Roaming internacional
21 Servicios suplementarios
22 Activación y desactivación de servicios suplementarios
23 Reposición de equipos terminales
24 Activación de líneas
25 Velocidad o intermitencia del servicio de acceso a Internet
26 Controles de consumo
27 Publicidad y/o oferta sobre los servicios ofrecidos
28 Equipos dados en comodato
29 Cumplimiento de una orden de la SIC
30 Suspensión del servicio sin justa causa
31 Transferencia de saldos en los servicios bajo la modalidad prepago
32 Recarga de saldos en servicios prepagos
33 Vigencia de tarjetas prepago
34 Ajustes a favor de usuario
35 Principio de neutralidad en Internet
36 Utilización de datos personales con fines comerciales o publicitarios
37 Daños en las instalaciones e infraestructura relacionadas con la prestación del servicio
38 Incumplimientos en tiempos de entrega
39 Incumplimientos reexpedición
40 Pérdida del objeto postal
41 Avería del objeto postal
42 Expoliación del objeto postal
43 Deficiencias en la atención al usuario
44 Negación de petición, queja, recurso o de solicitud de indemnización
45 Publicidad y/o ofertas sobre los servicios ofrecidos y tarifas
47 Pérdida o falta de entrega del objeto postal
48 Avería del objeto postal
49 Expoliación del objeto postal
Estado PQR CUN (Aplicación de uso: estadoPQRCUN):
Tabla 14. Estado PQR CUN
Código estado PQR CUN Estado PQR CUN
1 Traslado a operador competente
2 Traslado a la SIC para resolver recurso de apelación
4 Acumulado con el CUN
5 Anulado
6 Análisis por parte del operador
7 Análisis por parte de la SIC
8 Etapa de pruebas que practica el operador
9 Etapa de pruebas que practica la SIC
• CUN: Es el código único numérico que permitirá a los usuarios de los servicios postales y de comunicaciones identificar en todo momento el trámite de su PQR o de su solicitud de indemnización.
• PQR: Petición, queja o recurso formulado por el usuario ante el proveedor de servicio de comunicaciones u operador postal, que contribuye al adecuado ejercicio de sus derechos.
• Quejoso/usuario/: Persona natural o jurídica, consumidora de servicios de comunicaciones o postales.
• SIC: Superintendencia de Industria y Comercio.
• Solicitud de indemnización: Solicitud que hace el usuario para que el operador del servicio postal le reconozca el pago de las indemnizaciones consagradas en el artículo 25 de la Ley 1369 de 2009.
• CRC: Comisión de Regulación de Comunicaciones.
• Logs: Equivalente a la palabra bitácora, es un registro oficial de eventos durante un rango de tiempo en particular, usado para registrar datos o información sobre quién, qué, cuándo, dónde y por qué.
• No repudio: Suministra la prueba de integridad y el origen de los datos en una relación infalsificable, pueden ser identificados por un tercero en cualquier momento.
• NTC-27001: Técnicas de seguridad. Sistemas de gestión de seguridad de la información (SGSI). Requisitos. Brinda un modelo para el establecimiento, implementación operación, seguimiento, revisión, mantenimiento y mejora de un (SGSI). Transfer protocol (SMTP), o protocolo simple de transferencia de correo electrónico. Protocolo de red basado en texto utilizado para el intercambio de mensajes de correo electrónico entre computadoras.
• XML signature: Es una recomendación del W3C (world wide web consortium) que define una sintaxis XML para la firma digital. Está orientada hacia la firma de documentos XML. Asegura la integridad de partes de documentos XML transportados. Representa un sistema que a través de una firma digital permite ofrecer autenticidad de los datos. Con la firma digital se confirma la identidad del emisor, la autenticidad del mensaje y su integridad, sin olvidar que los mensajes no serán repudiados.
• SHA1: (secure hash algorithm, algoritmo de hash seguro) es un sistema de funciones hash criptográficas para calcular un código resumen de un mensaje o documento electrónico de 160 bits. Este código es el que se usa para proteger los ficheros contra modificaciones no autorizadas (preservar su integridad).
• RSA-SHA1: RSA es un sistema criptográfico de clave pública para el cifrado y la autenticación. RSA se combina con la función de hash SHA1 para firmar un mensaje.
• WSU timestamp: Timestamp (estampado cronológico) es una secuencia de caracteres, que denotan la hora y fecha (o alguna de ellas) en la cual ocurrió determinado evento. Este elemento permite marcas de tiempo para aplicar en cualquier parte, incluso como un encabezado SOAP (simple object access protocol).
• TLS (transport layer security): Es un protocolo criptográfico que proporciona comunicaciones seguras por una red. Establece una conexión segura por medio de un canal cifrado entre el cliente y servidor. Así el intercambio de información se realiza en un entorno seguro y libre de ataques.
• Contrato de servicio o WSDL: WSDL (en ocasiones leído como como wisdel) son las siglas de web services description language, un formato XML que se utiliza para describir servicios web. La versión 1.0 fue la primera recomendación por parte del W3C y la versión 1.1 no alcanzó nunca tal estatus. La versión 2.0 se convirtió en la recomendación actual por parte de dicha entidad. WSDL describe la interfaz pública a los servicios web. Está basado en XML y describe la forma de comunicación, es decir, los requisitos del protocolo y los formatos de los mensajes necesarios para interactuar con los servicios listados en su catálogo. Las operaciones y mensajes que soporta se describen en abstracto y se ligan después al protocolo concreto de red y al formato del mensaje. Así, WSDL se usa a menudo en combinación con SOAP y XML schema. Un programa cliente que se conecta a un servicio web puede leer el WSDL para determinar qué funciones están disponibles en el servidor. Los tipos de datos especiales se incluyen en el archivo WSDL en forma de XML schema. El cliente puede usar SOAP para hacer la llamada a una de las funciones listadas en el WSDL. El WSDL nos permite tener una descripción de un servicio web. Especifica la interfaz abstracta a través de la cual un cliente puede acceder al servicio y los detalles de cómo se debe utilizar.
• RPU: Régimen de protección de usuarios de comunicaciones.
• RPUSP: Régimen de protección de usuarios de servicios postales.
• Administrador: Representa cualquier persona que desea administrar los parámetros configurados para la solución.
• Operador: Representa cualquier persona que desea radicar una apelación.
• SOAP: Es el tipo de servicio que se expone para la comunicación entre capas.
• GEL-XML: Establece el estándar para estructurar la información para intercambio de información con otras entidades.
• Firewall operador: Este componente de software mantiene cerrado un determinado puerto, a través del script de port knocking instalado, detecta una secuencia prestablecida que procede de una conexión externa y abre dicho puerto para que el servicio asignado al puerto sea accesible.
• Cliente port knocking: Es el componente de software que envía la secuencia de paquetes dirigidos a dicho puerto, con el fin de que el cortafuegos detecte la secuencia correcta y abra el puerto dejando accesible el servicio.
• SSH: Representa el tipo de protocolo de transferencia de archivos que se llevará a cabo con el operador cuando el servicio está accesible para realizar el intento de conexión una vez el port knocking fue exitoso.
• Plataforma operador: Es el componente externo desde donde se radican las apelaciones y/o se obtienen los archivos de soporte de la radicación.
(1) El código deberá asignarse siguiendo como estructura, el formato definido en el numeral 3.1.1 del capítulo tercero del título III de la Circular Única.
(2) La fecha y hora que registre el sistema de información de los proveedores de servicios de comunicaciones u operador de servicios postales, deberá estar sincronizada con la hora legal de Colombia.
(3)(sic).
(4) XML schema definition: tecnología que define los elementos de lenguaje y convenciones que permiten estandarizar la forma y estructura como se conforman los datos a ser transmitidos a través de la web para que sean enviados y recibidos por XML web services.

References: Resolución 
 artículo 41
 Resolución 
 artículo 26
 Resolución 
 artículo 42
 Resolución 
 Resolución 
 artículo 1
 Resolución 
 Resolución 
 artículo 52
 Resolución 
 Resolución 
 artículo 52
 artículo 25