Exportar (0) Imprimir
Expandir todo
Expandir Minimizar

Desmistificación del cumplimiento de las normas

2006

Publicado: 26 de Enero de 2007

Security Innovation, Inc.

Resumen: Para un desarrollador, entender a fondo las cuestiones relacionadas con el cumplimiento de las normas puede resultar tanto difícil como frustrante. Este artículo hace que el cumplimiento de las normas cobre sentido desde el punto de vista del desarrollador. Se examinarán las normas de Sarbanes-Oxley, HIPAA, entre otras, y se hablará sobre las recomendaciones más importantes comunes a diferentes legislaciones.

En esta página

Introducción Introducción
Sarbanes-Oxley, sección 404 Sarbanes-Oxley, sección 404
Ley de portabilidad de seguros médicos y responsabilidad Ley de portabilidad de seguros médicos y responsabilidad
Estándar de seguridad de datos en el sector de tarjetas de pago Estándar de seguridad de datos en el sector de tarjetas de pago
Instalación del hardware Instalación del hardware
Ley de Gramm-Leachy Bliley Ley de Gramm-Leachy Bliley
SB 1386 SB 1386
Tecnologías y técnicas Tecnologías y técnicas
Otros elementos normativos Otros elementos normativos
Recomendaciones técnicas y tecnológicas Recomendaciones técnicas y tecnológicas
Conclusión Conclusión

Introducción

Para un desarrollador, entender a fondo las cuestiones relacionadas con el cumplimiento de las normas puede resultar tanto difícil como frustrante. La mayoría de los desarrolladores no tiene conocimientos jurídicos y, generalmente, los reguladores no tienen conocimientos sobre el desarrollo de software. Como resultado, se generan errores de comunicación: El lenguaje y los requisitos descritos en la legislación no son fáciles de adaptar a los requisitos explícitos del software. El problema se nutre de una creciente diversidad de normas a varios niveles (estatal, federal o autonómico e internacional) que termina conformando un puzzle de requisitos de cumplimiento con aplicaciones que a veces se superponen unas a otras. Este documento intenta salvar esta distancia y dar sentido a la cuestión del cumplimiento de las normas desde el punto de vista del desarrollador. Hemos invertido tiempo en leer y analizar la legislación para que usted no tenga que hacerlo. Si bien este documento puede no contener cada uno de los pormenores que necesita, puede ofrecerle un buen punto de partida para ayudarle a centrarse en las áreas correctas a fin de tener éxito en sus objetivos en materia de cumplimiento

Este documento trata a fondo seis de las leyes más importantes, para después entrar en otras cuatro de forma más superficial. Trataremos cuatro áreas de cada ley.

  • Resumen de la legislación: Explica la ley desde el punto de vista del desarrollador, indicando qué se necesita saber para entender las implicaciones en el desarrollo de aplicaciones.

  • Pasos de proceso necesarios: Explica más en profundidad cuáles son los requisitos pertinentes para los desarrolladores de software. Por lo general, esta sección describe los tipos de datos que son considerados confidenciales y cómo deben protegerse éstos.

  • Tecnologías y técnicas: Explica estrategias y técnicas para cumplir con los requisitos legales. Éstas se dividen en cinco categorías principales: Confidencialidad, integridad, disponibilidad, auditoría y registro, y autenticación.

  • Recursos adicionales: Ofrece vínculos a más información sobre la legislación en cuestión.

Tras las secciones sobre legislación se incluye una importante sección titulada "Recomendaciones técnicas y tecnológicas". En esta sección, hemos querido reunir las recomendaciones más importantes comunes a diferentes leyes. Por ejemplo, se encontrará con cuestiones de confidencialidad en la sección sobre HIPAA y podrá ir directamente a la sección de recomendaciones para saber más acerca de cómo mantener la información confidencial.

Es probable que no sepa qué leyes son aplicables, si es que alguna lo es. La tabla siguiente ofrece una descripción breve de cada ley y su área de aplicación:

Ley

Aplicable a:

Sarbanes-Oxley

Privacidad e integridad de datos financieros en corporaciones que cotizan en bolsa.

HIPAA

Confidencialidad, integridad y disponibilidad de información sobre asistencia sanitaria.

PCI

Confidencialidad de información de tarjetas de crédito almacenas y utilizadas por los comercios.

GLBA

Confidencialidad e integridad de información financiera personal almacenada por instituciones financieras.

SB 1386

Confidencialidad de información personal de clientes almacenada por cualquier organización que trabaje en el estado de California.

BASEL II

Confidencialidad e integridad de información financiera personal almacenada por instituciones financieras. Disponibilidad de sistemas financieros. Integridad de la información financiera al transmitirse. Autenticación e integridad de transacciones financieras.

Si su aplicación entra dentro de alguna de estas categorías, es probable que el cumplimiento de las normas sea de vital importancia en su caso. Si no es así, lo será pronto. El cumplimiento de las normas es cada vez más importante para los consumidores de software, y estos requisitos afectan también al desarrollo de software. Simplemente, es un problema que, si se omite, pondrá en peligro su negocio. La buena noticia es que la mayoría de las normas es competencia de los administradores de TI y los procesos de negocio corporativos. Como desarrollador, sólo tiene que preocuparse por un subconjunto de los requisitos que permiten a sus usuarios cumplir con los objetivos de cumplimiento de las regulaciones. Las secciones siguientes describen con todo detalle el significado de todo esto.

Sarbanes-Oxley, sección 404

Resumen de la legislación:

Tras ciertos escándalos financieros, como el del desastre de Enron en 2001, el congreso norteamericano aprobó lo que el presidente George Bush describió como "las reformas de mayor alcance en la práctica empresarial norteamericana desde los tiempos de Franklin Delano Roosevelt". La ley, conocida como Sarbanes-Oxley (y abreviada normalmente como SOX), entró en vigor en 2002 con el propósito de dar a los inversionistas más confianza en el proceso de generación de informes financieros de las compañías que cotizaban en bolsa mediante el establecimiento de sistemas de control que garantizasen la confidencialidad y la integridad de los datos financieros. La ley compete a compañías que cotizan en bolsa en Estados Unidos, pero también tiene aplicación internacional, ya que muchas compañías extranjeras de gran tamaño cotizan también en la bolsa de EE.UU. La parte clave de la ley SOX para los desarrolladores es la sección 404, denominada "Evaluación de los controles internos por parte de los directivos". Esta sección exige a los directivos hacerse responsables de la integridad de la información financiera evaluando sistemas y procesos TI y produciendo pruebas de que la compañía se ha esforzado en mantener a salvo la información confidencial. Si bien la ley SOX no va dirigida al sector de TI directamente, las implicaciones para él son inmensas, ya que la mayoría de los datos financieros de las organizaciones se transmiten a través de sistemas informáticos y el código que escribe el desarrollador.

