Superintendencia de Industria y Comercio

CIRCULAR EXTERNA 6 DE 2017

(Noviembre 17)

Asunto: Modificar los capítulos primero, tercero y eliminar el capítulo cuarto del título III de la Circular Única de la Superintendencia de Industria y Comercio.

1. Objeto.

Modificar los capítulos primero, tercero y eliminar el capítulo cuarto del título III de la Circular Única de la Superintendencia de Industria y Comercio, con el fin de actualizar las instrucciones existentes en la materia, acorde a los cambios de regulación que se han realizado en el sector de las comunicaciones y a las condiciones reales del mercado.

2. Fundamento legal.

De conformidad con lo previsto en la Ley 1341 de 2009 “por la cual se definen principios y conceptos sobre la sociedad de la información y la organización de las Tecnologías de la Información y las Comunicaciones (TIC), se crea la Agencia Nacional de Espectro y se dictan otras disposiciones”, se establece la protección de los derechos de los usuarios como uno de los principios orientadores para la promoción y el desarrollo en la prestación de sus servicios, en especial, en el sector de las Tecnologías de la Información y las Comunicaciones (TIC).

Asimismo, el artículo 53 de la ley en comento señala que el régimen jurídico de protección al usuario de servicios de comunicaciones será el dispuesto en la regulación que en materia de protección al usuario expida la Comisión de Regulación de Comunicaciones (CRC) y, en el régimen general de protección al consumidor. Adicionalmente, prevé el procedimiento para la atención de las peticiones, quejas y recursos, presentados por los usuarios.

La Comisión de Regulación de Comunicaciones (CRC) expidió la Resolución 5111 de 2017 “por la cual se establece el régimen de protección de los derechos de los usuarios de servicios de comunicaciones, se modifica el capítulo 1 del título II de la Resolución CRC 5050 de 2016 y se dictan otras disposiciones”, a través de la cual modificó el régimen jurídico de protección de los derechos de los usuarios de servicios de comunicaciones.

De acuerdo con los numerales 32 y 61 del artículo 1º del Decreto 4886 de 2011, le corresponde a esta entidad velar por la observancia de las disposiciones sobre protección de los usuarios de los servicios de comunicaciones y de los servicios postales, así como impartir instrucciones en materia de protección al consumidor y fijar los criterios y procedimientos para su cabal aplicación.

En observancia de lo expuesto, es necesario actualizar el marco regulatorio contenido en los capítulos primero y tercero del título III de la circular única y eliminar el capítulo IV, en aras de adecuarlo al cambio normativo contenido en las precitadas disposiciones y en las que las modifican o adicionan.

3. Instructivo.

Modificar los capítulos primero y tercero del título III de la circular única, los cuales quedarán así:

TÍTULO III

Servicios de comunicaciones

CAPÍTULO PRIMERO

Régimen de protección de usuarios de servicios de comunicaciones

1.1. Objeto.

El contenido del presente capítulo tiene como propósito instruir las obligaciones establecidas en el régimen de protección de los derechos de los usuarios de servicios de comunicaciones expedido por la Comisión de Regulación de Comunicaciones, cuyo cumplimiento corresponde a los operadores de dichos servicios.

Las instrucciones aquí impartidas garantizan los principios orientadores del régimen de protección de los derechos de los usuarios de servicios de comunicaciones, y en todo caso protegen los derechos de los usuarios de dichos servicios, en el ofrecimiento de estos, en la celebración de los contratos, durante su ejecución y en la terminación del mismo.

1.2. Deber de información.

Los operadores, de conformidad con el régimen de protección de los derechos de los usuarios de servicios de comunicaciones, tienen la obligación de brindar a sus usuarios, a través de todos los mecanismos de atención previstos para el efecto, información clara, cierta, completa, oportuna y gratuita, que les permita tomar decisiones de consumo con pleno conocimiento de las condiciones del servicio que se ofrece o se presta.

1.2.1. Información disponible al usuario.

1.2.1.1. Oficinas físicas de atención al usuario.

En cada oficina física de atención al usuario de que trata el régimen de protección de los derechos de los usuarios de servicios de comunicaciones (en adelante RPU), los operadores deben cumplir con los siguientes requerimientos:

a) Formularios de peticiones, quejas/reclamos y recursos (PQR)

Los operadores deben tener a disposición del público, en un lugar visible del establecimiento, de fácil acceso y sin que deba mediar solicitud por parte de los usuarios para su entrega, formatos para la presentación de peticiones, quejas/reclamos y recursos, cuyo contenido debe corresponder plenamente al establecido en el Anexo 2.2 del título denominado “Anexos título II” de la Resolución CRC 5050 de 2016 (modificado por la Res. CRC 5111/2017, art. 3º).

Lo anterior, sin perjuicio de que el usuario opte por presentar su PQR de forma verbal, o sin la utilización de los formularios previamente descritos, o a través de los mecanismos electrónicos dispuestos para tales efectos por el proveedor del servicio.

El diligenciamiento completo del formulario debe ser suficiente para cumplir con los requisitos del trámite correspondiente, salvo que por la naturaleza del mismo se requieran para su perfeccionamiento, documentos adicionales tales como copias de los documentos de identificación y autorizaciones. La exigencia de documentos adicionales no puede servir para impedir injustificadamente el desarrollo del trámite.

b) Información a disposición

Para efectos de consulta inmediata y permanente por parte de los usuarios, la siguiente información, que según lo establecido por el RPU debe ser proporcionada por los operadores, debe estar disponible en cada oficina física de atención al usuario, en un número de documentos físicos impresos y/o dispositivos tecnológicos (tabletas, pc, etc.) ubicados en lugares visibles y de fácil acceso al público, que permita atender la demanda de los usuarios, de acuerdo a los niveles de tráfico de usuarios establecidos por los operadores para cada una de sus oficinas físicas de atención:

1. Devolución de equipos terminales en desuso, indicando los respectivos lugares, fechas y horarios de entrega.

2. Información relativa a la solicitud de servicios a través de SMS, incluyendo tarifa del SMS de solicitud del servicio y la tarifa del servicio; las condiciones del mismo; y el responsable de su prestación.

3. Condiciones de vigencia de las recargas.

4. Condiciones aplicables a la activación de servicios de roaming internacional, así como las tarifas que aplican para dichos servicios, en pesos colombianos con todos los impuestos incluidos, indicando la unidad de medida utilizada para el cálculo del cobro.

5. Ubicación geográfica de la totalidad de las oficinas físicas de atención con que cuenta el proveedor de servicios de comunicaciones.

6. Versiones actualizadas del formato de contrato único de prestación de servicios móviles y del formato de condiciones generales para la prestación de servicios móviles en modalidad prepago, junto con todos sus anexos.

7. Procedimiento para la presentación, recepción, atención, trámite y respuesta de peticiones, quejas/reclamos y recursos, así como mecanismos habilitados para la presentación de las PQRʼs.

c) Cierres de las oficinas físicas de atención al usuario

Cuando los operadores deban realizar cierres programados de las oficinas físicas de atención al usuario, tienen la obligación de comunicar tal situación a sus usuarios por lo menos con tres (3) días hábiles de anticipación a la fecha prevista para el cierre, en las oficinas físicas de atención al usuario, así como en la página web y red social de la que trata el RPU. En dicha comunicación deben informar a su vez, la fecha en la que se tiene prevista la apertura de la oficina física de atención.

Cuando se trate de cierres de oficinas no programados por razones de caso fortuito y/o fuerza mayor, los operadores deben comunicar tal situación a sus usuarios, en las oficinas físicas de atención al usuario, así como en la página web y red social de la que trata el RPU, en un plazo máximo de veinticuatro (24) horas contadas a partir del momento en que tuvo lugar el cierre de la oficina.

d) Accesibilidad para personas en situación de vulnerabilidad

Con la finalidad de garantizar y asegurar el ejercicio efectivo de los derechos de las personas en situación de vulnerabilidad, es decir, mujeres embarazadas, personas de la tercera edad, y personas en situación de discapacidad y, en cumplimiento de lo previsto en el numeral 1º del artículo 14 y artículo 16 de la Ley 1618 de 2013, en concordancia con el contenido de la Ley 1346 de 2009, los operadores, en sus oficinas físicas de atención, deben contar con mecanismos y espacios que permitan la atención prioritaria y adecuada a toda la población que se encuentre en dichas condiciones de vulnerabilidad, a través de la adopción de medidas de inclusión, de acciones afirmativas y de ajustes razonables, y la eliminación de toda forma de discriminación por razón de tales condiciones.

1.2.1.2. Página web

En su página web, los operadores deben cumplir con lo siguiente:

a) Información a disposición

En la página de inicio del portal web principal de cada operador, estos deben incorporar un enlace ubicado en la barra principal de navegación, consistente en un botón destacado y fácilmente identificable, que se denomine “Información importante para usuarios”. Dicho botón debe desplegar una barra de navegación con enlaces que permitan acceder a cada uno de los siguientes segmentos informativos:

1. Área de cubrimiento.

Este enlace, denominado “Mapas de cobertura”, debe llevar a una sección de mapas de contorno de cobertura, que establezcan las áreas geográficas en las que existe cubrimiento por parte del operador de servicios de comunicaciones.

Las condiciones técnicas en que se debe disponer la información, son las establecidas en el RPU.

2. Comparador de planes y tarifas.

Este enlace denominado “Comparador de planes y tarifas”, debe llevar al lugar de la página web del operador donde se pueden consultar los distintos planes y tarifas de los paquetes de servicios ofrecidas por el respectivo operador, en las condiciones previstas para el efecto por el RPU.

3. Factores de limitación de la velocidad de Internet.

Este enlace denominado “Factores de limitación de la velocidad de internet” debe llevar al listado de los principales factores que pueden limitar la velocidad efectiva de los servicios de acceso a internet fijo o móvil que puede experimentar el usuario, diferenciando aquellos sobre los que tiene control el operador y los que son ajenos al mismo.

4. Indicadores de calidad del servicio de Internet.

Este enlace denominado “Indicadores de calidad del servicio de Internet” debe llevar al lugar de la página web del operador donde se encuentran las mediciones de los indicadores de calidad del servicio, de acuerdo con lo establecido para el efecto por el RPU.

5. Prácticas de gestión de tráfico.

Este enlace denominado “Prácticas de gestión de tráfico” debe llevar al lugar de la página web del operador donde se especifiquen las prácticas de gestión de tráfico de acuerdo con lo establecido para el efecto por el RPU.

6. Peticiones, quejas/reclamos y recursos.

Este enlace denominado “Procedimiento y trámite de PQR’s”, debe llevar al lugar de la página web del operador donde se puede consultar la información sobre el derecho de los usuarios de presentar PQR’s, los medios de atención al cliente a través de los cuales se pueden radicar y el procedimiento aplicable.

1.3. Peticiones, quejas/reclamos y recursos.

El trámite de las peticiones, quejas y recursos, se rige por lo dispuesto en el título IV de la Ley 1341 de 2009 y la sección 24 del RPU expedido por la Comisión de Regulación de Comunicaciones o las normas que la modifiquen o la sustituyan.

1.3.1. Información sobre el trámite de las peticiones y quejas/reclamos.

Dentro de la constancia de presentación de las peticiones y quejas/reclamos a la que se refiere el RPU, los operadores deben incluir el siguiente texto:

“Su petición o queja/reclamo será contestada a más tardar el día (indicar día, mes y año) a través del mismo medio de atención por el que la presentó o por el medio de su elección. Si su petición o queja/reclamo no es atendida en la fecha indicada, se entenderá que ha sido resuelta a su favor. (Esto se llama silencio administrativo positivo)”.

1.3.2. Asignación de tipología para peticiones.

Cuando los usuarios presenten peticiones frente a los operadores, estos últimos deben asignar la tipología correspondiente, de acuerdo al listado previsto en el formato 4.3 “Monitoreo de quejas” del anexo 1 del RPU.

1.3.3. Peticiones, quejas/reclamos y recursos a través de la línea telefónica gratuita.

Las peticiones, quejas/reclamos o recursos (PQR) presentados a través de la línea telefónica gratuita de atención al usuario, deben seguir en su trámite y procedimiento aplicable, las reglas previstas para el efecto por el RPU.

La asignación del código único numérico (CUN) a las peticiones, quejas/reclamos o recursos (PQR) presentados a través de la línea telefónica gratuita de atención al usuario, debe seguir los lineamientos previstos en la presente circular.

1.3.4. Peticiones, quejas/reclamos y recursos en página web del proveedor del servicio.

Con el fin de garantizar el acceso y uso de los mecanismos electrónicos y tecnológicos para la presentación de peticiones, quejas/reclamos y recursos (PQR) según lo establecido en el RPU, los operadores deben incorporar en la página de inicio de su portal web, un enlace ubicado en la barra principal de navegación, consistente en un botón destacado y fácilmente identificable, que le indique al usuario acerca del derecho que tiene a presentar PQR’s y lo direccione al formato previsto en el RPU denominado “Formato para presentación de peticiones, quejas/reclamos y recursos a través de oficinas virtuales”.

1.3.5. Información sobre oportunidad y trámite de peticiones y quejas/reclamos sobre facturación.

Cuando se trate de cualquier petición o queja/reclamo asociada con la facturación, los operadores deben informar a sus usuarios a través de los medios de atención establecidos en el RPU, (i) que estas podrán presentarse máximo dentro de los seis (6) meses siguientes contados a partir del vencimiento del pago oportuno de la misma; (ii) que el usuario NO debe pagar las sumas que sean objeto de reclamación, siempre y cuando la PQR se presente antes de la fecha de pago oportuno.

1.3.6. Respuesta a las peticiones, quejas/reclamos y recursos.

El operador debe dar respuesta a la PQR (petición, queja/reclamo o recurso) dentro de los 15 días hábiles siguientes a su presentación. Dicha actuación, para efectos del cómputo del término legal para emitir respuesta y la eventual configuración del silencio administrativo positivo, se entiende surtida cuando la respuesta es enviada al usuario a través del mismo medio de atención por el que el usuario presentó la PQR, o por el medio elegido por este, según corresponda, de acuerdo con lo previsto para el efecto por el RPU.

En el caso de las peticiones y quejas/reclamos, la respuesta emitida por el operador deberá incluir en su contenido el siguiente texto:

“En caso de no estar de acuerdo con la respuesta que le hemos dado, usted puede presentar ante nosotros recurso de reposición y en subsidio de apelación dentro de los diez (10) días hábiles siguientes a la notificación de esta decisión. Lo puede hacer a través de medios electrónicos (página web o red social), línea gratuita de atención al usuario número XXX o mediante comunicación escrita”.

1.3.7. Conservación de respuestas y notificaciones a las peticiones, quejas/ reclamos y recursos.

Los operadores deben conservar hasta por el término de tres (3) años contados a partir de la emisión de la respuesta, los soportes de las respuestas y notificaciones de sus decisiones empresariales.

1.3.8. Remisión de expedientes electrónicos a la Superintendencia de Industria y Comercio para decisión del recurso de apelación.

De conformidad con lo establecido por el RPU, los operadores dentro de los cinco (5) días hábiles siguientes a la notificación de la decisión que resuelve el recurso de reposición, deben remitir el expediente completo a la Superintendencia de Industria y Comercio para que la entidad proceda a resolver el recurso de apelación.

Para el efecto, los operadores deben realizar la remisión del expediente a la Superintendencia de Industria y Comercio para la decisión del recurso de apelación, únicamente a través de: (i) “Formulario web” o, (ii) “Web service”; los cuales corresponden a mecanismos establecidos por esta Entidad y cuyos requerimientos técnicos están desarrollados en el anexo técnico denominado “Requerimientos para la implementación de la asignación del CUN, consulta de PQR y reporte de apelaciones por medios electrónicos”, que hace parte integral del presente título.

Los expedientes electrónicos remitidos a la Superintendencia de Industria y Comercio por los operadores para que sea decidido el recurso de apelación interpuesto por el usuario en sede de empresa, deben cumplir, como mínimo, con los siguientes requisitos para su admisión y trámite:

a) Carátula o portada que deberá contener:

1. Razón social del operador

2. NIT del operador

3. Nombre del representante legal del operador

4. Nombre o razón social del recurrente

5. Identificación del recurrente (NIT, C.C., C.E., etc.)

6. Código único numérico - CUN.

7. Fecha de la asignación del CUN

8. Dirección de notificación del recurrente

9. Ciudad de domicilio del recurrente

10. Número de teléfono relacionado con la reclamación (móvil o fijo), cuando sea procedente.

11. Tipo de PQR, de conformidad con la tipología prevista en el formato 4.3 “Monitoreo de quejas” del anexo 1 del RPU.

12. Número total de folios remitidos.

b) Índice de contenido con registro de cada una de las piezas que hacen parte del expediente en su respectivo orden cronológico, así como su ubicación dentro de la respetiva foliación.

c) Documento que contenga la petición o queja presentado por el usuario, que dio lugar a la iniciación del trámite en sede de empresa, con inclusión de la totalidad de los anexos aportados por el usuario al momento de su radicación ante el operador.

d) Documento que contenga la respuesta o decisión suministrada por el operador a la petición o queja presentada por el usuario, que dio lugar a la iniciación del trámite en sede de empresa, con inclusión de la totalidad de los soportes probatorios que sirvieron de fundamento para la adopción de la respuesta o decisión.

e) Documento que contenga el recurso de reposición y subsidiario de apelación presentado por el usuario, con inclusión de la totalidad de los anexos aportados por el recurrente al momento de su radicación ante el operador.

f) Documento que contenga la decisión adoptada por el operador al recurso de reposición, con inclusión de la totalidad de los soportes probatorios que sirvieron de fundamento para la adopción de la decisión.

g) Prueba de la notificación de las respuestas o decisiones emitidas por el operador.

En caso de que algún operador remita los expedientes en medio físico, el recurso de apelación será decidido por la Superintendencia de Industria y Comercio. No obstante, el incumplimiento de la presente instrucción, dará lugar a la imposición de las sanciones legales que correspondan por el no uso de los mecanismos electrónicos establecidos por esta entidad.

PAR. TRANS.—A partir del primero (1) de diciembre de dos mil diecisiete (2017), y por el término de cuatro (4) meses, el operador de servicios de comunicaciones deberá trasladar —con periodicidad mensual— al menos el treinta (30) por ciento (%) de los expedientes de que trata el artículo 54 de la Ley 1341 de 2009 a esta Superintendencia, a través de los mecanismos electrónicos (i) “Formulario web” o, (ii) “Web service”.

La instrucción deberá ser observada por los operadores de servicios de comunicaciones que durante el primer semestre de 2017, hayan trasladado a la Superintendencia de Industria y Comercio mensualmente expedientes en un número superior a cien (100).

1.4. Contratación de servicios.

1.4.1. Conservación de documentos contractuales.

Los operadores, para efectos de consulta de sus usuarios, deben conservar todos los documentos que hacen parte integral del contrato de prestación de servicios de comunicaciones (contrato, anexos, modificaciones y cualquier otro documento que haya sido suscrito y/o puesto en conocimiento al usuario), durante el término y bajo las condiciones previstas por el artículo 28 de la Ley 962 de 2005 y/o cualquier otra norma que la modifique o sustituya.

1.4.2. Reglas asociadas a la terminación del contrato de prestación de servicios de comunicaciones.

En ningún caso el operador puede condicionar el trámite de una solicitud de terminación de contrato al pago de obligaciones insolutas a cargo del usuario que celebró el contrato. Sin embargo, ello no obsta para que el operador pueda perseguir el pago de estas, así como el de los valores correspondientes a la terminación anticipada del contrato.

La solicitud de terminación del contrato o de cancelación de servicios, debe ser almacenada por el operador de servicios de comunicaciones por el término de tres (3) años calendario, contado a partir de la fecha de la terminación del contrato.

La devolución o reintegro de los equipos o elementos entregados por el proveedor a título de comodato estará a cargo del operador del servicio, quien debe recoger los elementos en el lugar de la instalación del (los) servicio(s) de manera gratuita, en un término no superior a un (1) mes calendario, contado a partir de la fecha de la solicitud de la terminación del contrato. Finalizado dicho lapso, si el operador no procede a recoger tales elementos, el usuario queda exonerado de toda responsabilidad y correrá por cuenta del operador su deterioro o pérdida.

Para el efecto, el operador deberá concertar una cita con el usuario con al menos tres (3) días calendario previo a la fecha de recolección de los equipos o elementos entregados para la prestación del servicio, para lo cual deberá fijar una cita con el usuario con un rango de espera no superior a dos (2) horas.

En el evento en el que el usuario no atienda la visita programada para la recolección de los equipos o elementos entregados para la prestación del servicio, este deberá entregarlos en el lugar señalado por el operador.

1.5. Reportes de Información.

1.5.1. Información a disposición de la Superintendencia de Industria y Comercio.

a) Información de peticiones, quejas/reclamos y recursos

Los operadores deben mantener a disposición de la Superintendencia de Industria y Comercio, un registro debidamente actualizado de las peticiones, quejas/reclamos y recursos presentadas por los usuarios a través de cada uno de sus medios de atención, que contenga —como mínimo— si se trata de una petición, queja/reclamo o recurso, el número del CUN, la causal o motivo, el nombre e identificación del usuario, resumen de la petición, queja/reclamo o recurso y, la respuesta brindada a la PQR.

PAR.—Dicha información debe consolidarse por cada mes calendario y debe ser conservada hasta por el término de tres (3) años.

