El saneamiento de datos es un proceso complejo que requiere experiencia técnica para ser diseñado e implementado de manera efectiva. El enfoque de múltiples capas en R2v3 Standard está diseñado para incorporar múltiples medidas de seguridad para evitar errores en la desinfección de datos que pueden resultar en filtraciones de datos. Refleja las mejores prácticas del sistema de gestión de calidad que incorpora controles y equilibrios fundamentales en el proceso de saneamiento de datos que crea responsabilidad y transparencia que promueve la confianza en los resultados.

Además, el estándar R2 está diseñado para promover una economía circular en la que los productos electrónicos se reutilicen siempre que sea posible antes de reciclarlos. Esto se requiere en el Núcleo 2: Jerarquía de estrategias de gestión responsable. La reutilización solo es posible cuando los datos de usuarios anteriores se pueden desinfectar sin daños físicos y no se pueden recuperar con software comercial. La reutilización no se puede lograr cuando expone información personal, privada o confidencial de los usuarios anteriores. En R2v3, la única ruta para el saneamiento lógico de datos para reutilizar un dispositivo se encuentra en el Apéndice B.

El Apéndice B requiere que los medios se desinfecten lógicamente mediante software en lugar de restablecerlos manualmente. Esto tiene como objetivo garantizar un nivel de rigor, transparencia y responsabilidad en el que se pueda confiar para estar seguro de que los datos se han desinfectado adecuadamente, de modo que el dispositivo se pueda reutilizar. Los usuarios pueden desinfectar su propio dispositivo manualmente, ya que es su elección y riesgo individual. Sin embargo, para certificar una instalación comercial para desinfectar lógicamente los datos de otras personas para reutilizar su dispositivo, se requiere una barra más alta para mitigar los riesgos.

Solución – Transparencia y rendición de cuentas

La desinfección de datos lógicos es fundamental para la reutilización de productos electrónicos. Sin la confianza de que los datos privados, personales o confidenciales no se pueden recuperar, es probable que los dispositivos se destruyan físicamente para proteger esos datos. La transparencia de quién, qué, dónde, cuándo y cómo se desinfectó un dispositivo es importante para la credibilidad del proceso. Si bien la automatización es la mejor práctica, esta información podría recopilarse con una combinación de flujos de trabajo automatizados y manuales. Por ejemplo, cuando el software puede leer digitalmente la información del dispositivo, esa parte podría automatizarse. Sin embargo, la desinfección puede ser imposible por software y, por lo tanto, todavía requiere un reinicio manual. Otras opciones que pueden reducir los errores de entrada de datos podrían incluir el escaneo de códigos de barras o etiquetas QR en el dispositivo para capturar información del dispositivo.

La rendición de cuentas es la segunda parte de la credibilidad. Históricamente, hemos visto hojas de cálculo de medios que se han desinfectado. Las hojas de cálculo se prestan a errores al transcribir información y al copiar y pegar registros, lo que conduce a una falta de precisión y responsabilidad por cada medio/dispositivo desinfectado. Los flujos de trabajo en el proceso de restablecimiento del fabricante deben detallarse en los pasos para recordar al técnico cada paso requerido y obligar al técnico a aprobar cada paso, no solo una aprobación general en el dispositivo o lote de dispositivos. Registrar que se ha completado cada paso crea una mayor responsabilidad de que se siguió cada paso y hace que el técnico sea responsable de la desinfección de cada dispositivo.

Desafío: Explosión del mercado de dispositivos "inteligentes"

Desde el desarrollo de la versión 3 del estándar R2, los tipos de nuevos dispositivos electrónicos que se han vuelto "inteligentes" con el almacenamiento de datos se han disparado. Esto ha creado un entorno en el que se venden nuevos dispositivos sin planificar la desinfección de los datos de usuario almacenados en estos dispositivos. Si bien el almacenamiento de datos patentado agrega un nivel de seguridad de datos, también evita potencialmente la reutilización de dispositivos en funcionamiento cuando no se pueden eliminar los datos del usuario anterior. Ha comenzado una tendencia en la que el software comercial diseñado para desinfectar datos no siempre puede acceder a nuevos dispositivos para desinfectar datos debido a su diseño patentado único. Este no es un problema del final de la vida que tenga años para resolverse. El desafío comienza cuando se compran, configuran y devuelven nuevos productos al minorista con datos.

Reconociendo este desafío, no siempre es posible desinfectar todos los dispositivos con un software que automatice, controle y registre el proceso. La intención no es destruir los dispositivos que funcionan si se puede usar un método creíble para desinfectar de manera confiable los datos según las especificaciones del fabricante con transparencia y responsabilidad. Por lo tanto, es importante aceptar soluciones alternativas de desinfección de datos que se haya comprobado que eliminan de manera efectiva los datos de los dispositivos que se revenderán.