La ley SOX ha sido una gran propulsora de la seguridad en TI. Entre sus repercusiones está la importancia de la seguridad en TI en los niveles más altos de las organizaciones. La sección 302 de la ley de Sarbanes-Oxley exige al director general y al director financiero que emitan declaraciones periódicas que certifiquen que existen sistemas adecuados para controlar la información financiera de la organización. No ser consciente de que el sistema es vulnerable ya no es una excusa, ya que los ejecutivos superiores ahora tienen que atestiguar que se han instaurado sistemas de control apropiados. La ley impone también penas importantes en caso de tergiversar el estado de los sistemas de control, así como responsabiliza tanto a la organización como al director general y al director financiero personalmente. Para cumplir con la ley SOX, las compañías deben pasar auditorías externas regulares que evalúen los sistemas de control para garantizar que los datos sean exactos, no se hayan modificado y que representen fidedignamente la situación financiera de la compañía. La ley SOX ha generado un gasto significativo en TI y en seguridad TI.

Pasos de proceso necesarios:

Las corporaciones luchan desde el principio por cumplir con la ley SOX, ya que no existe ninguna lista de tareas ni ningún sistema de reglas rápidas que permita comprobar que "cumplen". El cumplimiento de la ley SOX se resume en que las declaraciones de los auditores externos atestigüen que existen sistemas de control que garanticen que los datos financieros se muevan a través de la organización sin modificarse y sólo quedan expuestos ante las personas adecuadas dentro de la organización. Parte del proceso de auditoría es hacer un seguimiento del flujo de la información financiera dentro de la organización. Para la mayoría de las compañías, la mayor parte de este flujo de información se transfiere a través de sistemas de TI. Esto significa que el sector de TI necesita ofrecer la certeza de que estos datos:

  • No pueden ser modificados por individuos no autorizados.

  • No pueden ser vistos por individuos no autorizados.

  • Están disponibles cuando los necesitan las personas autorizadas.

Garantiza también que cualquier cambio material en la infraestructura de TI que toque estos datos se documente, así como que se informe inmediatamente al respecto a los directivos.

El cumplimiento de esta ley se concreta en la implementación de sistemas de control de acceso a los datos que funcionen y que garanticen también que se protejan las vulnerabilidades del sistema y no permitan que se produzcan modificaciones ni filtraciones no autorizadas. Un marco utilizado comúnmente para ayudar al sector de TI a cumplir con las obligaciones que impone la ley SOX es COBIT (objetivos de control para tecnologías de la información y relacionadas), un estándar abierto emitido por el Instituto de control de TI y la Asociación de control y auditoría de sistemas de información.

Tecnologías y técnicas

Fundamentalmente, el cumplimiento de la ley Sarbanes-Oxley se sintetiza en la evaluación de un auditor acerca de la capacidad de una organización de restringir el acceso a los recursos que administran los datos financieros y acerca de los cambios acaecidos en el entorno de TI. Preceptivamente, los desarrolladores tienen que atender a estas obligaciones en las aplicaciones que crean. Para obtener más información sobre cada una de estas áreas, consulte el resumen de recomendaciones más abajo.

  • Confidencialidad: Uno de los requisitos de la ley SOX es que la información confidencial no puede quedar expuesta ante entidades no autorizadas. Apoye el uso de tecnologías de cifrado y algoritmos que garanticen que los datos sólo se divulguen a personas autorizadas. Un sistema de cifrado correctamente implementado ayuda a reducir drásticamente la demanda en sistemas intermedios que no necesitan descifrar ciertos datos y no tienen acceso a material clave.

  • Integridad: El software debe demostrar que los datos no han sido modificados con técnicas como algoritmos criptográficos hash y comprobaciones de integridad sólidas.

  • Disponibilidad: Uno de los requisitos de la ley SOX es que los datos financieros estén disponibles para las personas autorizadas. Esto incluye confiabilidad general del código, resistencia a ataques de denegación de servicio, uso de mecanismos seguros de almacenamiento de datos (inclusive la opción de almacenamiento y recuperación fuera de sitio), mecanismos de conmutación por error (como clústeres), y mecanismos de recuperación y almacenamiento de claves de cifrado en caso de daño del sistema.

  • Controles de acceso: Los desarrolladores necesitan posibilitar el acceso basado en funciones y la revocación de cuentas. La aplicación puede tener que compatibilizar esta función integrándose en marcos de trabajo de administración de identidades más grandes, como LDAP. Revise los derechos de acceso que dé la aplicación a los datos confidenciales. Asegúrese de que cuando la aplicación se instale, las funciones de base de datos, acceso a archivos y el resto de puntos de acceso a datos estén correctamente bloqueados, salvo para las reglas con privilegios para tener acceso a ellos.

  • Auditoría y registro: Una característica clave de los controles TI es auditar y registrar los eventos de los sistemas que procesan datos confidenciales. Es importante asegurarse de que se registran los eventos pertinentes del sistema, como cierres, reinicios o eventos excepcionales. Esto significa que los desarrolladores deben posibilitar la transferencia de estos registros de las aplicaciones a los administradores de una manera segura. El segundo aspecto que considerar es que los registros no deben revelar ninguna información que el sistema trate de proteger, exponiéndola así a su consulta por parte de personas no autorizadas. Evite registrar datos confidenciales, pues no existe garantía de que para obtener acceso a los registros y a los datos confidenciales se requerirán los mismos privilegios.

  • Administración de cambios: La administración de los cambios es una parte clave de la ley Sarbanes-Oxley, ya que exige a las compañías que notifiquen específicamente a la SEC cualquier cambio material realizado en el proceso que gobierna el flujo de datos financieros. Esto es sólo aplicable en su caso si está creando un sistema que rija el flujo de datos financieros y se pueda configurar para cambiar ese flujo. Si es así, necesita cumplir con este requisito dotando a la aplicación de capacidad para registrar los cambios del sistema de manera que estos registros sean capaces de resistir manipulaciones y estén disponibles sólo para usuarios con privilegios. Un ataque habitual que los usuarios malintencionados pueden emplear para manipular los registros es el que desborda el mecanismo de registro con millones de eventos que hace que se pierda información importante o se semioculten datos importantes. Evite esta situación limitando los eventos registrados. También puede considerar crear el registro en un sistema protegido aparte para evitar ataques por parte de usuarios no autorizados.

Recursos adicionales (en inglés)

Ley de portabilidad de seguros médicos y responsabilidad

Resumen de la legislación

La ley de portabilidad de seguros médicos y responsabilidad (HIPAA), aprobada por el congreso de EE.UU. en 1996, estableció la normativa federal que obligaba a médicos, hospitales y otros proveedores de asistencia médica a cumplir con algunos estándares básicos a la hora de trabajar con información sanitaria electrónica protegida (ePHI), como historiales médicos y cuentas médicas de pacientes.

Nota

Estos estándares no pretenden configurar un conjunto final de objetivos para los proveedores de servicios de asistencia médica. Más bien, pretenden servir como punto de partida para garantizar que todas entidades que trabajan con información sanitaria protegida de pacientes sigan un estándar, un conjunto mínimo de reglas que garanticen un nivel común mínimo que asegure la protección. Esto supone también un punto de partida para lograr objetivos más ambiciosos en el sistema nacional de asistencia sanitaria. Si desea consultar la lista completa de iniciativas TI para el sector sanitario, diríjase a http://www.hhs.gov/healthit/federalprojectlist.html#intiativestable (en inglés).