b) Facturación y cobro de servicios de contenido comercial y/o publicitario prestados a través de SMS, MMS y USSD

Los operadores deben mantener a disposición de la Superintendencia de Industria y Comercio, los registros de facturación y/o evidencia del cobro que se efectúen a través de sus sistemas de facturación a los usuarios, por el consumo de servicios de contenido comercial y/o publicitario prestados a través de SMS, MMS y USSD cursados por su red, bien sea que estén vinculados en modalidad prepago o pospago.

Los soportes de facturación deben estar a disposición de la Superintendencia de Industria y Comercio en el momento en que esta los requiera en el ejercicio de sus funciones de inspección, vigilancia y control, según la normativa aplicable.

CAPÍTULO TERCERO

Código único numérico (CUN)

“3.1. Código único numérico (CUN).

En virtud de los regímenes de protección de los derechos de los usuarios de servicios de comunicaciones y servicios postales, los usuarios tienen derecho a presentar peticiones, quejas/reclamos, recursos y solicitudes de indemnización (servicios postales), así como a consultar el estado actualizado de su trámite, utilizando para ello el código único numérico (CUN) asignado por el operador de servicios de comunicaciones o el operador postal, según corresponda, al momento de la presentación de la respectiva petición, queja/reclamo, recurso y solicitud de indemnización (servicios postales) por parte del usuario.

Para todos los efectos contenidos en el presente capítulo, entiéndase por código único numérico (CUN), el código de identificación que permitirá a los usuarios de los servicios de comunicaciones y servicios postales, hacer seguimiento sobre el estado del trámite de su petición, queja/reclamo, recurso y solicitud de indemnización (servicios postales) ante el operador de servicios de comunicaciones o el operador de servicios postales en sede de empresa, y ante la Superintendencia de Industria y Comercio.

En atención a lo anterior, el código único numérico (CUN), debe ser asignado por el operador de servicios de comunicaciones y/o el operador postal, a toda petición, queja/ reclamo, recurso y solicitud de indemnización, esta última para los servicios postales, salvo las que esta misma circular contemple. Dicho código deberá comunicarse en el momento de registro del trámite, de conformidad con las condiciones establecidas en el presente capítulo.

3.1.1. Estructura del código único numérico (CUN).

Los operadores, tanto de servicios de comunicaciones como de servicios postales, según corresponda deben implementar en su sistema de recepción de peticiones, quejas/ reclamos, recursos o solicitudes de indemnización los dieciséis (16) dígitos del código único numérico (CUN) que está compuesto de la siguiente estructura:

I.1,C.E.6
 

IO, identificador operador: Corresponde a los cuatro (4) primeros dígitos que identifican al operador de servicios de comunicaciones y al operador postal. El identificador operador IO será designado por la Superintendencia de Industria y Comercio en la fecha prevista en el cronograma para la implementación del código único numérico (CUN).

AA, año de radicación: Corresponde a los dos (2) últimos dígitos del año en el que se registra en el sistema de recepción de peticiones, quejas/reclamos, recursos y solicitudes de indemnización (servicios postales) del operador de servicios de comunicaciones u operador postal, la primera radicación de la solicitud.

CR, consecutivo de radicación: Es un número secuencial ascendente de diez (10) dígitos generado por el sistema de recepción de peticiones, quejas/reclamos, recursos y solicitudes de indemnización (servicios postales) de cada operador de servicios de comunicaciones u operador postal 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 de cada año.

3.2. Tipología de petición, queja/reclamo, recurso o solicitud de indemnización a la cual debe asignársele un código único numérico (CUN).

3.2.1. Tipología para los servicios de comunicaciones.

De conformidad con lo previsto en el formato 4.3 “Monitoreo de quejas” del anexo 1 del RPU, se debe asignar un código único numérico (CUN) por parte de los operadores a las peticiones, quejas/reclamos o recursos (PQR) que presenten los usuarios de los servicios de comunicaciones, utilizando para ello las tipologías allí establecidas.

No se debe asignar (CUN) a las siguientes solicitudes:

• Solicitud de reconocimiento del silencio administrativo positivo (SAP)

• Solicitudes sobre las cuales el operador dé respuesta inmediata y favorable al usuario.

• Sistemas de respuesta automática de llamadas o IVR (Interactive voice response).

• Consultas y reclamos relacionados con reporte ante centrales de riesgos y tratamiento de datos personales.

• Peticiones y quejas/reclamos relacionadas con garantías de equipos.

3.2.2. Tipología para los servicios postales.

De conformidad con lo previsto en RPU para servicios postales, se debe asignar un código único numérico (CUN) por parte de los operadores de servicios postales a las peticiones, quejas, recursos y solicitudes de indemnización de conformidad con la siguiente tipología:

Tipología asignación de Cun
Avería del objeto postal
Cumplimiento de una orden de la SIC
Deficiencias en la atención al usuario
Expoliación del objeto postal
Incumplimiento reexpedición
Incumplimientos en tiempo de entrega
Suplantación o fraude en la entrega de objetos postales
Pérdida del objeto postal
Publicidad y/u ofertas sobre los servicios ofrecidos y tarifas
Otros

No se debe asignar (CUN) a las siguientes solicitudes:

• Solicitud de reconocimiento del silencio administrativo positivo (SAP)

• Solicitudes sobre las cuales el operador dé respuesta inmediata y favorable al usuario.

• Sistemas de respuesta automática de llamadas o IVR (Interactive voice response).

• Consultas y reclamos relacionados con tratamiento de datos personales.

3.3. Registro de peticiones, quejas/reclamos, recursos y solicitudes de indemnización que no requieren la asignación de un código único numérico (CUN).

Los operadores de los servicios de comunicaciones y los operadores de servicios postales deben llevar una relación de las peticiones, quejas/reclamos, recursos y solicitudes de indemnización (servicios postales) que no generen la asignación del código único numérico (CUN), la cual debe mantenerse a disposición de esta superintendencia para su consulta y eventual remisión.

3.4. Mecanismos para informar o comunicar la asignación de un código único numérico (CUN).

La asignación del código único numérico (CUN), se debe efectuar al usuario que haya presentado una petición, queja/reclamo, recurso y solicitud de indemnización (servicios postales), y debe ser informada por el mismo medio que haya sido recibida inicialmente. El operador de servicios de comunicaciones y operador postal puede emplear medios electrónicos adicionales, ya sea por SMS o correo electrónico (en caso de tenerlo registrado), para informar el mencionado código.

Cuando se efectúen traslados de peticiones y/o quejas/reclamos entre operadores interconectados o que presten servicios empaquetados, el operador que traslade debe informar al operador responsable de resolverla, el medio a través del cual se presentó la petición o queja así como el número de CUN asignado inicialmente, a efectos de que en la comunicación que tendrá que emitir el operador que recibe por traslado de la petición o queja, pueda indicarle al usuario la invalidez del CUN asignado inicialmente. Por su parte, el operador responsable de resolverla deberá informar al usuario, a más tardar el día inmediatamente siguiente al de la recepción de la petición o queja/reclamo, la cancelación del código único numérico (CUN) asignado inicialmente, así como el nuevo código único numérico (CUN) asignado. Para tales efectos, se debe adicionar en la comunicación la siguiente información:

“(...) Le solicitamos tener en cuenta que para efectos de este trámite el código único numérico [“Número CUN anterior”] asignado por el proveedor [“Nombre proveedor que traslada”] ha sido cancelado por traslado de competencia. En consecuencia, para efecto de seguimiento a la petición o queja por usted presentada, deberá tener en cuenta a partir de la fecha, el código único numérico [“Nuevo número CUN asignado”], cuyo estado podrá ser consultado a través de nuestros canales de servicio”.

3.5. Asignación y reporte de estados del código único numérico (CUN) en servicios de comunicaciones empaquetados.

De conformidad con lo establecido en el RPU, cuando en el uso del servicio que el usuario ha contratado se encuentre vinculado un tercer operador, el operador de servicios de comunicaciones con el que el usuario suscribió el servicio de comunicaciones será el responsable de recibir las peticiones, quejas/reclamos y/o recursos (PQR) que hayan sido presentadas contra él o cualquiera de los otros operadores que presten alguno de los servicios empaquetados o vinculados, asignándole para tal efecto el código único numérico (CUN).

Cuando el hecho que generó la petición, queja/reclamo y/o recurso (PQR), no sea de responsabilidad del operador que la recibió, este debe remitir la petición, queja/ reclamo y/o recurso al operador responsable del servicio quien le asignará y comunicará el nuevo CUN de conformidad con las condiciones establecidas en el presente capítulo, y tendrá la obligación de dar respuesta efectiva al usuario, sin que para ello el término de respuesta exceda los quince (15) días hábiles contados a partir del día siguiente en que la petición, queja/reclamo y/o recurso (PQR) fuese recibida por parte del tercer operador.

El operador que recibió inicialmente la petición, queja/reclamo y/o recurso (PQR), debe informar al usuario de conformidad con las condiciones establecidas en el presente capítulo, el traslado por competencia de la petición, queja/reclamo y/o recurso y debe etiquetar el estado del código único numérico (CUN) que inicialmente hubiere asignado, como “Traslado por competencia” indicando adicionalmente el nombre del operador.

En el evento de que un operador reciba una petición, queja/reclamo y/o recurso (PQR) relacionada con servicios de comunicaciones empaquetados entre los que se encuentren el servicio de Televisión, esta será objeto de asignación de código único numérico (CUN), únicamente a lo que respecta a los servicios de comunicaciones vigilados por esta superintendencia.

3.6. Asignación del código único numérico (CUN) en servicios de comunicaciones por operadores interconectados.

De acuerdo con lo previsto en el RPU, el operador que reciba la petición o queja/ reclamo deberá asignar un código único numérico (CUN) y comunicarlo de conformidad con las condiciones establecidas en el presente capítulo.

Una vez verificado que la petición o queja/reclamo no tiene origen en el servicio por él prestado y habiendo agotado el trámite de traslado establecido en el RPU, debe el operador a quien le es trasladada la petición o queja, asignar un nuevo código único numérico (CUN) y comunicarlo de conformidad con las condiciones establecidas en el presente capítulo, siempre y cuando exista certeza de que la petición o queja tiene origen en el servicio por él prestado.

Surtido lo anterior, el operador a quien inicialmente se le presentó la petición o queja/ reclamo, puede etiquetar el estado del código único numérico (CUN) que inicialmente hubiere asignado, como “Traslado por competencia” indicando además el nombre del operador a quien se trasladó.

El operador a quien le es trasladada la petición o queja le asignará y comunicará al usuario el nuevo código único numérico (CUN) de conformidad con las condiciones establecidas en el presente capítulo, y tendrá la obligación de dar respuesta efectiva al usuario.

Los códigos únicos numéricos que hayan sido trasladados no pueden ser objeto de nuevas asignaciones o reutilizados para trámites posteriores.

3.7. Seguimiento y estado de la petición, queja, recurso o solicitud de indemnización.

Cuando el usuario a través de la página web del operador de servicios de comunicaciones o del operador postal, según corresponda, o de la página web de la Superintendencia de Industria y Comercio, haciendo uso del código único numérico (CUN) realice una consulta sobre una petición, queja/reclamo, recurso o solicitud de indemnización que se encuentre en trámite, debe obtener la información respecto al estado actualizado del trámite. Esta información debe estar disponible hasta un (1) año después de resuelta la actuación.

Cuando se trate de servicios de comunicaciones el operador deberá indicar los siguientes estados:

a) Traslado a operador competente [“Nombre operador al cual se trasladó”]

b) Traslado a la Superintendencia de Industria y Comercio, para resolver recurso de apelación

c) Resuelto

d) Acumulado con el CUN número [“Número de CUN”].

e) Anulado

f) Análisis por parte del operador de servicios de comunicaciones

g) En etapa de práctica de pruebas por parte del operador de servicios de comunicaciones

h) Análisis por parte de la Superintendencia de Industria y Comercio

i) En etapa de práctica de pruebas por parte de la Superintendencia de Industria y Comercio.

Cuando se trate de servicios postales el operador deberá indicar los siguientes estados:

a) Traslado a operador competente [“Nombre operador al cual se trasladó”]

b) Traslado a la Superintendencia de Industria y Comercio, para resolver recurso de apelación

c) Resuelto

d) Acumulado con el CUN número [“Número de CUN”].

e) Anulado

f) Análisis por parte del operador postal

g) En etapa de práctica de pruebas por parte del operador postal.

h) Análisis por parte de la Superintendencia de Industria y Comercio.

i) En etapa de práctica de pruebas por parte de la Superintendencia de Industria y Comercio.

En aquellos casos en los cuales el trámite se hubiese agotado, ya sea porque no se presentaron los recursos, o porque se resolvió el recurso de reposición sin que se hubiere interpuesto el de apelación de forma simultánea y subsidiaria, o porque se resolvió el recurso de reposición de forma totalmente favorable, el operador debe indicar que la decisión empresarial por medio de la cual se resolvió la petición, queja/reclamo y/o recurso fue “Resuelto”.

En el evento en que el usuario presente recurso de apelación de manera simultánea y subsidiaria al recurso de reposición, el usuario puede consultar en la página web de la Superintendencia de Industria y Comercio el acto administrativo por medio del cual se resuelve el recurso de apelación, una vez la decisión haya sido notificada en los términos de ley.

En caso de que el operador resuelva el recurso de reposición de manera parcial o totalmente desfavorable al usuario, debe informarle al usuario del envío del expediente a la dirección de investigaciones de usuarios de servicios de comunicaciones de la Superintendencia de Industria y Comercio, los términos en los que aquel se enviará y la forma de consultar el trámite ante esta entidad.

3.8. Recuperación de código único numérico (CUN) olvidado por el usuario.

En el evento en que el usuario haya olvidado el código único numérico (CUN) que le fue asignado, el operador de servicios de comunicaciones y el operador postal deben implementar un mecanismo que le permita recuperarlo mediante el ingreso del documento de identidad que se haya relacionado en la presentación de la petición, queja/ reclamo, recurso o solicitud de indemnización.

El anterior mecanismo de recuperación de código único numérico (CUN), solo será provisto en los eventos en que el usuario que presente la petición, queja/reclamo, recurso o solicitud de indemnización sea el mismo que figure contractualmente como usuario frente al proveedor de servicios de comunicaciones u operador postal.

En el evento en que el trámite se encuentre en etapa de apelación ante la Superintendencia de Industria y Comercio, el usuario podrá consultar el estado del trámite por medio del código único numérico o ingresando el tipo y número de identificación asociado al usuario que presentó la petición, queja o solicitud de información que originó el recurso.

3.9. Acumulación de código único numérico (CUN).

Cuando exista más de un código único numérico (CUN) asignado a una misma petición, queja/reclamo, recurso o solicitud de indemnización que verse sobre los mismos hechos y pretensiones, el operador de servicios de comunicaciones u operador postal, debe acumular la PQR o solicitud de indemnización al primer CUN asignado.

En todo caso la acumulación de la que se hace referencia no puede 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 o solicitud de indemnización.

3.10. Anulación de código único numérico (CUN).

La anulación del código único numérico (CUN) solo se admite en los siguientes eventos:

a) Por error involuntario, cuando se asigne código único numérico (CUN) a una actuación correspondiente a las tipologías exentas de tal obligación, en cuyo caso se le debe informar al usuario de esta situación.

b) Cuando se asigne un código único numérico (CUN) por un error atribuible a la plataforma tecnológica del proveedor de servicios de comunicaciones u operador postal.

En todo caso debe conservarse por parte del proveedor u operador el soporte de la causa que generó la anulación.

En ningún caso, puede reutilizarse el código único numérico (CUN) que ha sido anulado.

3.11. Procedimiento a seguir cuando el sistema no se encuentre disponible por fallas o mantenimientos.

Cuando el sistema no se encuentre disponible, el operador de servicios de comunicaciones u operador postal debe en todo caso garantizar a los usuarios la recepción de las peticiones, quejas/reclamos, recursos y solicitudes de indemnización. Una vez el sistema se encuentre disponible, el operador debe proceder de manera inmediata a asignar el CUN y a comunicarle la asignación al usuario, de conformidad con las condiciones establecidas en el presente capítulo.

En todo caso, la fecha que se tendrá en cuenta para efectos legales es la correspondiente a la fecha en que el usuario presentó su PQR; en tal sentido, el reproceso de asignación y comunicación del CUN no afecta el término de respuesta.

De igual forma, en los eventos en que el sistema de consulta CUN no se encuentre disponible por fallas técnicas, el proveedor de servicios de comunicaciones u operador postal debe 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.

En caso de que la interrupción obedezca a mantenimientos programados, el proveedor u operador debe comunicar tal situación a los usuarios por lo menos con tres (3) días hábiles de anticipación a la fecha prevista para el mantenimiento, mediante aviso que se debe publicar en sus instalaciones en un lugar visible.

4. Derogatoria.

4.1. Eliminar el capítulo cuarto del título III de la circular única.

4.2. La presente circular, deroga el contenido de los capítulos primero y tercero del anterior título III de la circular única.

5. Vigencia.

La presente circular entra a regir a partir del 1º de enero del año dos mil dieciocho (2018), salvo la obligación prevista en el parágrafo transitorio del numeral 1.3.8, que será exigible desde el 1º de diciembre del año dos mil diecisiete (2017).

N. del D.: La presente circular externa va dirigida a operadores.

Anexo técnico CUN

Requerimientos para la implementación de la asignación del CUN, consulta de PQR y reporte de apelaciones por medios electrónicos.

2017.

Anexo técnico CUN

Control de cambios

VersiónDescripciónAutorFecha
1.0Versión InicialDiego Pedroza 
1.0Revisión versión inicialJaroslav López y Leydi Peña 
1.0Aprobación versión inicialOscar Asprilla 
1.1Ajuste para incluir manejo de WS-Security en el Web Service de ApelacionesPablo Andrés Rodas21/09/2017
1.1Ajuste a validación de los campos del formulario de apelaciones para indicar cantidad, tipo y tamaño de los archivos permitidosNorberto Villegas Pablo Rodas22/09/2017

TABLA DE CONTENIDO

1 INTRODUCCIÓN

1.1 Ámbito de aplicación

1.2 Propósito

1.3 Alcance

1.4 Implementación del mecanismo de seguimiento y estado de PQR´s y solicitudes de indemnización (CUN)

2 ASPECTOS TÉCNICOS Y FUNCIONALES QUE DEBE CUMPLIR LA IMPLEMENTACIÓN DEL CUN

3 OBLIGACIONES GENERALES

3.1 Seguridad y calidad

3.2 Documentación

3.3 Divulgación de la información

4 ETAPA I - ASIGNACIÓN DEL CUN

4.1 Definiciones de criterios de seguridad y calidad

4.1.1 Criterios de seguridad

4.1.2 Criterios de calidad

5 ETAPA II - CONSULTA INTERACTIVA

5.1 Definiciones de criterios de seguridad y calidad

5.1.1 Criterios de seguridad

5.1.2 Criterios de calidad

5.2 Especificaciones técnicas

5.2.1 Escenario de consulta 1. 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 éste

5.2.2 Escenario de consulta 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 Superintendencia de Industria y Comercio

5.2.3 Escenario de consulta 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

5.2.4 Escenario de consulta 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

5.2.5 Diagrama de Interacción entre Operadores y SIC

5.2.6 Contratos de servicio

6 ETAPA III - ENVÍO DE EXPEDIENTES DE APELACIÓN A LA SIC POR MEDIOS ELECTRÓNICOS

6.1 Definiciones de criterios de seguridad y calidad

6.1.1 Criterios de seguridad

6.2 Específicaciones técnicas

6.2.1 Formulario web

6.2.2 Web service

7 CONFIGURACIÓN SERVIDOR DE ARCHIVOS EN LINUX

7.1 Requerimientos de hardware y software

7.1.1 Hardware

7.1.2 Software

7.1.3 Costos aproximados

7.2 Instalación y configuración de port-knocking

7.2.1 Instalación inicial

7.2.2 Configuración inicial

7.2.3 Verificar apertura inicial de puerto mediante un cliente

7.2.4 Verificar cierre inicial de puerto mediante un cliente

7.2.5 Bloqueo de los puertos

7.2.6 Verificación de apertura de los puertos

7.2.7 Verificación de cierre de los puertos

7.2.8 Persistir configuración de iptables

7.2.9 Configuración en el inicio del servidor de Portknocking

7.3 Instalación y configuración de SSH

8 CONFIGURACIÓN SERVIDOR DE ARCHIVOS EN WINDOWS

8.1 Requerimientos de hardware y software

8.1.1 Hardware

8.1.2 Software

8.1.3 Costos aproximados

8.2 Instalación y configuración de SSH

8.3 Instalación y configuración de port-knocking

8.3.1 Instalación de Winpcap

8.3.2 Instalación de Python

8.3.3 Instalación de Pcapy

8.3.4 Instalación de Python Port Knocking

8.3.5 Configuración inicial

8.3.6 Cierre de puerto SSH

8.3.7 Verificar apertura inicial de puerto mediante un cliente

8.3.8 Verificación de apertura de los puertos con el cliente

8.3.9 Verificar cierre inicial de puerto mediante un cliente

8.3.10 Verificación de cierre de los puertos mediante un cliente

8.3.11 Eliminar cuenta virtual

9 INFORMES

10 VALORES DE REFERENCIA