En los casos en que no exista un software automatizado, el software podría integrar las instrucciones de reinicio del fabricante para controlar el proceso y producir los datos que crearían un registro confiable del evento de desinfección de datos para cada dispositivo. Esto es más que una hoja de cálculo que puede estar sujeta a alteración o falsificación.

Desafío: brechas en el saneamiento de datos

Con el tiempo, se han demostrado algunas lagunas específicas en la desinfección adecuada de los datos. Por ejemplo, formatear un disco duro no borra los datos. Los dispositivos Android sin cifrar que se han restablecido de fábrica no muestran datos cuando uno inspecciona visualmente el dispositivo en busca de datos. Sin embargo, cuando se utiliza un software comercial de recuperación de datos, un escaneo a menudo devolverá imágenes, contactos y mensajes que aún son accesibles. Del mismo modo, un restablecimiento de fábrica puede simplemente restablecer el dispositivo a la configuración predeterminada sin eliminar el acceso a los datos anteriores.

Desafío: cifrado

Los dispositivos no cifrados suelen ser los culpables de que las funciones de reinicio manual no funcionen correctamente. Los restablecimientos manuales pueden ser efectivos cuando los datos están encriptados desde la configuración inicial del dispositivo, pero no son efectivos cuando el dispositivo no está encriptado o lo fue más tarde.

Cuando los datos no están cifrados en un dispositivo, los datos a menudo permanecen en segundo plano después de un reinicio, porque el reinicio no sobrescribe los datos. Si bien no se ve visualmente cuando se inspecciona el dispositivo en busca de datos, se puede acceder a él mediante un software comercial cuando se conecta a una computadora y se escanea en busca de datos. Por el contrario, es menos probable que los dispositivos cifrados se puedan recuperar con software comercial. Si bien el dispositivo se restablece de manera similar sin sobrescribir los datos, una vez que se destruye la clave de cifrado en el proceso de restablecimiento, no hay forma de leer los datos.

Esto puede resultar confuso porque, aunque el cifrado de datos puede ser el predeterminado en un dispositivo, es posible que no sea obligatorio. Si se puede desactivar el cifrado, entonces puede exponer los datos a partir de ese momento. Es complejo y requiere experiencia técnica para evaluar y guiar el proceso de desinfección de datos para cada modelo de dispositivo y no hacer suposiciones generales.

Verificación de Saneamiento con “Software Comercial” – Apéndice B(13)

“Software comercial” en el Apéndice B(13) se refiere al nivel de las técnicas de recuperación de datos aplicadas al método de muestreo. Este requisito en R2v3 es similar a NIST SP 800-88 Rev. 1 en la Sección 4.7.3 donde la tarea es volver a leer el almacenamiento en el dispositivo para verificar que se haya sobrescrito o que los datos anteriores sean inaccesibles (fuera de un laboratorio). Efectivamente, R2v3 establece el nivel de desinfección de datos lógicos entre Clear y Purge, como se describe en NIST SP 800-88 Rev.1 Sección 2.5.

Borrar es efectivo para dispositivos en los que se pueden sobrescribir todas las ubicaciones de almacenamiento direccionables. Algunos dispositivos propietarios no ofrecen opciones para sobrescribir. Los restablecimientos del fabricante pueden ser la única opción para borrar un dispositivo. De acuerdo con la Tabla 5.1, "Estos aún cumplen con la definición de Borrado siempre que la interfaz del dispositivo disponible para el usuario no facilite la recuperación de los datos Borrados".  La inspección visual de un dispositivo borrado no cumpliría con los requisitos del Apéndice B(13) y, por lo tanto, Borrar usando un restablecimiento de fábrica no siempre es una opción efectiva para R2v3.

Sin embargo, Purge va un paso más allá de lo que requiere R2v3. Purge “hace que la recuperación de datos de destino no sea factible utilizando técnicas de laboratorio de última generación.  R2v3 no requiere este nivel de saneamiento lógico para que los datos no puedan recuperarse mediante técnicas científicas de recuperación forense.. El Apéndice B(13) requiere un nivel no recuperado por “software comercial”.

El Apéndice B(13) es diferente a verificar que un registro de limpieza de datos esté disponible para los medios. Este requisito se basa en la técnica de intentar recuperar datos del dispositivo. A menudo, esto se puede lograr con productos de software comerciales para la recuperación de datos, que a menudo se utilizan cuando un usuario pierde datos en un disco duro defectuoso u otro dispositivo. Este tipo de software suele ser gratuito cuando se usa solo para buscar datos reconocibles en un dispositivo.

Si no se puede acceder físicamente a un dispositivo mediante software comercial porque no hay forma de conectar un dispositivo funcional (sin puerto IO o acceso remoto), entonces, por diseño, no hay forma de recuperar datos mediante software comercial. Esto requeriría un análisis forense para posiblemente recuperar datos, lo que va más allá del requisito establecido en el Apéndice B (13).