Antes de aprobar la ley HIPAA, la información personal sobre las personas acumulada en bases de datos privadas se consideraba propiedad de la organización propietaria de la base de datos. El concepto subyacente más importante de la ley HIPAA es la noción de que los propietarios de las bases de datos no son necesariamente los propietarios de los datos contenidos en ellas, son sólo intermediarios. Este es un cambio fundamental de paradigma, ya que las organizaciones que cumplen con la norma HIPAA deben garantizar que los propietarios de los registros estén protegidos (Ley de portabilidad de seguros médicos y responsabilidad, http://en.wikipedia.org/wiki/HIPAA) (en inglés):

  • Acceso a sus propios registros y derecho a solicitar la corrección de errores.

  • Conocimiento previo de cómo se usará su información.

  • Consentimiento explícito de las personas implicadas antes de poder utilizar los datos ePHI en marketing.

  • Derecho a exigir y esperar que las organizaciones sanitarias tomen los pasos adecuados para asegurar que las comunicaciones entre la persona y la organización se mantienen privadas.

  • Derecho a remitir quejas formales relacionadas con la privacidad al Ministerio de sanidad y seguridad social.

Dado que las regulaciones deben aplicarse a todos los distintos tipos de servicios y proveedores de asistencia sanitaria, éstas son deliberadamente poco concretas en sí mismas. La sección de disposiciones de seguridad de HIPAA comprende tres conjuntos diferentes de requisitos, cada uno con una lista medidas de seguridad específicas:

  • Las medidas de seguridad administrativas incluyen reglas para establecer e implantar las directivas y procedimientos de privacidad de la compañía (por ejemplo, recuperación de desastres y planes de emergencia).

  • Las medidas de seguridad físicas abarcan restricciones y reglas relacionadas con el acceso físico a instalaciones y equipos, controles de acceso y directivas y procedimientos asociados en relación con las entidades físicas en la organización.

  • Los estándares técnicos contienen todas las medidas de seguridad y las prácticas relacionadas con la información intangible contenida en los sistemas informáticos de las organizaciones, tales como prevención de intrusiones, corroboración de datos y controles de acceso. Este artículo se centrará en la sección de estándares técnicos, pues contienen la mayoría de los elementos que incumben a los desarrolladores.

Pasos de proceso necesarios:

La norma HIPAA incluye varias disposiciones divididas en dos títulos. El título I trata sobre la portabilidad de la cobertura del seguro médico de empleados y familias al cambiar de trabajo, y se creó también para garantizar que no se pudiera negar injustamente cobertura a aquellas personas con problemas de salud previos. El título II contiene las disposiciones de "simplificación administrativa" y tiene tres subcategorías: disposiciones de privacidad, disposiciones de intercambio de datos electrónicos HIPAA (HIPAA/EDI) y disposiciones de seguridad (Ley de portabilidad de seguros médicos y responsabilidad, http://en.wikipedia.org/wiki/HIPAA). Aquí no trataremos las disposiciones de privacidad y las disposiciones HIPAA/EDI, ya que implican principalmente políticas de empresa y procedimientos operativos internos [ministerio estadounidense sanidad y seguridad social, "Simplificación administrativa en el sector de asistencia sanitaria (en inglés), http://aspe.hhs.gov/admnsimp/] que escapan al alcance de este documento. Las disposiciones de seguridad son las que interesan principalmente a los desarrolladores, ya que integran los objetivos técnicos específicos de cumplimiento de regulaciones.

Las disposiciones de seguridad incluyen:

  • Garantía de confidencialidad, integridad y disponibilidad de toda la información ePHI que cree, reciba, transmita o mantenga la entidad de asistencia sanitaria.

  • No divulgación de la información ePHI no permitida o requerida.

  • Garantía de que esa información del sistema esté disponible para auditorías.

  • Garantía de que exista un sistema de autenticación que certifique que trabajadores o entidades específicos sean quienes dicen ser.

Al analizar los pasos del proceso, es importante clarificar los dos tipos de especificaciones declaradas en la sección de estándares técnicos de la norma HIPAA:

  • Las especificaciones necesarias son especificaciones que se pueden cumplir uniformemente en cuanto a la totalidad del estándar y por parte de todas las organizaciones. Por ejemplo, cualquier organización que quiera cumplir con la norma HIPAA deberá aceptar un nivel suficiente de solidez de cifrado para asegurar la privacidad del historial del paciente.

  • Las especificaciones referenciables dependen de una evaluación en términos de adecuación basada en consideraciones pragmáticas y circunstanciales. Por ejemplo, para cumplir con los requisitos de auditoría de HIPAA, las organizaciones necesitan implementar algún tipo de sistema de copia de seguridad y almacenamiento. Una consulta pequeña no necesita una solución de la misma magnitud que por ejemplo un hospital general. Las especificaciones referenciables proporcionan a la organización cierto nivel de control para decidir el grado de adecuación a la norma. Los elementos de cumplimiento referenciables no se deben tomar como opcionales, pues son obligatorios.

Tecnologías y técnicas

Hay varias tecnologías específicas fácilmente disponibles y que pueden satisfacer prácticamente las necesidades de los pasos del proceso mencionados anteriormente. Para obtener más información sobre cada una de estas áreas, consulte el resumen de recomendaciones siguiente.

  • Confidencialidad: Todos los datos ePHI deben mantenerse confidenciales para evitar que partes no autorizadas puedan obtener acceso a las cuentas de los propietarios de los historiales. Utilice un sistema de cifrado de alta seguridad apropiado para almacenar datos confidenciales en bases de datos o en archivos, al transmitirlos por una red o cuando los datos estén en la memoria. Diseñe software de modo que los algoritmos de cifrado sean reemplazables y los tamaños de las claves se puedan aumentar fácilmente para que la solidez del cifrado pueda adecuarse a los avances informáticos y los trucos de manipulación de algoritmos.

  • Integridad: Los historiales no deben poder modificarse por parte de personas ni entidades no autorizadas. Los desarrolladores necesitan aplicar los principios de privilegios mínimos y llevar a cabo un meticuloso sistema de administración de errores para minimizar el riesgo de elevación de privilegios. Toda la información confidencial debe utilizar un mecanismo de comprobación de la integridad como HMAC-SHA1 o un sistema de firma digital para limitar el riesgo de alteración de la información.

  • Disponibilidad: Dado que los propietarios de los historiales tienen garantizado el acceso a sus propios historiales, la falta de disponibilidad del servicio podría generar una infracción del cumplimiento de la norma HIPAA. Los desarrolladores deben diseñar sistemas que puedan administrar correctamente los errores y resistir a los ataques de denegación de servicio. Los registros de eventos deben contener suficiente información como para hacer posible reconstruir la actividad del sistema hasta el momento en que se produjo el error, de modo que pueda ser resuelto rápidamente.

  • Auditoría y registro: Todas las acciones de las que sea necesario hacer seguimientos deben quedar documentadas. Los sistemas de software deben generar toda la información de registro necesaria para poder reconstruir un recorrido de auditoría claro que muestre cómo intentó un usuario o una entidad tener acceso a los recursos y utilizarlos. Asegúrese de que se hacen copias de seguridad frecuentes de estos registros para evitar que se pierda información de auditoría por error del sistema.

  • Autenticación: Para trabajar de forma segura con información ePHI, es necesario saber que la entidad o la persona que va a utilizar los datos está legitimada y autorizada para tener acceso a dicha información. Los permisos son un conjunto de asignaciones que atribuyen a la identidad de una persona o una entidad un conjunto específico de operaciones posibles. Los sistemas de autenticación se deben diseñar asignando funciones claramente definidas a permisos para que sean más fácil de implementar para los desarrolladores y para que los evaluadores puedan descubrir mejor posibles casos de infracción. A la hora de configurar sistemas de autenticación, asegúrese de que el sistema implanta contraseñas seguras desde el principio.

Recursos adicionales (en inglés)

Estándar de seguridad de datos en el sector de tarjetas de pago

Resumen de la legislación:

El estándar de seguridad de datos en El sector de tarjetas de pago (PCI) se basa en programas de seguridad que crearon de forma independiente cuatro servicios de tarjeta independientes: el programa de seguridad de información de cuentas VISA (AIS) y su programa de seguridad de información de titulares de tarjeta (CISP) afiliado, el programa de protección de datos del sitio de Mastercard (SDP), la política operativa de seguridad de American Express (DSOP) y el programa de cumplimiento normativo y seguridad de información de Discover (DISC).

PCI establece un conjunto completo de estándares de seguridad mundiales para todos los comerciantes y proveedores de servicios relacionados con el almacenamiento, la transmisión o el procesamiento de datos de titulares de tarjetas de todos los servicios principales correspondientes. El cumplimiento del estándar de seguridad de datos del sector de tarjetas de pago (PCI) es obligatorio para comerciantes y proveedores de servicios de todos los canales de pago, inclusive tiendas con presencia física, pedidos por correo y teléfono y comercio electrónico. Este estándar cubre los sistemas, las políticas y los procedimientos (Medios interactivos en grupos de venta, http://www.imrg.org/IMRG/Library.nsf/0/ECB04B83B24D62D180256FEA00439EAF?OpenDocument) (en inglés).

Pasos de proceso necesarios:

Para certificar el cumplimiento oficial con el estándar PCI, se debe realizar una auditoría que compruebe que los estándares se cumplen adecuadamente. A ésta le siguen auditorías de cumplimiento con la normativa trimestrales y anuales, cuyos requisitos exactos dependerán de la clasificación del comerciante (nivel 1, 2, 3 o 4). Los comerciante se categorizan en niveles diferentes según su volumen promedio anual de transacciones de tarjeta de crédito (Medios interactivos en grupos de venta, detalles acerca de los criterios de selección, http://www.imrg.org/pci_compliance_uk.pdf ) (en inglés). Cuantas más transacciones procese una organización, más importante será que cumpla con los estándares PCI para salvar riesgos más grandes. Esta división corresponde a un intento de conciliar las dificultades asociadas a la necesidad de equilibrar la seguridad con la carga práctica. Hay varios objetivos ampliamente definidos que han de seguir los desarrolladores de software de organizaciones comerciales para lograr cumplir con el estándar (Medios interactivos en grupos de venta, detalles específicos de los pasos de proceso del estándar de seguridad de datos PCI, http://www.imrg.org/pci_compliance_uk.pdf) (en inglés):

  • Proteger los datos de los titulares de las tarjetas.

  • Implementar medidas seguras de control de acceso.

  • Supervisar y probar regularmente las redes.

Desgraciadamente, la capacidad de los comerciantes de descubrir las infracciones en privacidad e implantar medidas correctivas se ven entorpecidas drásticamente por la legislación y por los asuntos técnicos derivados del hecho de que las pruebas forenses para emprender dichas acciones son incompletas para todos los comerciantes. Una postura defensiva es realmente la única opción para el comerciante que deba desarrollar código que opere con datos de tarjetas de crédito.

Tecnologías y técnicas

Las estrategias siguientes son aplicables al cumplimiento del estándar PCI. Para obtener más información sobre cada una de estas áreas, consulte el resumen de recomendaciones siguiente.

  • Confidencialidad y autenticación: Este es el objetivo central del estándar PCI: proteger la información de las tarjetas de crédito de los consumidores. Desgraciadamente, los desarrolladores no tienen control total y global sobre el proceso de operación de tarjetas de crédito. En un mundo ideal, los datos de las tarjetas de crédito se podrían intercambiar directamente entre la compañía de la tarjeta de crédito y la persona, pero raramente es el caso. Los datos de las tarjetas de crédito a menudo pasan por varios agentes intermediarios, algunos de los cuales los consumidores ni siquiera ven, pero todos ellos se ven obligados a confiar de forma implícita. La mejor solución que se puede implementar desde la perspectiva de una sola organización es la de asegurar que los datos se hayan cifrado correctamente y que sólo los sistemas o los agentes autorizados puedan tener acceso a la información de cuenta confidencial. No es una solución eficaz globalmente, pero salvará a la compañía de las costosas multas que podría contraer en caso de infringir y divulgar datos privados.

  • Registro y auditoría: Este es el segundo aspecto más importante en cuanto a cumplimiento del estándar PCI. Los desarrolladores deben garantizar que su código proporcione vínculos para registrar todas las transacciones de las cuentas pertinentes y todos los accesos a ellas. Desgraciadamente, es muy difícil para los comerciantes determinar proactivamente casos de fraude de tarjetas de crédito, ya que no disponen de un banco centralizado de comportamientos que indique qué pautas de uso son sospechosas en una cuenta dada. Supervisar los comportamientos es tarea de las agencias de emisión y seguimiento de tarjetas de crédito. Desde la perspectiva del desarrollador, es importante garantizar que esta información quede registrada, de modo que las aplicaciones desarrolladas internamente no generen vacíos de responsabilidad cuando los agentes policiales soliciten los datos registrados.

Recursos adicionales (en inglés)

Instalación del hardware

Resumen de la legislación:

La ley de Gramm-Leachy Bliley (GLBA) la aprobó el senado estadounidense en noviembre de 1999 con objeto de facilitar una amplia reforma del sector de servicios financieros. La ley la propuso el senador Phil Gramm, de Texas, para mejorar las prácticas competitivas en el sector de servicios financieros ofreciendo un marco para la afiliación de bancos, de firmas de seguridad y de otros proveedores de servicios financieros (Biblioteca del Congreso, "Thomas," http://thomas.loc.gov/cgi-bin/bdquery/z?d106:SN00900) (en inglés).

La ley GLBA intentó "modernizar" los servicios financieros, es decir, terminar con la normativa que impedía que se fusionaran los bancos, las compañías de correduría de acciones y las compañías de seguros. La desaparición de estas regulaciones hizo que surgieran riesgos considerables en el sentido de que estas nuevas instituciones financieras tendrían acceso a una cantidad increíble de información personal, sin restricciones sobre su uso (Centro de información de privacidad electrónica, Chris Jay Hoofnagle y Emily Honig, "Victoria's Secret y la privacidad financiera", http://www.epic.org/privacy/glba/victoriassecret.html) (en inglés). Mientras que la ley en sí no especifica requisitos explícitos de privacidad y protección de la información del cliente, hay tres disposiciones que constituyen los requisitos de privacidad de la ley GLBA: la regla de privacidad financiera, la regla de medidas de seguridad y las disposiciones relativas al método de "pretexting", o robo de identidad.

La ley GLBA estadounidense autoriza a ocho agencias federales y a los estados para administrar e implantar la regla de privacidad financiera y la regla de medidas de seguridad. Las reglas de privacidad financiera y medidas de seguridad incumben a instituciones financieras, entre ellas bancos, sociedades de valores, compañías de seguros y compañías que ofrecen otros tipos de productos o servicios financieros al consumidor. Entre estos servicios están los de préstamos, correduría o administración de cualquier tipo de préstamo al consumo, transferencia o garantía de capitales, preparación de declaraciones de la renta individuales, consejo financiero o crediticio, servicios de información de liquidación de bienes raíces o recopilación de deudas. La ley GLBA responsabiliza personalmente específicamente a los directores y directores generales de las compañías de todo uso indebido de información personalmente identificable. El incumplimiento de la ley GLBA implica la contracción de multas por parte de la institución financiera infractora.

Pasos de proceso necesarios:

La ley GLBA permite establecer lazos más fuertes entre bancos, sociedades de valores y compañías de seguros, con la restricción de que las instituciones financieras y sus socios están obligados a proteger los datos personales privados e implementar diferentes sistemas de control de acceso y seguridad. El principal objeto de la ley GLBA es garantizar la integridad y la confidencialidad de la información y los registros de los clientes. La información financiera personal de los clientes consiste en el nombre, la dirección, el número de seguridad social (o de carnet de identidad), el número de cuenta y cualquier otra información que un cliente proporciona en una aplicación de contabilidad. Durante la recopilación, implantación y prueba de los requisitos, es importante tener en mente estos objetivos de integridad y confidencialidad. Si se tiene en cuenta esta cuestión durante cada fase del ciclo de vida de desarrollo será mucho menos probable que pueda pasarse por alto un problema.

Tecnologías y técnicas

Las estrategias siguientes son aplicables al cumplimiento del estándar GLBA. Para obtener más información sobre cada una de estas áreas, consulte el resumen de recomendaciones más abajo.

  • Confidencialidad: Toda la información del cliente debe mantenerse confidencial para evitar que partes no autorizadas puedan obtener acceso a sus cuentas. Los desarrolladores deben utilizar un sistema de cifrado de alta seguridad y de hash, pero deben asegurarse también de que las rutinas empleadas para administrar el sistema de cifrado, descifrado y firma son estándares en el sector. No utilice nunca rutinas de cifrado personalizadas. Asegúrese de que esas rutinas de cifrado sean modulares para que puedan reemplazarse con un gasto mínimo. No se apoye en bibliotecas de cifrado no seguras. Carecen de rigor o contienen vulnerabilidades que ponen en peligro el sistema de cifrado.

  • Integridad: Los historiales no deben poder modificarse por parte de personas ni entidades no autorizadas. Los desarrolladores necesitan aplicar los principios de privilegios mínimos y llevar a cabo un meticuloso sistema de administración de errores para minimizar el riesgo de elevación de privilegios. En software, es en las rutinas de administración de errores que se ejecutan con menos frecuencia donde se producen comportamientos inesperados que pueden llevar a un aumento de privilegios o generar un error inesperado. Toda la información confidencial debe utilizar un mecanismo de comprobación de la integridad como HMACSHA1, o un sistema de firma digital para limitar el riesgo de alteración de la información.

  • Auditoría y registro Todas las acciones de las que sea necesario hacer seguimientos deben quedar documentadas. Los sistemas de software deben generar toda la información de registro necesaria para poder reconstruir un recorrido de auditoría claro que muestre cómo intentó un usuario o una entidad tener acceso a los recursos y utilizarlos. Asegúrese de que se hacen copias de seguridad frecuentes de estos registros para evitar que se pierda información de auditoría por error del sistema. No incluya información confidencial en sus registros; es posible que la publicación no autorizada de información de clientes provenga de individuos con acceso legítimo a dichos registros.

  • Es importante analizar las pautas de acceso de los usuarios, ya que generalmente se puede destapar un uso ilegítimo de los datos observando pautas de uso que habrían pasado desapercibidas si el acceso a los datos hubiera tenido lugar siempre a través de canales legítimos. Por ejemplo, consulte los tiempos de acceso. Si un intercambio bancario se produce en horas de oficina normales, y hay una serie de transacciones en cuentas específicas que se producen en horas raras, podría ser indicio de un filtraje. Dado que cada institución tiene su propio conjunto de reglas empresariales, los desarrolladores y los jefes de operaciones podrán ampliar estos comportamientos sospechosos para obtener una idea más específica de qué buscar. Desde la perspectiva del desarrollador, tener en cuenta los tipos de información que puede ser interceptada para facilitar este enfoque basado en comportamientos le ahorrará tiempo y esfuerzo a la larga.

Recursos adicionales (en inglés)

Ley de Gramm-Leachy Bliley

Resumen de la legislación

SB 1386 es un proyecto de ley del estado de California que enmendó las leyes del derecho a la intimidad existentes para incluir estipulaciones que obligasen a dar a conocer las infracciones a la privacidad por parte de cualquier organización o individuo que guardase información personal acerca de clientes y operase en el estado de California. La información personal de los clientes se define oficialmente en el proyecto de ley como una que contiene el nombre del cliente o su inicial y su apellido, junto con uno de los datos siguientes como mínimo (LegalArchiver.org, "California SB 1386," http://www.legalarchiver.org/sb1386.htm):

  • Número de seguridad social.

  • Número de permiso de conducir o número de carnet de identidad de California.

  • Número de cuenta bancaria o de tarjeta de crédito o débito, junto con posibles códigos de seguridad necesarios, código de acceso o contraseña que permitiría obtener acceso a la cuenta financiera de un individuo.

Uno de los campos anteriores como mínimo debe estar disponible en forma no cifrada para constituir una infracción del derecho de privacidad (por ejemplo, si se filtran uno o todos los registros del cliente, pero todos los campos están cifrados, no se considera una infracción). Si toda la información personal filtrada está públicamente disponible a través de otras fuentes, no se considera una infracción del derecho a la privacidad. Las disposiciones aplicables del proyecto de ley SB 1386 entraron en vigor el 1 de julio de 2003.

El SB 1386 es un ejemplo de cómo los estados norteamericanos ponen en sus propias manos toda cuestión relacionada con la privacidad y toman las medidas necesarias para proteger la información privada de sus residentes.

Pasos de proceso necesarios

El proyecto de ley SB1386 es un conjunto de reglas muy directo y restringido ideado para asegurar que se guarda confidencialidad en la información del cliente. El ámbito de aplicación, muy claramente restringido, y la falta de ambigüedad en la redacción jurídica han dado a los legisladores considerable poder en su capacidad para aplicar el proyecto de ley SB 1386 en casos diferentes. Ya se han documentado muchos casos de infracción por parte de las compañías. (Consulte la cronología de infracciones de datos en la sección de referencia que sigue para ver casos específicos de la aplicación de la ley.)

Por motivos prácticos, este proyecto de ley incluye dos pasos específicos para su cumplimiento:

  1. Garantizar la privacidad de los datos del cliente a toda costa.

  2. Dar a conocer todos los casos en los que hay razones para sospechar que la información personal adscrita a los criterios anteriormente mencionados se haya divulgado inadecuadamente o haya sido adquirida por parte de una persona o entidad no autorizadas. Estas situaciones se deben dar a conocer directamente a los afectados lo antes posible. La única advertencia en cuanto a la divulgación sin dilación de infracciones en materia de privacidad es que la notificación en cuestión correspondiente no puede afectar a ninguna investigación criminal en curso.

Tecnologías y técnicas

Las estrategias siguientes son aplicables al cumplimiento del estándar SB 1386. Para obtener más información sobre cada una de estas áreas, consulte el "Resumen de recomendaciones" siguiente.

  • Confidencialidad: Asegurar la privacidad de los datos del cliente es uno de los objetivos principales del SB1386. Un examen cuidadoso de la legislación de la sección II, párrafo (e) revela una disposición específica: "En el ámbito de esta sección, 'información personal' significa el nombre de una persona o su inicial y su apellido, junto con uno o más de los datos siguientes, cuando o el nombre o los datos no estén cifrados." Esto viene a decir que si un atacante obtiene los datos, no supondrá necesariamente una infracción a menos que uno de los campos no esté adecuadamente cifrado. Al almacenar cualquier dato del cliente, es indispensable utilizar un sistema de cifrado para cumplir con la ley.

  • Auditoría y registro: Uno de los aspectos técnicamente más exigentes a la hora de cumplir con la disposición de divulgación total del proyecto de ley SB 1386 es detectar cuándo se producen infracciones en materia de privacidad. Los atacantes que quieran robar información no harán ningún daño a los sistemas que pretenden poner en peligro. La falta de daños evidentes implica que los signos de intrusión más obvios que normalmente pondrían sobre aviso a los investigadores acerca de la presencia de movimientos extraños no son fáciles de apreciar. La única manera de tratar de forma eficaz el problema de las intrusiones es garantizar que se registre cada transacción y se audite de forma irregular pero repetida, bien con revisiones manuales o a través de un motor de análisis basado en comportamientos. Los desarrolladores deben tener presente esta información y proporcionar los vínculos necesarios en su código para hacer un seguimiento de todas transacciones pertinentes, de modo que quede constancia de todo.

Recursos adicionales (en inglés)

SB 1386

Resumen de la legislación:

El nombre oficial de BASEL II es Convergencia internacional de medición y estándares de capital. Se trata de un marco de trabajo establecido por el comité Basel, un consorcio de bancos centrales de varios países. El objetivo de BASEL II es revisar los estándares internacionales existentes utilizados para medir la viabilidad del capital de un banco. El acuerdo anterior de BASEL se considera ya anticuado, dado que las normas no reflejan varias de las realidades de la banca mundial moderna. Por ejemplo, el acuerdo original de BASEL no tenía en cuenta el arbitraje de un mercado a otro.

Nota

"Arbitraje" significa esencialmente que hay que tener en cuenta las desigualdades y los desequilibrios de un mercado a otro al evaluar el valor de las instituciones financieras activas internacionalmente. Esto es especialmente así en el caso de bancos internacionales, ya que su valor estimado depende en gran parte en un sistema de igualdad respaldado por los mercados internacionales.

Pasos de proceso necesarios:

La mayor parte de BASEL II se ha redactado para los profesionales de la banca. Dado que BASEL II es un estándar internacional, está escrito de manera que se puede aplicar a una variedad de sistemas bancarios mundiales. Estas realidades justifican la vaguedad de los requisitos desde la perspectiva del sector TI, por lo menos en términos de objetivos de cumplimiento justiciables. Sin embargo, existe una importante cantidad de información disponible que describe los riesgos y los procedimientos atenuantes para banca y servicios financieros electrónicos. Esta es una recopilación de algunas de las fuentes consideradas más pertinentes para BASEL II desde la perspectiva del desarrollador. Para obtener una lista completa de todas las fuentes a las que se hace referencia, consulte la sección adjunta que sigue.

Si bien esta no es una lista exhaustiva, los siguientes pasos del proceso le ayudarán a garantizar que se cumpla la normativa BASEL II:

  • Evite que se divulgue información inadecuadamente.

  • Evite que se ejecuten transacciones no autorizadas en el sistema informático.

  • Evite que se produzcan cambios no autorizados en el software durante el desarrollo de rutinas y operaciones de mantenimiento que puedan permitir realizar transacciones fraudulentas, no deje ciertas clases de operaciones sin comprobar ni deshabilite la función de registro con propósito de eludir auditorías para que algunas acciones pasen desapercibidas.

  • Evite la intercepción y modificación de transacciones al transmitirse a través de sistemas de comunicaciones como teléfono, datos y redes satélite.

  • Evite interrupciones de servicios por error de hardware o software.

Tecnologías y técnicas

Las estrategias siguientes pueden ayudar a garantizar la ejecución de los pasos de proceso anteriores.

Nota

La mayoría de las técnicas para asegurar el cumplimiento del proceso puede funcionar como clientes que hagan de agentes que interactúen directamente con los bancos o una transacción de un tercero de una institución financiera a otro.

Para obtener más información sobre cada una de estas áreas, consulte el resumen de recomendaciones siguiente.

  • Confidencialidad: Los datos financieros deben permanecer confidenciales e intactos a toda costa. Los desarrolladores necesitan aplicar los principios de privilegios mínimos y llevar a cabo un meticuloso sistema de administración de errores para minimizar el riesgo de elevación de privilegios o error inesperado. En software, es en las rutinas de administración de errores que se ejecutan con menos frecuencia donde se producen comportamientos inesperados que pueden llevar a un aumento de privilegios. Asegúrese de que esas rutinas de cifrado sean modulares para que puedan reemplazarse con un gasto mínimo. No se apoye en bibliotecas de cifrado no confiables, ya que carecen de rigor o contienen vulnerabilidades que debilitan o ponen en peligro los datos cifrados.

  • Disponibilidad: Antes de que los sistemas bancarios estuvieran tan complejamente relacionados entre sí, el procedimiento operativo estándar en caso de inactividad del equipo informático implicaba volver a los procesos manuales existentes antes de integrar la informática en el sistema. Sin embargo, la dependencia en las comodidades que ofrecen los sistemas automatizados ha hecho que la opción de volver al cálculo manual quede desbancada por ser poco práctica. Como resultado, el tiempo de inactividad del equipo resultará inevitablemente en pérdidas, de modo que deberán existir planes de emergencia en caso de que se produzcan eventos inesperados. Cada sistema debe estar tener una segunda réplica como mínimo. La conmutación por error debe ser inmediata y automática en todos estos sistemas. La disponibilidad se señala generalmente como responsabilidad de los administradores de sistemas y profesionales de TI, pero los desarrolladores pueden afectar indirectamente a la disponibilidad de un sistema mejorando la portabilidad de las aplicaciones que desarrollan y asegurando su confiabilidad y solidez mediante buenas prácticas de codificación.

    Nota

    En el caso de sistemas críticos de gran tamaño, se implementan algunas aplicaciones en entornos heterogéneos para aumentar la variación e incrementar a ser posible la probabilidad de que las condiciones que contribuyan al error del sistema puedan no afectar a una parte diferente del entorno operativo. Por ejemplo: Un servidor web podría implementarse en un sistema Microsoft Windows NT que ejecute IIS, y otro servidor web se podría implementar en un sistema Red Hat Linux que ejecute un servidor web Apache. Si un gusano de Internet hace que el servidor Linux esté inactivo, quizás no afecte al servidor Windows. En este caso, la variación del entorno proporciona cierto nivel de protección, de manera muy parecida presumiblemente al funcionamiento de la variación genética en los sistemas biológicos.

  • Administración de cambios: Es importante que los desarrolladores se responsabilicen de los cambios realizados en los sistemas de software. Las modificaciones en el software bancario que permiten ejecutar transacciones fraudulentas no las han realizado virus de fuentes externas, sino desarrolladores o empleados enfurecidos. Es necesario instaurar medidas en materia de responsabilidad que eviten que las personas puedan insertar cambios arbitrarios en los sistemas de software bancarios críticos. El código se debe revisar con frecuencia por parte de equipos de desarrolladores y evaluadores para garantizar que los cambios sean justificados. Se deben instaurar sistemas de control de fuentes que eviten que se realicen cambios no autorizados, a ser posible implantando alguna clase de listas de control de acceso, o como mínimo, marcando los cambios recientes para revisarse de modo que se pueda construir un recorrido claro de auditoría en caso de sospecha.

  • Autenticación: Es necesario garantizar que las transacciones llevadas a cabo dentro de los bancos se ejecuten únicamente a través de agentes legítimos. La autenticación es el medio principal para garantizar que los agentes sean quien reclaman ser. A la hora de configurar sistemas de autenticación, asegúrese de implantar contraseñas seguras. No habilite ni proporcione cuentas de "invitado" ni otros medios de acceso que no se correspondan con identidades específicas para las cuentas y los recursos utilizados. Al almacenar las contraseñas, asegúrese de utilizar cifrado de alta seguridad capaz de proteger las credenciales frente a atacantes que quizás obtengan acceso a ellas. Emplee tecnologías como SSL y certificados digitales. Implante directivas de contraseñas que hagan caducar las credenciales con bastante frecuencia.

  • Asegúrese de que, ante cierto tiempo de inactividad, se cierre el sistema automáticamente cuando el usuario permanezca inactivo durante un espacio de tiempo específico. Si permite a los usuarios tener acceso a información de cuentas de forma remota a través de una red no segura, como Internet, piense en usar un sistema de autenticación en dos fases para reducir la probabilidad de robo de las identidades de cuentas. Procure usar identificadores de usuario no estándar y no consecutivos. Por ejemplo, muchos bancos permiten a los usuarios iniciar sesión con su número de seguridad social (o carnet de identidad) como nombres de usuario. No es buena idea, porque el número de seguridad social (o del carnet de identidad) es en sí mismo un dato confidencial y no debe quedar expuesto. También se considera un número inmutable excepto en casos únicos, y de quedar expuesto un número de seguridad social (o carnet de identidad), no se puede hacer nada por cambiar ni esconder las credenciales de la cuenta de usuario para evitar mayores alteraciones.

Recursos adicionales (en inglés)

Definición y ejemplos de arbitraje económico: http://economics.about.com/cs/finance/a/arbitrage.htm

Estándares de BASEL II: http://www.bis.org/publ/bcbs118.htm

Administración de riesgos en banca electrónica y actividades monetarias electrónicas: http://www.bis.org/publ/bcbs35.pdf

Riesgos en los sistemas de telecomunicaciones e informáticos: http://www.bis.org/publ/bcbsc136.pdf

Cronología de divulgaciones obligadas de infracciones en materia de privacidad desde febrero de 2005: http://www.privacyrights.org/ar/ChronDataBreaches.htm

Otros elementos normativos

Resumen de la legislación

Esta sección ofrece un breve resumen de dos leyes y un estándar con menos probabilidad de afectar al desarrollo de su aplicación.

Ley federal de administración de seguridad de la información

La ley federal de administración de seguridad de la información (FISMA) norteamericana se aprobó en 2002 con objeto de imponer un conjunto de estándares de seguridad de la información reconocidos a nivel federal. La ley declara que es obligatorio cumplir con los estándares federales de procesamiento de la información (FIPS) para todas las agencias gubernamentales. Si vende software a cualquier rama del gobierno federal, deberá cumplir con la ley. Como muchas de las otras leyes descritas, la ley FISMA se centra en la confidencialidad, la integridad y la disponibilidad de la información reservada. La ley contiene instrucciones para medir la posible repercusión de una infracción, y determina por lo tanto el nivel de protección necesario.

Puede encontrar más información en http://csrc.nist.gov/sec-cert/ (en inglés).

B 7799

Las B 7799 (instrucciones para la administración de riesgos de seguridad de la información) son un conjunto de recomendaciones que probablemente pasen a ser un estándar ISO en un futuro próximo. Se trata de un conjunto exhaustivo de estándares que cubren:

  • Evaluación de riesgos.

  • Tratamiento de riesgos.

  • Toma de decisiones de administración.

  • Reevaluación de riesgos

  • Supervisión y revisión de perfiles de riesgo.

  • Riesgo de seguridad de la información en el contexto de gobernanza corporativa.

  • Cumplimiento de otros estándares y regulaciones basadas en riesgos.

El propósito de las B 7799 es ayudar a una organización a establecer una política de seguridad de la información exhaustiva.

Puede encontrar más información en http://www.thewindow.to/bs7799/index.htm (en inglés).

Directiva de protección de datos de la UE

La directiva de protección de datos de la UE entró en vigor en octubre de 1998 y define un estándar que permite someter a juicio los casos de divulgación de datos confidenciales y prohíbe transferir estos datos a cualquier nación que no cumpla con el estándar. Dadas las complejidades de la ley y las interrupciones subsiguientes de las operaciones empresariales de muchas compañías de EE.UU., en julio de 2000 la UE aprobó la ley de Puerto seguro con objeto de racionalizar el proceso. Puerto seguro ofrece un marco que permite garantizar la adecuación del sistema de protección de datos personales en la compañía. Muchos de los requisitos de tal adecuación corresponden a procedimientos. Los que afectan al desarrollo de aplicaciones entran en las categorías habituales: confidencialidad, integridad y disponibilidad de datos reservados.

Puede encontrar más información sobre Puerto seguro en http://www.export.gov/safeharbor/index.html (en inglés).

Para obtener más información sobre la directiva europea de protección de datos, diríjase a http://www.cdt.org/privacy/eudirective/EU_Directive_.html (en inglés).

Recomendaciones técnicas y tecnológicas

Resumen de recomendaciones

Muchas de las tecnologías y técnicas descritas para las regulaciones anteriores son parecidas. Las secciones anteriores describen cada área aplicable a la legislación específica. Esta sección entra más en detalle y describe recomendaciones clave para cada área.

  • Confidencialidad: No se apoye en rutinas de cifrado personalizadas o no seguras. Use las interfaces API de cifrado de la plataforma del sistema operativo, ya que han sido totalmente inspeccionadas y probadas rigurosamente. Utilice un algoritmo asimétrico como RSA cuando no sea posible compartir sin riesgos información secreta entre la parte que cifra y la parte que descifra los datos. Se puede usar un algoritmo simétrico como AES cuando sea posible compartir información secreta antes de que comience la comunicación cifrada. Es importante elegir una clave apropiadamente calibrada para que el cifrado no se pueda romper fácilmente. Si usa RSA, elija una clave de 2048 bits. Si usa AES, elija una clave de 128 bits. Estos tamaños de clave dejan espacio para un posible crecimiento, pero necesitarán finalmente reemplazarse con claves más grandes a medida que aumenten las capacidades informáticas.

  • Integridad: Utilice sistemas hash para almacenar información confidencial, como contraseñas, que pueden tener que validarse pero que no se tendrán que recuperar por completo. Aplique comprobaciones de integridad para asegurarse de que los datos confidenciales no se hayan modificado. Use SHA1 cuando emplee un algoritmo hash y HMAC-SHA1 cuando aplique las comprobaciones de integridad. Es importante, sin embargo, tener presente que el algoritmo hash puede necesitar cambiar con el paso del tiempo a medida que avanzan las capacidades informáticas y los algoritmos anteriormente fuertes pierden aptitud.

  • Disponibilidad: La disponibilidad de los datos incluye el uso de soluciones de almacenamiento confiables, como RAID y copias de seguridad fuera del sitio. Es también importante comprobar que estas copias de seguridad se puedan proteger. Para los desarrolladores, esto significa que las aplicaciones se deben diseñar de modo que la información clave sea archivable y recuperable incluso si se produce un error terminal en el sistema. Donde se usa un sistema de cifrado, esto significa contar con un mecanismo para exportar claves de modo que los datos puedan recuperarse en caso de destruirse el sistema. Otro factor importante para los desarrolladores es asegurar la conmutación por error del sistema. Esto significa que el código de administración de errores no debe debilitar la seguridad del sistema y, donde sea oportuno, debe admitir clústeres y un sistema de conmutación por error seguro. La administración de errores en particular es un punto común de error. Al diseñar e implementar los mecanismos de administración de errores, tenga presentes las instrucciones siguientes:

    • Cree una arquitectura coherente de administración de errores y utilícela en su aplicación.

    • No revele información confidencial al usuario ni a la persona que llame, cuando haya un error en la aplicación.

    • Guarde los valores de las excepciones o de devolución de error en todas las llamadas a API que puedan proporcionar dicha información.

    • No permita que se produzcan estados no seguros, asegúrese de que limpia los recursos adecuadamente y preste atención con cualquier dato confidencial que pueda quedar en la memoria o en el sistema de archivos.

  • Auditoría y registro: Evite registrar datos confidenciales, pues no existe garantía de que para obtener acceso a los registros y a los datos confidenciales se requerirán los mismos privilegios. Si está involucrado en la implementación del sistema, asegúrese de que el registro de eventos sólo quede expuesto a los administradores. Incluso si no se registra ninguna información personal privada, la información contenida en el registro puede ser utilizada en otros ataques al sistema. Si usa ASP.NET 2.0 para crear su aplicación, puede utilizar la nueva característica de supervisión del estado para instrumentar su aplicación y capturar información pertinente. En otras aplicaciones .NET de la plataforma de Windows, puede utilizar la clase System.Diagnostics.EventLog. En el caso de aplicaciones no administradas, puede utilizar la API de ReportEvent dentro del SDK de la plataforma de Windows. Un ataque habitual que los usuarios malintencionados pueden emplear para manipular los registros es el que desborda el mecanismo de registro con millones de eventos que hacen que se pierda información importante o se semioculten los datos importantes. Evite esta situación limitando los eventos registrados. También puede considerar crear el registro en un sistema protegido aparte para evitar ataques por parte de usuarios no autorizados. Los registros de eventos deben contener suficiente información como para hacer posible reconstruir la actividad del sistema hasta el momento en que se produjo cualquier error, de modo que pueda ser resuelto rápidamente.

  • Autenticación: A la hora de configurar sistemas de autenticación, asegúrese de implantar contraseñas seguras. Como mínimo, exija que las contraseñas tengan siete caracteres de longitud y contengan por lo menos un carácter no alfanumérico. No habilite ni proporcione cuentas de "invitado" ni otros medios de acceso que no se correspondan con identidades específicas para las cuentas y los recursos utilizados. Al almacenar las contraseñas, asegúrese de utilizar cifrado de alta seguridad capaz de proteger las credenciales frente a atacantes que quizás obtengan acceso a ellas. Implante directivas de contraseñas que hagan caducar las credenciales con bastante frecuencia. Asegúrese de que, ante cierto tiempo de inactividad, se cierre el sistema automáticamente cuando el usuario permanezca inactivo durante un espacio de tiempo específico. Si está creando una aplicación de ASP.NET, puede establecer la opción de configuración de vencimiento variable en verdadero para que las sesiones de usuario caduquen pasado un tiempo fijo.

Recursos adicionales (en inglés)

Los recursos siguientes ofrecen una importante fuente de recomendaciones en una variedad de áreas:

Conclusión

Llegar a comprender los requisitos de cumplimiento de las regulaciones puede ser difícil. Hay una amplia variedad de regulaciones, y la información al respecto está repartida por muchos sitios. Hay muy pocos recursos que relacionen los requisitos regulativos con los requisitos de desarrollo de software o sus repercusiones en el proceso de desarrollo de software. Sin embargo, la dificultad de comprender la legislación no reduce su importancia. Estas regulaciones se aplican activamente en litigios en tribunales federales y estatales en EE.UU. Los jueces y el jurado no son compasivos con las dificultades que conlleva cumplir con este tipo de regulaciones. Los desarrolladores y las compañías deben preocuparse por las ramificaciones de los posibles casos de incumplimiento ante los tribunales de justicia, así como ante la opinión pública cuando las personas sienten que no se ha respetado su privacidad.

Las regulaciones pueden ser complejas en sí mismas, pero cumplir con los requisitos no tiene por qué serlo. Se reduce a los siguientes pasos críticos:

  • Identificar qué regulaciones suponen requisitos importantes para el sector y para la aplicación específica que se desarrolla.

  • Garantizar que los requisitos formen parte del proceso de desarrollo formal, desde el análisis de los requisitos hasta la fase de diseño, implantación, prueba e implementación.

  • Siga las recomendaciones existentes según sea oportuno en las áreas de confidencialidad, integridad, disponibilidad, auditoría y registro y autenticación.

La plataforma de desarrollo de Windows, y especialmente .NET Framework, hace especialmente fácil utilizar la criptografía, las características de integridad de datos y los servicios de autenticación de usuarios para seguir estas recomendaciones. La lista siguiente ofrece un resumen de las recomendaciones clave:

  • Use algoritmos de cifrado estándar en el sector (como RSA con clave de 2048 bits) para proteger la confidencialidad de los datos reservados.

  • Use comprobaciones de integridad (como HMACSHA1) para garantizar la integridad de los datos confidenciales.

  • Use un marco de trabajo de administración de errores bien diseñado para garantizar la disponibilidad de los datos confidenciales

  • Use un registro de eventos o HealthMonitoring para garantizar que tanto las modificaciones como el uso de los datos confidenciales es auditable.

  • Use los servicios de autenticación que ofrece la plataforma para comprobar la identidad y la función de cualquier usuario que trata de tener acceso a los datos confidenciales o trata de modificarlos.

  • Piense en usar la autenticación en dos fases para ofrecer un nivel extra de confianza en la identidad del usuario autenticado.

Use la información de este artículo para planear su estrategia de cumplimiento de las normas y como punto de partida para una investigación más profunda acerca de cómo puede ser necesario adaptar sus procesos de desarrollo a este entorno cambiante.

Mostrar:
© 2014 Microsoft