11 ACUERDO DE NIVEL DE SERVICIO

12 GLOSARIO DE TÉRMINOS

1 INTRODUCCIÓN

1.1 Ámbito de aplicación.

Las instrucciones y requerimientos que contiene el presente anexo técnico deben ser adoptadas e implementadas por todos los operadores de servicios de comunicaciones y servicios postales sujetos a los correspondientes regímenes de protección de los derechos de los usuarios de los servicios de comunicaciones y postales, en concordancia con lo establecido en el capítulo tercero del título III de la circular única de esta superintendencia y en los plazos previstos por esta entidad.

En todo caso, los vigilados destinatarios de las instrucciones contenidas en este documento, deben implementar, en los plazos previstos, la totalidad de los requerimientos de carácter obligatorio aquí exigidos.

1.2 Propósito.

Definir las especificaciones técnicas que deben cumplir los operadores de servicios de comunicaciones y 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 que contienen recursos de apelación interpuestos en sede de empresa, para ser resueltos por parte de la Superintendencia de Industria y Comercio.

Indicar la técnica del método de consulta y datos resultantes que se originan desde la Superintendencia de Industria y Comercio frente al estado del trámite de las PQRs o solicitudes de indemnización presentadas ante los operadores de servicios de comunicaciones y postales.

Presentar y explicar el método de consumo 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 operador de servicios de comunicaciones o postal.

1.3 Alcance.

Describir las actividades que deben ser desarrolladas tanto por los operadores de servicios de comunicaciones y postales, como por la Superintendencia de Industria y Comercio, con miras a llevar a cabo la implementación de la asignación, consulta de CUN y reportes de expedientes con recursos de apelaciones en sede de empresa para ser resueltos por la Superintendencia de Industria y Comercio.

Para el efecto este anexo técnico incluye la forma en que los operadores de servicios de comunicaciones y postales deben atender los requerimientos técnicos con el fin de implementar el CUN al interior de sus organizaciones.

Asimismo, contiene las especificaciones para el reporte de expedientes que contengan recursos de apelación interpuestos en sede de empresa que deben ser resueltos por la Superintendencia de Industria y Comercio y el mecanismo de consulta de las PQRs o solicitudes de indemnización presentadas por los usuarios, ya sea desde el portal de los operadores de servicios de comunicaciones y postales, o desde el portal de la SIC.

1.4 Implementación del mecanismo de seguimiento y estado de pqr´s y solicitudes de indemnización (CUN)

Con la finalidad de implementar la asignación del código único numérico, la consulta interactiva de PQR's y las solicitudes de indemnización y el envío de expedientes que contienen recursos de apelación a través de servicios web, se han previsto las siguientes etapas de desarrollo e implementación:

1) Asignación del CUN y seguimiento del estado de la PQRs o solicitud de indemnización en los sistemas de gestión del operador.

2) Implementación para los mecanismos de consulta interactiva entre los sistemas del 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).

3) Implementación de los medios electrónicos de transferencia de expedientes desde el operador hacia la Superintendencia de Industria y Comercio.

Para la primera etapa, siempre y cuando se trate de vigilados que aún se encuentren en proceso de cumplir con este requisito, las actividades que se deben desarrollar son las siguientes:

1) Se deben realizar mesas de trabajo en las instalaciones de la SIC con las empresas vigiladas, así como brindar soporte a través del correo electrónico soportecun@sic.gov.co, con el fin de verificar las 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 vigilados deben llevar a cabo 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. Las pruebas deben obedecer a un plan de pruebas establecidos por el operador.

3) Los operadores deben presentar un informe, que refleje los resultados de las pruebas piloto, al correo electrónico soportecun@sic.gov.co, 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 deben efectuar los ajustes resultantes de los incidentes detectados por ellos durante las pruebas piloto.

5) Una vez realizados, verificados y aprobados los anteriores pasos por la Superintendencia de Industria y Comercio, se dará el aval para poner en producción final el desarrollo expuesto en el presente numeral.

6) Las sociedades vigiladas, deberán llevar a cabo el proceso de puesta en producción final de los sistemas de asignación de CUN y seguimiento del estado de las PQR's y/o solicitudes de indemnización en sus sistemas de gestión, en un periodo de tiempo que no puede exceder un término máximo de un (1) mes.

Para la segunda etapa, los operadores deben llevar a cabo las siguientes actividades:

1) Implementar los mecanismos de consulta interactiva entre sus sistemas y los sistemas de la Superintendencia de Industria y Comercio.

a. Consulta de estado de PQRs o solicitudes de indemnización desde el portal del operador.

b. Servicio web expuesto por el operador para consulta de estado de PQRs o solicitudes de indemnización desde el portal web de la SIC.

c. Consumo del servicio web expuesto por la SIC para consulta del estado de una apelación.

2) Presentar informes de avance sobre la ejecución de las actividades técnicas destinadas a implementar los mecanismos de consulta interactiva. Dichos informes, como mínimo, deben contener la siguiente información:

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) Realizar mesas de trabajo y/o reuniones presenciales o virtuales programadas por la SIC o solicitadas por parte de las empresas vigiladas, a través del correo electrónico soportecun@sic.gov.co, para verificar la implementación del mecanismo de envío de expedientes y realizar la configuración de los parámetros de seguridad del operador en el sistema de la SIC.

4) Realizar pruebas piloto de los mecanismos de consulta interactiva entre los sistemas de los operadores y los sistemas de la Superintendencia de Industria y Comercio. Para ello, se coordinarán las fechas y la temática concreta de dichas pruebas piloto.

5) Presentar un informe de los resultados de cada una de las pruebas piloto efectuadas respecto de los mecanismos de consulta interactiva que trata esta segunda etapa. Dicho informe 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.

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. Nombre y versión del sistema a probar. (Ej. Consulta PQR v.1.0)

6) Realizar los ajustes resultantes de los incidentes detectados por los operadores durante las pruebas piloto.

7) Una vez realizados, verificados y aprobados los anteriores pasos por los la Superintendencia de Industria y Comercio, se dará el aval para poner en producción final el desarrollo expuesto en el presente numeral.

8) Llevar a cabo el proceso de puesta en producción final de los sistemas de asignación de CUN y seguimiento del estado de las PQR’s y/o solicitudes de indemnización en sus sistemas de gestión, en un periodo de tiempo que no puede exceder un término máximo de un (1) mes.

Para el desarrollo de la segunda etapa de implementación, los operadores deben llevar a cabo las siguientes actividades:

1) Implementar el cliente del servicio web para transferencia de expedientes expuesto por la SIC, siguiendo las indicaciones técnicas que se describen en este documento.

2) Realizar mesas de trabajo y/o reuniones presenciales o virtuales programadas por la SIC o solicitadas por parte de las empresas vigiladas, a través del correo electrónico soportecun@sic.gov.co, para verificar la implementación del mecanismo de envío de expedientes y realizar la configuración de los parámetros de seguridad del operador en el sistema de la SIC.

3) 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.

4) 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:

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. Consulta PQR v.1.0)

5) Realizar los ajustes resultantes de los incidentes detectados durante las pruebas piloto.

6) Una vez realizados, verificados y aprobados los anteriores pasos por parte de la Superintendencia de Industria y Comercio, se dará el aval para poner en producción final el desarrollo expuesto en el presente numeral.

7) Culminada exitosamente la etapa de pruebas, y previa habilitación por parte de esta entidad, se deberá efectuar la puesta en producción final de los mecanismos electrónicos de reporte de expedientes de apelaciones ante la SIC.

2 ASPECTOS TÉCNICOS Y FUNCIONALES QUE DEBE CUMPLIR LA IMPLEMENTACIÓN DEL CUN.

Con la finalidad de implementar de manera adecuada lo indicado en el numeral inmediatamente anterior, debe seguirse de manera estricta la estructura numérica y conceptual prevista en el capítulo tercero del título III de la Circular Única de la Superintendencia de Industria y Comercio, en lo referente al código único numérico (CUN).

3 OBLIGACIONES GENERALES.

En desarrollo de lo dispuesto en el presente anexo técnico, los operadores deberán cumplir dentro de sus políticas y procedimientos relativos a la administración del CUN, con las siguientes obligaciones:

3.1 Seguridad y calidad.

En desarrollo de los criterios de seguridad y calidad, y considerando los canales para la asignación del CUN, los operadores deben 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 que se encuentre disponible para consulta o que sea remitida a los usuarios esté libre de software malicioso.

• 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 operador debe utilizar e implementar de acuerdo a su capacidad e infraestructura las mejores prácticas sobre los estándares mínimos de seguridad dispuestos en la norma colombiana NTC-ISO/IEC 27001.

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 soporta 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 debe analizar 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 debe 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 seleccionada la estrategia de respaldo hay que desarrollarla e implementarla 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.

Los tres componentes del plan de contingencia deben estar debidamente documentados y sustentados. 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.

3.2 Documentación.

En materia de documentación, los operadores deben cumplir con los siguientes requerimientos:

• Un registro detallado de los códigos asignados, que debe 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 del trámite.

◌ Datos básicos del quejoso que solicita el trámite. (Nombres y apellidos y número y tipo de identificación)

◌ Datos básicos del operador frente al cual se interpuso el trámite. (Razón social y Nit.)

• 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. Esta información, debe ser conservada por un término mínimo de tres (3) años.

Asimismo, los operadores deben 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 el régimen de protección a usuarios de servicios de comunicaciones y en el título III de la circular única (para el caso de postales).

• En relación con los datos estadísticos, los datos que debe contener la bitácora de anulados son:

◌ Operador: Código base (Identificador del operador)

◌ CUN: Número de CUN asignado

◌ 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:

◌ Operador: Código base (identificador del operador)

◌ 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

◌ 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 registrar el porte del incidente

◌ Fecha reporte: Fecha en que se reporta la incidencia en formato AAAA-MM- DD HH:MM:SS

• En relación con los datos estadísticos asociados al tipo de PQR, se debe registrar tanto el tipo de PQR como la cantidad de solicitudes recibidas por el operador.

3.3 Divulgación de la información

En materia de divulgación de información, los operadores deben 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 de esta superintendencia.

• En el caso de servicios de comunicaciones empaquetados o interconectados, se deben tener en cuenta los procedimientos establecidos para asignación y reportes del CUN señalados en el 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 debe advertir previamente al usuario de esta situación, y debe seguirse el procedimiento señalado en el “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 operadores deben 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.

4 ETAPA I - ASIGNACIÓN DEL CUN.

4.1 Definiciones de criterios de seguridad y calidad.

4.1.1 Criterios de seguridad.

4.1.1.1 Confidencialidad.

Los operadores deben garantizar la confidencialidad de la información, según las políticas de cada empresa.

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

4.1.1.3 Disponibilidad.

La información asociada a la asignación del CUN, deberá estar disponible en el momento que la SIC lo requiera, al igual que los recursos tecnológicos empleados por el operador.

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 operadores, se debe garantizar la disponibilidad de tales servicios a efecto de que no se afecte la continuidad y la secuencia en la asignación del CUN.

Para ello cada operador debe disponer de las herramientas necesarias que le permitan alcanzar el nivel de disponibilidad del 98% +- 2%, de la infraestructura tecnológica que soporta el sistema de asignación del CUN

Los operadores deben tener disponibles los indicadores aquí señalados, con los cortes asociados a las metas establecidas. Los soportes de estos indicadores deben 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.

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

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 operador puede implementar mecanismos de auditoría adicionales.

4.1.2 Criterios de calidad.

4.1.2.1 Efectividad.

El operador debe entregar al usuario el CUN asignado en el mismo momento de la presentación de la PQR o solicitud de indemnización, a través del mismo medio por el que se realizó la radicación.

4.1.2.2 Eficiencia.

El operador debe ajustar su infraestructura y medios disponibles para lograr la asignación del CUN, de forma tal que se eviten situaciones tales como reprocesos y demoras en la notificación del CUN que terminen afectando la atención al usuario.

4.1.2.3 Confiabilidad.

El sistema debe garantizar que para cada PQRs o solicitud de indemnización, el CUN asignado sea acorde con la estructura definida, asignado cronológicamente y sea único por cada asignación que realice el operador.

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, al cual podrá accederse a través del sitio web de la Superintendencia de Industria y Comercio.

5 ETAPA II - CONSULTA INTERACTIVA.

5.1 Definiciones de criterios de seguridad y calidad.

5.1.1 Criterios de seguridad.

5.1.1.1 Confidencialidad.

Los operadores deben garantizar la confidencialidad de la información asociada a la consulta interactiva del CUN, proporcionando para ello mecanismos que permitan limitar la accesibilidad de dichos datos en su fase de transmisión, de manera exclusiva a los sistemas de información o personas destinatarias de la información.

Para asegurar la confidencialidad de la información a nivel de transporte para la consulta del CUN, los operadores deben implementar el protocolo TLS (Transport Layer Security) v 1.0 o superior (certificado de sitio seguro), en los canales de comunicación de los sistemas de información y aplicaciones que reciban o transmitan datos entre la infraestructura del operador y la SIC.

El certificado de sitio seguro debe ser un certificado válido (no autofirmado), de mínimo 256 bits, obtenido bajo la decisión y responsabilidad de cada una de las partes que por norma y política pública intervienen en esta implementación tecnológica, esta es una obligación tanto para esta entidad pública como para cada uno de los entes privados (operador).

5.1.1.2 Integridad.

La información asociada a la asignación del CUN debe ser precisa, coherente y completa. El sistema debe contar con los mecanismos que resulten necesarios para garantizar la trazabilidad de los códigos asignados y que los mismos no puedan ser alterados posteriormente.

5.1.1.3 Disponibilidad

En lo que corresponde a la disponibilidad en servicio del módulo de consulta interactiva, considerando que es un sistema de información de alto impacto en la gestión de las PQR´s y solicitudes de indemnización que realizan los usuarios ante los operadores, éstos deben garantizar, la disponibilidad de los mencionados servicios, con la finalidad de evitar afectaciones que alteren la continuidad del servicio de consulta interactiva del CUN.

Para ello cada operador deberá disponer de las herramientas necesarias que le permitan alcanzar los niveles de disponibilidad del 98% +- 2%, de la infraestructura tecnológica que soporta la consulta del CUN (a través de los servicios web que sean implementados).

Los soportes de estos indicadores, deben mantenerse a disposición de la Superintendencia de Industria y Comercio, para cuando esta entidad los requiera, durante un mínimo de tres (3) años. En todo caso, el informe de cada período deberá consolidarse dentro de los diez (10) días hábiles siguientes al vencimiento del mismo.

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

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 del consumo del servicio web.

• Identificación del usuario (tipo y número de identificación).

• Resultado de la transacción (éxito o fallo).

El operador 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.

5.1.2 Criterios de calidad.

5.1.2.1 Efectividad.

El operador debe entregar al usuario información exacta respecto a cada CUN consultado de forma instantánea, sin violar la ley de protección de datos personales cuando se realiza una consulta de forma pública (acceder a ella sin uso de usuario y clave personalizada).

5.1.2.2 Eficiencia.

El operador debe ajustar su infraestructura y medios disponibles para lograr proveer al usuario la información del estado actual del CUN, de forma tal que se eviten situaciones tales como la desinformación del estado actual del trámite del usuario.

5.1.2.3 Confiabilidad.

El operador debe entregar al usuario la información asociada a un CUN de forma íntegra, es decir, que esté implementada bajo un esquema que permita que la información sea exacta y completa.

5.2 Especificaciones técnicas.

Los operadores deben implementar el mecanismo que a continuación se especifica, el cual debe permitir la consulta interactiva del CUN, la cual debe estar accesible desde su página web.

Dicho mecanismo, debe permitir al usuario realizar una consulta sobre el estado actualizado de su PQR o solicitud de indemnización a través de la página web del operador, o desde la página web de la SIC (según aplique).

A continuación, se describen los cuatro escenarios en los que puede estar un usuario para obtener la información del estado actual de su PQR o solicitud de indemnización:

Escenario de consulta 1. 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 éste.

Escenario de consulta 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.

Imagen 1
 

Escenario de consulta 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.

Escenario de consulta 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.

Imagen 2
 

5.2.1 Escenario de consulta 1. 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 éste.

El operador debe implementar una consulta en su página web. El usuario podrá acceder a esta mediante un enlace (link) en la página principal del portal web del operador, que lo lleve a un formulario donde el usuario tenga la opción de consultar su trámite con los siguientes parámetros:

• CUN asignado.

• Tipo de identificación y número de Identificación.

La información que se suministre al usuario debe contener como mínimo los siguientes parámetros:

Tabla 1. Resultado de consulta escenario 1

Nombre del quejosoTipo de identificaciónNúmero de identificaciónCódigo único numérico (CUN)Fecha asignaciónTipo de quejaEstado del trámiteFecha de respuesta

• Nombre del quejoso: Deben visualizarse los nombres y apellidos completos del usuario.

• Código único numérico (CUN): Es el código que identifica el trámite ante el operador y se debe mostrar al usuario con la máscara establecida en el numeral 3.1.1 Estructura del código único numérico - CUN, del título III de la circular única, de la SIC.

• Fecha de asignación: Es la fecha cuando se le asignó el CUN al usuario, esta fecha debe ser de tipo datetime (Ejemplo: 2012-10-28 09:03:55).

• Tipo de queja: Es la tipología de petición, queja/reclamo, recurso o solicitud de indemnización a la cual debe asignársele un código único numérico de acuerdo a las tipologías previstas en el RPU (en el caso de operadores de servicios de comunicaciones) y en el título III de la circular única (en el caso de operadores postales).

• 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, estos estados son los que están previstos en el capítulo III título III de la circular única de esta entidad.

• Fecha de respuesta: Esta fecha es de tipo date (Ejemplo: 2012-10-28) que informa al usuario la fecha que darán respuesta a su PQR o solicitud de indemnización.

5.2.2 Escenario de consulta 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.

La SIC dispone de un esquema para la obtención de la información del operador, en el cual despliega un formulario en la página web de la SIC y requiere configurar un cliente de servicio web para establecer comunicación con el operador, quien a su vez expone un servicio web que permite la consulta del estado de una PQR.

Los parámetros que serán remitidos al operador son los definidos en el numeral 5.2.6.1 métodos públicos servicio web operador – consultaCUN - Parámetros de entrada.

Los parámetros de retorno que debe devolver el operador a la SIC son los definidos en el numeral 5.2.6.1 métodos públicos servicio web operador - consultaCUN - parámetros de salida.

La información que se desplegará será la siguiente:

Tabla 2. Resultado de consulta escenario 2

Nombre del quejosoTipo de identificaciónNúmero de identificaciónCódigo único numérico (CUN)Fecha asignaciónTipo de quejaEstado del trámiteFecha de respuesta

Imagen 3
 

5.2.3 Escenario de consulta 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.

La SIC dispone de un servicio web para consulta del estado actual de una apelación (ver numeral 5.2.6.3 servicio SIC). Los operadores deben implementar un mecanismo de consumo (cliente) del servicio web y generar un formulario web, que permita a sus usuarios consultar el estado actual de la apelación de su PQR o solicitud de indemnización.

Los parámetros que serán remitidos desde operador son los definidos en el numeral 5.2.6.2 métodos públicos servicio web SIC - consultaCUN - parámetros de entrada.

Los parámetros de retorno que debe devolver la SIC al operador son los definidos en el numeral 5.2.6.2 métodos públicos servicio web SIC - consultaCUN - parámetros de salida.

Los parámetros de retorno se describen a continuación:

• Datos mínimos del usuario (natural o jurídico según aplique).

• Código único numérico - CUN.

• Fecha de asignación.

• 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 cuándo 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.

Presentación de la Información:

“Resultado de información originada de la SIC”

Tabla 3. Parámetros de consulta escenario 3

Nombre del quejosoTipo de identificaciónNúmero de identificaciónCódigo único numérico (CUN)Fecha asignaciónTipo de quejaEstado del trámiteVer detalle del trámite

5.2.4 Escenario de consulta 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.

La SIC dispone de un formulario web por medio del cual el usuario podrá realizar la consulta del estado de su trámite (apelación), 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 4. Parámetros de consulta escenario 4

Nombre del quejosoTipo de identificaciónNúmero de identificaciónCódigo único numérico (CUN)Fecha asignaciónEstado del trámiteTipo de quejaVer detalle del trámite

Imagen 4
 

5.2.5 Diagrama de interacción entre operadores 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 desde el operador. Para tal efecto, se define a continuación un único esquema de transmisión, de tal manera que la integración de servicios sea transparente.

Imagen 5
Imagen 5
 

Imagen 1. Diagrama de interacción.

De acuerdo al diagrama anterior, se evidencia que tanto el operador como la SIC en la integración, deben realizar 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.

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

5.2.6.1 Métodos públicos servicio web operador.

Tabla 5. Métodos Públicos Web Services Operador

NombreParametros de entradaParametros 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).

5.2.6.2 Métodos públicos servicio web SIC.

Tabla 6. Métodos públicos web services SIC

NombreParametros de entradaParametros de salida
consultaCUN• CUN (cadena de caracteres)
• Tipo de identificación (tipo identificación)
• Número de identificación (cadena de caracteres)
XML (ver esquema).

5.2.6.3 Servicio SIC

Corresponde al contrato de servicios que expone la SIC para que el operador lo consuma. Este servicio se encuentra publicado en la URL:

http://wscun.sic.gov.co:8280/services/WSConsultaSIC?wsdl y en https://wscun.sic.gov.co:9443/services/WSConsultaSIC?wsdl

