Registro para HIPAA: auditoría segura en Linux
CÓMO de registro de HIPAA, parte 2
La Ley de Responsabilidad y Portabilidad del Seguro Médico de 1996 (HIPAA) describe estándares relevantes de seguridad y privacidad para la información médica, tanto electrónica como física. La misión principal de la ley es “mejorar la portabilidad y continuidad de la cobertura de seguro médico en los mercados individuales y grupales, para combatir el despilfarro, el fraude y el abuso en el seguro médico y la prestación de atención médica” (Ley HIPAA de 1996 http://www .hhs.gov/ocr/privacy/). Una mejora reciente de HIPAA se llama Ley de Tecnología de la Información de Salud para la Salud Económica y Clínica o Ley HITECH. La ley busca "promover la adopción y el uso significativo de la tecnología de la información sanitaria" y "aborda las preocupaciones de privacidad y seguridad asociadas con la transmisión electrónica de información sanitaria". (Ley HITECH de 2009 )
Como mencionamos antes, la HIPAA en sí no desciende al nivel de controles y tecnologías de seguridad a implementar. Esto requiere que las organizaciones afectadas por HIPAA -también conocidas como “entidades cubiertas” - intenten seguir el espíritu de la regulación en lugar de su letra. Lo que también es interesante señalar es que las compañías de seguros y muchos hospitales que aceptan tarjetas de pago están sujetos tanto a HIPAA como a PCI DSS (tratadas en nuestros boletines anteriores). Es comprensible que el alcance de su aplicabilidad en toda la organización pueda ser diferente, ya que los sistemas de procesamiento de pagos no deben almacenar información de salud del paciente y viceversa. Aún así, considerar los mismos controles técnicos y administrativos para ambas regulaciones es prudente y ahorrará dinero tanto a corto como a largo plazo.
El boletín anterior se centró en los procesos generales de registro y revisión de registros de HIPAA y en el registro de plataformas. Esta entrega del boletín cubre problemas de registro de aplicaciones específicos de aplicaciones médicas.
Si bien el registro a nivel de plataforma es útil para proteger la información de salud confidencial, es un hecho que la mayoría de la información de salud se almacena en bases de datos y se procesa mediante aplicaciones específicas de atención médica. Estas aplicaciones se obtienen de proveedores especializados o se desarrollan internamente (a través de desarrolladores subcontratados).
La HIPAA de controles de auditoría, mencionada en la Sección 164.312(b), se aplica al registro de aplicaciones tanto o más que al registro de la plataforma. Esto significa que las aplicaciones personalizadas deben diseñarse para tener un registro adecuado. Es necesario evaluar que el registro de aplicaciones existente tiene un registro adecuado; cabe señalar que muchas aplicaciones heredadas a menudo no registrarán suficientes detalles para los eventos e incluso podrían omitir los eventos de registro por completo. Por lo tanto, antes de embarcarse en este proyecto, tiene sentido determinar qué aplicaciones dentro de su organización contienen información médica protegida (PHI) y cuáles son sus niveles y métodos de registro existentes.
Definamos algunas de las pautas sobre qué registrar para satisfacer el espíritu y la letra de los requisitos de seguridad de HIPAA, así como las aclaraciones de NIST 800-66 HIPAA.
Guía de registro de aplicaciones
Antes de que podamos definir un buen registro HIPAA, consideremos el uso de seguridad típico para los datos de registro.
Los mejores registros de auditoría de alto nivel le indican exactamente qué sucedió (cuándo, dónde y cómo), así como quién estuvo involucrado. Estos registros son adecuados para análisis manuales, semiautomáticos y automatizados. Idealmente, se pueden analizar sin tener a mano la aplicación que los produjo y, definitivamente, sin tener al desarrollador de la aplicación disponible. En el caso de aplicaciones sanitarias, es posible que dicho desarrollador no esté disponible en absoluto y el equipo de seguridad tendrá que proceder por su cuenta. Desde el punto de vista de la gestión de registros, los registros se pueden centralizar para su análisis y retención. Por último, no deberían ralentizar el sistema y pueden resultar fiables si se utilizan como prueba forense.
Es necesario definir dos cosas principales.
- En primer lugar, hay tipos de actividades o eventos que siempre es necesario registrar. Por ejemplo, las decisiones de autenticación, el acceso a la información de salud y los cambios en el sistema siempre deben aparecer en los registros.
- En segundo lugar, para cada tipo de evento registrado hay una serie de detalles que son obligatorios para su interpretación, ya sea por parte de un ser humano o de un sistema automatizado. Por ejemplo, cada registro debe tener una marca de tiempo confiable y cada registro relacionado con la actividad del usuario debe contener el nombre de usuario de ese usuario.
También cabe señalar que ciertos detalles nunca deben registrarse. El ejemplo es obvio: las contraseñas de aplicaciones o sistemas nunca deberían aparecer en los registros (esto, lamentablemente, a veces todavía sucede con las aplicaciones web). Igual de obvio es que la información de salud en sí misma no debe incluirse en los registros.
¿Qué eventos registrar?
¿Cuál es el tema general para seleccionar qué eventos registrar?
Claramente, necesitamos saber quién, cuándo y por qué accede a cualquier información de salud. También necesitamos saber quién lo agrega, lo cambia o lo elimina. Pero esto no es todo: también debemos tener en cuenta quién intenta leer, cambiar o eliminar información pero no lo logra. Si no podemos registrar el acceso a cada dato, debemos registrar cuidadosamente todos los accesos a la aplicación misma.
A continuación, necesitamos saber quién realiza otras acciones en los sistemas que procesan información sanitaria, ya que dichas actividades podrían afectar el acceso futuro a los datos sanitarios. Por ejemplo, necesitamos registrar si alguien cierra la sesión o agrega un nuevo componente al sistema que podría permitir el acceso ilimitado a los datos. Además, debemos registrar otros eventos críticos en los sistemas de información de salud, ya que dichos eventos podrían presentar evidencia circunstancial de acceso no autorizado.
La siguiente lista presenta una vista estructurada de los criterios anteriores:
Autenticación, Autorización, Acceso
- Decisiones de autenticación/autorización, exitosas y fallidas (consulte “estado” a continuación), y especialmente autenticación privilegiada
- Registrar los cierres de sesión de los usuarios también es importante para saber cuándo el usuario ya no tenía acceso a la aplicación.
- Cambiar de una cuenta de usuario a otra
- Acceso al sistema, acceso a datos, acceso a componentes de aplicaciones
- Acceso de red a la aplicación, incluido el acceso remoto desde un componente de la aplicación a otro en un entorno de distribución.
Cambios
- Cambios en el sistema/aplicación (especialmente cambios de privilegios)
Problemas de disponibilidad
- Arranques y apagados de sistemas, aplicaciones y módulos/componentes de aplicaciones.
“Maldad”/Amenazas
- Entradas no válidas y otros posibles abusos de la aplicación
Si bien probablemente sea imposible crear una lista completa de "qué registrar" para cada aplicación de atención médica existente, la lista anterior debería brindarle un punto de partida útil para sus aplicaciones relevantes. Se puede convertir en la política de registro de su aplicación sin mucho trabajo adicional. Consulte el boletín anterior para configurar el proceso de revisión y monitoreo de registros.
¿Qué detalles registrar?
A continuación, ¿qué datos debería registrar para cada evento y con qué nivel de detalle debería registrarlos? El tema general que utilizamos aquí es el siguiente:
¿Quien estaba involucrado?
>¿Qué pasó?
¿Dónde ocurrió?
¿Cuándo ocurrió?
¿Por qué sucedió?
¿Cómo ha ocurrido?
La siguiente lista le brinda un punto de partida basado en ese tema:
Marca de tiempo + zona horaria : esto ayuda a responder la pregunta "cuándo", la zona horaria es esencial para las aplicaciones distribuidas.
Sistema, aplicación o componente: esto ayuda a responder la pregunta "dónde" y también debe proporcionar un contexto de aplicación relevante.
Fuente: para los mensajes relacionados con la conectividad de la red o el funcionamiento de la aplicación distribuida , los registros también deben responder a la pregunta "de dónde" proporcionando una fuente de red.
Nombre de usuario: esto ayuda a responder la pregunta "quién", para aquellos eventos que son relevantes para las actividades del usuario o administrador.
Acción: esto ayuda a responder la pregunta "qué" al proporcionar la naturaleza del evento que se registra en el registro.
Objeto: esto también ayuda a responder la pregunta "qué" al ayudar a saber qué componente del sistema u otro objeto (como la cuenta de usuario) se ha visto afectado.
Estado: esto también ayuda a responder la pregunta "qué" al explicar si la acción dirigida al objeto tuvo éxito o falló (también son posibles otros tipos de estado, como "diferido")
Prioridad: por último, pero no menos importante, cada evento registrado debe tener una indicación de su importancia. Si bien es imposible crear una escala uniforme para el alquiler de eventos por importancia, ya que diferentes organizaciones tendrán diferentes prioridades (por ejemplo, los eventos que afectan la disponibilidad versus la confidencialidad de la información pueden leerse de manera diferente).
Por lo tanto, un mensaje de registro de auditoría de aplicación útil podría verse así:
31/12/2010 10:00:01 a. m. GMT+7 prioridad=3, sistema=servidor principal, módulo=autenticación, fuente=127.0.0.1, usuario=anton, acción=inicio de sesión, objeto=base de datos_PHI, estado=fallido, motivo="contraseña incorrecta"
Por cierto, observe que se agrega otro campo al mensaje de registro de ejemplo anterior para explicar el motivo del error. Tenga en cuenta también que los ejemplos anteriores no están en XML; como mencionamos anteriormente, la legibilidad humana es una propiedad útil para tener en los registros y las computadoras pueden manejar pares nombre=valor tan bien como XML. Los mensajes basados en XML Health Level Seven (HL7) se pueden convertir fácilmente a texto, para aquellas aplicaciones que pueden iniciar sesión en HL7.
También mencionamos anteriormente que poder centralizar fácilmente los registros es esencial para el análisis de registros distribuidos, ya sea en múltiples sistemas o en múltiples componentes de una aplicación distribuida. Si bien syslog ha sido el rey de la centralización de registros debido a su fácil entrega UDP, los marcos de aplicaciones multiplataforma modernos como un modelo de llamada de publicación/suscripción para la entrega de registros, similar a los utilizados en las versiones modernas de Windows. En este caso, la herramienta de monitoreo de seguridad puede solicitar una suscripción para un tipo particular de evento registrado y recibir todos los registros relevantes casi en tiempo real, si es necesario.
Conclusiones
Además de esa conclusión tan básica (debe registrar el acceso a datos sanitarios confidenciales), debemos recordar a nuestros lectores que la importancia del registro no hará más que crecer, junto con la creciente complejidad de las aplicaciones. En particular, la necesidad de analizar el comportamiento de las aplicaciones y el movimiento de información confidencial a través de aplicaciones distribuidas y basadas en la nube exige que finalmente tengamos bajo control el registro de aplicaciones.
Los arquitectos e implementadores de software necesitan "obtener" el registro; NO hay otra manera, ya que el registro de infraestructura desde dispositivos de red y sistemas operativos no sirve para detectar e investigar amenazas a nivel de aplicación a ePHI. El equipo de seguridad, responsable en última instancia de la revisión de los registros, deberá guiar a los desarrolladores hacia un registro útil y eficaz que pueda utilizarse tanto para actividades de seguimiento como de investigación.
Ciertamente, los estándares de registro como MITRE CEE (cee.mitre.org) ayudarán, pero podrían pasar algunos años antes de que se desarrollen y aumente su adopción. A la espera de un estándar global, una organización debería crear rápidamente y luego utilizar su propio estándar de registro de aplicaciones para las aplicaciones. El cumplimiento de HIPAA presenta una gran motivación para crear y adoptar dichos estándares de registro.
Noticias de la industria
El hackeo de Pirate Bay expone el botín de los usuarios
Las debilidades de seguridad en el popular sitio web para compartir archivos thepiratebay.org han expuesto los nombres de usuario, el correo electrónico y las direcciones de Internet de más de 4 millones de usuarios de Pirate Bay... Un hacker argentino llamado Ch Russo dijo que él y dos de sus asociados descubrieron múltiples vulnerabilidades de inyección SQL que les permitieron acceder a la base de datos de usuarios del sitio.
Zeus está de regreso con una campaña de spam con temas terroristas
Los correos electrónicos cargados de troyanos que afirman ofrecer información oficial sobre terrorismo han estado llegando a las bandejas de entrada... Los correos electrónicos están falsificados para que parezcan provenir del Departamento de Seguridad Nacional de EE. UU. , Pentágono o Administración de Seguridad del Transporte. Se anima a los usuarios a hacer clic en dos enlaces que supuestamente conducen a informes, pero que en realidad son archivos ZIP que contienen el insidioso troyano Zeus o Zbot.
Recurso relacionado: Seminario web: aprenda cómo la implementación del control de cambios en su empresa puede ayudarle a manejar desafíos de seguridad críticos, incluidos BOTnet y ataques de día cero.
Administrador de base de datos recibe 12 meses por piratear a su empleador
Un ex administrador de base de datos de GEXA Energy de Houston fue sentenciado a 12 meses de prisión y una multa de 100 000 dólares por piratear la red de su antiguo empleador. Accedió de forma remota a la red de GEXA Energy sin autorización, perjudicó la disponibilidad de datos y copió un archivo de base de datos que contenía información personal. GEXA Energy estima que las acciones de Kim resultaron en una pérdida de al menos 100.000 dólares.
¿Lo sabías? Las infracciones de seguridad cometidas por personas internas suelen ser las más difíciles de descubrir, pero causan el mayor daño y son las que más cuestan reparar. EventTracker ayuda a supervisar toda la actividad de los usuarios y administradores, detectando automáticamente infracciones de políticas y comportamientos fuera de lo común o sospechosos.