Personalmente, creo que necesita contratar una empresa de consultoría de seguridad para cubrir adecuadamente los problemas de seguridad aquí. Sus problemas de seguridad exactos probablemente serán altamente contextuales, y hay implicaciones regulatorias adicionales en los hospitales. Dicho esto, intentaré cubrir sus inquietudes.
Esta aplicación se usa en muchos sistemas hospitalarios grandes, por lo que resulta difícil creer que el proveedor no haya abordado esto de alguna manera
Desafortunadamente, eso es bastante común. Hable con cualquier persona que maneje infraestructura de TI, redes, seguridad, software, etc. en un hospital (o en cualquier organización) y le dirán lo mismo: los proveedores suelen ser lentos para solucionar los problemas y, a menudo, no ponen la esfuerzo por productos heredados en los que aún se confía.
¿Esto es una preocupación?
Muy probablemente, sí. Está poniendo un marco obsoleto e inseguro en los sistemas afectados. Java puede invocarse a través del navegador a menos que esté configurado correctamente, lo que potencialmente permite ataques remotos contra el sistema. Otro posible vector de ataque contra el marco es a través de servidores web Java como Apache Tomcat, que podrían exponer una funcionalidad explotable (por ejemplo, RMI) independientemente de lo que haga la aplicación.
¿Qué preguntas le hago al proveedor para determinar nuestra vulnerabilidad específica? si mantienen nuestro sistema actualizado con parches críticos, etc.?
El problema es que, si están utilizando Java desactualizado (especialmente 1.6 o anterior), entonces no importa lo que hagan para abordar las vulnerabilidades individuales en su aplicación: el marco subyacente en sí está roto y no se puede mitigar eso individualmente.
¿El único recurso es insistir en que el proveedor pase a la versión 1.8 antes de crear acceso a nuestra red desde entidades externas?
La respuesta simple es sí. La respuesta más compleja es que usted podría excluir del servidor de la aplicación para que, si fuera comprometido, haya un nivel limitado de acceso a su red interna, si lo hubiera. Sin embargo, si se incluyen los datos del paciente (especialmente cualquier PII), entonces tiene requisitos reglamentarios con los que disputar.
El TL; DR es que el proveedor debe actualizar su código para que funcione con una versión más moderna de Java. Hay dos formas principales de acelerar este proceso: ofrecer un pago por el tiempo de desarrollo requerido para hacerlo, o amenazar con desconectar su servicio y usar una alternativa que esté más actualizada.
Otra vía que tiene es la normativa: suponiendo que se encuentre en los EE. UU., informe a su organismo regulador de la HIPAA que su software utiliza un marco vulnerable que genera riesgos de exposición de la información del paciente. Si su base de clientes es grande, es posible que la ley les exija actualizar su software o mitigar cualquier problema.