<wsdl:definitions xmlns:wsdl=“http://schemas.xmlsoap.org/wsdl/“ xmlns:wsaw=“http://www.w3.org/2006/05/addressing/wsdl” xmlns:http=“http://schemas.xmlsoap.org/wsdl/http/” xmlns:tns=“http://ws.wso2.org/dataservice“ xmlns:xs=“http://www.w3.org/2001/XMLSchema”xmlns:mime=“http://schemas.xmlsoap.org/wsdl/mime/“ xmlns:soap=“http://schemas.xmlsoap.org/wsdl/so ap/” xmlns:soap12=“http://schemas.xmlsoap.org/wsdl/soap12/“targetNamespace=“http://ws.wso2.org/dataservice“>
<wsdl:types>
<xs:schema attributeFormDefault=“unqualified” elementFormDefault=“qualified” targetNamespace=“http://ws.wso2.org/datas ervice”>
<xs:element name=“DataServiceFault” type=“xs:string”/>
<xs:element name=“REQUEST_STATUS” type=“xs:string”/>
<xs:element name=“DATA_SERVICE_RESPONSE”>
<xs:complexType>
<xs:sequence>
<xs:any minOccurs=“0”/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name=“consultaCUN”>
<xs:complexType>
<xs:sequence>
<xs:element name="identificadorOperador" nillable="true" type="xs:integer"/>
<xs:element name="anoRadicacionCun" nillable="true" type="xs:integer"/>
<xs:element name="ConsecutivoRadCun" nillable="true" type="xs:integer"/>
<xs:element name="numeroRadicacion" nillable="true" type="xs:integer"/>
<xs:element name="anoRadicacion" nillable="true" type="xs:integer"/>
<xs:element name="nombreOperador" nillable="true" type="xs:string"/>
<xs:element name="tipoIdentificacion" nillable="true" type="xs:string"/>
<xs:element name="numeroIdentificacion" nillable="true" type="xs:integer"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name=“ArrayOfIntegracionCUN” type=“tns:ArrayOfIntegracionCUN”/>
<xs:complexType name=“ArrayOfIntegracionCUN”>
<xs:sequence>
<xs:element maxOccurs=“unbounded” minOccurs=“0” name=“IntegracionCUN” type=“tns:IntegracionCUN”/>
</xs:sequence>
</xs:complexType>
<xs:complexType name=“IntegracionCUN”>
<xs:sequence>
<xs:element name=“nomOperador” nillable=“true” type=“xs:string”/>
<xs:element name=“codigoUnicoNumerico” type=“tns:codigoUnicoNumerico”/>
<xs:element name=“numRadicadoCun” type=“tns:numRadicadoCun”/>
<xs:element minOccurs=“0” name=“nomPersona” type=“tns:nomPersona”/>
<xs:element name=“tipoIdNacionalPersona” nillable=“true” type=“tns:tipoIdNacionalPersona”/>
<xs:element name=“grupoNumeroIdentificacion” nillable=“true” type=“xs:string”/>
<xs:element name=“descripcionEstado” type=“xs:string”/>
<xs:element name=“fechaEstRespuesta” type=“xs:dateTime”/>
<xs:element name=“fechaAsignacion” type=“xs:dateTime”/>
<xs:element minOccurs=“0” name=“razonSocial” type=“xs:string”/>
<xs:element name=“url” type=“xs:string”/>
<xs:element name=“tipoQuejaSic” nillable=“true” type=“tns:tipoQuejaSic”/>
<xs:element minOccurs=“0” name=“MensajeServicio” nillable=“true” type=“tns:MensajeServicio”/>
</xs:sequence>
</xs:complexType>
<xs:complexType name=“codigoUnicoNumerico”>
<xs:sequence>
<xs:element name=“identificadorOperador” type=“xs:integer”/>
<xs:element name=“anoRadicacionCun” nillable=“true” type=“xs:integer”/>
<xs:element name=“ConsecutivoRadCun” type=“xs:integer”/>
</xs:sequence>
</xs:complexType>
<xs:complexType name=“numRadicadoCun”>
<xs:sequence>
<xs:element name=“anoRadicacionCun” type=“xs:dateTime”/>
<xs:element name=“numRadicacionCun” type=“xs:integer”/>
<xs:element name=“controlRadicadoCun” type=“xs:string”/>
<xs:element name=“consecutivoRadicacion” type=“xs:integer”/>
</xs:sequence>
</xs:complexType>
<xs:complexType name=“nomPersona”>
<xs:sequence>
<xs:element name=“primerApellido” nillable=“true” type=“xs:string”/>
<xs:element minOccurs=“0” name=“segundoApellido” nillable=“true” type=“xs:string”/>
<xs:element name=“primerNombre” nillable=“true” type=“xs:string”/>
<xs:element minOccurs=“0” name=“segundoNombre” nillable=“true” type=“xs:string”/>
</xs:sequence>
</xs:complexType>
<xs:complexType name=“tipoIdNacionalPersona”>
<xs:sequence>
<xs:element name=“codTipoIdNacionalPersona” nillable=“true” type=“xs:string”/>
<xs:element name=“nomTipoIdentificacionNacionalPersona” nillable=“true” type=“xs:string”/>
</xs:sequence>
</xs:complexType>
<xs:complexType name=“tipoQuejaSic”>
<xs:sequence>
<xs:element name=“nomTipoQuejaSic” nillable=“true” type=“xs:string”/>
<xs:element minOccurs=“0” name=“codTipoQuejaSic” nillable=“true” type=“xs:string”/>
</xs:sequence>
</xs:complexType>
<xs:complexType name=“MensajeServicio”>
<xs:sequence>
<xs:element name=“CodigoError” nillable=“true” type=“xs:string”/>
<xs:element name=“Descripcion” nillable=“true” type=“xs:string”/>
<xs:element minOccurs=“0” name=“Opcional” nillable=“true” type=“xs:string”/>
<xs:element name=“TimeStamp” type=“xs:dateTime”/>
</xs:sequence>
</xs:complexType>
</xs:schema>
</wsdl:types>
<wsdl:message name=“consultaCUNRequest”>
<wsdl:part name=“parameters” element=“tns:consultaCUN”/>
</wsdl:message>
<wsdl:message name=“consultaCUNResponse”>
<wsdl:part name=“parameters” element=“tns:ArrayOfIntegracionCUN”/>
</wsdl:message>
<wsdl:message name=“DataServiceFault”>
<wsdl:part name=“parameters” element=“tns:DataServiceFault”/>
</wsdl:message>
<wsdl:portType name=“WSConsultaSICPortType”>
<wsdl:operation name=“consultaCUN”>
<wsdl:input message=“tns:consultaCUNRequest” wsaw:Action=“urn:consultaCUN”/>
<wsdl:output message=“tns:consultaCUNResponse” wsaw:Action=“urn:consultaCUNResponse”/>
<wsdl:fault message=“tns:DataServiceFault” name=“DataServiceFault” wsaw:Action=“urn:consultaCUNDataServiceFault”/>
</wsdl:operation>
</wsdl:portType>
<wsdl:binding name=“WSConsultaSICSoap11Binding” type=“tns:WSConsultaSICPortType”>
<soap:binding transport=“http://schemas.xmlsoap.org/soap/http” style=“document”/>
<wsdl:operation name=“consultaCUN”>
<soap:operation soapAction=“urn:consultaCUN” style=“document”/>
<wsdl:input>
<soap:body use=“literal”/>
</wsdl:input>
<wsdl:output>
<soap:body use=“literal”/>
</wsdl:output>
<wsdl:fault name=“DataServiceFault”>
<soap:fault use=“literal” name=“DataServiceFault”/>
</wsdl:fault>
</wsdl:operation>
</wsdl:binding>
<wsdl:binding name=“WSConsultaSICSoap12Binding” type=“tns:WSConsultaSICPortType”>
<soap12:binding transport=“http://schemas.xmlsoap.org/soap/http” style=“document”/>
<wsdl:operation name=“consultaCUN”>
<soap12:operation soapAction=“urn:consultaCUN” style=“document”/>
<wsdl:input>
<soap12:body use=“literal”/>
</wsdl:input>
<wsdl:output>
<soap12:body use=“literal”/>
</wsdl:output>
<wsdl:fault name=“DataServiceFault”>
<soap12:fault use=“literal” name=“DataServiceFault”/>
</wsdl:fault>
</wsdl:operation>
</wsdl:binding>
<wsdl:binding name=“WSConsultaSICHttpBinding” type=“tns:WSConsultaSICPortType”>
<http:binding verb=“POST”/>
<wsdl:operation name=“consultaCUN”>
<http:operation location=“consultaCUN”/>
<wsdl:input>
<mime:content type=“text/xml” part=“parameters”/>
</wsdl:input>
<wsdl:output>
<mime:content type=“text/xml” part=“parameters”/>
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
<wsdl:service name=“WSConsultaSIC”>
<wsdl:port name=“WSConsultaSICHttpSoap11Endpoint” binding=“tns:WSConsultaSICSoap11Binding”>
<soap:address
location=“http://wscun.sic.gov.co:8280/services/WSConsultaSIC.WSConsultaSICHttpSoap11Endpoint”/>
</wsdl:port>
<wsdl:port name=“WSConsultaSICHttpSoap12Endpoint” binding=“tns:WSConsultaSICSoap12Binding”>
<soap12:address
location=“http://wscun.sic.gov.co:8280/services/WSConsultaSIC.WSConsultaSICHttpSoap12Endpoint”/>
</wsdl:port>
<wsdl:port name=“WSConsultaSICHttpEndpoint” binding=“tns:WSConsultaSICHttpBinding”>
<http:address location=“http://wscun.sic.gov.co:8280/services/WSConsultaSIC.WSConsultaSICHttpEndpoint”/>
</wsdl:port>
</wsdl:service>
</wsdl:definitions>

Imagen 2. Servicio SIC

5.2.6.4 Servicio operador.

Corresponde al servicio que debe exponer el operador para que la SIC lo consuma. Incluye el método para la consulta del CUN. A continuación se describe el XSD del servicio:

<?xml version=“1.0” encoding=“iso-8859-1”?>
<wsdl:definitions xmlns:soap=“http://schemas.xmlsoap.org/wsdl/soap/“ xmlns:tns=“http://www.example.org/WSConsultaOperador/“ xmlns:wsdl=“http://schemas.xmlsoap.org/wsdl/“ xmlns:xsd=“http://www.w3.org/2001/XMLSchema” name=“WSConsultaOperador” targetNamespace=“http://www.example.org/WSConsultaOperador/“>
<wsdl:types>
<xsd:schema targetNamespace=“http://www.example.org/WSConsultaOperador/“>
<xsd:element name=“consultaCUN”>
<xsd:complexType>
<xsd:sequence>
<xsd:element name=“identificadorOperador” type=“xsd:int” default=“0” />
<xsd:element name=“anoRadicacionCun” type=“xsd:int” default=“0” />
<xsd:element name=“ConsecutivoRadCun” type=“xsd:int” default=“0” />
<xsd:element name=“tipoIdentificacion” type=“xsd:string” default=“%%” />
<xsd:element name=“numeroIdentificacion” type=“xsd:int” default=“0” />
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name=“consultaCUNResponse”>
<xsd:complexType>
<xsd:sequence>
<xsd:element name=“respuesta” type=“xsd:string”/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:schema>
</wsdl:types>
<wsdl:message name=“consultaCUNRequest”>
<wsdl:part element=“tns:consultaCUN” name=“parameters”/>
</wsdl:message>
<wsdl:message name=“consultaCUNResponse”>
<wsdl:part element=“tns:consultaCUNResponse” name=“parameters”/>
</wsdl:message>
<wsdl:portType name=“WSConsultaOperador”>
<wsdl:operation name=“consultaCUN”>
<wsdl:input message=“tns:consultaCUNRequest”/>
<wsdl:output message=“tns:consultaCUNResponse”/>
</wsdl:operation>
</wsdl:portType>
<wsdl:binding name=“WSConsultaOperadorSOAP” type=“tns:WSConsultaOperador”>
<soap:binding style=“document” transport=“http://schemas.xmlsoap.org/soap/http“/>
<wsdl:operation name=“consultaCUN”>
<soap:operation soapAction=“http://www.example.org/WSConsultaOperador/consultaCUN”/>
<wsdl:input>
<soap:body use=“literal”/>
</wsdl:input>
<wsdl:output>
<soap:body use=“literal”/>
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
<wsdl:service name=“WSConsultaOperador”>
<wsdl:port binding=“tns:WSConsultaOperadorSOAP” name=“WSConsultaOperadorSOAP”>
<soap:address location=“http://www.example.org/”/>
</wsdl:port>
</wsdl:service>
</wsdl:definitions>

Imagen 3. Servicio Operador

Teniendo en cuenta que la etiqueta <respuesta> es de tipo String-XML a continuación se relacionan dos ejemplos de respuesta dependiendo el usuario que consulta la información:

Usuario persona natural:

<soap:Envelope xmlns:soap=“http://schemas.xmlsoap.org/soap/envelope/“>
<soap:Body>
<ns2:consultaCUNResponse xmlns:ns2=“http://WSConsultaOperador/“>
<respuesta>
<![CDATA[
<tns:ArrayOfIntegracionCUN xmlns:tns=“http://ws.wso2.org/dataservice”>
<tns:IntegracionCUN>
<tns:nombreOperador>OPERADOR</tns:nombreOperador>
<tns:codigoUnicoNumerico>
<tns:identificadorOperador>1234</tns:identificadorOperador>
<tns:anoRadicacionCun>14</tns:anoRadicacionCun>
<tns:ConsecutivoRadCun>0000000002</tns:ConsecutivoRadCun>
</tns:codigoUnicoNumerico>
<tns:nomPersona>
<tns:primerNombre>NOMBRE_1</tns:primerNombre>
<tns:segundoNombre>NOMBRE_2</tns:segundoNombre>
<tns:primerApellido>APELLIDO_1</tns:primerApellido>
<tns:segundoApellido>APELLIDO_2</tns:segundoApellido>
</tns:nomPersona>
<tns:tipoIdNacionalPersona>
<tns:codTipoIdNacionalPersona>CC</tns:codTipoIdNacionalPersona>
<tns:nomTipoIdentificacionNacionalPersona>
CEDULA DE CIUDADANIA
</tns:nomTipoIdentificacionNacionalPersona>
</tns:tipoIdNacionalPersona>
<tns:grupoNumeroIdentificacion>1044999999
</tns:grupoNumeroIdentificacion>
<tns:descripcionEstado>
ANALISIS POR PARTE DEL OPERADOR
</tns:descripcionEstado>
<tns:fechaAsignacion>2013-04-11T00:00:00</tns:fechaAsignacion>
<tns:fechaEstRespuesta>2013-04-11<tns:fechaEstRespuesta>
<tns:razonSocial></tns:razonSocial>
<tns:tipoQuejaSic>
<tns:nomTipoQuejaSic>
ACTIVACION DE LINEAS ACTIVACION DE LINEAS
</tns:nomTipoQuejaSic>
<tns:codTipoQuejaSic>1</tns:codTipoQuejaSic>
</tns:tipoQuejaSic>
</tns:IntegracionCUN>
</tns:ArrayOfIntegracionCUN>
]]>
</respuesta>
</ns2:consultaCUNResponse>
</soap:Body>
</soap:Envelope>

Usuario persona jurídica:

<soap:Envelope xmlns:soap=“http://schemas.xmlsoap.org/soap/envelope/“>
<soap:Body>
<ns2:consultaCUNResponse xmlns:ns2=“http://WSConsultaOperador/“>
<respuesta>
<![CDATA[
<tns:ArrayOfIntegracionCUN xmlns:tns=“http://ws.wso2.org/dataservice”>
<tns:IntegracionCUN>
<tns:nombreOperador>OPERADOR</tns:nombreOperador>
<tns:codigoUnicoNumerico>
<tns:identificadorOperador>1234</tns:identificadorOperador>
<tns:anoRadicacionCun>14</tns:anoRadicacionCun>
<tns:ConsecutivoRadCun>0000000002</tns:ConsecutivoRadCun>
</tns:codigoUnicoNumerico>
<tns:nomPersona>
<tns:primerNombre></tns:primerNombre>
<tns:segundoNombre></tns:segundoNombre>
<tns:primerApellido></tns:primerApellido>
<tns:segundoApellido></tns:segundoApellido>
</tns:nomPersona>
<tns:tipoIdNacionalPersona>
<tns:codTipoIdNacionalPersona>NI</tns:codTipoIdNacionalPersona>
<tns:nomTipoIdentificacionNacionalPersona>
NUMERO DE IDENTIFICACION TRIBUTARIA
</tns:nomTipoIdentificacionNacionalPersona>
</tns:tipoIdNacionalPersona>
<tns:grupoNumeroIdentificacion>10006000911</tns:grupoNumeroIdentificacion>
<tns:descripcionEstado>
ANALISIS POR PARTE DEL OPERADOR
</tns:descripcionEstado>
<tns:fechaAsignacion>2013-04-11T00:00:00</tns:fechaAsignacion>
<tns:fechaEstRespuesta>2013-04-11<tns:fechaEstRespuesta>
<tns:razonSocial>MI RAZON SOCIAL</tns:razonSocial>
<tns:tipoQuejaSic>
<tns:nomTipoQuejaSic>
ACTIVACION DE LINEAS ACTIVACION DE LINEAS
</tns:nomTipoQuejaSic>
<tns:codTipoQuejaSic>1</tns:codTipoQuejaSic>
</tns:tipoQuejaSic>
</tns:IntegracionCUN>
</tns:ArrayOfIntegracionCUN>
]]>
</respuesta>
</ns2:consultaCUNResponse>
</soap:Body>
</soap:Envelope>

6 ETAPA III - ENVÍO DE EXPEDIENTES DE APELACIÓN A LA SIC POR MEDIOS ELECTRÓNICOS.

6.1 Definiciones de criterios de seguridad y calidad.

6.1.1 Criterios de seguridad.

6.1.1.1 Confidencialidad.

En relación con la confidencialidad de la información, los operadores deben implementar el protocolo TLS (Transport Layer Security) v 1.0 o superior.

Adicionalmente, a nivel de los mensajes que son intercambiados a través del web service expuesto por la SIC, se implementará el estándar WS-Security aplicando criptografía asimétrica o de clave pública(1), mecanismo que permite el cifrado de mensajes para asegurarse de que ninguna parte ni proceso puede acceder a la información del mensaje o divulgarla, ya que, sólo puede descifrar y leer el mensaje, un servicio que conozca la clave correspondiente. Este mecanismo requiere un intercambio de llaves, donde la SIC entregará su llave pública a los operadores, quienes, a su vez, deberán entregar su llave pública a la SIC, de tal modo que se pueda realizar la encripción del mensaje. Las llaves intercambiadas para este fin, serán las mismas utilizadas para realizar la firma del mensaje.

Para asegurar la confidencialidad mientras se transmiten a la SIC los archivos correspondientes 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 éste solo se abre ante una secuencia de golpeteo de puertos correctos.

Para realizar la conexión a un puerto determinado, los operadores deben establecer de común acuerdo con la Superintendencia de Industria y Comercio, la secuencia que permita realizar de manera válida la apertura del mismo, por medio de la configuración de un demonio (proceso) 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.

6.1.1.2 Integridad.

Se garantizará la integridad de los mensajes intercambiados entre la SIC y los operadores a través del web service, implementando el estándar WS-Security haciendo uso del mecanismo de criptografía asimétrica descrito en el punto anterior. Éste utiliza la firma de mensajes para asegurarse que la información no sea modificada, o eliminada durante su transmisión. Cuando se implementa este esquema, se genera una firma digital XML en el contenido del mensaje SOAP, garantizando que, si se realizan cambios no autorizados en los datos del mensaje, la validación de la firma realizada por la otra parte no será satisfactoria. Este mecanismo requiere un intercambio de llaves, donde la SIC entregará su llave pública a los operadores, quienes, a su vez, deberán entregar su llave pública a la SIC, de tal modo que se pueda realizar la validación de la firma en el mensaje. Las llaves intercambiadas para este fin, serán las mismas utilizadas para realizar la encripción del mensaje.

Los operadores deberán garantizar la integridad de información de los paquetes mediante la utilización de XML signature. Para asegurar que los datos transmitidos sean íntegros, deben 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.

La Superintendencia de Industria y Comercio debe 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.

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

En el log se debe registrar como mínimo, lo siguiente:

• Fecha y hora de la transmisión

• Operador que realiza la transmisión

• Resultado de la transacción (éxito o fallo)

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

A nivel de mensajes intercambiados a través del web service expuesto por la SIC, se garantizará el no repudio a través de la implementación de WS-Security para firma y encripción de mensajes como se describió en los puntos anteriores.

6.1.1.5 Control de acceso.

El servicio solo podrá ser consumido desde la IP indicada por cada uno de los operadores/proveedores. El mismo servicio está expuesto con protocolo seguro (https).

Para la transferencia de archivos, se realizará una autenticación, generada por el demonio de port knocking, que debe ser configurado por los operadores para que el puerto no se encuentre público en todo momento. Adicionalmente, la SIC entregará una llave pública para certificación de ssh.

6.2 Específicaciones técnicas.

Para los efectos del presente anexo son mecanismos de reporte de apelaciones ante la Superintendencia de Industria y Comercio: (6.2.1) formulario web y, (6.2.2) servicio web.

