El Suministro deberá incluir todos aquellos ítems que no hubiesen sido expresamente indicados en la presente sección, pero que pueda inferirse razonablemente que son necesarios para satisfacer el requisito de suministro indicado, por lo tanto, dichos bienes serán suministrados por el Proveedor como si hubiesen sido expresamente mencionados, salvo disposición contraria en el Contrato.
Los bienes suministrados deberán ajustarse a las especificaciones técnicas y las normas estipuladas en este apartado. En caso de que no se haga referencia a una norma aplicable, la norma será aquella que resulte equivalente o superior a las normas oficiales de la República del Paraguay. Cualquier cambio de dichos códigos o normas durante la ejecución del contrato se aplicará solamente con la aprobación de la contratante y dicho cambio se regirá de conformidad a la cláusula de adendas y cambios.
El Proveedor tendrá derecho a rehusar responsabilidad por cualquier diseño, dato, plano, especificación u otro documento, o por cualquier modificación proporcionada o diseñada por o en nombre de la Contratante, mediante notificación a la misma de dicho rechazo.
Los productos a ser requeridos cuentan con las siguientes especificaciones técnicas:
GENERALIDADES:
De acuerdo a lo establecido en la Res. DNCP N° 1930/20 Por la cual se dispone la utilización del Sistema de Información de Contrataciones Públicas para la presentación y apertura de ofertas electrónicas en los procedimientos de contratación:
La adenda es el documento emitido por la convocante, mediante la cual se modifican aspectos establecidos en la convocatoria y/o en las bases de la licitación. La adenda será considerada parte integrante del documento cuyo contenido modifique.
La convocante podrá introducir modificaciones o enmiendas a los pliegos de bases y condiciones, siempre y cuando se ajuste a los parámetros establecidos en la Ley.
La convocante podrá prorrogar el plazo de presentación de ofertas a fin de dar a los posibles oferentes, un plazo razonable para que puedan tomar en cuenta la enmienda en la preparación de sus ofertas. Esta prórroga deberá quedar asentada en la adenda citada.
Las modificaciones al pliego de bases y condiciones serán autorizadas por el Gerente General del BCP, mediante adendas numeradas debidamente justificadas por el área técnica y/o otras instancias administrativas, y se darán a conocer a través del portal de la DNCP (www.contrataciones.gov.py).
La Unidad Operativa de Contratación, con el visto bueno del Gerente General, queda autorizada a modificar el contrato en cuanto a plazos, suscribiéndose la correspondiente Adenda. Cuando sea necesario modificar montos, dicha modificación deberá ser autorizada por acto administrativo de la máxima autoridad de la Institución (Directorio del BCP).
1. El Proveedor deberá suministrar todos los bienes o servicios de acuerdo con las condiciones establecidas en el pliego de bases y condiciones y sus adendas, así como en el Contrato y sus adendas.
2. El Proveedor será responsable de cualquier indemnización por daños causados en el marco de la ejecución del contrato por él o su personal a los funcionarios y/o a terceros, y/o a los bienes de éstos, y/o a los bienes o instalaciones o imagen reputacional de la Contratante; por causas imputables al mismo.
3. Responder por todo incumplimiento o consecuencia imputable al mismo, derivados de la incorrecta o incompleta ejecución de lo contratado.
4. Contratar y mantener el personal calificado necesario para la realización de los servicios requeridos. Cumplir con todas las leyes laborales y de Seguridad Social vigentes. Asumir todos los riesgos en los términos del Código del Trabajo vigente, liberando al BCP de cualquier responsabilidad al respecto.
5. Cumplir con todas las medidas de seguridad que se requieran respecto a su personal, a fin de evitar accidentes de trabajo durante la ejecución contractual.
6. El Proveedor deberá indemnizar y eximir de cualquier responsabilidad a la contratante y a sus empleados y funcionarios, por cualquier litigio, acción legal o procedimiento administrativo, reclamación, demanda, pérdida, daño, costo y gasto cualquiera sea su naturaleza, incluidos los honorarios y gastos de representación legal, en los cuales pueda incurrir la contratante como resultado de riesgos profesionales o muerte de los empleados del Proveedor, sea reclamado por el trabajador o sus causahabientes durante la vigencia del contrato. Como riesgos profesionales se entenderán los accidentes de trabajo y enfermedades profesionales. Se considerarán igualmente accidentes del trabajo los hechos constituidos por caso fortuito o fuerza mayor inherentes al trabajo que produzcan las mismas lesiones.
De acuerdo a lo indicado en la Sección Especificaciones técnicas y Suministros Requeridos, el personal del Proveedor deberá firmar un Compromiso de Confidencialidad de la Información en los términos del Formulario N° 7 de la Sección Formularios.
MODALIDAD DE CONTRATACIÓN
Contrato Cerrado
ESPECIFICACIONES TÉCNICAS
Las soluciones deben cumplir con las siguientes características:
|
ESPECIFICACIONES TÉCNICAS |
|||
|
Requisito |
Detalle y definiciones |
Cumple / No Cumple |
Evidencia técnica de cumplimiento en oferta (Especificar en qué documento incluido en la oferta se acredita) |
|
LOTE N° 1 CONTRATACIÓN DE SOLUCIÓN DE SEGURIDAD PARA ACCESOS PRIVILEGIADOS |
|||
|
1.1. Gestión de Accesos Privilegiados (PAM) |
|||
|
1.1. |
Marca y Modelo ofrecidos: |
|
|
|
1.1.1 Generalidades del Servicio |
|||
|
1.1.1.1 |
La solución propuesta deberá ser escalable mediante un diseño modular para adaptarse a crecimientos de utilización, inclusión de más plataformas o inclusión de esquemas de alta disponibilidad sin incurrir en licenciamiento adicional. |
|
|
|
1.1.1.2 |
La solución de Seguridad de Cuentas Privilegiadas debe ser una solución basada en software y debe estar disponible como SaaS o en modelo de suscripción para implementación en ambientes de Nube y/o instalable sobre entorno físico o virtualizado con infraestructura. |
|
|
|
1.1.1.3 |
Los elementos críticos de la solución, como Bóveda segura de credenciales, deben garantizar esquemas de alta disponibilidad, en caso de ser nube deben cumplir con SOC2, en caso de ser implementaciones On-Premises, Nubes Privadas o ambientes híbridos esta debe instalarse en alta disponibilidad, Satelite o al menos DR en cada una de las ubicaciones (sitio principal y sitio alterno, con sincronización entre sitios), asegurando que el proceso sea transparente para los usuarios conectados en caso de pérdida de comunicación y mecanismos para la recuperación ante desastres compatibles con soluciones de copia de seguridad y archivado disponibles en el mercado. |
|
|
|
1.1.1.4 |
El oferente debe incluir todo el hardware y software (licencias de sistemas operativos, aplicaciones de base) que sea necesario para el funcionamiento óptimo de la solución, mientras sea ofrecido el servicio. En el caso de requerirse de licencias Windows Server, estas serán provistas por el BCP a través de su contrato EA. La oferta debe incluir todas las actualizaciones disponibles del software provisto y el servicio de soporte técnico Premium del fabricante, al menos en formato 8x5, durante el periodo del contrato. |
|
|
|
1.1.2 Capacidades generales de la herramienta PAM |
|||
|
1.1.2.1 |
La solución propuesta debe ser capaz de administrar cuentas privilegiadas de al menos los siguientes Sistemas Operativos: Windows, Unix, Linux, MAC OS, ESX/ESXi, XenServers, Linux RedHat. |
|
|
|
1.1.2.2 |
La solución propuesta debe ser capaz de administrar cuentas privilegiadas de al menos las siguientes Bases de datos: Oracle, MSSQL, DB2, Postgresql. |
|
|
|
1.1.2.3 |
La solución propuesta debe ser capaz de administrar cuentas privilegiadas basadas en al menos los siguientes servicios de directorio: Microsoft, Azure AD. |
|
|
|
1.1.2.4 |
La solución propuesta debe ser capaz de administrar cuentas privilegiadas de dispositivos de red (Firewalls, Routers, Switches, APs, PBXs, NACs, Proxys). |
|
|
|
1.1.2.5 |
La solución propuesta debe ser capaz de administrar cuentas privilegiadas de dispositivos de Storage (almacenamiento), y permitir la conexión autologeada a cualquier Storage, sea administrado por interfaz web o sesiones SSH, no exponiendo la contraseña privilegiada. |
|
|
|
1.1.2.6
|
La solución propuesta debe ser capaz de administrar cuentas privilegiadas de Aplicaciones Cloud como Facebook, Google G Suite, Google Gmail, GitHub, Docker, Cloudflare, IBM Cloud, LinkedIn, Instagram, Twitter, Amazon, Azure, VMware, Office 365, Paloalto, RedHat. |
|
|
|
1.1.2.7 |
La solución propuesta debe ser capaz de administrar cuentas privilegiadas de Saas/websites/web interfaces. |
|
|
|
1.1.2.8 |
La solución propuesta debe ser capaz de administrar cuentas privilegiadas de redes sociales: Facebook, Instagram, Whatsapp, Linkedin, etc. |
|
|
|
1.1.2.9 |
La solución propuesta debe ser capaz de soportar cualquier dispositivo de red mediante conexión SSH. |
|
|
|
1.1.2.10 |
La solución propuesta debe ser capaz de soportar cualquier repositorio de datos mediante conexión ODBC. |
|
|
|
1.1.2.11 |
La solución propuesta debe ser capaz de permitir a través de un administrador definir y agregar cuentas privilegiadas. |
|
|
|
1.1.2.12 |
La solución propuesta debe tener la capacidad de que un usuario pueda solicitar el uso de una cuenta privilegiada para una fecha u hora futura. |
|
|
|
1.1.2.13 |
La solución propuesta debe permitir búsquedas dentro de los videos de auditoria. |
|
|
|
1.1.2.14 |
La solución propuesta debe ser capaz de detectar automáticamente nuevos dispositivos Laptops o PCs Windows, Servicios Windows (Windows Services), Scheduled Tasks, IIS Service Accounts, para su administración en la solución. |
|
|
|
1.1.2.15 |
Debe soportar integración con soluciones HSM (Hardware Security Module). |
|
|
|
1.1.2.16 |
Debe soportar integración con soluciones Two Factor Authentication (2FA). |
|
|
|
1.1.2.17 |
Debe soportar integración con soluciones de análisis de vulnerabilidades. |
|
|
|
1.1.2.18 |
La solución debe disponer de un servicio REST API (Application Programming Interface) vía WebServices para administrar y aprovisionamiento de la solución, que permita entre otras cosas automatizar procesos. |
|
|
|
1.1.2.19 |
La solución debe tener la capacidad de entregar un acceso remoto seguro (externo a la red corporativa) a los usuarios administradores sin necesidad de instalación de clientes VPN en los dispositivos de usuarios remotos y garantizando un acceso seguro con MFA sin necesidad de modificar los recursos de autenticación corporativos como el AD. |
|
|
|
1.1.2.20 |
Debe supervisar las sesiones, grabar, detectar, correlacionar y mitigar todos los comportamientos anormales, entre ellos servidores Linux/Unix, Windows, controladores de dominio de Microsoft Active Directory, estaciones de trabajo Windows, diversos activos de red y de Seguridad así como aplicaciones Cliente servidor/Web y servicios en Nube ya sean IaaS, SaaS o PaaS. |
|
|
|
1.1.2.21 |
La Solución debe entregar sesiones administrativas a las que se acceda y monitoree en tiempo real, con el uso compartido de pantalla y el control de periféricos, como el teclado y el ratón (asistencia remota), y mediante la grabación de comandos y vídeos de los mismos, en formato estándar de ejecución no propietaria de la solución, permitiendo que los comandos y vídeos generados se puedan indexar para futuras búsquedas, permitiendo el filtro de comandos y acciones realizadas a lo largo de la sesión grabada, lo que le permite buscar acciones específicas en la sesión grabada. |
|
|
|
1.1.2.22 |
Debe permitir identificar acciones que tipifican abusos, comportamientos anormales y fuera de los estándares aprendidos/asignados, aplicando acciones atenuantes automáticas como la re-autenticación, suspensión y terminación de sesiones y rotación de credenciales privilegiadas en caso de actividad sospechosa de alto riesgo, detectando al menos los siguientes casos: - Durante horarios irregulares (cuando un usuario recupera una contraseña de cuenta con privilegios en un momento irregular según su perfil de comportamiento); - Durante días irregulares (cuando un usuario recupera una contraseña de cuenta con privilegios en un día irregular de acuerdo con su perfil de comportamiento); - A través de IP irregular y desconocida (cuando un usuario accede a cuentas con privilegios de una dirección IP o subred inusual, de acuerdo con su perfil de comportamiento); - Cuando se realiza una conexión a un equipo con una cuenta con privilegios que no se administra en la solución. |
|
|
|
1.1.2.23 |
La solución propuesta debe tener la capacidad de soportar controles duales, la solución debe soportar diferentes configuraciones de aprobaciones cuando por ejemplo un usuario solicite una contraseña. Esto debe incluir notificaciones automáticas vía email. |
|
|
|
1.1.2.24 |
La solución propuesta debe tener la capacidad de soportar procesos flexibles de workflows para designar múltiples aprobadores. Por ejemplo, se requieren dos o más aprobaciones antes de que el acceso sea autorizado. |
|
|
|
1.1.2.25 |
La solución propuesta debe tener la capacidad de generar logs de los procesos de workflow y/o la habilidad de generar reportes o auditarlos. |
|
|
|
1.1.2.25 |
Debe incluir licencias para 20 usuarios administradores, con acceso remoto seguro SSL. |
|
|
|
1.1.3 Seguridad de la aplicación |
|||
|
1.1.3.1 |
La solución propuesta debe tener la capacidad de integrarse con métodos empresariales de autenticación, por ejemplo LDAP, Windows SSO, PKI, RADIUS y mecanismos propios de autenticación. |
|
|
|
1.1.3.2 |
La solución propuesta debe tener la capacidad de encriptar todos los datos (credenciales, secretos, sesiones grabadas) |
|
|
|
1.1.3.3 |
La solución debe contemplar la seguridad en el almacenamiento y acceso de los logs para preservar la integridad de los mismos. |
|
|
|
1.1.3.4 |
La solución propuesta debe tener la capacidad de permitir que ciertos administradores no puedan visualizar las contraseñas que son controladas por otros departamentos de la compañía. |
|
|
|
1.1.3.5 |
Todas las comunicaciones que se realicen hacia la solución y desde la solución deben estar cifradas. |
|
|
|
1.1.4 Integración de la Solución |
|||
|
1.1.4.1 |
La solución propuesta debe contar con la capacidad de integrarse con el SIEM IBM QRadar. |
|
|
|
1.1.4.2 |
La solución propuesta debe tener la capacidad de integrarse con directorios LDAP/AD. |
|
|
|
1.1.4.3 |
La solución propuesta debe tener la capacidad de integrarse con soluciones de Scanner de vulnerabilidades. |
|
|
|
1.1.5 Reportes y Auditoría |
|||
|
1.1.5.1 |
La solución propuesta debe tener la capacidad de mostrar en un quick view todas las actividades relativas a una cuenta privilegiada, como el reset de una contraseña o sesiones de administración utilizando dicha cuenta. |
|
|
|
1.1.5.2 |
La solución propuesta debe tener la capacidad de generar todos los reportes de forma periódica, bajo demanda o en forma programada. |
|
|
|
1.1.5.3 |
La solución propuesta debe tener la capacidad de generar reportes detallados y programados con la siguiente información: Reporte de privilegios, Actividad de usuarios, Inventario de cuentas privilegiadas, Inventario de aplicaciones, Reportes de Cumplimiento entre otros. |
|
|
|
1.1.5.4 |
La solución propuesta debe tener la capacidad de auditar y generar reportes de todos los cambios administrativos realizados en el sistema. |
|
|
|
1.1.5.5 |
La solución propuesta debe cumplir con las siguientes normativas: GDPR, ISO27001, PCI-DSS, NIST 800-53 |
|
|
|
1.1.6 Gestión de claves y cuentas privilegiadas |
|||
|
1.1.6.1 |
La solución propuesta debe tener la capacidad de cambiar contraseñas en periodos configurables de días, meses o años. |
|
|
|
1.1.6.2 |
La solución propuesta debe tener la capacidad de cambiar múltiples contraseñas en una sola vez para un solo sistema o sistemas agrupados bajo un solo criterio. |
|
|
|
1.1.6.3 |
La solución propuesta debe tener la capacidad de asignar contraseñas a un valor random. |
|
|
|
1.1.6.4 |
La solución propuesta debe tener la capacidad de cambiar manualmente una contraseña por un administrador en cualquier momento. |
|
|
|
1.1.6.5 |
La solución propuesta debe tener la capacidad de cambiar automáticamente el valor de una contraseña después de un tiempo especificado de un check-out |
|
|
|
1.1.6.6 |
La solución propuesta debe tener la capacidad de cambiar automáticamente la contraseña de una cuenta que acaba de ser definida en el sistema. |
|
|
|
1.1.6.7 |
La solución propuesta debe tener la capacidad de verificación automática del valor de una contraseña en el sistema correspondiente. |
|
|
|
1.1.6.8 |
La solución propuesta debe tener la capacidad de automáticamente sincronizar contraseñas que se hayan detectado como out of sync o que se hayan perdido, sin utilizar herramientas externas de restauración |
|
|
|
1.1.6.9 |
La solución propuesta debe tener la capacidad de configurar una longitud mínima de contraseña y complejidad para cuentas de súper usuarios de todos los sistemas |
|
|
|
1.1.6.10 |
La solución propuesta debe tener la capacidad de mantener el historial de contraseñas. |
|
|
|
1.1.6.11 |
La solución propuesta debe tener la capacidad de administrar cuentas de súper usuario que han sido renombradas de su nombre por default |
|
|
|
1.1.6.12 |
La solución propuesta debe tener la capacidad de soportar conexiones transparentes a un dispositivo target, sin la necesidad de ver o teclear la contraseña como parte de la conexión. |
|
|
|
1.1.6.13 |
La solución propuesta debe tener la capacidad de soportar conexión directa a dispositivos UNIX/LINUX de administración (SSH) pudiendo grabar la sesión. |
|
|
|
1.1.6.14 |
Debe permitir la gestión de al menos 1.000 activos en su bóveda de contraseñas. |
|
|
|
1.1.7 Monitoreo/Grabación de Actividad Privilegiada |
|||
|
1.1.7.1 |
La solución propuesta debe tener la capacidad de grabar sesiones privilegiadas en: Windows, Virtual Servers, Linux, equipos de comunicaciones, Bases de Datos, Aplicaciones Web. |
|
|
|
1.1.7.2 |
La solución propuesta debe tener la capacidad de hacer búsquedas de comandos privilegiados dentro de las grabaciones de video. |
|
|
|
1.1.7.3 |
La solución propuesta debe poder restringir la ejecución de comandos / Aplicaciones que se estén ejecutando con las cuentas privilegiadas gestionadas por la solución, sin la necesidad de tener que realizar configuraciones en los sistemas target. |
|
|
|
1.1.7.4 |
La solución propuesta debe tener la capacidad de intervenir y/o terminar remotamente una sesión en tiempo real cuando se ejecuta una actividad sospechosa o es requerido por el administrador o auditor. |
|
|
|
1.1.8 Gestión de llaves SSH |
|||
|
1.1.8.1 |
La solución propuesta debe tener la capacidad de contar con un método para detectar llaves SSH pares, llaves huérfanas y relaciones de confianza en la organización. |
|
|
|
1.1.8.2 |
La solución propuesta debe tener la capacidad de almacenar de forma segura y controla el acceso a las llaves privadas SSH |
|
|
|
1.1.8.3 |
La solución propuesta debe tener la capacidad de permitir la automatización de rotación de llaves |
|
|
|
1.2 Análisis de Comportamiento de Usuario (UBA) |
|||
|
1.2.1 |
La solución se debe basar en algoritmos de aprendizaje de máquina (machine learning) no supervisados. Los modelos estadísticos con los casos de uso ya deben estar listos y calibrados. |
|
|
|
1.2.2 |
La solución debe medir el riesgo de la autenticación verificando el comportamiento histórico de la identidad a través del conjunto de los siguientes atributos: - GeoVelocidad; Geolocalizacion; Día de la semana; Horario de acceso; Sistema operativo; Fallas de login consecutivas. |
|
|
|
1.2.3 |
La solución debe permitir el establecimiento de niveles personalizados de riesgos en relación al comportamiento del usuario. |
|
|
|
1.2.4 |
La herramienta debe permitir tomar decisiones y acciones (permitir Single Sign On, solicitar MFA, denegar autenticación, etc.) respecto al tipo de autenticación teniendo en cuenta el nivel de riesgo asignado a la cuenta de usuario. |
|
|
|
1.2.5 |
Debe brindarles a los administradores de la solución la capacidad de explorar los datos históricos a través de dashboards, filtros y gráficos configurables, verificar las alertas y los factores que los influenciaron y explorar los eventos capturados y sus atributos. |
|
|
|
1.2.6 |
Debe proveer gráficos de línea de tiempo, torta, mapas con la geolocalización de los eventos, gráficos de barras, tablas analíticas y mapas de relación. Sus dimensiones y categorías deben ser personalizables. |
|
|
|
1.2.7 |
La solución debe permitir configurar dashboards personalizados. |
|
|
|
1.3 Gestión de Privilegios para Endpoints (EPM) |
|||
|
1.3.1 |
Las funcionalidades deben proporcionarse mediante agentes instalados en el sistema operativo de las estaciones de trabajo y permitir la protección y el control de los privilegios. |
|
|
|
1.3.2 |
Debe ofrecer opciones de ejecución sin previo aviso: desde aplicaciones privilegiadas en modo explícito y transparente, supervisadas desde aplicaciones en modo explícito y transparente, con restricciones de aplicación en modo explícito y transparente. |
|
|
|
1.3.3 |
Debe ser capaz de evaluar la reputación del archivo ejecutado desde al menos 1 (una) fuente externa y proporcionar la opción de reenvío de archivos sospechosos para el análisis de malware en soluciones de mercado. |
|
|
|
1.3.4 |
Debe soportar al menos Windows Server 2012/2012 R2, Windows Server 2016 y Windows Server 2019; estaciones de trabajo: Windows 7 x32 y x64, Windows 8/8.1 x32 y x64, Windows 10 x32 y x64; |
|
|
|
1.3.5 |
Debe ser posible implementar reglas de control para que las aplicaciones permitidas y bloqueadas se ejecuten haciendo uso de las funcionalidades instaladas en el sistema operativo de destino, independientemente de si el acceso al activo se realiza a través de monitores/grabadoras de sesión o directamente en el recurso. |
|
|
|
1.3.6 |
Debe ser posible implementar reglas para controlar el nivel de privilegio utilizado en la ejecución de las aplicaciones permitidas que hacen uso de las funcionalidades instaladas en el sistema operativo de destino, independientemente de los monitores/grabadoras de sesión o directamente en el activo. |
|
|
|
1.3.7 |
Debe ser posible implementar el control de nivel de privilegios independientemente del permiso que el usuario tiene localmente en el activo o dominio, lo que permite a los usuarios restringidos realizar actividades de nivel administrativo. |
|
|
|
1.3.8 |
Debe permitir acceder a aplicaciones y archivos, cuando se incluyen en reglas, individualmente o en grupos. |
|
|
|
1.3.9 |
Debe ser posible la liberación de emergencia de la ejecución de comandos y la elevación de privilegios sin deshabilitar la solución si el usuario está sin conexión. |
|
|
|
1.3.10 |
Debe tener una integración con el Control de Cuentas de Usuarios (UAC) de Windows y contener informes del uso de mensajes a los usuarios realizados por UAC |
|
|
|
1.3.11 |
Debe permitir que se muestren mensajes personalizados antes de que una aplicación se ejecute o se bloquee |
|
|
|
1.3.12 |
Debe permitir la configuración de señuelos" tales como contraseñas y credenciales falsas del administrador local para la detección de ataques en curso y el bloqueo proactivo. |
|
|
|
1.3.13 |
Debe ser posible implementar la verificación de CheckSum de archivos, los parámetros permitidos y la firma del fabricante para objetos de solución reutilizables. |
|
|
|
1.3.14 |
Debe prevenir el robo de credenciales en entornos de autenticación Microsoft (LSASS, SAM, etc) y en aplicaciones de uso y administración de plataformas y browsers. |
|
|
|
1.3.15 |
Debe permitir la elevación de privilegios utilizando Autenticación Multifactor (MFA) adaptativo, que permita la configuración de múltiples factores para aplicar antes de la elevación de privilegios en una estación de trabajo o servidor, permitiendo así verificar la identidad antes de la elevación del privilegio. |
|
|
|
1.3.16 |
Debe incluir al menos 300 agentes de elevación de privilegios para estaciones de trabajo Windows y al menos 10 agentes para servidores. |
|
|
|
1.4 Autenticación Multifactor (MFA) |
|||
|
1.4.1 |
La solución debe ser capaz de cumplir mínimamente los siguientes casos de uso para solicitar uno y más factores de autenticación:
|
|
|
|
1.4.2 |
La solución debe ser capaz de ofrecer mínimamente los siguientes métodos para múltiples factores de autenticación:
|
|
|
|
1.4.3 |
La solución debe ser capaz de soportar autenticadores que admiten FIDO2 / U2F, que admiten mínimamente: |
|
|
|
1.4.4 |
La solución debe ser capaz de soportar confirmación de código por correo electrónico. |
|
|
|
1.4.5 |
La solución debe ser capaz de soportar clientes de Oath OTP (por ejemplo, Google Authenticator). |
|
|
|
1.4.6 |
La solución debe ser capaz de soportar preguntas y respuestas previamente configuradas. |
|
|
|
1.4.7 |
Debe permitir que los usuarios realicen el restablecimiento de contraseña y el desbloqueo del usuario, autoservicio mediante los múltiples métodos de factor de autenticación citados para la verificación positiva a través del portal de soluciones, Windows y la pantalla de inicio de sesión del sistema operativo MacOS, y a través de las API de REST que ofrece la solución. |
|
|
|
1.4.8 |
Debe soportar autenticación dinámica basada en el contexto de riesgo y seguridad aprendido por la solución, permitiendo la creación de un perfil para cada usuario, aprovechando los atributos históricos y situacionales específicos del mismo, como la ubicación, el dispositivo, la red, el horario y el índice de riesgo de comportamiento. |
|
|
|
1.4.9 |
Debe permitir el análisis de las solicitudes de autenticación con los estándares históricos, asignación de índice de riesgo a cada intento de inicio de sesión, generación de alertas y creación de directivas de bloqueo para que se activen cuando se detecte un comportamiento anómalo y se simplifique el acceso cuando se entienda que el usuario es legítimo. |
|
|
|
1.4.10 |
Debe permitir a los usuarios agregar y modificar factores de autenticación directamente en un portal con una definición de período de omisión de autenticación multifactor. |
|
|
|
1.4.11 |
Debe proporcionar informes y paneles personalizables que detallen la información en tiempo real sobre las actividades de autenticación, como errores de autenticación secundarios, intentos de inicio de sesión correctos y los factores de autenticación más utilizados. |
|
|
|
1.4.12 |
Soporte de MFA (Autenticación Multifactor) para 300 usuarios. |
|
|
|
1.5 Single Sign On (SSO) |
|||
|
1.5.1 |
La solución debe permitir la configuración de las aplicaciones web mínimamente a través de los siguientes protocolos y métodos, para por lo menos 20 usuarios administradores: • SAML 2.0 |
|
|
|
1.5.2 |
La solución debe ofrecer un componente/software para intermediar el SSO en aplicaciones web hosteadas en el centro de datos de la organización sin necesidad de exponer estas aplicaciones al uso de Internet o VPN y debe admitir los mismos métodos y protocolos que el elemento anterior. |
|
|
|
1.5.3 |
La solución debe proporcionar una extensión avanzada del explorador solo para los administradores de soluciones, con el fin de asignar los campos de los formularios (normalmente inicio de sesión y contraseña) para que después de asignar el usuario administrado pueda incluir como una aplicación web para SSO en el catálogo general, lo que permite el SSO de aplicaciones que no admiten protocolos más modernos como SAML y Oauth. |
|
|
|
1.5.4 |
Debe soportar SSO a través de la autenticación integrada de Windows (IWA) que reutiliza el inicio de sesión de red para la autenticación en aplicaciones web, sin necesidad de introducir el usuario y la contraseña de nuevo. |
|
|
|
1.5.5 |
Debe admitir la personalización de respuestas SAML, como la asignación de atributos de directorio a atributos SAML, la capacidad de incluir lógica compleja para controlar las respuestas SAML y habilitar la visualización de la respuesta SAML configurada antes de su implementación. |
|
|
|
1.5.6 |
Debe disponer de un servicio de directorio para almacenar identidades en la solución, sin depender de la sincronización con otros servicios de directorio on-premise o en la nube de terceros. |
|
|
|
1.5.7 |
El servicio de directorio de soluciones debe tener la capacidad de ampliar su esquema configurando atributos personalizados para satisfacer requisitos empresariales complejos |
|
|
|
1.5.8 |
La solución debe admitir la integración con los servicios de directorio en la nube y on-premises, lo que debe admitir mínimamente: |
|
|
|
1.5.9 |
Las integraciones con un directorio de terceros no deben sincronizarse con estas bases de datos, es decir, cargar todo el directorio configurado en la nube, la solución debe actuar como intermediario entre los servicios de directorio de terceros y la solución. |
|
|
|
1.5.10 |
La solución debe tener la capacidad de configurar LOS PROVEEDORES DE IDENTIDAD (IDP) de los socios comerciales de la organización para dar acceso a identidades federadas en aplicaciones empresariales de la organización sin necesidad de crear una nueva identidad en la infraestructura, a través de la federación realizada a través del protocolo SAML. |
|
|
CONDICIONES GENERALES
Administración del Contrato: la administración del contrato estará a cargo del Departamento de Ciberseguridad del Banco Central del Paraguay.
Compromiso de Confidencialidad: el personal interviniente del Proveedor deberá firmar un Compromiso de Confidencialidad de la Información, dado que podría acceder a información confidencial del BCP, conforme al Formulario N° 7.
La firma del Compromiso de Confidencialidad se realizará al momento de la suscripción del Contrato. El Departamento de Ciberseguridad será el responsable de gestionar la firma de dicha documentación.
En caso de que se incorpore nuevo personal del Proveedor se deberá gestionar la firma del Compromiso de Confidencialidad por parte de los mismos.
ACUERDO DE NIVEL DE SERVICIO
El Proveedor deberá suscribir un Acuerdo de Nivel de Servicio, bajo los siguientes términos:
Tiempo de respuesta a incidentes que afectan la disponibilidad del servicio:
En caso de no cumplir con el plazo establecido, el Proveedor deberá comunicarlo por escrito mediante nota dirigida al DCS, indicando los motivos técnicos de su atraso. En estos casos, el Proveedor está obligado a proporcionar y mantener funcionando el servicio de respaldo/contingencia mientras dure la reparación y puesta a punto del servicio.
El Proveedor facilitará el nombre, número telefónico y correo electrónico del contacto para gestionar los incidentes críticos y no críticos.
• El presente llamado a ser publicado ha sido solicitado por: el Departamento de Ciberseguridad del Banco Central del Paraguay.
• La necesidad que se pretende satisfacer mediante la contratación realizada radica en: soluciones que brinden seguridad y protección a la base de datos y accesos de la Institución.
• Con relación a la planificación, se indica que: se trata de un llamado periódico, sucesivo ya que la necesidad es continua.
• Las especificaciones técnicas establecidas se justifican en: las necesidades actuales de la Institución, en su infraestructura, conocimiento del área técnica, entre otros.
La entrega de los bienes se realizará de acuerdo al Plan de Entrega y Cronograma de Cumplimiento, indicado en el presente apartado. Así mismo, de los documentos de embarque y otros que deberá suministrar el Proveedor indicados a continuación:
|
Ítems |
Descripción del bien |
Cantidad |
Unidad de medida |
Lugar de entrega de los bienes |
Plazo de entrega de los bienes |
Plazo de vigencia del Contrato |
|
De acuerdo a la Lista de Precios publicada en el SICP |
De acuerdo a la Lista de Precios publicada en el SICP |
De acuerdo a la Lista de Precios publicada en el SICP |
De acuerdo a la Lista de Precios publicada en el SICP |
La ejecución deberá poder ser realizada por el Proveedor en forma on site u on line, según sea requerido por el BCP. En caso de que sea on site, deberá ser prestado en el Banco Central del Paraguay, sito en Av. Federación Rusa y Augusto Roa Bastos. |
El plazo máximo de entrega e instalación de la solución será de 30 (treinta) días a partir de la suscripción del Contrato. La suscripción a la solución será de 24 (veinticuatro) meses, contados a partir de la fecha de aceptación de la entrega e instalación de la solución por parte del Departamento de Ciberseguirdad. |
El plazo de vigencia será partir de la suscripción del contrato, hasta el cumplimiento total de las obligaciones contractuales. |
Para la presente contratación se pone a disposición los siguientes planos o diseños:
No aplica
El embalaje, la identificación y la documentación dentro y fuera de los paquetes serán como se indican a continuación:
No aplica
Las inspecciones y pruebas serán como se indica a continuación:
La Contratante fiscalizará la ejecución del Contrato a través del área administradora del Contrato. Se verificará que lo ejecutado cumpla a cabalidad con lo establecido en la Sección Especificaciones Técnicas y Suministros Requeridos y en la Lista de Precios; y se adecuen al Plan de Entrega de los Bienes
1. El proveedor realizará todas las pruebas y/o inspecciones de los Bienes, por su cuenta y sin costo alguno para la contratante.
2. Las inspecciones y pruebas podrán realizarse en las instalaciones del Proveedor o de sus subcontratistas, en el lugar de entrega y/o en el lugar de destino final de entrega de los bienes, o en otro lugar en este apartado.
Cuando dichas inspecciones o pruebas sean realizadas en recintos del Proveedor o de sus subcontratistas se le proporcionarán a los inspectores todas las facilidades y asistencia razonables, incluso el acceso a los planos y datos sobre producción, sin cargo alguno para la contratante.
3. La contratante o su representante designado tendrá derecho a presenciar las pruebas y/o inspecciones mencionadas en la cláusula anterior, siempre y cuando éste asuma todos los costos y gastos que ocasione su participación, incluyendo gastos de viaje, alojamiento y alimentación.
4. Cuando el proveedor esté listo para realizar dichas pruebas e inspecciones, notificará oportunamente a la contratante indicándole el lugar y la hora. El proveedor obtendrá de una tercera parte, si corresponde, o del fabricante cualquier permiso o consentimiento necesario para permitir al contratante o a su representante designado presenciar las pruebas o inspecciones.
5. La contratante podrá requerirle al proveedor que realice algunas pruebas y/o inspecciones que no están requeridas en el contrato, pero que considere necesarias para verificar que las características y funcionamiento de los bienes cumplan con los códigos de las especificaciones técnicas y normas establecidas en el contrato. Los costos adicionales razonables que incurra el proveedor por dichas pruebas e inspecciones serán sumados al precio del contrato, en cuyo caso la contratante deberá justificar a través de un dictamen fundado en el interés público comprometido. Asimismo, si dichas pruebas y/o inspecciones impidieran el avance de la fabricación y/o el desempeño de otras obligaciones del proveedor bajo el contrato, deberán realizarse los ajustes correspondientes a las Fechas de Entrega y de Cumplimiento y de las otras obligaciones afectadas.
6. El proveedor presentará a la contratante un informe de los resultados de dichas pruebas y/o inspecciones.
7. La contratante podrá rechazar algunos de los bienes o componentes de ellos que no pasen las pruebas o inspecciones o que no se ajusten a las especificaciones. El proveedor tendrá que rectificar o reemplazar dichos bienes o componentes rechazados o hacer las modificaciones necesarias para cumplir con las especificaciones sin ningún costo para la contratante. Asimismo, tendrá que repetir las pruebas o inspecciones, sin ningún costo para la contratante, una vez que notifique a la contratante.
8. El proveedor acepta que ni la realización de pruebas o inspecciones de los bienes o de parte de ellos, ni la presencia de la contratante o de su representante, ni la emisión de informes, lo eximirán de las garantías u otras obligaciones en virtud del contrato.
El documento requerido para acreditar el cumplimiento contractual, será:
El documento requerido para acreditar el cumplimiento contractual será:
Nota/Formulario de conformidad del área técnica.
Planificación de indicadores de cumplimiento:
|
INDICADOR |
TIPO |
FECHA DE PRESENTACIÓN PREVISTA |
|
Conformidad del área técnica administradora del contrato |
Nota/Formulario de conformidad del área técnica. |
Durante la ejecución contractual, de acuerdo al plazo establecido en el Plan de Entrega o Prestación de los bienes o servicios del presente PBC, el área administradora del Contrato emitirá la Nota/Formulario de conformidad, exigida/o para los pagos correspondientes. |
De manera a establecer indicadores de cumplimiento, a través del sistema de seguimiento de contratos, la convocante deberá determinar el tipo de documento que acredite el efectivo cumplimiento de la ejecución del contrato, así como planificar la cantidad de indicadores que deberán ser presentados durante la ejecución. Por lo tanto, la convocante en este apartado y de acuerdo al tipo de contratación de que se trate, deberá indicar el documento a ser comunicado a través del módulo de Seguimiento de Contratos y la cantidad de los mismos.
La Convocante adjudicará el contrato al oferente cuya oferta haya sido evaluada como la más baja y cumpla sustancialmente con los requisitos de las bases y condiciones, siempre y cuando la convocante determine que el oferente está calificado para ejecutar el contrato satisfactoriamente.
1. La adjudicación en los procesos de contratación en los cuales se aplique la modalidad de contrato abierto, se efectuará por las cantidades o montos máximos solicitados en el llamado, sin que ello implique obligación de la convocante de requerir la provisión de esa cantidad o monto durante de la vigencia del contrato, obligándose sí respecto de las cantidades o montos mínimos establecidos.
2. En caso de que la convocante no haya adquirido la cantidad o monto mínimo establecido, deberá consultar al proveedor si desea ampliarlo para el siguiente ejercicio fiscal, hasta cumplir el mínimo.
3. Al momento de adjudicar el contrato, la convocante se reserva el derecho a disminuir la cantidad de bienes requeridos, por razones de disponibilidad presupuestaria u otras razones debidamente justificadas. Estas variaciones no podrán alterar los precios unitarios u otros términos y condiciones de la oferta y de los documentos de la licitación.
En aquellos llamados en los cuales se aplique la modalidad de contrato abierto, cuando la convocante deba disminuir cantidades o montos a ser adjudicados, no podrá modificar el monto o las cantidades mínimas establecidas en las bases de la contratación.
La comunicación de la adjudicación a los oferentes será como sigue:
1. Dentro de los cinco (5) días corridos de haberse resuelto la adjudicación, la convocante comunicará a través del Sistema de Información de Contrataciones Públicas, copia del informe de evaluación y del acto administrativo de adjudicación, los cuales serán puestos a disposición pública en el referido sistema. Adicionalmente el sistema generará una notificación a los oferentes por los medios remotos de comunicación electrónica pertinentes, la cual será reglamentada por la DNCP.
2. En sustitución de la notificación a través del Sistema de Información de Contrataciones Públicas, las convocantes podrán dar a conocer la adjudicación por cédula de notificación a cada uno de los oferentes, acompañados de la copia íntegra del acto administrativo y del informe de evaluación. La no entrega del informe en ocasión de la notificación, suspende el plazo para formular protestas hasta tanto la convocante haga entrega de dicha copia al oferente solicitante.
3. En caso de la convocante opte por la notificación física a los oferentes participantes, deberá realizarse únicamente con el acuse de recibo y en el mismo con expresa mención de haber recibido el informe de evaluación y la resolución de adjudicación.
4. Las cancelaciones o declaraciones desiertas deberán ser notificadas a todos los oferentes, según el procedimiento indicado precedentemente.
5. Las notificaciones realizadas en virtud al contrato, deberán ser por escrito y dirigirse a la dirección indicada en el contrato.
Una vez notificado el resultado del proceso, el oferente tendrá la facultad de solicitar una audiencia a fin de que la convocante explique los fundamentos que motivan su decisión.
La solicitud de audiencia informativa no suspenderá ni interrumpirá el plazo para la interposición de protestas.
La misma deberá ser solicitada dentro de los dos (2) días hábiles siguientes en que el oferente haya tomado conocimiento de los términos del Informe de Evaluación de Ofertas.
La convocante deberá dar respuesta a dicha solicitud dentro de los dos (2) días hábiles de haberla recibido y realizar la audiencia en un plazo que no exceda de dos (2) días hábiles siguientes a la fecha de respuesta al oferente.
Luego de la notificación de adjudicación, el proveedor deberá presentar en el plazo establecido en las reglamentaciones vigentes, los documentos indicados en el presente apartado.
|
|
|
|
|
|
|
|
2. Documentos. Consorcios |
|
|
|
|