Fundamentos de auditoria de TI

1. 1. INTRODUÇÃO: Olá e bem-vindo ao curso Fundamentos da auditoria de TI. Meu nome é paciente e, como seu instrutor, meu objetivo é compartilhar com você os princípios fundamentais da auditoria de TI. Este curso é um alicerce fundamental que é importante para obter uma melhor compreensão da TI. Auditoria e controles testados. 2. 2. Introdução à auditoria e controles de TI: Ok, vamos começar com a primeira palestra, Introdução à auditoria e controles de TI. Nesta palestra, abordaremos os seguintes itens. Definiremos TI, auditorias, controles definidos, explicaremos a hierarquia dos controles, os motivos dos controles e os elementos dos controles. Também analisaremos os tipos de controle e examinaremos vários exemplos para que você se sinta confortável com o conceito de controles. Então, primeiro, o que é uma auditoria de TI? Na tela, você pode ver o que eu chamo de definição mais formal de auditorias de TI. Em termos leigos, porém, uma auditoria de TI é simplesmente um exame dos controles que estão incorporados dentro e ao redor do sistema de TI. E esses controles são avaliados quanto à eficácia. Isso significa que estamos avaliando para determinar se está funcionando da maneira que deveria estar. Reduzindo facilmente o risco que foi projetado para lidar com os requisitos mínimos de conformidade ou atende aos requisitos mínimos de conformidade? Você pode estar se perguntando: o que é um controle? Se você não sabe o que é um controle no momento, tudo bem. Aguenta aí. Abordaremos isso um pouco mais tarde. Uma coisa que eu quero abordar aqui é que, quando a auditoria de TI é realizada, fornece apenas uma garantia razoável em relação à integridade e precisão dos dados nos sistemas de TI. Eles não fornecem garantia absoluta porque são sempre aspectos do ambiente de controle que não podem ser contabilizados. Por exemplo, controles automatizados podem parecer que talvez um sistema falhe. Ou um controle manual pode ser anulado por qualquer ser humano. Ou você pode ter objetivos de controle que não foram projetados adequadamente para começar. Isso. As auditorias não devem ser absolutas. Eles só podem dar uma garantia razoável em relação à integridade e precisão dos dados nos sistemas de TI. Tudo bem, a seguir, vamos definir os controles. Quais são nossos controles. Novamente, na tela, você pode ver uma definição mais formal de controles. Mas, em termos leigos, um controle é como uma atividade de checkpoint que é implementada para reduzir o risco de uma ação indesejada acontecer. O objetivo de um controle é mitigar os riscos que podem impedir a empresa de atingir seus objetivos corporativos. Os riscos podem ser riscos de conformidade, riscos operacionais, riscos de reputação ou até mesmo riscos de relatórios financeiros. Portanto, o controle é a atividade implementada para reduzir esse risco. Agora, vamos falar sobre os principais controles, porque pode haver vários, até centenas de controles em uma organização. No entanto, normalmente, apenas um subconjunto deles é considerado controles principais. Os controles de manutenção são os controles que são realmente vitais para proteger a integridade dos sistemas do de vista da conformidade ou de qualquer outra perspectiva da área de risco, conforme observado em o slide. E você pode ver que seus principais controles são necessários para atingir um objetivo. A falha de um controle de chave geralmente tem um impacto significativo na organização. Se um controle sem chave preencher isso às vezes, ok? Mas se um campo de controle de chave geralmente significa que há problemas maiores. Então, vamos dar um exemplo aqui. Por exemplo, um controle de chaves pode estar limitando o acesso para fazer alterações no balanço patrimonial. significa que há um controle que limita os indivíduos que podem alterar diretamente o balanço patrimonial. Se esse controle for preenchido, significa que as informações no balanço patrimonial podem não ser confiáveis, porque outra porque um indivíduo não autorizado pode ter feito alterações inadequadas. Por favor, quero que você observe que uma compreensão profunda dos controles, como eles são definidos e implementados, é fundamental para seu sucesso como auditor de TI. Minha crença é que você precisa entender por que está testando um controle antes de poder projetar com eficácia a forma de testar esse controle. Se você não entender o que o controle está protegendo, por exemplo, o balanço patrimonial ou as aprovações de pagamento de faturas, o teste que você projeta e executa pode não ser adequado para lidar com o risco de esse controle não está sendo implementado adequadamente. Tudo bem, vamos discutir a hierarquia de controles. Essa imagem mostra a hierarquia de controles ou o controle normalmente existe para atender a um objetivo de controle. Um exemplo de objetivo de controle pode ser um. Os controles fornecem garantia razoável de que o acesso ao sistema de contas a pagar é limitado para autorizar indivíduos. Em segundo lugar, os controles fornecem uma garantia razoável de que o acesso para fazer alterações nos sistemas financeiros é limitado para autorizar indivíduos. Esses são objetivos de controle. Para atender a esses objetivos de controle, controles como controles de acesso do usuário, que limitam. Indivíduos que podem acessar essas áreas ou controles de senha que determinam ou exigem que as senhas sejam usadas para acessar esses sistemas. E os controles de privilégios são implementados. Em seguida, controlarei se o objetivo está em vigor para atingir um objetivo de auditoria. Um exemplo de objetivo de auditoria é que há uma garantia razoável de que as demonstrações financeiras podem ser confiáveis e estão livres de distorções materiais. Ou, para a auditoria relacionada ao PCI, um objetivo de auditoria pode ser a garantia razoável de que sistema processa pagamentos de forma adequada rápida para proteger as informações do cliente. Portanto, esses objetivos de auditoria são de nível superior. Eles são o nível superior que precisa ser alcançado. Para atingir o objetivo da auditoria, temos que nos resumir ao objetivo de controle que o divide ainda mais. E então, para atingir um objetivo de controle, você precisa ter os controles reais que ajudarão você a atingir esse objetivo. E, como você pode ver no slide, o objetivo da auditoria geralmente é o objetivo da auditoria, o que o auditor espera alcançar. E então, o objetivo do controle são os objetivos do gerenciamento que são usados como uma estrutura para desenvolver e implementar controles a fim de atingir o objetivo geral. Bem-vindo à segunda parte da palestra sobre auditoria e controles de TI. Começaremos com os motivos dos controles. Então, vamos discutir por que as organizações implementam controles. Os controles são implementados por vários motivos diferentes. Um que eu tenho aqui é a confiabilidade dos relatórios financeiros. As organizações precisam mostrar que têm controles em vigor para fornecer garantia razoável de que os relatórios financeiros são precisos e podem ser usados por chaves públicas ou privadas, as partes interessadas. Portanto, para poder mostrar isso, as organizações precisam mostrar que têm controles em vigor para permitir essa garantia. Outro item que temos aqui é a conformidade com as leis e regulamentos aplicáveis. Os controles são implementados porque as leis e os regulamentos exigem que eles sejam implementados. Por exemplo, o Regulamento Sarbanes-Oxley exige que a gerência forneça uma afirmação sobre os controles que eles implementaram e testaram em torno de seu processo de apresentação de relatórios financeiros. Isso é chamado de Eco para controles internos sobre relatórios financeiros. Outros exemplos incluem os padrões regulatórios PCI e SSE 16. Isso também exige que os controles sejam implementados para que possam ser testados conforme apropriado com base nesses padrões específicos. Outro motivo para os controles seria alcançar a eficácia e a eficiência das operações. Quando as organizações têm controles, determinadas atividades operacionais são mais simplificadas e estão melhor posicionadas para ajudar a organização a atingir suas metas. Embora isso possa não estar relacionado a certas leis e padrões, eles ainda são cruciais para o sucesso da empresa. Por exemplo, existem controles sobre as práticas de contratação de RH para garantir que candidatos qualificados sejam contratados. Ou pode haver controles sobre a proteção de segredos comerciais ou fórmulas. Outro motivo para os controles é que eles ajudam a alcançar processos definíveis e reproduzíveis que melhoram a consistência dos resultados operacionais. Quando os controles são implementados adequadamente, determinadas atividades se tornam reproduzíveis e padronizadas e potencialmente até automatizadas para garantir a consistência contínua dos processos. Por exemplo, a. Os relatórios de balanço de testes podem ser revisados periodicamente para identificar e tratar quaisquer discrepâncias nos livros financeiros. Além disso, você pode ter controles de reconciliação implementados para garantir que os saldos financeiros estejam sempre sincronizados entre as entidades, para que você possa identificar e resolver rapidamente qualquer discrepâncias. Portanto, você deve poder verificar os itens com frequência para garantir que coisas que deveriam estar sincronizadas ou ainda incidentes. Por último, e definitivamente não a lista, a segurança do sistema de segurança do sistema garante que os controles sejam implementados para impedir ou pelo menos impedir que bandidos acessem os sistemas. acesso do usuário, controles de senha, controles de rede, exemplo, configuração de firewall. Tudo isso é implementado para garantir que somente usuários autorizados e apropriados acessem sistemas. Portanto, isso fornece uma visão geral de alguns motivos dos controles. Em seguida, abordaremos os elementos dos controles. Os controles devem ter certos elementos para serem qualificados como controles adequados. Dependendo do tipo de controle, ele pode não ter todos os elementos listados neste slide. No entanto, ele deve ter esses elementos suficientes para ser considerado adequado. Exemplo adequado de controle. Vou ler um exemplo e, em seguida, abordaremos esse elemento. As senhas são necessárias antes de acessar o sistema. Portanto, essa é a verificação de senha ou outro controle se o acesso ao sistema requer um formulário de solicitação de acesso do usuário preenchido e aprovação do gerente. Esses são controles para itens específicos no sistema. Então, o primeiro elemento é o que é uma atividade de controle? O que é a atividade de controle? Por exemplo, pode ser um controle de autenticação e controle de autorização, um controle de senha, como o que acabei de ler. Controle de acesso ou livros, controle de reconciliação. Seu controle deve indicar qual é a atividade em um dos exemplos que li anteriormente, parte disso é a aprovação de um formulário de solicitação de acesso por um gerente. O segundo elemento aqui é a frequência com que o controle ocorre, que é a frequência. Pode ser de hora em hora, diariamente, semanalmente ou até M0. E você também pode ter um controle automatizado que é apenas uma verificação frequente. Então você quer dizer qual é a frequência. E se não houver uma frequência definida, se for automatizada, você também deve defini-la. Prefiro usar isso também. Outro elemento é o título da OMS que está realizando o controle. E se houver alguma segregação de funções envolvidas, há algum conflito potencial com a pessoa que executa o controle, o gerente que aprova o formulário não deve ser a mesma pessoa que está criando acesso no sistema, por exemplo, você quer ter certeza de que tem uma separação de tarefas em vigor. Então, você quer declarar o título da pessoa que executa o controle. Em um exemplo que afirmei anteriormente, o gerente é a pessoa ou comprovou o formulário, mas o acesso ao sistema normalmente é concedido pelo administrador e você pode querer incluí-lo no controle. Outro elemento aqui é quando a atividade de controle ocorre? Existe um horário específico de ocorrência do banco de dados que seja importante observar. Então, por exemplo, uma revisão diária dos lançamentos do diário pode ocorrer às 16h todos os dias antes do fechamento do negócio ou após atividades específicas? Tem algum antecessor no processo? Então você pode querer ficar com tudo isso. Você também pode querer declarar algo como uma atividade temporária da conta de usuário com privilégios que pode ocorrer após o bloqueio de um usuário. Então, se houver alguma sequência específica para esse controle, isso é algo que você consideraria adicionar ao controle. Outro elemento que temos aqui é que, se houver algum arquivo de documento de relatório que será usado na execução do controle, pode ser razoável incluí-lo no controle. Por exemplo, se houver um controle sobre avaliações de acesso do usuário e você precisar gerar um relatório de acesso específico a partir do sistema. Você pode colocar isso nos controles para que fique claro do que se trata esse controle. Ou, se forem verificações cruzadas balanceadas, verificações cruzadas de saldo da conta que exigem relatórios de diferentes sistemas específicos. Talvez você queira declarar isso para que fique claro qual sistema ou quais relatórios estão sendo reconciliados. Por último, mas não menos importante, temos evidências produzidas como resultado da realização do controle. Então, quando o controle for realizado, quais evidências serão mantidas para mostrar que o controle foi realmente realizado? Por exemplo, isso pode ser um relatório com os resultados da análise do acesso dos usuários ou um relatório mostrando os saldos da conta que foram reconciliados. É algo que você pode considerar incluir em seu controle. Agora eu sei que falamos muito sobre controles, mas uma coisa importante a ser observada aqui no slide um processo não está sob controle. O processo suporta o controle. O objetivo do controle não é o controle. O objetivo do controle é simplesmente o objetivo do controle. E o último item é que o teste é realizado sobre o controle real. É importante saber a diferença entre um controle, que é a atividade do ponto de verificação, e o processo que envolve os suportes desse controle. E então, o objetivo final de controle que muitos controles importantes suportarão. Isso conclui esta parte da palestra e, na próxima parte da palestra, falaremos sobre os tipos de controle. Tudo bem, bem-vindo à próxima parte desta palestra. Começaremos falando sobre os tipos de controle. Existem diferentes tipos de controles, e esses são os três principais tipos de controles. Você pode encontrar outros textos ou outros tipos de controle em textos de auditoria, mas geralmente são categorias menores. Essas são as principais categorias de tipos de controle. O primeiro que temos nos controles preventivos. Os controles preventivos são implementados para evitar que um evento indesejável aconteça. Então, esses controles são implementados para tentar impedir que algo ruim aconteça. Portanto, o desenvolvimento desses controles envolve tentar prever possíveis problemas que possam ocorrer e seguida, implementar maneiras de evitar esses controles, por exemplo, senhas, que você exige que as pessoas IDs de login e senhas antes que eles possam entrar nos sistemas. Ou você pode ter outra lista, controle de privilégios, o que significa que você só dá às pessoas acesso ao que elas precisam para desempenhar sua função profissional. Então, ao fazer isso, você está evitando possíveis problemas no futuro. A próxima guia de controle são os controles de detetive. Os controles de detetive são implementados para identificar eventos indesejáveis que já ocorreram. Então, por exemplo se seu controle preventivo não foi capaz de impedir que algo acontecesse, você quer ter controles de detetive que você possa realmente identificar se algo já aconteceu. Portanto, isso pode ser uma revisão periódica do acesso normal para garantir que apenas as pessoas certas tenham acesso. Ou você pode ter vários controles de gerenciamento de alertas e eventos que notificam quando ocorrem problemas. Então, tudo isso está sob o controle de detetives. E a terceira categoria aqui, os controles corretivos. Os controles corretivos são projetados para corrigir erros ou irregularidades que foram detectados. Portanto, se você já tem problemas contínuos e está pensando em maneiras de corrigi-los. É quando você traz controles corretivos. E um bom exemplo controles corretivos é o treinamento ou reciclagem de usuários. Se você identificar que o erro do usuário é a razão pela qual muitos controles preventivos estão falhando, convém treinar novamente ou treinar os usuários se eles não tiverem sido treinados inicialmente. Agora, vamos ver alguns exemplos de controle. Os exemplos que tenho na tela aqui não estão em uma ordem específica, então vamos examiná-los. A primeira na tela é a autorização de acesso. E o controle. acesso do usuário ao aplicativo deve ser autorizado pelo gerente do indivíduo antes que o acesso seja concedido. Aqui você vê o elemento de controle que fala sobre o que é a atividade, que é a aprovação ou autorização do gerente do indivíduo. E você entende que isso deve ocorrer antes o acesso do usuário seja realmente concedido no aplicativo. Assim, você pode ver que alguns dos elementos que discutimos anteriormente estão nesse controle específico. O próximo exemplo que temos na lista é o acesso administrativo e diz que o acesso de superusuário ao banco de dados do SQL Server está restrito aos DBAs. Novamente, isso também tem o elemento de dizer quem é essa restrição. Porque você vê aqui que ele está falando primeiro sobre o acesso de superusuário no banco de dados. E parecia que apenas indivíduos que têm uma função de DBA deveriam ter acesso de superusuário. E ele informa o que é o banco de dados do SQL Server. Novamente, você pode ver onde alguns desses elementos de controle que discutimos anteriormente foram abordados. O terceiro exemplo que temos é sobre o acesso encerrado do usuário. E diz que todos os usuários encerrados têm sua conta de rede removida dentro de dois dias após o encerramento. Isso também está muito claro. Está falando sobre usuários demitidos. Está falando sobre o eixo, especificamente o acesso à conta de rede e tem uma duração de dois dias. Dentro de dois dias após o término, acesso à rede deve ser removido. Portanto, está muito claro do que trata essa atividade de controle específica. E o último que temos na tela é um controle de senha que lê. O banco de dados Oracle exige que os usuários tenham senhas com pelo menos oito caracteres alfanuméricos, e a senha deve ser alterada pelo menos a cada 90 dias. Novamente, você pode ver que isso é muito específico. Está dizendo que isso é especificamente para o banco de dados Oracle. E mostra as características da frase, as configurações que devem ser habilitadas. Portanto, a configuração da senha deve ter oito caracteres alfanuméricos anotados. E então você também quer ter certeza de que há uma configuração de exploração que diz que uma senha expira após 90 dias, período em que ela deve ser alterada. Aqui estão alguns exemplos adicionais de controle. O primeiro diz acesso físico e diz que acesso ao data center é limitado à equipe de TI. E essa também é muito clara. Está falando sobre o datacenter e o acesso, e está falando sobre as funções que a equipe de TI deve ter acesso. Esse controle pode ser aprimorado informando se há algum grupo dentro do grupo de TI que deveria ter acesso ou não. Isso pode ser uma melhoria nesse controle, em que você é um pouco mais específico sobre quem deve ter acesso ao data center. O próximo controle que temos na tela é o gerenciamento de alterações. Todas as solicitações de alteração nos sistemas da organização devem ser devidamente autorizadas, testadas e aprovadas antes da implementação. Isso também tem alguns dos elementos que discutimos porque você pode ver aqui que estamos falando sobre as solicitações de mudança. Essa é a parte do controle e informa as atividades específicas que devem ocorrer para solicitações de alteração, que inclui autorização, teste e aprovação antes de você implementá-las no produção. Então, a palavra produção está faltando aqui. Essa é uma melhoria que poderíamos acrescentar. Mas você pode ver aqui que vários elementos estão presentes para deixar isso bem claro. Esse controle é quase o último controle que temos aqui, é treinamento em políticas de TI? E isso afirma que a orientação de novos contratados inclui treinamento básico de conscientização sobre segurança. E após a conclusão, o novo contratado deve assinar que concluiu o treinamento. E você pode ver aqui que está lhe dizendo o que está ocorrendo. A atividade que está ocorrendo é o treinamento sobre conscientização sobre segurança. E você pode ver aqui que a evidência desse controle ocorrendo ou sendo realizado é a assinatura do novo contratado que diz que ele realmente concluiu o treinamento. E você pode ver alguns elementos entrando em jogo aqui. Conforme discutido anteriormente. Todos os elementos que abordamos há alguns slides não precisam estar presentes em todos os controles, mas você precisa de uma boa quantidade de bebida para garantir que o controle seja muito claro. Tudo bem, chegamos ao final desta seção. Vamos falar sobre os itens que aprendemos nesta palestra. Aprendemos sobre a definição de auditoria de TI. Também aprendemos sobre a definição de controles e controles de teclas. Analisamos a hierarquia de controles, as razões por trás dos controles por que as organizações implementam controles. Também analisamos os elementos básicos dos controles. E então discutimos os diferentes tipos de controles, os três tipos principais de controles, e encerramos isso com exemplos de controle. Muito obrigado por ouvir esta palestra. Nos vemos na próxima palestra. 3. 3. Controla o teste e a amostragem: Bem-vindo à seção sobre testes de controles. Agora que sabemos o que são controles, vamos falar sobre testes de controles. Aqui estão os itens que abordaremos nesta seção. Vamos revisar. Por que testamos os controles? Os tipos de controles que testamos, os tipos de testes que realizamos e como fazer seleções para testes. Então, nesta primeira palestra aqui, a pergunta é: por que testamos os controles? O principal motivo, o principal motivo, é que testamos os controles para determinar se eles estão cumprindo a finalidade para a qual foram implementados. Se um controle não está cumprindo o propósito de que o Egito foi implementado, então ele é ineficaz e pode precisar ser alterado. Portanto, não basta dizer que projetei e implementei controles no ambiente. É absolutamente necessário testar esses controles periodicamente para garantir que eles estejam realmente executando e realizando o trabalho para o qual foram implementados. E se houver alguma lacuna, gerência precisará tomar a decisão de como alterar esses controles, conforme apropriado. Vamos falar sobre os tipos de controles que testamos. Há duas grandes categorias de controles. São controles gerais, ou algumas pessoas podem chamá-lo gerais de TI e controles de aplicativos. Os controles de aplicativos são específicos para determinados processos de negócios que ocorrem em um aplicativo. E B geralmente se baseiam na personalização de um aplicativo pelo cliente. Por exemplo, os controles de aplicativos serão controles sobre limites de aprovação, autorizações de pagamento, por exemplo, essa pessoa só pode aprovar até X dólares para pagamento. Ou você também pode ter autorização para editar entradas específicas do diário ou acesso para executar e visualizar relatórios de RH específicos. Para uma auditoria regulatória, a equipe de auditoria, a equipe de auditoria financeira normalmente identificada, os controles de aplicativos que fazem parte do escopo da auditoria. É importante observar que controles de aplicativos são o álcool, os controles de negócios que impulsionam os controles gerais de TI que são testados. Por outro lado, controles gerais de TI ou você pode vê-los chamados de IT GCS. E nós nos referimos a eles assim. Eles são controles abrangentes que dão suporte ao ambiente de TI da organização e ao impacto de vários aplicativos em uso pela organização. O que isso significa? Isso significa que os controles gerais de TI oferecem suporte a todo o ambiente de TI, o que inclui o aplicativo específico que pode estar no escopo de uma auditoria. Geralmente, os GCS de TI precisam estar operando de forma eficaz para que os controles do aplicativo sejam confiáveis. Vamos falar sobre um exemplo apenas para deixar as coisas um pouco mais claras. Ele controla em geral as senhas e o acesso, que veremos em alguns exemplos em nossa seção anterior. Como eles são para autenticação e autorização, eles ajudam a garantir que os indivíduos precisem ser autenticados no ambiente de TI antes de poderem acessar os sistemas nos quais tenham autorização. . Se esses controles não estiverem operando de forma eficaz, isso significa que muitos usuários podem acessar aplicativos financeiros sem a devida autenticação. E eles podem acessar partes do aplicativo sem a devida autorização. Será muito difícil provar que somente usuários autorizados têm acesso aos aplicativos financeiros. Pessoas não autorizadas podem ter acesso para aprovar pagamentos no aplicativo porque os controles gerais de TI não foram efetivos. Este exemplo mostra a importância da TI. Os controles gerais que estão sendo eficazes para que os auditores estejam testando para confiar nos controles desse aplicativo. No próximo slide, veremos um exemplo ilustrado. Este slide aqui é uma imagem que mostra o que acabamos de discutir. Então, você pode ver aqui que o ambiente de TI é o grande círculo. O departamento geral de TI controla toda a rede, servidores, banco de dados e aplicativos. Os controles são todos abrangentes. Bem, eu não deveria dizer tudo, mas eles têm um alcance distante e são muito difundidos. E você pode ver que ele abrange vários sistemas de aplicativos que estão no escopo. No entanto, você pode ver que cada sistema terá seus próprios controles de aplicativo específicos que são específicos para os processos dentro desse aplicativo, dependendo de qual desses sistemas está no escopo de uma auditoria, primeiro você precisa testar o ambiente geral de TI e ver como são confiáveis, que determinará a extensão dos testes que serão realizados em cada sistema individual. Então, espero que isso tenha lhe dado um pouco mais de clareza sobre as diferenças entre TI, controles gerais e controles de aplicativos. Como este curso é sobre auditoria de TI, aqui estão algumas subcategorias dos controles gerais de TI. Não abordamos isso em profundidade neste curso específico, mas é bom dar a vocês uma visão geral do que são as subcategorias. As categorias são segurança lógica, que tem a ver com acesso. Também temos mudanças no programa, desenvolvimento de programas, operações de computadores, controles físicos e ambientais. Agora, vamos discutir os tipos de testes que realizamos para controles. Para testar os controles, primeiro você precisa determinar se o controle foi projetado adequadamente antes de determinar se ele está operando de forma eficaz. O teste de design é determinar se um controle foi projetado adequadamente, de forma que, se você fosse implementado conforme projetado, operaria de forma eficaz. Isso significa que você testa o controle para determinar se há alguma lacuna ou problema que impeça de funcionar da forma como foi projetado. Por exemplo, vamos dar uma olhada nos controles de senha. Se você quiser testar o design dos controles de senha selecionados, as senhas devem ser alfanuméricas. Você quer ter certeza de que existem políticas documentadas em vigor para controlar as configurações de senha dos sistemas de TI. Você gostaria de ter certeza de que o sistema que está sendo testado também tem a capacidade suportar senhas alfanuméricas. Se não houver políticas corporativas que exijam senhas alfanuméricas ou se o sistema não puder oferecer suporte a senhas alfanuméricas, o controle não foi projetado adequadamente porque falhará quando você tentar testar a eficácia operacional. O teste de design pode ser realizado usando vários métodos para que possamos concluir sobre a adequação do projeto. E abordaremos isso no próximo slide. O teste de eficácia operacional ocorre após o teste de design. E é usado para determinar se o controle está operando conforme o esperado quando foi projetado. Seguindo o exemplo dos controles de senha. Para testar a eficácia operacional desse controle, obteríamos as configurações de senha do sistema que foi auditado e garantiríamos que as configurações, a as configurações exigem senhas alfanuméricas dos usuários. Mostrar que a configuração está ativada será a evidência de que o controle de senhas alfanuméricas está operando de forma eficaz. Existem também vários métodos que podem ser usados para realizar testes de eficácia operacional. E também abordaremos isso no próximo slide. Antes de finalizarmos este slide, há algumas coisas que precisamos considerar ao realizar um teste de eficácia operacional. Você tem que considerar a natureza do controle. É um controle automatizado ou manual? Isso afetará o tipo de evidência que você precisa revisar para o teste. Você também deve considerar a frequência da operação. frequência o controle é realizado? Isso afetará o tamanho da seleção que você precisa fazer para testar. E você também deve considerar a importância do controle e o risco de falha. Quão importante é esse controle? Qual é a chave de um controle de chave? E está propenso ao fracasso? Isso também afetará os tamanhos de seleção que você faz ao testar esse controle específico. Examinaremos os tamanhos de seleção em uma palestra diferente. Em geral, todos esses itens ajudarão a determinar como você projeta o teste a ser executado e como você faz a seleção dos itens que você testará. A seguir, vamos falar sobre técnicas de teste. No slide anterior, mencionei que existem vários métodos para realizar testes de design e testar a eficácia operacional. Aqui estão algumas técnicas e métodos para testes de design que normalmente realizariam investigações. Primeiro, o que é o mesmo fazer perguntas às pessoas por meio de uma entrevista. Inspecionamos documentos e, em seguida, também observamos os processos. Você precisa usar pelo menos dois desses métodos para testes de design, porque a pesquisa por si só nunca é suficiente para testes de design. Nos casos em que é absolutamente impossível inspecionar evidências ou processos observados, pode ser aceitável realizar o que é chamado de investigação colaborativa, o que significa perguntar a duas ou mais pessoas o mesmo conjunto de perguntas da entrevista, a fim de determinar se suas respostas em relação ao processo e controle são as mesmas. Para testar a eficácia operacional, você pode utilizar as técnicas listadas aqui. Vamos analisar cada um deles. Observação significa que você pode observar a ocorrência de um processo para garantir que o controle seja executado como parte desse processo. Um exemplo seria observar alguém usando seu distintivo. Para acessar a sala do servidor, para testar o controle de que o acesso à sala do servidor é restrito pelo acesso por crachá. Inspeção significa que você revisa as evidências fornecidas para determinar se o controle está operando de forma eficaz. Por exemplo, vamos dar uma olhada no controle de acesso à sala do servidor. Você pode solicitar e obter um relatório do sistema de lotes para determinar se somente indivíduos aprovados têm as permissões da sala do servidor em seus crachás. Você quer ter certeza de que todos não tenham as permissões da sala do servidor em seu crachá. E isso é restrito apenas a indivíduos que precisam acessar o servidor. Redesempenho significa que você está executando o controle novamente para determinar se você chegou à mesma conclusão do controle executado originalmente. Um exemplo aqui seria, por exemplo um controle de reconciliação, em que você reconcilia os mesmos itens no processo e vê se obtém os mesmos resultados. Recálculo significa que você calcula itens do controlador novamente para determinar se ele obteve o mesmo resultado. Por exemplo, se o controle deve calcular dois números em contas diferentes para reconciliação, você pode recalcular manualmente esses números para garantir que os números que usamos na reconciliação onde Correto. O último item que temos aqui é uma consulta do sistema. Isso significa que você pode executar relatórios do sistema para visualizar novos usuários criados, alterações feitas em um campo ou outros relatórios aplicáveis que podem ser usados para testes de controle. Por exemplo, se você quiser testar o processo de aprovação para novos usuários, você pode executar um relatório do sistema de todas as novas contas de usuário que foram criadas. Em seguida, você pode usar essa lista para fazer uma seleção que você testaria para determinar se cada usuário tinha um formulário de solicitação de acesso preenchido e aprovado adequadamente pelo gerente. Então, isso realmente tem dois elementos. No exemplo que acabei de usar, você usa a consulta do sistema para gerar um relatório que você pode usar para seleção. E então, quando você obtiver suas evidências para a seleção, poderá usar a inspeção para realizar um teste para garantir que todos os elementos do controle foram atendidos. Isso conclui a palestra sobre técnicas de teste. Vamos analisar os tamanhos de seleção. Bem-vindo à palestra sobre seleção de tamanhos. Nesta palestra, abordaremos o conceito de seleções. Esse conceito é baseado no fato de que, ao realizar testes de controle, geralmente há muitos itens que podem ser testados, mas não é prático testar tudo. Como tal. Somente uma amostra de itens que são elegíveis para teste, você faz o teste? Então, vamos começar com o que é uma seleção? Simplificando, de acordo com o dicionário, acilação é uma coleção cuidadosamente escolhida ou representativa de pessoas ou coisas, neste caso, itens ou evidências para testes. Por que fazemos seleções? Conforme observado anteriormente, é simplesmente porque não é viável olhar para uma população inteira. Vamos falar por meio de um exemplo. Portanto, temos o controle sobre como obter aprovação do supervisor antes de conceder acesso aos usuários. O teste de eficácia operacional consiste em verificar os novos usuários criados e garantir que a aprovação tenha sido concedida para cada usuário. Para identificar os novos usuários, executaríamos uma consulta ao sistema, conforme discutimos anteriormente, para determinar o número de novos usuários criados durante o período de auditoria. E para uma grande organização, isso pode ser facilmente na casa das centenas. Então, isso pode ser uma centena de indivíduos. Se o número de novas contratações for, digamos, 200, 300 , 500, não é viável nem razoável testar todos esses usuários. Nesse caso, será mais prático fazer uma seleção representativa desses usuários e testá-los. Ao testar uma amostra representativa de usuários, podemos então extrapolar a conclusão do teste para a seleção para o resto da população. Ao selecionar amostras, você deve considerar a frequência com que o controle é realizado e o risco de falha. Isso ajuda você a determinar qual deve ser a seleção apropriada do tamanho da amostra. A maioria das organizações tem um guia de tamanho de amostra que fornece orientação e o número de amostras a serem selecionadas com base na frequência do controle e no risco de falha. E mostrarei um exemplo de guia no próximo slide. Finalmente, você também deve considerar a variedade de variáveis na população. O que isso significa é que você deve tentar cobrir todo o período de auditoria em sua seleção de amostra. Portanto, abrange toda a gama de variáveis. Por exemplo, se o período de auditoria for de janeiro a dezembro, certifique-se de selecionar amostras que sejam cortadas durante todo o ano, em vez de ter amostras distorcidas para apenas algumas meses do ano. Portanto, isso significa que seleção do tamanho da amostra não é totalmente aleatória porque deve ser uma amostra representativa de toda a população de itens. Vamos dar uma olhada em um exemplo de guia de seleção de tamanhos. Neste guia específico, você verá aqui que a frequência de controle está na coluna da esquerda. E então você corre o risco de falhar nas duas colunas certas abaixo e acima. Então, o que isso mostra é que para cada frequência de controle, se for baseada no risco de falha, se for um risco menor de falha ou maior risco de falha, você pode selecionar qual o número de itens que você testaria. Vamos analisar semanalmente, por exemplo, para um controle que ocorre semanalmente, se ele tiver um risco menor de falha, você só precisa selecionar cinco itens para testar de acordo com este guia específico. No entanto, se houver um risco maior de falha , convém testar pelo menos oito. Esses números são apenas mínimos. Você pode testar pelo menos cinco na extremidade inferior do risco de falha ou oito na extremidade superior do risco de falha. Não está dizendo que o máximo é apenas o número mínimo de itens que precisam ser testados para garantir que uma amostra representativa tenha sido testada. Consulte sua organização para ver se eles têm um gráfico semelhante sempre que você estiver realizando testes. Uma coisa a se observar é que se a natureza do controle for esporádica e a frequência do controle não puder ser claramente identificada. Você deve determinar a frequência usando toda a população. Se a população for de 12 itens no total, você poderá usar a frequência do Motley. Ou se você tem cerca de 52 itens na população, você quer usar a frequência semanal. No entanto, se a população estiver entre duas frequências de controle definidas acima, sempre use a frequência mais alta. Então, por exemplo, se você tem 25 itens, não quer usar mensalmente. Você quer usar semanalmente porque vai para a próxima frequência de controle no gráfico. Tudo bem, chegamos ao final desta seção. Vamos analisar os itens que aprendemos. Aprendemos por que testamos os controles. Discutimos os tipos de controles que testamos, os tipos de testes que são realizados e, em seguida, como fazer seleções para testes. 4. 4. Obrigado: Muito obrigado por fazer este curso, e espero que você descubra os objetivos do curso foram cumpridos, você deveria ter aprendido os fundamentos da auditoria de TI. Se você tiver alguma dúvida, não hesite em entrar em contato comigo. Obrigada