6.2.1 Formulario web.

El formulario web es un mecanismo a través del cual los operadores pueden remitir los recursos de apelación a la Superintendencia de Industria y Comercio. Dicho mecanismo puede ser accedido utilizando los datos de registro (usuario y contraseña) que fueron remitidos en las comunicaciones de notificación de CUN, haciendo uso de la dirección web http://serviciolinea.sic.gov.co/cun/, opción que está disponible en la página web de la Superintendencia de Industria y Comercio, en la sección dedicada a protección al consumidor.

En caso de no contar con la precitada información, se debe remitir una comunicación formal por escrito a la dirección de investigaciones de protección de usuarios de servicios de comunicaciones de la Superintendencia de Industria y Comercio, suscrita por el representante legal de la respectiva sociedad.

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

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 operador que haya registrado ante la SIC.

Imagen 6
 

Imagen 4. Acceso al sistema CUN web

La siguiente imagen, corresponde al formulario web desarrollado para que los operadores, realicen el proceso de reporte de apelaciones ante la SIC.

Este formulario está compuesto por dos pasos (ver numeral 6.2.1.1 formulario de reporte), que deben ser diligenciados en su totalidad. La confirmación de la remisión de la información debe ser 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.2.1.1 Formulario de reporte.

Imagen 7
 

Imagen 5. Formulario de reporte de expediente de apelaciones paso 1

Imagen 8
 

Imagen 6. Formulario de reporte de expediente de apelaciones paso 2

A continuación se especifican las reglas implementadas en el formulario.

6.2.1.2 Validaciones de los campos del reporte de apelaciones.

Tabla 7. Validaciones de los campos de reporte de apelaciones

Nombre del campoDescripción del campoTipoLongitudValidacionesObservaciones
IOCorresponde a los 4 primeros dígitos que identifican al operador.Entero4• Campo de texto.
• Campo requerido.
• Campo protegido contra escritura.
• El campo se auto diligencia con los datos del operador en sesión.
AACorresponde 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.Entero2• 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
CREs 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.Entero10• Campo de texto.
• Campo requerido.
• 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ónEs la fecha de asignación del CUN, esta fecha nace en el momento que nace la PQR.DateTime • 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 documentoCorresponde tipo de documento asociado al usuario que presentó la PQR.String2• 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 documentoCorresponde al número de documento asociado al usuario que presentó la PQR.Entero11• 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 nombreCorresponde al primer nombre asociado al usuario que presentó la PQR.String20• Campo de texto
• Campo requerido.
• Campo alfabético
• No se debe permitir escribir espacios al inicio del campo ni al final
Segundo nombreCorresponde al segundo nombre asociado al usuario que presentó la PQR.String20• Campo de texto
• Campo requerido.
• Campo alfabético
• No se debe permitir escribir espacios al inicio del campo ni al final
Primer apellidoCorresponde al primer apellido asociado al usuario que presentó la PQR.String20• Campo de texto
• Campo requerido.
• Campo alfabético
• No se debe permitir escribir espacios al inicio del campo ni al final
Segundo apellidoCorresponde al segundo apellido asociado al usuario que presentó la PQR.String20• Campo de texto
• Campo requerido.
• Campo alfabético
• No se debe permitir escribir espacios al inicio del campo ni al final
DirecciónCorresponde a la dirección física de notificación asociado al usuario que presentó la PQR.String60• Campo de texto
• Campo requerido.
• Campo alfabético
• No se debe permitir escribir espacios al inicio del campo ni al final
Teléfono FijoCorresponde número de teléfono fijo asociado al usuario que presentó la PQR.Entero12• Campo de texto
• Campo requerido.
• Campo numérico
• No se debe permitir escribir espacios al inicio del campo ni al final
Teléfono CelularCorresponde al número telefónico celular asociado al usuario que presentó la PQR.Entero10• Campo de texto
• Campo requerido.
• Campo numérico
• No se debe permitir escribir espacios al inicio del campo ni al final
FaxCorresponde al número de fax asociado al usuario que presentó la PQR.Entero10• Campo de texto
• Campo requerido.
• Campo numérico
• No se debe permitir escribir espacios al inicio del campo ni al final
PaísCorresponde al país asociado al usuario que presentó la PQR.String2• Campo lista de selección única.
• Campo requerido.
• Este campo debe de estar pre diligenciado en la opción Colombia.
DepartamentoCorresponde al departamento asociado al usuario que presentó la PQR.Entero10• Campo lista de selección única.
• Campo requerido.
• Campo deshabilitado.
• Este campo traerá la lista de departamentos pertenecientes a cada país
CiudadCorresponde a la ciudad asociado al usuario que presentó la PQR.Entero10• Campo lista de selección única.
• Campo requerido.
• Campo deshabilitado.
• Este campo traerá la lista de ciudades pertenecientes a la llave país y departamento.
Correo electrónicoCorresponde a la dirección de correo electrónico asociado al usuario que presentó la PQR.String40• Campo texto.
• Campo requerido.
• 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ámiteCorresponde al tipo de servicio que hace referencia a la PQR (Telefonía móvil, internet / otros servicios no domiciliarios, telefonia fija)Entero10• Campo lista de selección única.
• Campo requerido.
• Es campo obligatorio
Tipo de PQR y solicitud de indemnizaciónCorresponde al tipo de queja relacionada para los servicios del CUN y asociada a cada PQR o solicitud de indemnización.Entero10• Campo lista de selección única.
• Campo requerido.
La tipología que debe tenerse en cuenta es la prevista en el RPU y en el título III de la circular única, en el caso de postales.
Descripción de la quejaDescripción de la queja asociada a la PQR.String500• Campo de texto.
• Campo requerido.
• Campo mínimo de 20 caracteres.
• Es campo obligatorio
AdjuntoSon 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.
• La cantidad máxima de archivos que se pueden adjuntar es de 5
• El tamaño máximo por archivo es de 30mb
• La extensión de los diferentes tipos de archivos que se pueden adjuntar son los siguientes::
jpeg, gif, png, jpg, pdf, doc, docx, ppt, pptx, xls, xlsx, mp3, txt, tif y tiff.

6.2.2 Web service.

Este servicio permite realizar a un operador o vigilado la solicitud de radicación de una apelación de una PQR ante la Superintendencia de Industria y Comercio —SIC—. El servicio recibe los datos del operador, del quejoso y de la apelación y retorna un mensaje de éxito o error de recepción de la solicitud. Si la solicitud fue recibida exitosamente, se retorna el número asignado por el sistema a dicha solicitud. Se aclara que este número recibido como respuesta del WS no corresponde al número de radicación, ya que el proceso de radicación se realizará posteriormente.

Luego de ser aceptada la solicitud de radicación, esta solicitud queda en una lista para ser procesada. Como parte de este proceso el sistema de la SIC descargará desde el operador el archivo de soporte del expediente, para lo cual el operador debe haber configurado su servidor SSH con Port Knocking.

Una vez el proceso de radicación ha sido finalizado, el sistema de la SIC enviará al operador un correo electrónico de notificación del éxito de la radicación con un PDF adjunto en el que se informa todos los datos de la radicación. Si el proceso de radicación fallase por cualquier motivo el operador recibirá un correo de notificación del fallo de la radicación.

En los únicos casos en los que el operador no recibirá notificación por correo electrónico serán en aquellos en los que no se encuentre adecuadamente configurada la dirección de correo del operador en la SIC, o en el caso en que el buzón de correo presente fallas.

El web service para solicitud de radicación de apelación implementa el estándar de seguridad WS-Security, debe ser consumido mediante un mensaje encriptado y firmado digitalmente, y dará un resultado encriptado y firmado de igual forma. Dado lo anterior, para que se pueda enviar y recibir estos mensajes adecuadamente, se deberá realizar un intercambio de llaves entre la SIC y el operador de la siguiente forma:

• El operador deberá generar un certificado de persona jurídica entidad o empresa, a través de una entidad certificadora de confianza.

• Una vez generado el certificado, se deberá enviar la llave pública correspondiente a la Superintendencia de Industria y Comercio al correo soportecun@sic.gov.co.

• Tan pronto se reciba la llave pública por parte del operador, la SIC enviará su llave pública al correo electrónico desde el que se recibió la llave pública por parte del mismo.

Nota: Si ya se dispone de un certificado de este tipo por parte del operador, no es necesario generar uno nuevo, y se debe enviar la llave pública correspondiente a la SIC.

En las próximas secciones, se describe con más detalle el proceso de interacción entre la SIC y el operador al momento de realizar el consumo del web service.

6.2.2.1 Diagrama de interacción entre operadores 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, para tal efecto, se ha definido un único esquema de transmisión de tal manera que la integración de servicios sea transparente.

La solución seleccionada fue por medio de una lógica asíncrona segura de transferencia de archivos, en la siguiente imagen se muestran los pasos relevantes del proceso y los artefactos involucrados en este.

Imagen 9
 

Imagen 7. Proceso diseñado para recepción de documentación de soporte.

Para hacer más sencilla la explicación de la estrategia, haremos una descripción de los pasos evidenciados en la imagen anterior.

Por parte del operador:

1. El operador genera un paquete de datos que representa las características de estado de la PQR/Apelación y lo envía a la SIC por medio del servicio tecnológico dispuesto para esto. El mensaje generado desde el operador debe estar firmado y encriptado de acuerdo a las políticas de WS-Security para firma y encripción definidas por el contrato. Si es decisión del operador no implementar este mecanismo, se ofrece por parte de la SIC una URL para consumo del servicio que no requiere de la implementación de WS-Security. Como respuesta a la invocación del servicio, el operador recibirá por parte de la SIC, un consecutivo de solicitud que indica el número con el que fue generada la solicitud de radicación de apelación.

Por parte de la SIC

2. EL servidor se encarga de validar la seguridad del mensaje del paso 1 y recibe el paquete de datos o la “Apelación” para darle trámite, valida la “Apelación” y revisa sus datos internos para así poder determinar las direcciones y archivos en donde se encuentran los soportes, es decir todos aquellos archivos que han servido para dar fundamento al proceso de la PQR y que ahora tiene carácter de apelación.

3. Si hay archivos de respaldo del proceso, genera una tarea que es enviada al sistema ActiveMQ para que ponga en cola la tarea para procesar la solicitud de los archivos y su posterior transferencia.

4. Hay un componente (listener en el diagrama) de programación que se encarga de ir tomando tareas de la cola, mientras en ese momento siguen llegando apelaciones al ESB.

5. El componente (listener en el diagrama) se encarga de generar una conexión segura hacia la ubicación de los archivos para poderlos descargar.

6. Una vez descargados los archivos, estos son almacenados en las áreas de almacenamiento en red de la SIC, y posteriormente se realiza la radicación de la apelación asociada a los archivos. Una vez el proceso de radicación ha sido finalizado, el sistema de la SIC enviará al operador un correo electrónico de notificación del éxito de la radicación, con un PDF adjunto en el que se informa todos los datos de la radicación. Si el proceso de radicación fallase por cualquier motivo el operador recibirá un correo de notificación del fallo de la radicación.

Este proceso se repite continuamente, dado que la tarea de recibir apelaciones puede realizarse en cualquier momento y debido a que obtener los archivos es un proceso que requiere de un tiempo considerable, dependiendo del tamaño de los archivos que se transmiten, es necesario hacer uso de una estrategia de colas que permita manejar una funcionalidad asíncrona, es decir, que mientras se realiza la radicación de solicitudes, también se pueda solicitar la transferencia de archivos, evitando que el operador se quede en espera de una respuesta síncrona

6.2.2.2 Estructura de datos de transmission.

El siguiente esquema define la estructura implementada por la SIC expuesta en internet para que el operador realice el reporte de apelaciones.

Como se mencionó previamente, la SIC ofrece la posibilidad de consumir el servicio implementando el estándar WS-Security para firma y encripción de los mensajes, o sin implementarlo. La decisión del esquema de consumo se deja al operador.

A continuación, la definición del contrato para consumir el servicio sin implementar WS-Security:

<wsdl:definitions xmlns:xsd=“http://www.w3.org/2001/XMLSchema“ xmlns:wsu=“http://docs.oasis- open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd”
xmlns:wsp=“http://www.w3.org/ns/ws-policy“ xmlns:wsdl=“http://schemas.xmlsoap.org/wsdl/“
xmlns:wsaws=“http://www.w3.org/2005/08/addressing”
xmlns:tns=“http://solicitudradicacion.ws.cs.mintic.gov.co/”
xmlns:sp=“http://schemas.xmlsoap.org/ws/2005/07/securitypolicy”
xmlns:soap=“http://schemas.xmlsoap.org/wsdl/soap/“
xmlns:ns1=“http://schemas.xmlsoap.org/soap/http“ name=“RadicarSolicitudApelacion” targetNamespace=“http://solicitudradicacion.ws.cs.mintic.gov.co/“>
<wsdl:types>
<xs:schema xmlns:xsd=“http://www.w3.org/2001/XMLSchema”
xmlns:xs=“http://www.w3.org/2001/XMLSchema”
xmlns:wsu=“http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility- 1.0.xsd” xmlns:wsp=“http://www.w3.org/ns/ws-policy”
xmlns:wsdl=“http://schemas.xmlsoap.org/wsdl/”
xmlns:wsaws=“http://www.w3.org/2005/08/addressing”
xmlns:tns=“http://solicitudradicacion.ws.cs.mintic.gov.co/“
xmlns:sp=“http://schemas.xmlsoap.org/ws/2005/07/securitypolicy”
xmlns:soap=“http://schemas.xmlsoap.org/wsdl/soap/“ xmlns:ns1=“http://schemas.xmlsoap.org/soap/http”
elementFormDefault=“unqualified”
targetNamespace=“http://solicitudradicacion.ws.cs.mintic.gov.co/“ version=“1.0”>
<xs:element name=“radicarSolicitudApelacion” type=“tns:radicarSolicitudApelacion” />
<xs:element name=“radicarSolicitudApelacionResponse”
type=“tns:radicarSolicitudApelacionResponse” />
<xs:complexType name=“radicarSolicitudApelacion”>
<xs:sequence>
<xs:element minOccurs=“0” name=“integracionCUN” type=“xs:string” />
</xs:sequence>
</xs:complexType>
<xs:complexType name=“radicarSolicitudApelacionResponse”>
<xs:sequence>
<xs:element minOccurs=“0” name=“return” type=“xs:string” />
</xs:sequence>
</xs:complexType>
</xs:schema>
</wsdl:types>
<wsdl:message name=“radicarSolicitudApelacionResponse”>
<wsdl:part element=“tns:radicarSolicitudApelacionResponse” name=“parameters”></wsdl:part>
</wsdl:message>
<wsdl:message name=“radicarSolicitudApelacion”>
<wsdl:part element=“tns:radicarSolicitudApelacion” name=“parameters”></wsdl:part>
</wsdl:message>
<wsdl:portType name=“RadicacionSolicitudApelacion”>
<wsdl:operation name=“radicarSolicitudApelacion”>
<wsdl:input message=“tns:radicarSolicitudApelacion” name=“radicarSolicitudApelacion”></wsdl:input>
<wsdl:output message=“tns:radicarSolicitudApelacionResponse” name=“radicarSolicitudApelacionResponse”></wsdl:output>
</wsdl:operation>
</wsdl:portType>
<wsdl:binding name=“RadicarSolicitudApelacionSoapBinding” type=“tns:RadicacionSolicitudApelacion”>
<soap:binding style=“document” transport=“http://schemas.xmlsoap.org/soap/http” />
<wsdl:operation name=“radicarSolicitudApelacion”>
<soap:operation soapAction=““ style=“document” />
<wsdl:input name=“radicarSolicitudApelacion”>
<soap:body use=“literal” />
</wsdl:input>
<wsdl:output name=“radicarSolicitudApelacionResponse”>
<soap:body use=“literal” />
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
<wsdl:service name=“RadicarSolicitudApelacionNoSec”>
<wsdl:port binding=“tns:RadicarSolicitudApelacionSoapBinding” name=“RadicacionSolicitudApelacionPort”>
<soap:address location=“https://webcundes.sic.gov.co/RadicarCunApelacionWS/RadicarSolicitudApelacionNoSec” />
</wsdl:port>
</wsdl:service>
</wsdl:definitions>

Imagen 8. Estructura de datos para el intercambio de información del CUN – Sin WS-Security

A continuación, la definición del contrato para consumir el servicio implementando WS-Security:

<wsdl:definitions xmlns:xsd=“http://www.w3.org/2001/XMLSchema“ xmlns:wsu=“http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd”
xmlns:wsp=“http://www.w3.org/ns/ws-policy“ xmlns:wsdl=“http://schemas.xmlsoap.org/wsdl/“
xmlns:wsaws=“http://www.w3.org/2005/08/addressing”
xmlns:tns=“http://solicitudradicacion.ws.cs.mintic.gov.co/”
xmlns:sp=“http://schemas.xmlsoap.org/ws/2005/07/securitypolicy”
xmlns:soap=“http://schemas.xmlsoap.org/wsdl/soap/“
xmlns:ns1=“http://schemas.xmlsoap.org/soap/http“ name=“RadicarSolicitudApelacion” targetNamespace=“http://solicitudradicacion.ws.cs.mintic.gov.co/“>
<wsdl:types>
<xs:schema xmlns:xsd=“http://www.w3.org/2001/XMLSchema”
xmlns:xs=“http://www.w3.org/2001/XMLSchema”
xmlns:wsu=“http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd” xmlns:wsp=“http://www.w3.org/ns/ws-policy”
xmlns:wsdl=“http://schemas.xmlsoap.org/wsdl/”
xmlns:wsaws=“http://www.w3.org/2005/08/addressing”
xmlns:tns=“http://solicitudradicacion.ws.cs.mintic.gov.co/“
xmlns:sp=“http://schemas.xmlsoap.org/ws/2005/07/securitypolicy”
xmlns:soap=“http://schemas.xmlsoap.org/wsdl/soap/“ xmlns:ns1=“http://schemas.xmlsoap.org/soap/http”
elementFormDefault=“unqualified”
targetNamespace=“http://solicitudradicacion.ws.cs.mintic.gov.co/“ version=“1.0”>
<xs:element name=“radicarSolicitudApelacion” type=“tns:radicarSolicitudApelacion” />
<xs:element name=“radicarSolicitudApelacionResponse” type=“tns:radicarSolicitudApelacionResponse” />
<xs:complexType name=“radicarSolicitudApelacion”>
<xs:sequence>
<xs:element minOccurs=“0” name=“integracionCUN” type=“xs:string” />
</xs:sequence>
</xs:complexType>
<xs:complexType name=“radicarSolicitudApelacionResponse”>
<xs:sequence>
<xs:element minOccurs=“0” name=“return” type=“xs:string” />
</xs:sequence>
</xs:complexType>
</xs:schema>
</wsdl:types>
<wsdl:message name=“radicarSolicitudApelacionResponse”>
<wsdl:part element=“tns:radicarSolicitudApelacionResponse” name=“parameters”></wsdl:part>
</wsdl:message>
<wsdl:message name=“radicarSolicitudApelacion”>
<wsdl:part element=“tns:radicarSolicitudApelacion” name=“parameters”></wsdl:part>
</wsdl:message>
<wsdl:portType name=“RadicacionSolicitudApelacion”>
<wsdl:operation name=“radicarSolicitudApelacion”>
<wsdl:input message=“tns:radicarSolicitudApelacion” name=“radicarSolicitudApelacion”></wsdl:input>
<wsdl:output message=“tns:radicarSolicitudApelacionResponse” name=“radicarSolicitudApelacionResponse”></wsdl:output>
</wsdl:operation>
</wsdl:portType>
<wsdl:binding name=“RadicarSolicitudApelacionSoapBinding” type=“tns:RadicacionSolicitudApelacion”>
<wsp:PolicyReference URI=“#SecurityServiceSignThenEncryptPolicy” />
<soap:binding style=“document” transport=“http://schemas.xmlsoap.org/soap/http” />
<wsdl:operation name=“radicarSolicitudApelacion”>
<soap:operation soapAction=““ style=“document” />
<wsdl:input name=“radicarSolicitudApelacion”>
<soap:body use=“literal” />
</wsdl:input>
<wsdl:output name=“radicarSolicitudApelacionResponse”>
<soap:body use=“literal” />
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
<wsdl:service name=“RadicarSolicitudApelacion”>
<wsdl:port binding=“tns:RadicarSolicitudApelacionSoapBinding” name=“RadicacionSolicitudApelacionPort”>
<soap:address location=“https://webcundes.sic.gov.co/RadicarCunApelacionWS/RadicarSolicitudApelacion” />
</wsdl:port>
</wsdl:service>
<wsp:Policy xmlns:sp=“http://schemas.xmlsoap.org/ws/2005/07/securitypolicy“ wsu:Id=“SecurityServiceSignThenEncryptPolicy”>
<wsp:ExactlyOne>
<wsp:All>
<sp:AsymmetricBinding xmlns:sp=“http://schemas.xmlsoap.org/ws/2005/07/securitypolicy”>
<wsp:Policy>
<sp:AlgorithmSuite>
<wsp:Policy>
<sp:TripleDes />
</wsp:Policy>
</sp:AlgorithmSuite>
<sp:Layout>
<wsp:Policy>
<sp:Lax />
</wsp:Policy>
</sp:Layout>
<sp:OnlySignEntireHeadersAndBody />
</wsp:Policy>
</sp:AsymmetricBinding>
<sp:SignedParts xmlns:sp=“http://schemas.xmlsoap.org/ws/2005/07/securitypolicy”>
<sp:Body />
</sp:SignedParts>
<sp:EncryptedParts xmlns:sp=“http://schemas.xmlsoap.org/ws/2005/07/securitypolicy“>
<sp:Body />
</sp:EncryptedParts>
<sp:Wss10 xmlns:sp=“http://schemas.xmlsoap.org/ws/2005/07/securitypolicy“>
<wsp:Policy>
<sp:MustSupportRefIssuerSerial />
</wsp:Policy>
</sp:Wss10>
</wsp:All>
</wsp:ExactlyOne>
</wsp:Policy>
</wsdl:definitions>

