Se sua organização lida regularmente com dados confidenciais, você deve implementar estratégias de conformidade de segurança de dados para proteger não apenas os indivíduos aos quais os dados pertencem, mas também sua organização de violar quaisquer leis federais (por exemplo, HIPPA, GDPR, etc.). Isso afeta organizações em setores como saúde, bancos, governo, jurídico ... na verdade, qualquer organização que lida com dados confidenciais.
Estamos a falar de PII (informações de identificação pessoal) e PHI (informações de saúde protegidas). Exemplos de PII-
- Números de segurança social
- contas bancárias
- Nomes completos
- Números de passaporte, etc.
Exemplos de PHI-
- Registros de saúde
- Resultados laboratoriais
- Contas médicas e similares, que incluem identificadores individuais
Métodos de proteção de dados confidenciais
Alguns clientes descreveram seus métodos como cenas que você pode imaginar em algum filme que você assistiu ... visualize um grupo de pessoas armadas com suas autorizações de segurança exigidas sendo amontoadas em uma sala trancada, sem janelas, para verificar manualmente as impressões de relatórios para garantir que informações confidenciais não está incluído. Embora isso contribua para uma cena de filme dramática, não é a maneira mais infalível nem a mais eficiente de testar relatórios para informações confidenciais. E com os requisitos de força de trabalho remota da Covid-19, isso simplesmente não é possível no momento.
Ajudamos vários de nossos clientes a implementar o poder do teste automatizado para testar dinamicamente as saídas de relatórios do Cognos. Essa estratégia de teste captura os relatórios mais cedo, assim que eles não estiverem em conformidade e antes que acabem em produção e acabem nas mãos erradas. É sempre uma boa ideia saber onde fica o escritório da previdência social mais próximo de você, como o Escritórios da Previdência Social em Nevada, caso aconteça o pior, pois a equipe do escritório local saberá como administrar a situação.
Valor do teste no início dos ciclos de desenvolvimento
A detecção de vulnerabilidades de segurança de dados no início do estágio de desenvolvimento pode ajudar a evitar quaisquer multas e sanções impostas pelo governo no futuro. De acordo com Departamento de Saúde e Serviços Humanos dos Estados Unidos, até o momento, o Office for Civil Rights (OCR) “estabeleceu ou impôs uma pena de dinheiro civil em 75 casos, resultando em um valor total em dólares de $ 116,303,582.00”. Isso é mais de $ 1.5 milhão por caixa! E de acordo com o Jornal HIPAA a "falha em realizar uma análise de risco em toda a organização é uma das violações HIPAA mais comuns que resultam em uma penalidade financeira."
Além de evitar penalidades impostas pelo governo, geralmente é importante detectar erros no início do ciclo de desenvolvimento, pois esse é o estágio em que os problemas são muito mais fáceis e baratos de corrigir. Como resultado, o principal objetivo deste exercício é usar MotioCIO poder do teste de regressão para identificar facilmente esses erros e, portanto, evitá-los no início do ciclo de desenvolvimento.
Vamos dar uma olhada em como configurar o teste. Começaremos com a configuração de nosso ambiente Cognos e, em seguida, explicaremos como configurar o teste automatizado para dados PHI e PII para nosso exemplo. Também usaremos esses mesmos casos de teste no ambiente de produção para um nível adicional de verificação de conformidade e segurança.
Configuração do ambiente Cognos PHI e PII
Nosso ambiente Cognos de amostra (Figura 1) consiste em vários relatórios, cada um contendo uma combinação de dados sensíveis de PII e PHI (por exemplo, código de diagnóstico, prescrição, número do seguro social, sobrenome do paciente e etc.) e dados minimamente sensíveis (por exemplo, paciente nome, data da visita e etc.).
Figura 1: Nosso ambiente Cognos de amostra.
Existem duas funções do Cognos, Permitir IPI e PermitirPHI, que determinam se algum dos dados confidenciais é processado quando os relatórios são executados. (Tabela 1)
| Funções Cognos | Notas |
| Permitir IPI | Os membros dessa função podem visualizar todos os dados de PII (ou seja, número do seguro social e sobrenome do paciente) nos relatórios do Cognos. |
| PermitirPHI | Os membros dessa função podem visualizar todos os dados de PHI (por exemplo, códigos de diagnóstico ICD10, descrição detalhada do diagnóstico, etc.) nos relatórios do Cognos. |
Tabela 1: Funções do Cognos controlando a renderização de dados confidenciais.
Por exemplo, um usuário que não tem ambas as funções do Cognos, seu relatório de “Consumo Diário do Paciente” deve ser parecido com este (Figura 2):
Figura 2: Relatório de saída produzido por um usuário que não possui as funções AllowPII e AllowPHI.
Como você pode ver, todos os dados PHI e PII são totalmente ofuscados para o usuário sem associação em ambas as funções “PermitirPHI / PII”.
Agora, vamos executar o relatório com um usuário que é membro da função “AllowPII”, o que significa que esperamos que esse usuário seja capaz de visualizar apenas dados PII (Figura 3):
Figura 3: Relatório de saída produzido por um usuário que é membro da função AllowPII e NÃO da função AllowPHI.
E você pode ver aqui que as colunas Número da Previdência Social e Sobrenome estão aparecendo de forma adequada, sem qualquer redação.
Até agora, demos uma olhada no ambiente Cognos de nossa clínica mítica e tudo o que vimos até agora é a segurança de dados baseada em funções do Cognos que muitos de vocês podem já ter implementado em seus próprios ambientes Cognos. Isso nos levaria à questão principal que os portadores de dados confidenciais esperam nunca ter que enfrentar:
E se, digamos, após um grande esforço de desenvolvimento, alguns dados confidenciais escapem e comecem a aparecer para usuários que não deveriam vê-los?
Erros são certamente inevitáveis, portanto, mais tarde no blog, usaremos MotioCIo poder do teste de regressão para manter um olhar atento sobre nossos relatórios para garantir que os dados privados nunca sejam expostos ao público indesejado.
Compreendendo os testes de conformidade para Cognos
Conforme mencionado na seção anterior, erros simples na criação ou modelagem de relatórios podem induzir um comportamento indesejado na saída dos relatórios em seu ambiente Cognos. E se essas mudanças não forem detectadas, elas têm o potencial de se infiltrar em seu ambiente de produção. O que seria ainda mais desastroso se essas alterações indesejadas incluíssem a exposição de dados privados a um público indesejado.
Por exemplo, um usuário sem ser membro de nenhum Permitir IPI or PermitirPHI As funções do Cognos não devem ver dados privados PII ou PHI em nosso ambiente Cognos de amostra. No entanto, como você pode ver abaixo (Figura 4), uma simples mudança no modelo de FM fez com que a descrição do diagnóstico e o número SSN do paciente fossem expostos a esse usuário, o que é uma GRANDE violação da Regra de Segurança HIPAA federal.
Figura 4: Um usuário sem associação às funções AllowPII e AllowPHI é de alguma forma exposto aos dados confidenciais do HIPAA.
Antes de mover as coisas para MotioCI, vamos primeiro criar três usuários de teste em nosso ambiente Cognos e atribuí-los às nossas duas funções da seguinte maneira (Tabela 2):
| Utilizadores | Associação de Função | Notas |
| TestUserA | Permitir IPI | Todos os dados PHI devem ser ocultados deste usuário |
| TestUserB | PermitirPHI | Todos os dados PII devem ser ocultados deste usuário |
| TestUserC | nenhum | Espera-se que o usuário NÃO veja PHI ou PII |
Tabela 2: Teste de contas de usuário do Cognos com suas funções designadas.
Essas contas de usuário de teste serão utilizadas posteriormente em MotioCI para testes de regressão de nossos relatórios que contêm dados sensíveis de PII e PHI. Nossos resultados de teste dependerão da visibilidade dos dados confidenciais de cada usuário de acordo com sua participação na função.
Agora que configuramos nossos usuários de teste, estamos prontos para configurar nosso teste de regressão em MotioCI.
MotioCI Configuração do ambiente
Nosso ambiente de amostra consiste em instâncias de Desenvolvimento, UAT e Produção Cognos. Apesar de MotioCI nos permite fazer login em todos os três ao mesmo tempo, vamos começar nossa configuração de teste de regressão no ambiente de Desenvolvimento em três fases diferentes.
Figura 5: MotioCI tela de login.
Figura 6: MotioCI tela inicial, mostrando as instâncias do Cognos.
Com relação ao teste de regressão em MotioCI, um afirmação é uma verificação individual ou "teste" que um caso de teste realiza em um objeto em seu MotioCI instância, como um relatório, pasta ou pacote. A declaração que fará o trabalho de testar as saídas do relatório para dados confidenciais é chamada Teste de conformidade de dados confidenciais (Figura 7). Esta é uma afirmação personalizada que reunimos para este exercício. Abaixo você pode ver o tipo de afirmação que basicamente atua como o modelo principal que é copiado para casos de teste em todo o nosso MotioCI ambiente. Mais sobre isso mais tarde.
Figura 7: Tipo de afirmação “Teste de conformidade de dados confidenciais”. Cópias dessa afirmação são implantadas no ambiente de teste.
Algumas afirmações fornecem alguma funcionalidade ajustável pelo usuário por meio de um janela de prompt. Aqui você pode alterar como gostaria que uma determinada afirmação testasse qualquer relatório do Cognos. A Figura 8 abaixo mostra o janela de prompt de nossa afirmação de que usaremos para testar nossos relatórios Cognos contendo dados confidenciais.
Figura 8: Janela de prompt da declaração “Teste de conformidade de dados confidenciais”, revelando todas as opções de teste ajustáveis pelo usuário.
A seção destacada superior na Figura 8 mostra as opções de teste para dados sensíveis de PII e PHI. Isso permite que você tenha o teste de asserção se o relatório deve mostrar ou ocultar seus dados PII ou PHI. Faremos alterações nessas duas opções à medida que começarmos a criar casos de teste para cada um de nossos três usuários de teste.
A seção destacada no meio na Figura 8 mostra os nomes das colunas que contêm dados confidenciais de PHI em nossos relatórios. Embora nosso ambiente de amostra consista em colunas com os nomes de Código ICD10 Diag, Descrição do diagnóstico, Procedimento e Rx, você certamente pode modificar esta lista para atender às suas necessidades.
Por fim, a seção realçada inferior na Figura 8 mostra as opções de e-mail. Em caso de falha, esta afirmação enviará uma mensagem de e-mail detalhada ao destinatário configurado nesta seção.
Fase I: Relatórios Exibindo Apenas PII
Vamos criar um projeto sob o Desenvolvimento instância em MotioCI e chame isso Permitir apenas PII. Podemos fazer isso clicando primeiro com o botão direito no Desenvolvimento nó de instância no MotioCI árvore de navegação e selecionando o Adicionar projeto opção (Figura 9).
Figura 9: Criando um novo projeto. No MotioCI cada projeto atua como um campo de teste para uma seção predefinida do armazenamento de conteúdo.
A Adicionar Assistente de Projeto o guiará por algumas etapas para selecionar os caminhos necessários para o seu projeto. Em nosso exemplo, todos os relatórios contendo dados confidenciais de PII e PHI existem sob o Dados do Paciente pasta. A seleção desta pasta pai incluirá automaticamente todos os relatórios subjacentes (Figuras 10 e 11).
Figura 10: Determinando o escopo do projeto em MotioCI selecionando os caminhos do ambiente Cognos.
Figura 11: Mostrando todos os objetos Cognos selecionados para o MotioCI projeto.
Como todos os relatórios neste projeto devem permitir que todos os dados PII sejam exibidos e todos os PHI sejam ofuscados, precisaremos configurar nosso tipo de asserção com as configurações corretas antes de adicionar qualquer caso de teste (Figura 12). Isso significa definir as duas opções de teste na mesma asserção janela de prompt que vimos antes na Figura 8.
Figura 12: Opções de teste PII e PHI da afirmação “Teste de conformidade de dados confidenciais”.
Agora estamos prontos para adicionar nossos casos de teste aos nossos relatórios. Para fazer isso, clique com o botão direito no nó do projeto (ou seja, o Permitir apenas PII projeto) em MotioCI e selecione o Gerar Casos de Teste opção (Figura 13). Isso iniciará o assistente de geração de casos de teste, que nos permitirá criar um grande número de casos de teste para todos os relatórios do projeto.
Figura 13: MotioCI pode gerar automaticamente todos os casos de teste necessários em qualquer nível de dentro do projeto.
A Gerar Caso de Teste assistente também nos permitirá selecionar os formatos de saída para o caso de teste em que gostaríamos de realizar os testes. Para nosso ambiente de amostra, escolhi a saída CSV. O assistente também nos permitirá escolher as afirmações que cada caso de teste utilizará para o trabalho real de teste. E para nós isso seria o Teste de conformidade de dados confidenciais afirmação. Você pode ver essas duas opções destacadas abaixo (Figura 14).
Figura 14: As opções reveladas durante o assistente “Gerar casos de teste”.
Depois de clicar em “OK”, você será levado de volta ao MotioCI tela inicial, onde você poderá ver todos os nossos relatórios, cada um contendo um único caso de teste e cada um contendo nossa única afirmação (Figura 15).
Figura 15: MotioCI árvore de navegação mostrando todos os objetos Cognos agora, cada um contendo um caso de teste e a asserção subjacente.
Finalmente, precisamos configurar todos os casos de teste para executar seus relatórios pai usando o usuário Cognos correto (por exemplo, um dos três usuários de teste que configuramos no Cognos antes de configurar as coisas no MotioCI) E já que para este projeto, estamos testando para garantir que o conteúdo de PHI seja não exibidos para usuários que têm permissão apenas para visualizar dados PII, precisaremos definir todos os casos de teste para serem executados com TestUserA (ver tabela 2).
A princípio, isso pode parecer uma tarefa tediosa, mas, para nossa sorte, podemos definir o usuário no nível do projeto, que seria então herdado por TODOS os casos de teste subjacentes nesse projeto. Para fazer isso, na árvore de navegação à esquerda, vamos clicar no nó do projeto ( Permitir apenas PII projeto) e, em seguida, selecione o Configurações do projeto no meio da tela. Então, sob o ensaio seção, veremos uma opção para alterar as credenciais (Figura 16):
Figura 16: Definir as credenciais do usuário em um projeto fará com que todos os casos de teste executem o relatório Cognos pai no Cognos com aquele usuário. Isso pode ser substituído por cada caso de teste individual.
Depois de clicar no Editar botão localizado na frente do Credenciais opção, seremos apresentados com a Editar credenciais janela. Seguiremos em frente e inseriremos as credenciais para TestUserA (Figura 17).
Figura 17: A janela “Editar credenciais” permite definir as novas credenciais do usuário ou utilizar as credenciais pai definidas no nível da instância do Cognos, também conhecidas como credenciais do sistema.
Agora vemos o novo usuário refletido no ensaio secção do Configurações do projeto guia (Figura 18).
Figura 18: As novas credenciais do usuário agora estão definidas no projeto.
Agora estamos todos configurados e prontos para executar todos os nossos casos de teste.
Para fazer isso, clicaremos no Permitir apenas PII projeto e no meio seremos apresentados com o Casos de teste guia que exibe todos os casos de teste localizados dentro do projeto. Como ainda não executamos nada, veríamos o Status mostrando como Nenhum resultado. Para executar todos os casos de teste, clicaremos na pequena seta ao lado do Execute botão e selecione o Executar tudo opção (Figura 19).
Figura 19: A guia “Casos de teste” fornece uma série de ações que podem ser realizadas em todos ou em parte dos casos de teste em massa. Aqui estamos apenas executando todos os casos de teste.
MotioCI agora executará todos os casos de teste e nos apresentará os resultados quando todos estiverem concluídos (Figura 20).
Figura 20: A guia “Casos de teste” exibe o status de execução de cada caso de teste, incluindo saídas, se houver.
Como você pode ver, todos os nossos casos de teste foram bem-sucedidos, com exceção do Paciente internado relatório. Então, vamos dar uma olhada nos resultados. Para fazer isso, clicaremos no carimbo de data / hora azul localizado abaixo do Resultado coluna e observe os detalhes na Figura 21.
Figura 21: O painel “Resultado do Caso de Teste” mostra os resultados detalhados da execução do caso de teste, incluindo o caminho do objeto testado, resultados de asserção e quaisquer saídas produzidas pelo relatório.
Sob o Resultados da afirmação seção, agora podemos ver que nosso relatório viola os requisitos de conformidade de PHI. Podemos baixar a saída do relatório CSV do Resultados do caso de teste seção clicando no ícone CSV (Figura 21).
Figura 22: A saída do relatório CSV mostrando uma coluna “Procedimento” exibida que deve ter sido ofuscada para o usuário de teste.
Como você pode ver em nosso relatório (Figura 22), além dos dados PII aos quais o TestUserA pode ter acesso, podemos ver os dados do procedimento de PHI que colocam o relatório em violação da Regra de Segurança HIPAA federal.
Se você se lembra da janela de configurações de asserção, também deveríamos receber uma notificação por e-mail sobre essa falha. Vamos ver como é (Figura 23):
Figura 23: Mensagem de e-mail enviada pela afirmação do caso de teste com falha, mostrando uma violação de conformidade de dados confidenciais, provavelmente devido a uma alteração recente no relatório.
Neste ponto, concluímos o teste para garantir que os dados de PHI estejam ocultos dos usuários sem o necessário PermitirPHI Cognos Função. Agora estamos prontos para estender nosso teste para que os dados PII sejam ocultados de usuários sem o necessário Permitir IPI Cognos Função.
Fase II: Relatórios Exibindo Apenas PHI
Antes de criar o novo projeto, primeiro vamos editar as opções de nossa asserção principal para garantir que agora teste todas as PII a serem ocultadas e todas as PHI a serem mostradas (Figura 24).
Figura 24: Opções de teste PII e PHI da afirmação “Teste de conformidade de dados confidenciais” sendo definida para TestUserB.
Com nossa asserção agora toda configurada, estamos prontos para criar o novo projeto e nossos casos de teste. Para isso iremos apenas seguir os mesmos passos da “Fase I” e criar um projeto chamado Permitir apenas PHI. Além disso, não vamos esquecer de adicionar as credenciais de TestUserB como o usuário do projeto.
Quando terminarmos com todas as etapas de configuração, executaremos todos os casos de teste como fizemos na Fase I. Em nosso ambiente de amostra, desta vez temos um relatório diferente que parece estar em violação de HIPAA (Figura 25).
Figura 25: A guia “Casos de teste” exibindo o status de execução de cada caso de teste, incluindo saídas, se houver.
Uma investigação mais aprofundada sobre os resultados do caso de teste do Ingestão Diária do Paciente relatório mostra que nosso relatório está exibindo os números do seguro social do paciente para o público indesejado (Figura 26).
Figura 26: O resultado do caso de teste mostrando uma violação do requisito de conformidade SSN PII.
Baixar e abrir o arquivo CSV confirmará ainda mais os resultados do nosso teste (Figura 27):
Figura 27: A saída do CSV mostra o SSN do paciente revelado onde deveria ter sido ofuscado.
Como você pode ver na Figura 27, no entanto, nosso relatório está mascarando adequadamente a coluna do sobrenome do paciente (também um PII) exibindo apenas a inicial.
| Dever de casa! |
| Repita os mesmos passos para TestUserC que carece tanto do Permitir IPI e PermitirPHI funções, o que significa que eles não devem ver dados PII ou PHI quando executam qualquer um de nossos relatórios. |
Neste ponto, nosso ambiente deve ter alcançado o teste de regressão completo de dados sensíveis de PHI e PII utilizando a segurança de dados baseada em funções do Cognos. Cada um de nossos casos de teste executará seu relatório pai e analisará a saída de acordo com a configuração de teste definida em suas afirmações subjacentes e nos dirá se algum dos relatórios sair da linha.
Certamente, uma das distinções mais importantes entre nosso ambiente de teste e o que você pode ter em seu ambiente é o tamanho. Um ambiente Cognos típico provavelmente tem mais de centenas ou mesmo milhares de relatórios e a execução de todos ao mesmo tempo, como temos feito em nosso ambiente de amostra minúsculo, pode prejudicar o desempenho do Cognos. Com MotioCINos scripts de teste do, no entanto, você pode programar seus casos de teste para serem executados em lotes menores durante as horas de folga, garantindo, portanto, o desempenho ideal de seu ambiente Cognos durante as horas de alto tráfego.
Uma boa prática de teste durante o desenvolvimento
Entre os tempos de execução programados, no entanto, você ainda pode executar manualmente quantos casos de teste individuais desejar. Um bom exemplo seria, ao desenvolver um relatório, você poderia executar o caso de teste para se certificar de que suas alterações não criaram violações de HIPAA.
Automatizando Casos de Teste Cognos
Back to MotioCI, na árvore de navegação, expandimos um dos projetos que criamos para revelar seu conteúdo. Isso deve revelar um nó chamado Scripts de teste. Expandi-lo mostrará um conjunto de scripts de teste que foram criados automaticamente quando você criou seu projeto pela primeira vez (Figura 28).
Figura 28: Os scripts de teste podem ser criados para exibir apenas um número limitado de casos de teste que correspondem a certos critérios definidos pelo usuário administrador.
Por definição, um script de teste é um componente de um projeto que seleciona casos de teste que pertencem a um projeto com base em critérios especificados. Você pode agendar scripts de teste ou executá-los manualmente. Quando você executa um script de teste, MotioCI executa todos os casos de teste que atendem aos critérios do script.
Em nosso caso, gostaríamos de definir todos os casos de teste em uma programação. Então, para fazer isso, clicamos no Todos os Produtos teste o script da árvore de navegação e clique no Configurações do script de teste guia encontrada no meio da tela (Figura 29).
Figura 29: A guia “Configurações do script de teste” permite adicionar uma programação para todos os casos de teste.
Em seguida, selecionamos o Adicionar programação opção. Aqui podemos definir um cronograma para o nosso script de teste. Prosseguirei e executarei nossos casos de teste diariamente, de segunda a sexta-feira, às 3h (Figura 00).
Figura 30: Além da programação diária e semanal, você também pode definir uma frequência de minuto em uma programação.
É isso! Agora podemos verificar nossa caixa de entrada de e-mail todas as manhãs para descobrir se algum de nossos relatórios não está em conformidade. Também podemos ver todos os relatórios de falha simplesmente clicando no Alterado ou Falhou script de teste e todos os casos de teste com falha serão apresentados a nós sob o Casos de teste painel (Figura 31).
Figura 31: O script de teste “Alterado ou Reprovado” incluído, mostrando o único caso de teste que falhou na última execução do lote de casos de teste.
Conclusão
Deixar de cumprir a HIPPA, GDPR e outras regulamentações federais sobre informações confidenciais e privacidade pode ser bastante caro, cerca de US $ 1.5 milhão por caso encontrado em violação, na verdade.
Ao implementar uma estratégia de teste automatizado para lidar com o teste de conformidade, você terá aquela camada extra de segurança e também a tranquilidade de estar cumprindo as leis. Além das obrigações de dados de privacidade, os testes automatizados podem beneficiar todos os tipos de indústrias e qualquer tipo de requisitos de teste que sua organização gostaria de implementar.
Como podemos ajudar?
Se você gostaria de assistir ao webinar sobre este tópico do blog, acesse aqui. Ou, Contacte-nos para discutir mais detalhadamente suas questões de teste do Cognos.