Estructura de datos para el intercambio de información del CUN – Con WS-Security

6.2.2.3 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, 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 8.Tipología de código errores

Error/mensajeCapaNúmero
1 Error1 Acceso a datos0 -9
2 Aplicación0 -9
2 Mensaje1 OK0
2 Diagnóstico0 -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 9. Listado del uso de la codificación de errores

Código de errorDescripción
210OK - Éxito
1001Mensaje de error con la comunicación del WEB service interno del sistema
1002Error Autenticación por credenciales inválidas
1003Error número CUN se encuentra en otra solicitud
1004Error interno del sistema
1005Error Validar datos de entrada
1006Error Actualizar datos del quejoso
1007Error Transferencia de archivo
1008Error Validar archivo.ZIP
1009Error SMTP
1010Error Enviar notificación
1011Error Ejecución de la aplicación
1012Error Escribir en la SAN
1013Error Convertir el PDF
1014Error Desempaquetar archivo.ZIP
1015Error Al renombrar el archivo
1016Mensaje para informar error en la radicación

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 éste sería:

<MensajeServicio>
<CodigoError>121</CodigoError>
<Descripción>Error de procesamiento de datos en la lógica de negocios</Descripción>
<Opcional>Exception: ArithmeticException Handler: System.DivideByZeroException:
Attempted to divide by zero.
at ExceptionTestClass.Main()</Opcional>
<TimeStamp>2011-06-09 23:53:40</TimeStamp>
</MensajeServicio>

Imagen 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.2.2.4. Eventuales fallas del sistema: Pueden presentarse fallas en la solicitud y/o inicio del consumo del servicio o en el proceso de transferencia de datos. Sin embargo, la plataforma web service está diseñada para detectar en cuál de los extremos se presenta la falla. En caso que la falla sea atribuible a los sistemas de la SIC, al operador le corresponde:

(i) reportar el suceso de inmediato al correo electrónico soportecun@sic.gov.co, en el que indique en qué consistió de la falla y; (ii) deberá guardar constancia de ello. Con el precitado reporte de falla, la superintendencia evaluará y determinará la procedencia o no de la suspensión del término de radicación del(los) recurso(s) de apelación.

7 CONFIGURACIÓN SERVIDOR DE ARCHIVOS EN LINUX

En esta sección se detallan los aspectos requeridos para la instalación del servidor de archivos en ambiente Linux.

7.1 Requerimientos de hardware y software

A continuación se detallan los requisitos de hardware y de software del servidor de archivos.

7.1.1 Hardware

Tabla 10. Hardware recomendado servidor de archivos

ServidorHardware
Sistema de ArchivosCaracterísticas físicas
Plataforma de 64 Bits
Procesador a 2.0 GHz o más, dual core o superior
4 GB memoria
500GB de almacenamiento (esto es dependiente de la cantidad de archivos almacenados)
Características de red
Requiere de IP pública

7.1.2 Software

Tabla 11. Software base requerido ambiente Linux

ServidorSoftware base requerido
Sistema de archivosSistema operativo basado en distribuciones: Red Hat Enterprise Linux 5 o superior(2)
CentOS 5 o superior(3)
Debian 6 o superior(4)
La instalación base del sistema operativo debe tener como mínimo: GlibC(5), es una librería base para C en Linux.
Libpcap(6), es una librería utilizada para la captura de paquetes. Normalmente esta librería se encuentra instalada por defecto. IPtables, es un firewall que permite definir políticas de filtrado del tráfico que circula por la red(7)
SSH (Secure Shell), es un programa que permite acceder a la aplicación de forma remota utilizando un protocolo seguro de comunicación(8).

7.1.3 Costos aproximados.

Componente de HardwareCaracterísticasValor
Servidor de AplicacionesPlataforma de 64 Bits
Procesador Intel Xeon (6-Core) E5-2603v3 - 1.6GHz, 15MB L3
Memoria RAM: Estándar 8GB (1x8GB) DDR4 RDIMM Discos Duro 2TB HDD
$ 3.000.000 COP
Componente de SoftwareCaracterísticasValor
Sistema Operativo Red HatLicencia Red Hat Enterprise Linux (rhel) 6$ 361.900 COP
GlibC:Software Libre
Librería base para C en Linux.
$ 0
Libpcap:Software Libre
Librería utilizada para la captura de paquetes. (Normalmente esta librería se encuentra instalada por defecto).
$ 0
IPtables:Software Libre
Firewall que permite definir políticas de filtrado del tráfico que circula por la red
$ 0
SSH (Secure Shell):Software Libre
Programa que permite acceder a la aplicación de forma remota utilizando un protocolo seguro de comunicación
$ 0
Knock Server:Software Libre
Servidor que escucha todo el tráfico en una interfaz Ethernet y busca en especial secuencias knock de golpe de puertos.
$ 0
Total Inversión (valor aproximado)$ 3.361.900

7.2 Instalación y configuración de Port-Knocking.

En los siguientes numerales se indicarán cada uno de los pasos que permiten realizar la instalación y verificación del servidor de port knocking en Linux, realizando las pruebas mediante un cliente Linux o Windows:

7.2.1 Instalación inicial.

1. Para la instalación inicial verifique la versión de sistema operativo. Para las distribuciones Red Hat y CentOS ejecute los siguientes comandos:

cat /etc/redhat-release
uname -r

2. Al ejecutar el primer comando observará la versión del sistema operativo que para el caso particular que muestra la siguiente imagen corresponde a Red Hat Enterprise Linux Server 6.3. Para el segundo comando observará la versión del kernel de Linux que se utiliza, para el caso particular corresponde a 2.6.32. en una máquina con arquitectura x86 de 64 bits. Tenga en cuenta que si el kernel es de 32 bits observará 386 o 686 al final.

Imagen 10
 

Imagen 10. Verificación de la versión de sistema operativo en linux

3. De acuerdo con la versión de sistema operativo y de kernel debe proceder a descargar el archivo correcto del servidor de Port Knocking, a continuación se muestra la ubicación de algunos de los paquetes de instalación para las distribuciones respectivas, de acuerdo con el sistema operativo y la arquitectura:

Tabla 12. Software base requerido ambiente Linux

DistribuciónVersiónArquitecturaURL
Red Hat Enterprise Linux o CentOS6.XX86_64http://li.nux.ro/download/nux/dextop/el6/x86_64/knock-server-0.5-7.el6.nux.x86_64.rpm
Red Hat Enterprise Linux o CentOS6.Xi386http://li.nux.ro/download/nux/dextop/el6/i386/knock-server-0.5-7.el6.nux.i686.rpm
Red Hat Enterprise Linux o CentOS5.XX86_64http://apt.sw.be/redhat/el5/en/x86_64/rpmforge/RPMS/knock-0.5-3.el5.rf.x86_64.rpm
Red Hat Enterprise Linux o CentOS5.XI386http://ftp.belnet.be/packages/dries.ulyssis.org/redhat/el5/en/i386/RPMS.dries/knock-0.5-1.el5.rf.i386.rpm
Debian6.X, 7.XI386http://ftp.us.debian.org/debian/pool/main/k/knockd/knockd_0.5-3_i386.deb
Debian6.X, 7.XAmd64http://ftp.us.debian.org/debian/pool/main/k/knockd/knockd_0.5-3_amd64.deb

4. Descargue el archivo respectivo utilizando el comando wget de Linux, para el ejemplo se tomará como base Red Hat Linux con arquitectura x86_64:

wget http://li.nux.ro/download/nux/dextop/el6/x86_64/knock-server-0.5-7.el6.nux.x86_64.rpm

Imagen 11
 

Imagen 11. Descarga del paquete de instalación del servidor de knock en Linux

5. Instale la aplicación utilizando el comando yum como se muestra a continuación:

yum install knock-server-0.5-7.el6.nux.x86_64.rpm

Imagen 12
 

Imagen 12. Instalación de knock en Linux parte 1

Cuando se le pregunte si es correcto indique que si (y)

Imagen 13
 

Imagen 13. Instalación de knock en Linux parte 2

Asegurarse que al final de la instalación se encuentra la palabra “Complete”.

7.2.2 Configuración inicial.

1. Edite el archivo knock.conf con un editor de texto, para el ejemplo se utilizará vi:

vi/etc/knocd.conf

Imagen 14
 

Imagen 14. Edición del archivo de configuración de knock

Al ejecutar el comando de vi aparecerá el siguiente contenido (este puede variar dependiendo del sistema operativo):

Imagen 15
 

Imagen 15. Contenido inicial del archivo de configuración de knock

3. Reemplace el contenido del archivo teniendo en cuenta las siguientes consideraciones para cada uno de los parámetros:

a. Logfile: Este parámetro debe cambiarse por la línea que indica UseSysLog, este define la ubicación del archivo de log de la aplicación.

b. En la sección openSSH:

• sequence: Este parámetro define la secuencia de puertos que debe realizar el cliente knocking para la apertura del puerto. Estos puertos se deben modificar pero es indispensable informar a la SIC cual fue la secuencia seleccionada.

• Seq_timeout: Este parámetro define el tiempo máximo que se espera para completar la secuencia anterior en segundos.

• Command: Este parámetro define el comando de iptables requerido para la apertura del puerto de ssh que el para el caso particular es el 22.

c. En la sección closeSSH:

• sequence: Este parámetro define la secuencia de puertos que debe realizar el cliente knocking para cerrar el puerto SSH. Estos puertos se deben modificar pero es indispensable informar a la SIC cual fue la secuencia seleccionada.

• Seq_timeout: Este parámetro define el tiempo máximo que se espera para completar la secuencia anterior en segundos.

• Command: Este parámetro define el comando de iptables requerido para la cierre del puerto de ssh que el para el caso particular es el 22.

A continuación se muestra el ejemplo para la secuencia de apertura 7000, 8000 y 9000, y, la secuencia de cierre 9000, 8000 y 7000:

[options]
logfile = /var/log/knockd.log
[openSSH]
sequence = 7000,8000,9000
seq_timeout = 10 tcpflags = syn
command = /usr/sbin/iptables -A INPUT -s %IP% -p tcp --dport 22 -j ACCEPT
[closeSSH]
sequence = 9000,8000,7000
seq_timeout = 10 tcpflags = syn
command = /usr/sbin/iptables -D INPUT -s %IP% -p tcp --dport 22 -j ACCEPT

Imagen 16
 

Imagen 16. Contenido final del archivo de configuración de knock

4. Iniciar el servidor de port-knocking con el siguiente comando:

/etc/init.d/knockd start

Imagen 17
 

Imagen 17. Inicio del servidor de port-knocking en Linux

7.2.3 Verificar apertura inicial de puerto mediante un cliente

Para asegurar el adecuado funcionamiento de la aplicación mediante una simulación del port-knocking, realicé los siguientes pasos en un cliente de acuerdo con el ambiente en que se desee realizar la verificación:

Ambiente Linux

1. Descargue el archivo respectivo utilizando el comando wget de Linux:

wget http://li.nux.ro/download/nux/dextop/el6/x86_64/knock-0.5-7.el6.nux.x86_64.rpm

Imagen 18
 

Imagen 18. Descarga del paquete de instalación del cliente de knock en Linux

2. Instale la aplicación utilizando el comando yum como se muestra a continuación:

yum install knock-0.5-7.el6.nux.x86_64.rpm

Imagen 19
 

Imagen 19. Instalación del cliente knock en Linux parte 1

Cuando se le pregunte si es correcto indique que si (y)

Imagen 20
 

Imagen 20. Instalación del cliente de knock en Linux parte 2

Asegurarse que al final de la instalación se encuentra la palabra “Complete”.

3. Ejecute el comando de apertura del puerto utilizando la misma secuencia de puertos utilizada anteriormente en la configuración (para el ejemplo 9000 8000 7000), esto se hace sobre la máquina que tiene configurado el knockd (para el ejemplo 192.168.1.79) así:

4.

knock -v 192.168.1.79 9000 8000 7000

Imagen 21
 

Imagen 21. Port-knocking desde el cliente en Linux

Ambiente Windows

1. Descargue el cliente de portknocking en un equipo diferente al servidor, para el caso particular se utilizará el cliente de knockd que se encuentra en: http://www.zeroflux.org/projects/knock

2. Busque el cliente para Windows que aparece como “Native Win32Client”:

Imagen 22
 

Imagen 22. Descarga del cliente de port-knocking para Windows

3. Descomprima el archivo knock-win32.zip.

4. Inicie un “Símbolo del Sistema” en Windows.

Imagen 23
 

Imagen 23. Ejecución de “Símbolo del sistema” en Windows

5. Ubíquese en la carpeta donde descomprimió el archivo, para el ejemplo corresponde al directorio de descargas del usuario mediante el comando cd <carpeta>:

6.

Imagen 24
 

Imagen 24. Carpeta de descarga del cliente de port-knocking en Windows

7. Ubíquese en la siguiente subcarpeta donde se descomprime el cliente, basado en knock-win32, correspondiente a knock-win32\knock-win32-port\Release, mediante el comando cd:

Imagen 25
 

Imagen 25. Carpeta del cliente de port-knocking en Windows

8. Ejecute el comando de apertura del puerto utilizando la misma secuencia de puertos utilizada anteriormente en la configuración (para el ejemplo 9000 8000 7000), esto se hace sobre la máquina que tiene configurado el knockd (para el ejemplo 192.168.1.79) así:

knock -v 192.168.1.79 9000 8000 7000

Imagen 26
 

Imagen 26. Port-knocking desde el cliente en Windows

Verificación en el servidor

Es necesario verificar la adecuada configuración del firewall para ello debe realizar los siguientes pasos:

1. Verifique el archivo de log del servidor de port-knocking ejecutando el comando cat así:

cat/var/log/knockd.log

2. Debe encontrar las frases openSSH, Stage 1, Stage 2, Stage 3, OPEN SESAME y el comando iptables de apertura del puerto, como se observa en la siguiente figura:

Imagen 27
 

Imagen 27. Verificar correcto funcionamiento del servidor de portknocking en Linux

3. Adicionalmente verifique que iptables se configuró adecuadamente, al ejecutar el comando “iptables –L” debe observar la apertura del puerto desde la máquina que realiza la conexión como cliente (para el ejemplo es 192.168.4.116), como lo muestra la siguiente imagen:

Imagen 28
 

Imagen 28. Verificar iptables para el servidor de portknocking en Linux

7.2.4 Verificar cierre inicial de puerto mediante un cliente.

Para asegurar el adecuado funcionamiento de la aplicación realizando una simulación del port-knocking, realicé los siguientes pasos en un cliente de acuerdo con el ambiente en que se desee realizar la verificación:

Ambiente Linux

1. El siguiente paso es asegurar que se ejecuta adecuadamente el cierre del puerto de ssh. Para ello desde una terminal en Linux ejecute el comando de cierre del puerto utilizando la misma secuencia utilizada anteriormente (para el ejemplo 7000 8000 9000), esto se hace sobre la máquina que tiene configurado el knockd (para el ejemplo 192.168.1.79) así:

knock –v 192.168.1.79 7000 8000 9000

Imagen 29
 

Imagen 29. Port-knocking de cierre desde el cliente en Linux

Ambiente Windows

1. El siguiente paso es asegurar que se ejecuta adecuadamente el cierre del puerto de ssh. Para ello desde el “Símbolo del sistema” en Windows ejecute el comando de cierre del puerto utilizando la misma secuencia utilizada anteriormente (para el ejemplo 7000 8000 9000), esto se hace sobre la máquina que tiene configurado el knockd (para el ejemplo 192.168.1.79) así:

knock –v 192.168.1.79 7000 8000 9000

Imagen 30
 

Imagen 30. Port-knocking de cierre desde el cliente en Windows

Verificación en el servidor

Es necesario verificar la adecuada configuración del firewall para ello debe realizar los siguientes pasos:

1. Verifique el archivo de log del servidor de port-knocking ejecutando el comando cat así:

cat /var/log/knockd.log

2. Debe encontrar las frases closeSSH, Stage 1, Stage 2, Stage 3, OPEN SESAME y el comando iptables que cierra el puerto, como se observa en la siguiente imagen:

Imagen 31
 

Imagen 31. Verificar cierre en el servidor de portknocking en Linux

3. Adicionalmente verifique que iptables eliminó la regla adecuadamente, al ejecutar el comando “iptables –L” debe observar que ya no se encuentra la regla de apertura del puerto como lo muestra la siguiente figura:

Imagen 32
 

Imagen 32. Verificar iptables para el cierre del puerto en iptables en Linux

7.2.5 Bloqueo de los puertos.

Bloqueo en el servidor

Para asegurar el adecuado cierre de los puertos en el firewall realice los siguientes pasos:

1. Cree una archivo denominado cierrePuertos.sh con el editor vi como aparece a continuación:

vi cierrePuertos.sh

2. Para borrar las reglas actuales del firewall y definir las nuevas requeridas para el adecuado funcionamiento del port-knocking debe incluir el siguiente contenido:

echo Limpiar iptables
iptables –F
iptables –Z
iptables –X
echo Bloquear trafico
iptables -P INPUT DROP
iptables -P FORWARD DROP
echo Permitir ping y loockback
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
iptables -A INPUT -p icmp -j ACCEPT
iptables -A OUTPUT -p icmp -j ACCEPT

Imagen 33

Imagen 33. Archivo de configuración de iptables en Linux

Los comandos iniciales realizan las siguientes operaciones:

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

Si requiere incluir algún servicio adicional, como por ejemplo un servidor http que tenga en el servidor incluya los comandos adicionales:

iptables -A INPUT -p TCP -dport 80 -d IPSERVIDOR -m state -state NEW -j ACCEPT

3. Otorgue los permisos requeridos para la ejecución del script, mediante el comando chmod así:

chmod +x cierrePuertos.sh

Imagen 34
 

Imagen 34. Permisos requeridos para permisos de iptables en Linux

4. Ejecute el script mediante el comando ./cierrePuertos.sh.

Nota: Este script cierra las conexiones realizadas de forma externa, por lo que su ejecución debe realizarse directamente en el servidor.

Imagen 35
 

Imagen 35. Cierre de puertos de iptables en Linux

5. Verifique que las nuevas reglas se encuentran activas en el servidor de iptables, mediante el comando “iptables -L”:

Imagen 36
 

Imagen 36. Verificación de cierre de puertos de iptables en Linux

7.2.6 Verificación de apertura de los puertos.

A continuación debe realizar la verificación de la adecuada apertura de los puertos mediante port-knocking, de acuerdo con cada uno de los ambientes del cliente que se utiliza:

Ambiente cliente en Linux

1. Intente acceder al servidor desde el cliente en Linux configurado previamente mediante el comando ssh (para el ejemplo la ip es 192.168.1.79):

ssh root@<ip>

Imagen 37
 

Imagen 37. Acceso ssh bloqueado en Linux

Observara que el comando ssh nunca permite indicar las credenciales para el acceso al servidor.

2. Ejecute el comando de apertura del puerto utilizando la misma secuencia de puertos utilizada anteriormente en la configuración (para el ejemplo 9000 8000 7000), esto se hace sobre la máquina que tiene configurado el knockd (para el ejemplo 192.168.1.79) así:

knock -v 192.168.1.79 9000 8000 7000

Imagen 38
 

Imagen 38. Port-knocking de apertura de puertos en Linux

3. Intente acceder nuevamente al servidor desde el cliente en Linux configurado previamente mediante el comando ssh (para el ejemplo la ip es 192.168.1.79):

ssh root@<ip>

Imagen 39
 

Imagen 39. Acceso permitido para ssh en Linux

Observara que el comando ssh permite indicar las credenciales para el acceso al servidor.

Ambiente Windows

1. Para iniciar es necesario asegurar la conexión al servidor, para ello utilice un cliente ssh en Windows, se sugiere utilizar putty que se encuentra disponible en:

http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html

Asegurarse de bajar putty<version>-installer.exe

2. Cree una sesión en putty para acceder al servidor:

Imagen 40
 

Imagen 40. Crear sesión en putty

3. Intente acceder al servidor desde putty:

Imagen 41
 

Imagen 41. Acceso ssh bloqueado en Windows

Observara que el comando ssh nunca permite indicar las credenciales para el acceso al servidor y obtiene un error de conexión.

4. Ejecute el comando de apertura del puerto utilizando la misma secuencia de puertos utilizada anteriormente en la configuración (para el ejemplo 9000 8000 7000), esto se hace sobre la máquina que tiene configurado el knockd (para el ejemplo 192.168.1.79) así:

knock -v 192.168.1.79 9000 8000 7000

Imagen 42
 

Imagen 42. Port-knocking de apertura de puertos en Windows

5. Intente acceder nuevamente al servidor desde putty:

Imagen 43
 

Imagen 43. Acceso permitido para ssh en Linux

Observara que el comando ssh permite indicar las credenciales para el acceso al servidor.

7.2.7 Verificación de cierre de los puertos

A continuación debe realizar la verificación del adecuado cierre de los puertos mediante port-knocking, de acuerdo con cada uno de los ambientes del cliente que se utiliza:

Ambiente cliente en Linux

1. Ejecute el comando de cierre del puerto utilizando la misma secuencia de puertos utilizada anteriormente en la configuración (para el ejemplo 7000 8000 9000), esto se hace sobre la máquina que tiene configurado el knockd (para el ejemplo 192.168.1.79) así:

knock -v 192.168.1.79 7000 8000 9000

Imagen 44
 

Imagen 44. Port-knocking de cierre de puertos en Linux

2. Intente acceder al servidor desde el cliente en Linux configurado previamente mediante el comando ssh (para el ejemplo la ip es 192.168.1.79):

ssh root@<ip>

Imagen 45
 

Imagen 45. Acceso ssh bloqueado en Linux

Observara que el comando ssh nunca permite indicar las credenciales para el acceso al servidor.

Ambiente Windows

1. Ejecute el comando de cierre del puerto utilizando la misma secuencia de puertos utilizada anteriormente en la configuración (para el ejemplo 7000 8000 9000), esto se hace sobre la máquina que tiene configurado el knockd (para el ejemplo 192.168.1.79) así:

knock -v 192.168.1.79 7000 8000 9000

Imagen 46
 

Imagen 46. Port-knocking de cierre de puertos en Windows

2. Intente acceder al servidor desde putty con la sesión previamente creada:

Imagen 47
 

Imagen 47. Acceso ssh bloqueado en Windows

Observará que el comando ssh nunca permite indicar las credenciales para el acceso al servidor y obtiene un error de conexión.

7.2.8 Persistir configuración de iptables.

Es necesario que las operaciones realizadas previamente sobre el firewall queden de manera definitiva, para ello debe realizar los siguientes pasos:

1. Ingrese al servidor de port-knocking y persista la configuración del servidor iptables ejecutando los siguientes comandos:

service iptables save
service iptables restart

Imagen 48
 

Imagen 48. Persistir configuración de iptables

2. Verifique la configuración del servidor utilizando iptables:

lptables -L

Imagen 49
 

Imagen 49. Verificar configuración final de iptables

7.2.9 Configuración en el inicio del servidor de portknocking.

1. Para asegurar que el servidor de port-knocking se ejecute al reiniciar el servidor realice los siguientes comandos:

cd /etc/rcS.d
ln -s ../init.d/knockd S99knockd

Imagen 50
 

Imagen 50. Configuración inicio servicio port knocking

7.3 Instalación y configuración de ssh.

Mediante ssh y particularmente con scp se realizará la transferencia de los archivos soporte de las PQR al servidor de la SIC, de tal manera que se utilicen certificados digitales para la autenticación con el sistema, para permitir esto debe realizar los siguientes pasos:

1. Debe crear un usuario específico para la transferencia de archivos hacia la SIC y colocar una contraseña. Para ello debe ejecutar los siguientes comandos en el servidor, indicando que para el ejemplo se está creando el usuario filesuser:

adduser filesuser
passwd filesuser

Imagen 51
 

Imagen 51. Creación de usuario para transferencia en Linux

Nota: No se recomienda que la transferencia se haga con el usuario root ya que tendría acceso al sistema operativo

Tenga en cuenta que todos los archivos deben ser publicados en una ruta vinculada con este usuario.

2. Posteriormente debe ingresar con el usuario creado en el paso anterior, ubicarse en la carpeta home y crear la carpeta .ssh con los permisos adecuados, es indispensable que los permisos de ésta carpeta sean únicamente para el usuario creado, ya que de otra manera no funcionará adecuadamente la conexión ssh.

Para realizar la actividad indicada debe ejecutar los siguientes comandos:

mkdir .ssh
chmod 700 .ssh
cd .ssh

Imagen 52
 

Imagen 52. Creación de directorio .ssh en Linux

3. Adicionalmente debe crear el archivo authorized_keys, el cual contiene las llaves públicas permitidas para el acceso desde un cliente externo hacia el servidor, es indispensable que los permisos del archivo sean únicamente para el usuario creado, ya que de otra manera no funcionará adecuadamente la conexión ssh.

Para realizar la actividad indicada debe ejecutar los siguientes comandos:

touch authorized_keys
chmod 600 authorized_keys

Imagen 53
 

Imagen 53. Creación de archivo de llaves públicas en Linux

4. Debe agregar la llave pública entregada por la SIC al archivo creado en el paso anterior, para el ejemplo la llave entregada por la SIC corresponde a id_rsa.pub. El archivo debe ser descargado al servidor en la cuenta del usuario creado en el paso 1.

Para realizar la actividad indicada debe ejecutar el siguiente comando:

cat ../id_rsa.pub>> authorized_keys

Imagen 54
 

Imagen 54. Adición de llave pública de SIC en Linux

5. Para verificar la adecuada adición de la llave, observe el contenido del archivo authorized_keys y deberá encontrar el contenido del archivo de la llave pública entregada por la SIC.

Para realizar la actividad indicada debe ejecutar el siguiente comando:

cat authorized_keys

Imagen 55
 

Imagen 55. Verificar llave pública de SIC en Linux

6. Para verificar la adecuada configuración de la llave pública debe comunicarse con la SIC, solicitando realizar una prueba en la cual se debe asegurar que tenga acceso a la cuenta utilizando certificados digitales y no una contraseña específica. Para ello debe informar a la SIC el usuario creado en el paso 1 únicamente, no debe informar la contraseña asignada.

8 Configuración servidor de archivos en Windows.

En esta sección se detallan los aspectos requeridos para la instalación del servidor de archivos en ambiente Windows.

8.1 Requerimientos de hardware y software.

A continuación se detallan los requisitos de hardware y de software del servidor de archivos.

8.1.1 Hardware

Tabla 13. Hardware recomendado servidor de archivos

ServidorHardware
Sistema de archivosCaracterísticas físicas mínimas
Plataforma de 64 Bits
Procesador a 2.0 GHz o más, dual core o superior 4 GB memoria
500GB de almacenamiento (esto es dependiente de la cantidad de archivos almacenados)
Características de red
Requiere de IP pública

8.1.2 Software

Tabla 14. Software base requerido ambiente Windows

ServidorSoftware base requerido
Sistema de archivosSistema Operativo Windows Server 2003, 2008 R2 Standard o superior

8.1.3 Costos aproximados

Componente de HardwareCaracterísticasValor
Servidor de AplicacionesPlataforma de 64 Bits
Procesador Intel Xeon (6-Core) E5-2603v3 - 1.6GHz, 15MB L3
Memoria RAM: Estándar 8GB (1x8GB) DDR4 RDIMM Discos Duro 2TB HDD
$ 3.000.000 COP
Componente de SoftwareCaracterísticasValor
Sistema Operativo Windows Server 2012Licencia Windows Server 2012$ 909.000 COP
Bitvise SSH ServerPrograma bajo Licencia Estándar tipo Site License.
Permite acceder a la aplicación de forma remota utilizando un protocolo seguro de comunicación.
Para más información consulte:
https://www.bitvise.com/large-scale#site
US$ 10
Sha256sumSoftware libre
Permite generar el hash SHA256 de cualquier archivo por línea de comandos
$ 0
WinpcapSoftware Libre
Librerías base para el acceso de los paquetes en la tarjeta de red
$ 0
PythonSoftware Libre
Librería del lenguaje de programación interpretado Python
$ 0
MsvcrSoftware Libre
Librerías de ejecución de C de Microsoft
$ 0
PcapySoftware Libre
Es un módulo que extiende Python para hacer uso de la librería winpcap
$ 0
PypkSoftware Libre
Py-port knocking Project, es la implementación específica de portknocking para Windows
$ 0
Total inversión (valor aproximado)$ 3.938.950

8.2 Instalación y configuración de ssh

Software requeridoDescripción
Bitvise SSH ServerPrograma que permite acceder a la aplicación de forma remota utilizando un protocolo seguro de comunicación
Sha256sumPermite generar el hash SHA256 de cualquier archivo por línea de comandos.

Mediante ssh y particularmente con scp se realizará la transferencia de los archivos soporte de las PQRS al servidor de la SIC, de tal manera que se utilicen certificados digitales para la autenticación con el servicio de radicación de apelaciones de la SIC, para permitir esto debe realizar los siguientes pasos, teniendo en cuenta que para el caso de Windows es necesario instalar inicialmente el servidor SSH previo a la instalación de port knocking.

1. Descargar el servidor SSH para Windows denominado BitVise, de la URL http://www.bitvise.com/download-area, asegúrese de bajar el servidor ssh tal como lo muestra la siguiente imagen:

Imagen 56
 

Imagen 56. Página inicial de descarga de bitvise

Seleccione el instalador de SSH disponible en la página:

Imagen 57
 

Imagen 57. Seleccionar instalador de Bitvise

2. Ejecute el instalador que se descargó en el paso anterior (como usuario administrador), por ejemplo BvSshServer-Inst.exe:

Imagen 58
 

Imagen 58. Instalador de Bitvise

3. Al iniciar el instalador se le solicitará validar la fuente:

4.

Imagen 59
 

Imagen 59. Validar fuente de Bitvise

5. Se mostrará la pantalla inicial de la instalación, acepte la licencia de la aplicación, seleccione la opción de instalar un nuevo servidor SSH indicando “lnstall net Bitvise SSH Server Site” y la subopción “lnstall new default site (Bitvise SSH Server), no cambie el directorio de instalación, seleccione la opción de “Run Bitvise SSH Server Control Panel when done” y presione el botón “lnstall”:

Imagen 60
 

Imagen 60. Opciones de instalación de Bitvise

2. Seleccione el tipo de edición a instalar, tenga en cuenta que para ambiente de pruebas se puede utilizar “Personal Edition” (incluyendo los datos específicos primer nombre, segundo nombre y apellido), pero para ambiente de producción debe realizar la compra del producto es por ello que para ese ambiente debe seleccionar “Standard Edition”:

Imagen 61
 

Imagen 61. Tipo de instalación de Bitvise

3. Se iniciará la instalación de Bitvise, al finalizar se mostrará la terminación adecuada, para finalizar simplemente presione el botón “Aceptar”:

Imagen 62
 

Imagen 62. Fin de instalación de Bitvise

4. Inicialmente abra el puerto 22 para todos los computadores, para poder realizar la prueba inicial, para ello en “Open Windows Firewall” seleccione la opción “Open port(s) to any computer”:

Imagen 63
 

Imagen 63. Abrir puerto del firewall en Bitvise

5. Las demás opciones inicialmente debe dejarlas con los valores por defecto, presione el botón “Save changes”.

6. Posteriormente debe indicar almacenar la configuración e iniciar el servidor:

Imagen 64
 

Imagen 64. Persistir la configuración en Bitvise

7. El servidor de bitvise debe iniciar adecuadamente y mostrar la siguiente pantalla:

Imagen 65
 

Imagen 65. Inicio del servidor de Bitvise

8. Para realizar la prueba es necesario asegurar la conexión al servidor desde un computador diferente, para ello utilice un cliente ssh en Windows, se sugiere utilizar putty que se encuentra disponible en:

http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html

Asegurarse de bajar putty<version>-installer.exe

9. Cree una sesión en putty para acceder al servidor: y presione el botón “Open”:

Imagen 66
 

Imagen 66. Creación de sesión en putty

10. Se le solicitará validar la firma que identifica el servidor, simplemente presione el botón “Sí”:

Imagen 67
 

Imagen 67. Validación de llave en putty

11. Se iniciará la sesión SSH en el servidor:

Imagen 68
 

Imagen 68. Inicio de sesión en putty

Con este paso verificará la adecuada conexión al servidor SSH en Windows.

12. Con el fin de permitir la autenticación con llaves, es necesario reiniciar el servidor.

13. Una vez reinicie el servidor abra el Bitvise SSH Server control panel, que fue instalado por el software:

Imagen 69
 

Imagen 69. Abrir control panel de Bitvise

14. A continuación debe indicar la configuración básica para ello presione el botón

“Open easy settings”:

Imagen 70

Imagen 70. Control panel de Bitvise

15. Seleccione posteriormente la sección de cuentas virtuales presionando el botón “Virtual accounts”:

Imagen 71

Imagen 71. Cuentas virtuales en Bitvise

16. Adicione una cuenta virtual presionando el botón “Add”:

17.

Imagen 72

Imagen 72. Adicionar cuenta virtual en Bitvise

18. Agregue un nuevo usuario, para el ejemplo se denominará “pruebaSSH” con el cual se intercambiará la información de los anexos con la SIC, debe informar el nombre del usuario utilizado a la SIC. Igualmente debe darle acceso por terminal seleccionando la opción “Allow file transfer”.

19. Configurar la opción Command Prompt para el tipo Shell Access type, al momento de crear el usuario virtual, tal y como se muestra en la siguiente imagen:

Imagen 73

Imagen 73. Datos iniciales de la cuenta virtual en Bitvise

20. Agregue la llave pública enviada por la SIC, para ello haga click en el enlace “Public keys” indicado previamente, posteriormente importe la llave presionando el botón “Import”:

Imagen 74

Imagen 74. Importar llave pública en la cuenta virtual en Bitvise

21. Seleccione el archivo que descargo de la llave pública, para el ejemplo se denominará llave publica:

Imagen 75
Imagen 75
 

Imagen 75. Seleccionar archivo de llave pública de la cuenta virtual en Bitvise

22. Al abrir el archivo se debe importar la llave y debe observar los datos de ella en la ventana de llaves del servidor:

Imagen 76
 

Imagen 76. Resultado de la importación de la llave pública en Bitvise

23. Presione el botón close para continuar con la configuración de la cuenta virtual.

24. En la opción “Virtual filesystem layout” seleccione la opción “Limit to root directory”, indique una ruta específica que es donde se alojarán los archivos (allí se colocará el zip) de los archivos anexos, configurar la opción Root directory en la carpeta BvSsh_VirtualUsers ubicada en la ruta C:\<USERS_WINDOWS>\BvSsh_VirtualUsers (esta carpeta se crea automáticamente en Windows al momento de instalar el servidor BitVise SSH.). En dicha carpeta se colocaran los archivos a transferir.

Imagen 77
 

Imagen 77. Datos carpeta archivos de la cuenta virtual en Bitvise

25. Presione el botón “OK” para agregar la cuenta virtual creada.

26. Presione el botón “Save changes” para guardar los cambios sobre las cuentas virtuales.

Imagen 78
 

Imagen 78. Guardar la cuenta virtual en Bitvise

27. Descargar la herramienta sha256sum.exe de la siguiente url http://www.labtestproject.com/using_windows/step_by_step_using_sha256sum_on_windows_xp.html y colocar dicho archivo en la carpeta BvSsh_VirtualUsers ubicada en la ruta C:\<USERS_WINDOWS>\BvSsh_VirtualUsers. El propósito de dicha operación es generar el hash asociado al archivo mediante sha256 mediante la herramienta sha256sum.exe independientemente del sistema operativo Windows instalado.

Imagen 79
 

Imagen 79. Descarga de la herramienta sha256Sum.exe

Para verificar la adecuada configuración de la llave pública debe comunicarse con la SIC, solicitando realizar una prueba en la cual se debe asegurar que tenga acceso a la cuenta utilizando certificados digitales y no una contraseña específica.

8.3 Instalación y configuración de port-knocking.

Para la instalación de port knocking en Windows es necesario realizar la instalación del siguiente software que no hace parte de la instalación base del sistema operativo:

Tabla 15. Software requerido portknocking ambiente Windows

SoftwareVersiónDescripción
Winpcap4.1.3Librerías base para el acceso de los paquetes en la tarjeta de red
Python2.5.4.Librería del lenguaje de programación interpretado Python
msvcr7.1Librerías de ejecución de C de Microsoft
Pcapy0.10.8.Es un módulo que extiende Python para hacer uso de la librería winpcap
pypk0.2Py-port knocking Project, es la implementación específica de portknocking para Windows

En los siguientes numerales se indicarán cada uno de los pasos que permiten realizar la instalación y verificación del servidor de port knocking en Windows con clientes en Windows, teniendo en cuenta el software indicado previamente.

8.3.1 Instalación de winpcap.

1. Descargar el software Winpcap de la URL http://www.winpcap.org, tenga en cuenta que la versión a descargar debe ser la versión 4.1.X, actualmente la versión disponible es la 4.1.3.

Imagen 80
 

Imagen 80. Página principal de winpcap

2. Ejecute el instalador que se descarga en el paso anterior, por ejemplo WinPcap_4_1_3.exe:

Imagen 81
 

Imagen 81. Instalador de winpcap

3. Al iniciar el instalador se le solicitará validar la fuente:

Imagen 82
 

Imagen 82. Validar fuente de winpcap

4. Se mostrará la pantalla inicial de la instalación, simplemente presione el botón “Next”:

Imagen 83
 

Imagen 83. Pantalla inicial de instalación de winpcap

5. Acepte la licencia de instalación de WinPCap, presionando el botón “I Agree”:

Imagen 84
 

Imagen 84. Aceptar licencia de instalación de winpcap

6. Posteriormente se le indicará que si debe iniciar winpcap al iniciar el servidor, indique que sí, seleccionando la opción “Automatically start de WinPCap driver at boot time”:

Imagen 85
 

Imagen 85. Iniciar winpcap al iniciar el servidor

7. Finalice la instalación de winpcap presionando el botón “Finish”:

Imagen 86
 

Imagen 86. Finalizar instalación de winpcap

8.3.2 Instalación de Python.

1. Descargar el software de Python de la URL http://www.python.org/download/releases/2.5.4/, tenga en cuenta que la versión a descargar debe ser la 2.5.4 exactamente, ya que de otra manera no funcionará adecuadamente el software de port knocking para Windows que se instalará posteriormente.

Imagen 87
 

Imagen 87. Página principal de descarga de python

2. Ejecute el instalador que se descarga en el paso anterior, por ejemplo python- 2.5.4.exe:

Imagen 88
 

Imagen 88. Instalador de python

3. Al iniciar el instalador se le solicitará validar la fuente:

Imagen 89
 

Imagen 89. Validar fuente de python

4. Se mostrará la pantalla inicial de la instalación, simplemente seleccione “lnstall for all users” y presione el botón “Next”:

Imagen 90
 

Imagen 90. Pantalla inicial de instalación de python

5. Seleccione la ruta de instalación de Python, se recomienda que no la cambie de la opción por defecto c:\python25\

Imagen 91
 

Imagen 91. Ruta de instalación de python

6. Posteriormente se le indicará definir los componentes a instalar, no cambie ninguno de ellos, presione el botón “Next” para continuar:

Imagen 92
 

Imagen 92. Ruta de instalación de Python

7. Finalice la instalación de Python, presionando el botón “Finish”:

Imagen 93
 

Imagen 93. Finalizar instalación de python

8. Posteriormente debe configurar a Python para que pueda ser llamado desde la línea de comandos, para ello presione el botón de Windows, haga click con el botón derecho del mouse en Equipo y seleccione la opción propiedades:

Imagen 94
 

Imagen 94. Seleccionar propiedades del equipo en Windows

9. Seleccione posteriormente la opción “Configuración avanzada del sistema”:

Imagen 95
 

Imagen 95. Configuración avanzada del equipo en Windows

10. Ingresa a las variables de entorno del sistema presionando el botón con el mismo nombre:

Imagen 96
 

Imagen 96. Variables de entorno en Windows

11. Cree una nueva variable de entorno presionando el botón “Nueva”:

Imagen 97
 

Imagen 97. Crear nueva variable de entorno en Windows

12. Defina una nueva variable de entorno denominada PYTHON_HOME con el valor de la ruta de instalación (c:\Python25) y presione el botón “Aceptar”:

Imagen 98
 

Figura 98. Definir variable de entorno PYTHON_HOME

13. Posteriormente edite la variable de entorno Path, seleccionándola de la lista y presionando el botón “Editar”:

Imagen 99
 

Imagen 99. Editar variable Path

14. Agregue al comienzo de la variable la siguiente cadena y presione el botón “Aceptar”:

%PYTHON_HOME%;

Imagen 100
 

Imagen 100. Agregar PYTHON_HOME al Path

15. Para terminar la configuración de la variable de entorno presione el botón “Aceptar”:

Imagen 101

Imagen 101. Terminar configuración de variables de entorno

16. Para verificar la adecuada configuración de Python, inicie un “Símbolo del Sistema” en Windows:

Imagen 102
 

Imagen 102. Iniciar símbolo de sistema en Windows

17. En el símbolo de sistema, escriba python a lo cual debe ejecutar el intérprete del lenguaje, para salir presione las teclas Control y Z, si esto no sucede verifica la configuración de la variable de entorno:

Imagen 103
 

Imagen 103. Verificar configuración de Python en Windows

8.3.3 Instalación de pcapy

1. Descargar la librería de Visual C (msvcr71.dll) de la URL http://es.dll-files.com/msvcr71.dll.html:

Imagen 104

Imagen 104. Descargar librería msvcr71.dll

2. Posteriormente seleccione el archivo zip de la librería descargada:

3.

Imagen 105

Imagen 105. Librería msvcr71.dll

4. Descomprima el archivo utilizando winrar (www.winrar.es) o cualquier software que lo permita sobre la misma carpeta:

Imagen 106

Imagen 106. Extraer librería msvcr71.dll

Asegurarse que el archivo msvcr71.dll existe al realizar la acción anterior:

Imagen 107
 

Imagen 107. Verificar librería msvcr71.dll

5. Descargar el software de pcapy de la URL http://corelabs.coresecurity.com/index.php?module=Wiki&action=view&type=tool&name=Pcapy, tenga en cuenta que la versión a descargar debe ser la 0.10.8 exactamente, ya que de otra manera no funcionará adecuadamente el software de port knocking para Windows que se instalará posteriormente.

Imagen 108
 

Imagen 108. Página principal de descarga de pcapy

6. Ejecute el instalador que se descarga en el paso anterior, por ejemplo pcapy- 0.10.8.win32-py2.5.exe:

Imagen 109
 

Imagen 109. Instalador de Python

Asegurarse que el archivo de instalación de pcapy se encuentra en el mismo directorio de la librería msvcr71.dll.

7. Al iniciar el instalador se le solicitará validar la fuente:

Imagen 110
 

Imagen 110. Validar fuente de pcapy

8. Se mostrará la pantalla inicial de la instalación, simplemente presione el botón “Siguiente”:

9.

Imagen 111
 

Imagen 111. Iniciar instalación de pcapy

10. A continuación se mostrará la ruta de instalación de Python y de la librería de pcapy:

Imagen 112
 

Imagen 112. Directorio de instalación de pcapy

11. Se mostrará la pantalla para iniciar la instalación de pcapy:

Imagen 113
 

Imagen 113. Comenzar la instalación de pcapy

12. Para finalizar la instalación de pcapy presione el botón “Finalizar”:

Imagen 114
 

Imagen 114. Finalizar instalación de pcapy

8.3.4 Instalación de Python port knocking.

1. Descargar el software de Py-port knocking Project de la URL, http://billiejoex.altervista.org/Prj_Py_port_knock.htm. Asegurarse de descargar la versión 0.2 (código fuente NO los instaladores binarios).

2.

Imagen 115

Imagen 115. Descargar pypk

3. Posteriormente seleccione el archivo pypk_v0.2.tar.gz descargado previamente:

Imagen 116

Imagen 116. Seleccionar pypk para descomprimir

4. Descomprima el archivo utilizando winrar (www.winrar.es) sobre la misma carpeta:

Imagen 117

Imagen 117. Extraer pypk

5. Al descomprimir se creará la carpeta [src]-pypk_v0.2, observe el contenido de la carpeta:

Imagen 118
 

Imagen 118. Resultado al descomprimir pypk

6. Seleccione todo el contenido de la carpeta anterior:

Imagen 119

Imagen 119. Contenido código fuente pypk

7. Cree una carpeta denominada knockd en la raíz del directorio c:\ como lo muestra la siguiente imagen:

Imagen 120

Imagen 120. Crear carpeta knockd

8. Pegar el contenido seleccionado en el paso 5 al interior de la carpeta knockd:

Imagen 121

Imagen 121. Pegar contenido código fuente pypk

8.3.5 Configuración inicial.

1. Observe el contenido de la carpeta pypk, en el encontrará un archivo con el nombre knockd.conf como lo muestra la siguiente figura:

Imagen 122

Imagen 122. Contenido archivo knock.conf en WIndows

2. Reemplace el contenido del archivo teniendo en cuenta las siguientes consideraciones para cada uno de los parámetros:

a. Interface: Este parámetro define la tarjeta de red que se tendrá en cuenta para realizar la lectura de paquetes.

b. Timeout: Este parámetro define el tiempo máximo que se espera para completar la secuencia anterior en segundos.

c. Logfile: Este parámetro define la ubicación del archivo de log de la aplicación.

d. En la sección openSSH:

i. sequence: Este parámetro define la secuencia de puertos que debe realizar el cliente knocking para la apertura del puerto. Estos puertos se deben modificar pero es indispensable informar a la SIC cual fue la secuencia seleccionada.

ii. Command: Este parámetro define el comando de netsh requerido para la apertura del puerto de ssh que el para el caso particular es el 22.

e. En la sección closeSSH:

i. sequence: Este parámetro define la secuencia de puertos que debe realizar el cliente knocking para cerrar el puerto SSH. Estos puertos se deben modificar pero es indispensable informar a la SIC cual fue la secuencia seleccionada.

ii. Command: Este parámetro define el comando de netsh requerido para la apertura del puerto de ssh que el para el caso particular es el 22.

A continuación se muestra el ejemplo para la secuencia de apertura 5100, 5200 y 5300, y, la secuencia de cierre 7500, 7600 y 7700:

# knockd.conf
# ...configuration file used by py-port knock daemon.

# Default ethernet interface on which knockd listens on.
# Special argument “all” can be used to run knockd on all
# interfaces.
interface=all

# Log file location.
logfile=knockd.log

# Sequence timeout: time within sequences have to take place.
timeout=3

# Sequences:
# - All lines beginning with “[“ character are considered
# sequences.
# - Every sequence must have at least two entries:
# “sequence=<seq>“ and “command=<cmd>”.
# - The special keyword argument “%1P%” usable in “command”
# statement is referred to knocker's 1P source address and
# it will be automatically translated by knockd at run time.
# - 1f “keep_count=<seq>“ option is used inside [current_seq]
# statement knockd will execute [current_seq]'s command for
# every time <seq> is being satisfied in the past, or at least
# just one time if <seq> has been never satisfied before.
# - Other sets of sequences can be optionally declared depending
# on the number of service you want to protect.

[open SSH] sequence=5100,5200,5300
command=netsh firewall add portopening protocol=TCP port=22 name=SSH mode=ENABLE scope=CUSTOM addresses=%1P%

[close SSH]
sequence=7500,7600,7700
command=netsh firewall delete portopening protocol=TCP port=22

# A script (batch, python, perl, etc...} could also be used:
#[Open service]
#sequence=42100,22521,3250,2544,33123
#command=C:\scripts\my_script.bat

#[Close service]
#sequence=15000,15635,14254,13555
#command=C:\Python24\python.exe C:\scripts\my_script.py

5. Iniciar el servidor de port-knocking de Python, abriendo una línea de comandos de Windows, ubicándose en la carpeta c:\knockd\pypk con los siguientes comandos:

cd c:\knockd\pypk
python knockd.py

Imagen 123
 

Imagen 123. Inicio del servidor de port-knocking en Windows

8.3.6 Cierre de puerto SSH.

Posteriormente debe asegurarse que el puerto SSH se encuentre cerrado, para ello debe eliminar la regla del firewall y realizar una prueba inicial, para ello haga los siguientes pasos.

1. En el servidor abra el control panel del sistema operativo.

Imagen 124
 

Imagen 124. Abrir control panel en Windows

2. Seleccione la opción de “Comprobar el estado del firewall”:

Imagen 125
 

Imagen 125. Configuración del firewall en Windows

3. Seleccione la opción de “Configuración avanzada”.

Imagen 126
Imagen 126
 

Imagen 126. Seleccionar configuración avanzada del firewall en Windows

4. Seleccione la opción de “Reglas de entrada”:

Imagen 127

Imagen 127. Reglas de entrada del firewall en Windows

5. Busque la regla que tiene el nombre “Bitvise SSH Server (TCP 22) y elimínela.

Imagen 128
 

Imagen 128. Eliminar regla del servidor de Bitvise en Windows

6. Posteriormente se recomienda agregar un nuevo usuario al servidor Bitvise SSH server a través del control panel tal como lo hizo previamente en los pasos 14 a 16 de la sección 4.2, con usuario, password, acceso de terminal y acceso total de archivos tal como aparece en la siguiente imagen:

7.

Imagen 129
 

Imagen 129. Creación del usuario de prueba en Bitvise

8. Posteriormente intente acceder desde un equipo diferente al mismo servidor tal como lo hizo en el paso 9 de la sección 4.2, al intentar acceder con putty observará que no tendrá acceso al servidor.

Imagen 130
 

Imagen 130. Acceso denegado al servidor Bitvise mediante PuTTY

8.3.7 Verificar apertura inicial de puerto mediante un cliente.

Para asegurar el adecuado funcionamiento de la aplicación realizando una simulación del port-knocking, para ello realicé los siguientes pasos en un cliente de acuerdo con el ambiente en que se desee realizar la verificación:

1. Descargue el cliente de portknocking en un equipo diferente al servidor, para el caso particular se utilizará el cliente de knockd que se encuentra en: http://www.zeroflux.org/projects/knock

2. Busque el cliente para Windows que aparece como “Native Win32Client”:

Imagen 131
 

Imagen 131. Descarga del cliente de port-knocking para Windows

3. Descomprima el archivo knock-win32.zip.

4. Inicie un “Símbolo del sistema” en Windows.

Imagen 132
 

Imagen 132. Ejecución de “Símbolo del sistema” en Windows

5. Ubíquese en la carpeta donde descomprimió el archivo, para el ejemplo corresponde al directorio de descargas del usuario mediante el comando cd<carpeta>:

Imagen 133
 

Imagen 133. Carpeta de descarga del cliente de port-knocking en Windows

6. Ubíquese en la siguiente subcarpeta donde se descomprime el cliente, basado en knock-win32, correspondiente a knock-win32\knock-win32-port\Release, mediante el comando cd:

Imagen 134
 

Imagen 134. Carpeta del cliente de port-knocking en Windows

7. Ejecute el comando de apertura del puerto utilizando la misma secuencia de puertos utilizada anteriormente en la configuración (para el ejemplo 5100, 5200, 5300), esto se hace sobre la máquina que tiene configurado el knockd (para el ejemplo 192.168.1.88) así:

knock -v 192.168.1.88 5100 5200 5300

Imagen 135
 

Imagen 135. Port-knocking desde el cliente en Windows

Verificación en el servidor

Es necesario verificar la adecuada configuración del firewall para ello debe realizar los siguientes pasos:

1. Verifique en la consola del servidor, debe encontrar las frases openSSH, xxx.xxx.xxx.xxx:5100 OK!, xxx.xxx.xxx.xxx:5200 OK!. xxx.xxx.xxx.xxx:5300 OK!, xxx.xxx.xxx.xxx COMPLETE! y el comando netsh de apertura del puerto, como se observa en la siguiente figura:

Imagen 136
 

Imagen 136. Verificar correcto funcionamiento del servidor de portknocking en Windows

2. Adicionalmente verifique que netsh se configuró adecuadamente, al ver la configuración del firewall debe observar la apertura del puerto desde la máquina que realiza la conexión como cliente (para el ejemplo es 192.168.4.245), como lo muestra la siguiente figura:

Imagen 137
Imagen 137

Imagen 137. Verificar apertura de puerto del firewall en Windows

8.3.8 Verificación de apertura de los puertos con el cliente

A continuación debe realizar la verificación de la adecuada apertura de los puertos mediante port-knocking con el cliente:

1. Intente acceder al servidor desde PuTTY, utilizando el usuario de prueba creado previamente:

Imagen 138

Imagen 138. Acceso permitido para ssh en Windows

Observara que el comando ssh permite indicar las credenciales para el acceso al servidor.

Imagen 139

Imagen 139. Acceso ssh en Windows

8.3.9 Verificar cierre inicial de puerto mediante un cliente.

Para asegurar el adecuado funcionamiento de la aplicación realizando una simulación del port-knocking, para ello realicé los siguientes pasos en un cliente para realizar la verificación:

1. El siguiente paso es asegurar que se ejecuta adecuadamente el cierre del puerto de ssh. Para ello desde el “Símbolo del Sistema” en Windows ejecute el comando de cierre del puerto utilizando la misma secuencia utilizada anteriormente (para el ejemplo 7500 7600 7700), esto se hace sobre la máquina que tiene configurado el knockd (para el ejemplo 192.168.1.79) así:

knock -v 192.168.1.88 7500 7600 7700

Imagen 140
 

Imagen 140. Port-knocking de cierre desde el cliente en Windows

Verificación en el servidor

Es necesario verificar la adecuada configuración del firewall para ello debe realizar los siguientes pasos:

1. Verifique en la consola del servidor, debe encontrar las frases closeSSH, xxx.xxx.xxx.xxx:7500 OK!, xxx.xxx.xxx.xxx:7600 OK!. xxx.xxx.xxx.xxx:7700 OK!, xxx.xxx.xxx.xxx COMPLETE! y el comando netsh de cierre del puerto, como se observa en la siguiente figura:

Imagen 141

Imagen 141. Verificar cierre del servidor de portknocking en Windows

2. Adicionalmente verifique que netsh se configuró adecuadamente para el cierre del puerto, al ver la configuración del firewall debe observar que ya no se encuentra el puerto SSH, como lo muestra la siguiente figura:

3.

Imagen 142
Imagen 142

Imagen 142. Verificar apertura de puerto del firewall en Windows

8.3.10 Verificación de cierre de los puertos mediante un cliente.

A continuación debe realizar la verificación del adecuado cierre de los puertos mediante port-knocking:

1. Intente acceder al servidor desde PuTTY con la sesión previamente creada:

Imagen 143
 

Imagen 143. Acceso ssh bloqueado en Windows

Observara que el comando ssh nunca permite indicar las credenciales para el acceso al servidor y obtiene un error de conexión.

8.3.11 Eliminar cuenta virtual.

1. Para evitar acceso mediante la cuenta virtual creada previamente debe ingresar al control panel del servidor Bitvise y eliminar la cuenta creada previamente.

Imagen 144

Imagen 144. Eliminación de cuenta virtual de pruebas de Bitvise

9. Informes.

Para el total cumplimiento de las normas referentes al CUN, se debe remitir a esta superintendencia una información periódica y otra información al momento de finalizar la implementación de cada etapa. A continuación se presenta un cuadro con las características de cada informe.

Nombre del informeDestinatarioContenidoPeriodicidad
informe de resultados de las pruebas piloto de asignación del CUNSoporte CUN (soportecun@ sic.gov.co)• Fecha de realización de la Prueba.
• Casos a probar.
• Parámetros. (Parámetros de entrada requeridos para realizar la prueba)
• Persona(s) que realiza(n) la prueba.
• Datos del ambiente de Pruebas (motor base de datos, sistema operativo del servidor de aplicación y del servidor de base de datos).
• Resultado de la Prueba (Exitoso/No exitoso).
• Nombre y versión del sistema a probar. (Ej. Sistema PQR v.1.0)
Una vez terminada la implementación.
informes de avance sobre la ejecución de las actividades técnicas por parte de los operadores para implementar los mecanismos de consulta interactivaSoporte CUN (soportecun@ sic.gov.co)• Fecha generación del informe.
• Fecha inicial y final del periodo a reportar.
• Cronograma de actividades (actividad, descripción, fecha inicial, fecha final, porcentaje avance, resultado de la actividad).
Mensual durante la implementación.
informe de los resultados de las pruebas piloto de los mecanismos de consulta interactivaSoporte CUN (soportecun@ sic.gov.co)• Fecha de realización de la Prueba.
• Casos a probar.
• Parámetros.(Parámetros de entrada requeridos para realizar la prueba)
• Persona(s) que realiza(n) la prueba.
• Datos del ambiente de pruebas. (motor base de datos, sistema operativo del servidor de aplicación y del servidor de base de datos).
• Resultado de la prueba (exitoso/no exitoso).
• Nombre y versión del sistema a probar. (Ej. Consulta PQR v.1.0)
Una vez terminada la implementación.
informe de los resultados de las pruebas piloto de los mecanismos de reporte de expedientes de apelaciones ante la SICSoporte CUN (soportecun@ sic.gov.co)• Fecha de realización de la Prueba.
• Casos a probar.
• Parámetros. (Parámetros de entrada requeridos para realizar la prueba)
• Persona(s) que realiza(n) la prueba.
• Datos del ambiente de pruebas. (motor base de datos, sistema operativo del servidor de aplicación y del servidor de base de datos).
• Resultado de la prueba. (exitoso/no exitoso).
• Nombre y versión del sistema a probar. (Ej. Consulta PQR v.1.0)
Una vez terminada la implementación.

10 Valores de referencia

A continuación se describen los valores de referencia que deberán ser empleados por los operadores 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, están conforme al estándar definido para el lenguaje de intercambio de información por el Estado colombiano, para intercambiar información entre organizaciones, facilitando el entendimiento de los involucrados en los procesos de intercambio de información.

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 en el portal del lenguaje de intercambio de información del Mintic:

Tipo identificación nacional persona (Aplicación de uso: tipoIdNacionalPersona):

Tabla 16. Tipo identificación nacional persona

Código tipo identificación nacional persona alfanumérico 2Nombre tipo identificación nacional persona
RERegistro civil
TITarjeta identidad
CCCédula ciudadanía
CECédula extranjería
ASAdulto sin identificar
MSMenor sin identificar
RNRecién nacido
PAPasaporte
DEDocumento extranjero
CDCarné diplomático
NINúmero identificación tributaria
NDNo definido
TETarjeta de extranjería
ODOtro documento

Tipo TramitedelaSuperintendenciadeIndustriayComercio(Aplicacióndeuso: tipoTramiteSic):

Código tramiteNombre trámite
228Telefonía móvil celular
328Otros srvcios telecomunicaciones no domicilirias
383Telefonía fija
391Servicios postales

Estado PQR CUN (Aplicación de uso: estadoPqrCun): 

Codigo estado
PQR CUN
Estado PQR CUN
1Traslado a operador competente
2Traslado a la sic para resolver recurso de apelación
3Resuelto
4Acumulado con el cun
5Anulado
6Análisis por parte del operador
7Análisis por parte de la sic
8Etapa de pruebas que practica el operador
9Etapa de pruebas que practica la sic

11 Acuerdo de nivel de servicio.

Para recibir soporte técnico se establecen los siguientes canales de comunicación: Correo electrónico: soportecun@sic.gov.co

Teleconferencia: hangout de google, con la cuenta de soporte.

Manejo de errores

Error presentadoAcciónTiempo de respuesta
No se puede establecer comunicación con servicio de la SICInformar al área de soporte técnico de CUN mediante correo electrónico.1 día
Error de validación de datos enviados en el servicioEl servicio retorna un mensaje informando el error presentado.
No se acepta la solicitud.
Inmediato
Error de autenticaciónEl servicio retorna un mensaje informando el error presentado.
No se acepta la solicitud.
Inmediato
Error en transferencia de archivosEl servicio envía mensaje de correo electrónico a operador/proveedor y a área de soporte técnico de CUN.
No se acepta la solicitud.
Inmediato (Después de procesar la petición de transferencia n veces)
Error en radicación en la SICEl servicio envía mensaje a área de soporte técnico.
En este punto ya se han validado los datos y se ha realizado la transferencia de los archivos, por tanto se acepta la radicación con fecha de la solicitud.
0 a 2 días.

12 Glosario de términos.

• 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 operador, 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 dotas 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 preestablecida 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 llevara 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.

• BITVISE: Es un servidor SSH para Windows que implementa tanto el uso de ssh como de SCP en Windows.

• Firewall (Cortafuegos): Un cortafuegos es una parte de un sistema o una red que está diseñada para bloquear el acceso no autorizado, permitiendo al mismo tiempo comunicaciones autorizadas(9).

• IPTABLES: Son las tablas que provee el cortafuegos/firewall del kernel de Linux(10)

• LIBPCAP: Es una librería para la captura de paquetes en diferentes sistemas operativos(11).

• NETSH: Es una utilidad de línea de comandos que ofrece varias opciones para la configuración de una red en Windows(12).

• Portknocking: El golpeo de puertos (del inglés port knocking) es un mecanismo para abrir puertos externamente en un firewall mediante una secuencia preestablecida de intentos de conexión a puertos que se encuentran cerrados(13)

• PUTTY: PuTTY es un cliente SSH, Telnet, rlogin, y TCP raw con licencia libre(14).

• SCP: Secure Copy o SCP es un medio de transferencia segura de archivos informáticos entre un host local y otro remoto o entre dos hosts remotos, usando el protocolo Secure Shell (SSH)(15).

• SSH: (Secure SHell) es el nombre de un protocolo y del programa que lo implementa, y sirve para acceder a máquinas remotas a través de una red(16).

• URL: Hace referencia a una dirección virtual que representa la ubicación de un recurso.

1 https://es.wikipedia.org/wiki/Criptograf%C3%ADa_asim%C3%A9trica

2 http://co.redhat.com/

3 http://www.centos.org

4 http://www.debian.org/index.es.html

5 http://es.wikipedia.org/wiki/Glibc

6 http://sourceforge.net/projects/libpcap/

7 http://es.wikipedia.org/wiki/Netfilter/iptables

8 http://es.wikipedia.org/wiki/Ssh

9 Tomado de http://es.wikipedia.org/wiki/Cortafuegos_(inform%C3%A1tica)

10 Tomado de http://en.wikipedia.org/wiki/lptables

11 Tomado de http://es.wikipedia.org/wiki/Pcap_(interfaz)

12 Tomado de http://es.wikipedia.org/wiki/Netsh

13 Tomado de http://es.wikipedia.org/wiki/Golpeo_de_puertos

14 Tomado de http://es.wikipedia.org/wiki/Putty

15 Tomado de http://es.wikipedia.org/wiki/Secure_Copy

16 Tomado de http://es.wikipedia.org/wiki/Ssh