Resumo - Auditoria de Sistemas

Prévia do material em texto

AUDITORIA DE SISTEMAS 
AULA 1
A filosofia de auditoria em TI está calcada em segurança e em controles internos. Seu objetivo
maior é verificar se os controles internos foram implementados e, se existirem, se são efetivos.
Dessa forma, podemos dizer que a Auditoria de Sistemas é uma atividade que engloba o exame das
operações, processos, sistemas e responsabilidades gerenciais de uma determinada empresa, com
o objetivo de garantir/ verificar:
1) A conformidade com os objetivos da empresa, políticas administrativas, orçamentos, regras,
normas ou padrões.
2) A segurança das informações, recursos, serviços e acesso.
Os recursos podem ser: Humanos (pessoas)
 Tecnológicos (Softwares, hardware, equipamentos eletrônicos, etc)
 Financeiros, materiais (Móveis, salas, suprimentos, etc)
No contexto de sistemas de informações, Gil enumera as 3 funções clássicas de uma organização:
Planejamento, execução e controle.
Planejamento – Determinação de padrões com informações que exprimem uma expectativa de
comportamento futuro. (Como deve ser)
Execução – Caracterização de medidas com informações relacionadas aos registros das operações
ocorridas. (Como está sendo - registro)
Controle – Acompanhamento de desvios através da confrontação das medidas com os padrões.
(Compara o padrão com o registro). Em caso de discrepância, solicitação de ações corretivas por
parte dos responsáveis. Medidas x padrões
O auditor de sistemas atua como um verificador do trabalho realizado, atuando segundo as ações de
validação e avaliação do ciclo administrativo. Corresponde a uma ação independente e duplicada
logicamente, pois reside no conceito de que diversos níveis de chefia já poderão ter feito processos
análogos aos da auditoria, embora não estruturados.
Validação – Exprime a idéia de teste.
Avaliação – Exprime a idéia de julgamento e emissão de opinião. 
Posicionamento da Auditoria de Sistemas nas organizações – Considerando que um auditor de
sistemas necessita de autonomia para verificar o trabalho realizado e apontar distorções não só na
área de sistemas mas também nas áreas do cliente, seu posicionamento no organograma da empresa
deve ser logo abaixo da direção executiva da empresa. 
Perfil do Auditor de Sistemas - O auditor de sistemas deve ter:
- Conhecimento teórico e prático de SI
- Visão abrangente da empresa (Não precisa conhecer tudo da empresa, mas o suficiente para saber
o que perguntar a quem, quando precisar consultar especialistas no assunto que fugir ao seu
domínio)
- Comportamento condizente com quem tem autoridade no assunto.
- Vestir-se adequadamente (nada de extravagâncias).
- Nada de gírias
- Não aceitar presentes.
Qualificação profissional – Algumas organizações certificadoras:
ISACA – Certified Information Systems Auditor (CISA)
British Computer Society – Exame de Sociedade Britânica de Informática
Institute of Internal Auditors (IIA) – Qualificação em auditoria computacional
Equipe de auditoria
Pode ser: Interna ou externa.
Interna – Quando os auditores são colaboradores da empresa. A equipe é treinada conforme
objetivos de segurança da empresa. A metodologia é adquirida ou desenvolvida na própria empresa.
Externa – Quando a empresa contrata uma empresa de auditoria de alguma área ou sistema
específico. Os métodos de condução da auditoria são pertinentes à empresa contratada. Nesse caso,
existe a possibilidade de se perder o controle sobre trabalhos realizados. 
Programa de Desenvolvimento de carreira de Auditor de TI
Pouca ou nenhuma experiência em TI – O treinamento de quem tem pouca ou nenhuma
experiência em TI deve incluir:
- Conceitos de TI
- Fundamentos de arquitetura de sistemas, Input/Output, processamento lógico, unidade de memória
principal e auxiliar, visando auditoria. 
- Redes de computadores, teleprocessamentos, internet, intranet e extranet, com configurações
pertinentes,
- Programação de computação, incluindo os conceitos de flowchart e diagrama de fluxo de dados.
- Tabelas de decisão e sua aplicação nas principais linguagens de programação. (deverá aprender
somente os itens necessários para as atividades do dia a dia)
- Introdução aos controles gerais de computadores (operação, aquisição, desenvolvimento e
manutenção de sistemas, controles de acesso, hardware, controles organizacionais e suporte técnico)
Estudo de caso que exemplifique casa situação (jogo de negócios) é desejável. 
Experiente em TI – O treinamento de quem possui experiência em TI deve incluir:
- Revisão dos controles gerais (operações, aquisição, desenvolvimento e manutenção, controles de
acesso, hardware, controles organizacionais e suporte técnico) Auditoria de sistemas aplicativos,
princípios e práticas de auditoria com ênfase nos controles gerenciais e organizacionais,
monitoramento e emissão de relatórios.
- Gerenciamento de riscos, privacidade, desenvolvimento e implementação de políticas e estratégias
de segurança da informação.
- Avaliação dos sistemas online com relação ao processamento em tempo real, controles de recall e
identificação de programas, verificação das autenticações e autorizações de acessos e registros
(contabilização) das transações. Também inclui correção, detecção e manutenção de diários
(journaling) das operações.
- Transmissão de dados, proteção das informações, segurança associada ao uso dos sistemas,
teleprocessamentos, redes interne, intranet e extranet.
- Controle de operações, processamento interativo em atividades de negócios e e-commerce. -
Iniciação de trilha de auditoria em ambiente de TI e propriedade intelectual, abordagens aos
métodos existentes e supervisões necessárias.
- Controles de acesso à biblioteca de dados ou programas, armazenamento e recuperação dos
mesmos a partir de bases hierárquicas, relacionais ou Data Warehouse, plano de contingência (de
backup, emergência e recuperação) de desastres.
- Software de auditoria, distinguindo-se os softwares generalistas dos específicos, como apoio dos
especialistas em TI para desenvolver softwares que atentem para metodologias próprias. 
Biblioteca Técnica – O grupo de auditores de sistemas de uma empresa deve ter à sua disposição
uma biblioteca técnica para consulta. Não apenas sobre informações pertinentes ao processamento
de dados, mas também sobre produtos da empresa para os quais houve uma auditoria prévia.
Também devem ser arquivados todos os relatórios de auditorias prévias, com os respectivos papéis
de trabalho, pois servirão de fonte de consulta em auditorias futuras. Manuais de metodologia de
gerência e desenvolvimento de sistemas, políticas administrativas e demais padrões e normas da
empresa também deverão fazer parte da biblioteca da auditoria, bem como manuais e folhetos de
hardware e software. 
Abordagens da auditoria de sistemas – Dependendo da sofisticação dos sistemas
computadorizados, podemos ter 3 tipos de abordagens de auditoria de sistemas:
Abordagem ao redor do computador – Muito usada no passado, o auditor analisava os
documentos fonte com suas respectivas entradas e saídas. Pouca ou nenhuma atenção é prestada às
funções de processamento (Não exige muito conhecimento de TI) Utilização de rotinas manuais.
Pouco envolvimento com os registros gerados pelo computador (informática era utilizada para
tarefas menores, tais como controle de estoque). Envolve custos mais baixos (e riscos mais altos).
Essa abordagem não é eficiente devido ao fato de que negligencia algumas das qualidades dos
controles internos dos sistemas e propicia falta de disponibilidade de testes substantivos
convincentes que visam ajudar na conclusão sobre os sistemas.
Abordagem atravésdo computador – Envolve mais do que mera confrontação de documentos-
fonte com resultados esperados. Simula todas as transações possíveis através do uso do test data
(ferramenta de auditoria). Capacita o auditor a verificar com maior frequência as áreas que
necessitam de verificação constante. Faz aprovação dos registros armazenados. Esta abordagem não
deixa evidências documentais através dos controles dos programas (o auditor precisa acompanhar o
processamento através e dentro do computador). Uma realização incorreta pode potencializar riscos.
Essa abordagem, embora melhor que a anterior, também pode produzir registros incompletos, pois
ao invés de efetuar uma verificação de equilíbrio de ferramentas, ela tende a negligenciar os
procedimentos manuais, deixando incompleta a maioria das tarefas normalmente efetuadas
manualmente. 
Abordagem com o computador – Possibilita a perfeição possível, fazendo uma compilação dos
processos automatizados e manuais. Utiliza as capacidades lógicas e aritméticas do computador
para verificar se os cálculos das transações econômicas e financeiras são feitos corretamente. Utiliza
a capacidade de cálculos estatísticos e de geração de amostras que facilitem confirmação de saldos
necessários para aferir a integridade de dados de contas a receber, estoques imobilizados,
fornecedores, etc. Utiliza a capacidade de edição e classificação do sistema computadorizado a fim
de ordenar e selecionar registros de interesse. Utiliza as capacidades matemáticas do computador
para analisar e fornecer listas de amostras de auditoria. Pode também incluir a confirmação dos
resultados de auditoria executada manualmente como cálculos globais. 
Facilidades do uso desta abordagem:
- Utilização de técnicas de Auditoria Assistida por Computador (TAAC) ou CAAT (Computer
Assisted Audit Techniques)
- Desenvolvimento de programas específicos para serem usados pelo auditor quando tiverem
necessidade de evidenciar uma opinião sobre algum processo.
- Ganhar tempo sobre os passos aplicados com o uso de pacotes generalizado s de auditoria de TI. 
Abrangência da auditoria de TI:
Ambiente de informática como um todo – Segurança da informação, recursos, serviços e acesso,
procedimentos de contingência e operação.
Organização do departamento de informática – Aspectos administrativos da organização, tais
como políticas, padrões e procedimentos, responsabilidades organizacionais, gerência de pessoal e
planejamento de capacidade.
Controles – Banco de dados, redes de comunicação para alta plataforma (mainframe) ou baixa
plataforma (microcomputadores) e controles sobre os aplicativos. 
Áreas de auditoria – Auditoria de Segurança da Informação
 Auditoria de TI
 Auditoria de Aplicativos
*Cada empresa define como classificará sua auditoria, não há uma regra fixa.
Auditoria de Segurança da Informação
- Avaliação da conformidade com as políticas de segurança
- Controles de acesso sobre confidencialidade, integridade, disponibilidade, consistência e
confiabilidade
- Controles ambientais
- Plano de contingência e continuidade de serviços
Confidencialidade – Controle de acesso (Físico e lógico).
Integridade – Gravação e atualização autorizadas (dono).
Disponibilidade – Sistema disponível quando necessários.
Consistência – Sistema funciona conforme requisitos.
Confiabilidade – Sistema atuará conforme o esperado.
Auditoria de TI
Organizacionais
De mudanças
De operações de sistemas
Sobre banco de dados
Sobre computadores (alta e/ou baixa plataforma)
Sobre ambientes cliente-servidor
Auditoria de Aplicativos
Controles sobre o desenvolvimento de sistemas aplicativos
Controle de entrada, processamento e saída de dados
Controles sobre conteúdo e funcionamento do aplicativo em relação à área por ele atendida
Padrões e código de ética para auditoria de sistemas de informação
Conforme padrões emitidos pelo Comitê de Padrões da Associação de Controle de Tecnologia de
Informação dos Estados Unidos, os padrões são:
Responsabilidade, autoridade e prestação de contas (Devem ser documentadas em uma carta
proposta ou de aderência ao escopo)
Independência profissional (a função de auditor deve ser suficientemente independente da área sob
auditoria para permitir uma conclusão objetiva da auditoria.)
Ética profissional e padrões (O auditor de TI deve aderir ao código de ética da Associação de
Controle e Auditoria de TI)
Competência (o auditor deve ser competente tecnicamente, possuindo habilidades e conhecimentos
necessários para a execução do trabalho do auditor. Deve também manter constante aprimoramento
profissional via educação continuada)
Planejamento (o auditor deve planejar suas tarefas e seguir os padrões profissionais de auditoria
aplicáveis. Durante o curso da auditoria, deve obter evidências suficientes do trabalho realizado,
sendo estas evidências confiáveis, relevantes e proveitosas para alcançar efetivamente os objetivos
da auditoria. Os pontos e as conclusões da auditoria devem ser fundamentados por meio de análise e
interpretação apropriados destas evidências.
Emissão do relatório (O auditor deve prover um relatório de forma apropriada para os destinatários,
por ocasião da conclusão do trabalho de auditoria. O relatório deve apresentar escopo, objetivos,
período de abrangência, natureza e extensão do trabalho executado. Deve identificar a organização,
os usuários desejáveis e quaisquer restrições à sua circulação. Ainda neste relatório, devem-se
incluir as observações, conclusões, recomendações e quaisquer ressalvas ou conceitos que o auditor
possua a respeito da auditoria.
Atividades de follow-up (O auditor deve requisitar e avaliar as informações apropriadas sobre o
ponto, as conclusões e as recomendações anteriores e relevantes para determinar se ações
apropriadas foram implementadas em tempo hábil, conforme informado pelos auditados. 
Código de ética profissional segundo o ISACA
1) Apoiar a implementação de padrões sugeridos para procedimentos e controles dos sistemas de
informações e encorajar o seu cumprimento.
2) Exercer suas funções com objetividade, diligência e zelo profissional de acordo com os padrões
profissionais e melhores práticas.
3) Servir aos interesses dos stakeholders de forma legal e honesta, atentando para a manutenção de
alto padrão de conduta e caráter profissional e não encorajar atos de descrédito à profissão.
4) Manter privacidade e confidencialidade das informações obtidas no decurso de suas funções,
exceto quando exigido legalmente. Tais informações não devem ser utilizadas em vantagem própria
ou entregues a pessoas desautorizadas.
5) Manter a competência nas respectivas especialidades e assegurar que nos seus exercícios
somente atua nas atividades em que tem razoável habilidade para competir profissionalmente.
6) Informar partes envolvidas sobre resultados de seus tralhos, expondo todos os fatos significativos
que estiverem a seu alcance.
7) Apoiar a conscientização profissional dos stakeholders para auxiliar sua compreensão dos
sistemas de Informação, segurança e controle.
AULA 2 
Contingência – Que pode ser ou não ser, que pode ocorrer ou não ocorrer. 
Plano de contingência – Uma sequência de ações a serem seguidas em situações de emergência,
previstas ou não, para assegurar a continuidade do serviço.
*Normalmente as catástrofes tem baixa frequência de ocorrência e altos riscos de incerteza mas se
ocorrem, suas consequências podem ser devastadoras.
Um plano de contingência é necessário para:
Reduzir a possibilidade de danos – Identificando previamente os riscos que poderão ocorrer em
nossos sistemas/negócios, podemos dificultar sua ocorrência de modo a minimizar seus impactos. 
Aperfeiçoar a habilidadeem sobreviver à descontinuidade de rotinas – Estando preparados para a
eventualidade da ocorrência de uma ameaça, saberemos como agir, caso ela ocorra. 
Reduzir a descontinuidade de rotinas – Tendo alternativas para sobreviver em situações precários de
trabalho, realizando os trabalhos críticos (ou seja, aqueles sem os quais a empresa não sobrevive).
Reduzir custos de recuperação – Pensando antes no que poderá acontecer, tomamos medidas que
envolvam melhor custo benefício para sobreviver em situações de emergência.
Envolvimento das áreas de negócio 
Responsáveis pela continuidade da operação de suas áreas, mesmo na eventualidade de o acordo de
nível de serviço ( Documento entre cliente e área de sistemas onde são registrados os serviços a
serem executados pelo CPD com data, hora, periodicidade, medidas emergenciais, distribuição de
relatórios, etc) não ser cumprido.
Desenvolvem seus planos, para todas as funções e níveis
Cada área deve incluir os planos das áreas interdependentes (cada área possui o plano de
contingência das áreas com quem possui interface. Atentar ao fato que os planos devem ser
distintos)
Coordenação das atividades (alguém deve gerenciar a confecção dos planos de contingência da
empresa a fim de se evitar situações não gerenciáveis por incompatibilidade de estratégia e m´ltiplas
requisições de mesmos recursos).
Riscos e ameaças
Ameaça – Evento ou atitude indesejável (roubo, incêndio, vírus...) que potencialmente remove,
desabilita, danifica ou destrói um recurso. É quando algo ou alguém viola a confidencialidade,
integridade, disponibilidade, etc.
Podem ser acidentais (falhas de hardware, por exemplo) ou deliberadas. As deliberadas podem ser
passivas (não alteram as informações) ou ativas (alteram as informações). 
Exemplos: Vazamento de informações, violação de integridade (alteração de dados),
indisponibilidade de serviços de informática, ameaças programadas, roubo, incêndio, inundação,
etc.
Vulnerabilidade – Fraqueza que pode ser explorada por uma ameaça. Está associada à
probabilidade de ocorrência. 
Ataque – Ameaça concretizada.
Risco – Medida da exposição a qual o sistema está sujeito. Envolve: ameaças, vulnerabilidades e
impactos. 
Impacto – É o resultado da concretização de uma ameaça. (Resultado de um ataque). Pode ser
direto (quando envolve perdas financeiras) ou indireto (quando não envolve diretamente perdas
financeiras, mas situações como descumprimento da lei, perda de reputação e credibilidade, etc)
Recurso – Um componente físico, hardware, software, informação. Pode ser humano também. 
* Quando pretendemos fazer um plano de contengência, devemos identificar as funções (se
estvermos fazendo o plano de contingência de um sistema), os sistemas (se estivermos fazendo um
plano de contingência para o CPD) ou nas áreas críticas (se estivermos trabalhando com
departamentos). A elaboração, implementação e teste de um plano de contingência não é um
trabalho barato, muitas vezes temos que desenvolver programas ou processos específicos para
atender a uma situação de emergência. Por isso, não fazemos plano de contingência da totalidade
das funções do objeto do plano de contingência.
Plano de contingência
Sistema – Identificar funções críticas
Área de TI – Identificar sistemas críticos
Departamento – Identificar áreas críticas
Matriz de risco (Analisando impacto e calculando riscos)
Ao se pensar em fazer um plano de contingência, devemos inicialmente, levantar os riscos
envolvidos. Este trabalho deverá ser feito por uma equipe composta de pessoas relacionadas ao
objeto de contingência (sistema, área, CPD). Uma boa ferramenta para isso é o brainstorming. 
Temos ameaças que possuem uma chance mínima de ocorrência e temos ameaças que ocorrem
frequentemente, mas com baixo impacto na empresa (worms, por exemplo). Para que possamos
identificar os riscos para os quais iremos desenvolver o plano de contingência, devemos priorizá-
los. Para isso usamos uma matriz de risco onde são considerados o impacto que ela poderá causar
na empresa e a probabilidade de ocorrência de uma ameaça, caso ocorra. O método mais usual de se
obter essa matriz é através de ponderação, onde damos pesos aos critérios (probabilidade e impacto)
e observamos o comportamento de cada risco em relação aos critérios. No final, conseguimos o
escore de risco que decidirá para quais riscos iremos fazer o plano de contingência. 
Classificação do impacto
São analisados sob 2 aspectos: curto e longo prazo (em função do tempo que em que o impacto
permanece afetando os negócios da empresa) Podemos classficiá-lo em uma escala de 0 a 5:
0 – impacto irrelevante
1 – Efeito pouco significativo, sem afetar a maioria dos processos de negócio da empresa
2 – Sistemas não disponíveis por um determinado período de tempo, podendo causar perda de
credibilidade junto aos clientes e pequenas perdas financeiras.
3 – Perdas financeiras de maior vulto e perda de clientes para a concorrência
4 – Efeitos desastrosos, porém não compromete a sobrevivência da empresa
5 – Efeitos desastrosos comprometendo a sobrevivência da empresa.
Classificação conforme probabilidade de uma ameaça ocorrer:
0 – Ameaça completamente improvável de ocorrer
1 – Probabilidade de ameaça ocorrer menos de 1 vez ao ano
2 – Probabilidade de ameaça ocorrer ao menos 1 vez ao ano
3 – Probabilidade de ameaça ocorrer ao menos 1 vez por mês
4 – Probabilidade de ameaça ocorrer ao menos 1 vez por semana
5 – Probabilidade de ameaça ocorrer diariamente
Ambiente vulnerável → Risco calculado → Estratégia
Estratégias:
1 – Eliminar o risco
2 – Reduzir o risco a um nível aceitável
3 – Limitar o dano, reduzindo o impacto
4 – Compensar o dano por meio de seguros
*Ameaças que envolvem risco de vida devem ser considerados de alto escore, independente da
probabilidade de ocorrência da mesma.
Planos de contingência:
Plano de emergência – Formado pelas respostas de risco (ações a serem seguidas na eventualidade
de uma ameaça ocorrer) e tentativas de evitar danos causados por desastres mantendo, dentro do
possível, a capacidade de funcionamento da empresa/sistema. Possui alto escore na matriz de risco.
Objetivos:
Prever as possibilidades de desastres (naturais ou provocados)
Prover meios necessários para detectar antecipadamente e eliminar/frear o dano
Prover segurança física contra fogo, fumaça, água, intrusos, etc
Prover respostas de risco para ameaças. (Ações a serem seguidas, como em um checklist, na
eventualidade de ocorrer uma ameaça. 
Exemplo: Deve conter o nome de quem as executará, bem como o telefone onde estas pessoas
podem ser encontradas nas 24hs do dia. No caso de um incêndio, deve ser definido por exemplo
quem decide que o local deve ser evacuado, quando evacuá-lo, quem chama os bombeiros, etc.
*Participação dos integrantes da CIPA (comissão Interna de Prevenção de Acidentes. 
 
Plano de backup – Tem a função de prover recursos de continuidade (para serviços críticos).
Provê:
Backup de arquivos
Atualização da biblioteca externa (um lugar afastado do local principal de trabalho onde são
guardados todos os recursos que possam ser necessários para a operação do negócio em caso de
emergência
Acordos com terceiros através de acordos de reciprocidade (são acordos feitos entre 2 empresas que
possuam o mesmo tipo de equipamento ou área de trabalho equivalente. Quando uma das empresas
não puder usar o seu equipamento, usará o do parceiro em turnos de trabalho diferentes).
Processamento alternativo através de processamento manual
Continuidade dos serviços com a manutenção de múltiplas facilidades de produção em locais
distintos
Processamento dos sistemas através de hot site (são instalações de TI configuradas pelo cliente, que
ficam inoperantes até o momento emque o cliente precisar delas. O cliente para mensalidades para
ter este serviço disponibilizado na hora em que precisar).
Plano de recuperação – Provê a capacidade de restauração permanente das atividades da área de
negócio/CPD. São as atividades e recursos necessários para se passar da situação de emergência
para a situação normal. 
AULA 3 
Realizando uma auditoria – Fases de uma auditoria de sistemas
Planejamento – Tendo ou não uma equipe de auditores internos, as empresas devem fazer
auditorias periódicas no seu data center ou CPD, mas não fazem auditoria de todos os seus sistemas.
É necessário escolher quais os sistemas que são passíveis de serem auditados e geralmente, a
escolha é pelo seu escore de risco.
Para o cálculo do risco de um sistemas podemos considerar os seguintes itens:
1 – Custo do sistemas
2 – Valor diário das transações
3 – Volume diário de transações processadas em média, por dia
4 – Visibilidade do cliente (clientes afetados pelo sistema)
5 – Impacto em outros sistemas
6 – Extensão do sistemas (número de unidades operacionais que o sistema servirá)
7 – Capacitação da equipe (profissionais de desenvolvimento e usuários)
*Com exceção do último item, quando mior o valor de cada item, maior o risco.
Para medir o risco de cada sistemas, podemos usar o método da ponderação: definimos pesos para
os itens e verificamos a situação de cada sistema em relação a esses itens, atribuindo uma nota de 0
a 10 para cada item. Multiplicamos o peso pela nota e somamos essas multiplicações e então temos
o escore de risco do sistema. A empresa então deve determinar que serão auditados os sistemas de
escore considerado alto. 
Uma vez tendo um sistema sido escolhido para ser auditado, o auditor necessita ter conhecimento
sobre a área, o produto e o ambiente para o qual o sistema dará suporte operacional. Esse
conhecimento pode ser adquirido através de cursos, manuais, visitas técnicas ou qualquer outro
meio que permita ao auditor entender sobre a área. 
Após essa fase de iniciação, o passo seguinte é decidir quais os controles internos, quais processos e
controles de negócio devem estar presentes no sistema, em forma sistêmica ou manual, bem como
as ferramentas de auditoria serão usadas e quais os recursos serão necessários. 
Controles internos
C01 – Integridade de dados/processos
C02 – Segurança do sistema
C03 – Legibilidade operacional
C04 – Conformidade
C05 – Guarda de registros (rastreamento)
C06 – Guarda de ativos
C07 – Programas de sistemas
C08 – Organização/ administração
C09 – Processo de desenvolvimento
C10 – CPD / data center
Processos
1 – Plano do negócio
2 – Aprovação do projeto
3 – Definição / viabilidade
4 – Plano de implementação
5 – Análise detalhada / desenho do sistema 
6 – Requisição de aprovação
7 – Seleção de parcerias / fornecedores
8 – Desenho do sistema
9 – Plano de teste de desenvolvimento
10 – Plano de conversão / instalação
11 – Plano de teste
12 – Programação / teste
13 – Teste de aceitação
14 – Manual do usuário
15 – Manual de operação
16 – Relatório de aceitação de tteste
17 – Conversão 
18 – Aceite do usuário
Controle de negócio (Controles específicos para cada projeto conforme o produto para o qual o
sistema dará suporte operacional.
Exemplo: Cartão de crédito
O sistema deverá estar preparado com processamento e rotinas manuais para:
Cartão clonado
Cartão extraviado
Extrato de pagamento extraviado
Cliente tentar comprar acima do seu limite de crédito, etc.
*Toda auditoria deve ser tratada como um projeto e portanto deverá ter um cronograma e um
orçamento. 
O cronograma é baseado na estimativa de tempo que será gasto em cada ponto de controle (unidade
a ser auditada – controle interno, processo ou controle de negócio) a ser trabalhado, além da
confecção e emissão do relatório de auditoria. Além das atividades pertinentes à auditoria em si
(contatos, revisão de documentação, documentação, preparação de fluxos de sistemas, testes,
representação gráfica de todo o ambiente computacional sob auditoria, etc devemos considerar
atividades não específicas de auditoria como viagens, treinamento de auditoria, etc para a
determinação dos prazos.
* Na fase de planejamento o auditor seleciona quais os pontos de controle farão parte da auditoria e
qual a tecnologia necessária para testá-los. Após o teste, se não for encontrada fraqueza para o ponto
de controle, passamos ao ponto seguinte. Caso sejam encontradas fraquezas, passamos a chamar
este ponto de controle de ponto de auditoria e comunicaremos ao auditado com recomendações de
acerto.
Resumo – planejamento:
1 – Escolher sistemas
2 – Obter conhecimento inerente
3 – Decidir sobre controles internos, processos e controles de negócios
Execução
Terminado o planejamento da auditoria, o auditor deverá informar a área auditada o sistema que foi
eleito para auditoria. Deve ser realizada uma reunião inicial entre a auditoria e as pessoas-chave da
área de sistemas e da área usuária, onde a auditoria informará que o sistema foi selecionado para ser
auditado. Informará também o que será investigado, o tempo estimado e a provável data de emissão
do relatório final. Pedirá também a colaboração das áreas de sistemas para que os funcionários
colaborem com os auditores, fornecendo-lhes o que for pedido. 
Começa então o trabalho de campo onde os auditores irão verificar a existência dos controles
internos, processos e controles de negócios. Serão feitos testes, as documentações serão analisadas e
entrevistas serão realizadas com o pessoal das áreas envolvidas. Ao identificar uma fraqueza,
informar verbalmente o fato e solicitar acerto fomalizando uma data prevista. O auditor emite
documento com comunicação de falha, mostrando os riscos que ela poderá trazer ao sistema,
negócio e empresa e recomenda o acerto da mesma. Solicita nesse documento que o auditado diga
se concorda ou não com a falha encontrada e, em caso afirmativo, que informe a data de acerto
prevista. Caso o auditado discorde, ele deverá informar por escrito e justificar sua discordância. O
auditor recebe a resposta com a data prevista para acerto da falha e segue seu trabalho de campo. Na
data prevista, o auditor deverá verificar pessoalmente, com evidências, que a mesma foi acertada.
Em caso positivo, anota que a falha foi consertada, em caso negativo, emite outra comunicação de
falha e segue no procedimento. Ao término do trabalho de campo, quando todos os controles
internos, processos e controles de negócio forem verificados, o auditor prepara-se para a emissão do
relatório. Este trabalho deve ser todo documentado, pois será a evidência do trabalho de auditoria. 
*Nunca, sob qualquer hipótese, o auditor dará a solução para acerto da fraqueza. 
Emissão e divulgação dos relatórios
O relatório de auditoria será emitido baseado no trabalho de campo realizado. A nota do relatório
será dada conforme as comunicações de falhas emitidas e não resolvidas até o momento da emissão
do relatório. O rascunho do relatório (sem a nota) é discutido com os auditados antes da emissão
oficial. O objetivo é esclarecer que todos os pontos abordados no relatório foram trabalhados com
os auditados e não há nenhuma surpresa no relatório. Somente após essa reunião é que a auditoria
emite o relatório, endereçado ao diretor da área de sistemas, com cópia para a direção da área
usuária do sistema. Quem assina o relatório é o auditor responsável e o diretor de auditoria. 
Follow-up
A auditoria deve acompanhar a solução das falhas durante o trabalho de campo, e após a emissão do
relatório. A verificação do acerto deve ser feita pessoalmente, incluindo testes para verificar se os
acertos foram eficientes. Todo o acompanhamento deve ser documentado e servirá de subsídio para
auditorias futurasdo mesmo sistema ou do data center. 
Resumo das etapas:
Planejamento – Escolher sistema / decidir controles internos, processos e controles de negócios
Execução – Trabalho de campo 
Emissão e divulgação de relatórios – relatório emitido baseado no trabalho de campo. Rascunho/
discussão com os auditados e depois relatório de auditoria com nota para diretor da área de sistemas
com cópia para a direção da área usuária do sistema. Quem assina: auditor responsável e diretor de
auditoria.
Follow-up – Acompanhamento da solução de falhas
AULA 4
Podemos realizar uma auditoria de sistemas em:
a) Sistemas em desenvolvimento – Nossa atenção é focada no que foi planejado em termos de
controles internos, processos e controles de negócios a serem implementados nos sistemas.
b) Sistemas em operação – Além de vermos se tais pontos de controle foram implementados,
devemos testá-los e saber quantos registros serão testados é algo a ser definido. Verifica a existência
dos pontos de controle e processos planejados e executa os respectivos testes. Para tanto, o auditor
pode contar com 3 tipos de programas de auditoria de TI:
1) Softwares generalistas - São constituídos de um conjunto de programas em ambiente batch
(processamento offline do sistema), que pode processar várias funções de auditoria e simulação
paralela no formato desejado (exemplo: extração de dados de amostra, testes, geração de dados
estatísticos para análise, detecção de duplicidades, sequência incorreta, etc). Normalmente são
sistemas comprados prontos, que carecem de personalização conforme necessidade dos auditores.
Exemplos:
1) ACL (Audit Command Language) – É um software para extração e análise de dados.
2) IDEA (Interactive Data Extraction & Analysis) – Software para extração e análise de dados.
3) Audimation - É a versão norte americana do IDEA, da Caseware-IDEA, fornecendo consultoria
e suporte.
4) Galileo – É um software integrado de gestão de auditoria. Inclui gestão de risco de auditoria,
documentação e emissão de relatórios para auditoria interna.
5) Pentana – Software de planejamento estratégico de auditoria, sistema de planejamento e
monitoramento de recursos, controle de horas, registro de checklists e programas de auditoria.
6) SE Audit (Gestão de Auditorias) – Software que realiza o gerenciamento de todas as etapas do
processo de auditoria, desde o planejamento e aprovação até o monitoramento, seja ela interna de
fornecedores e/ou de organismos certificadores.
7) Snort – Ferramenta NIDS (Network Intrusion Detection System) – open source bastante popular
por sua flexibilidade nas configurações de regras e constante atualização frente às novas
ferramentas de invasão.
8) Nessus – Ferramenta de auditoria muito usada para detectar e corrigir vulnerabilidades nos Pcs
da rede local. Ele realiza uma varredura de portas, detectando servidores ativos e simulando
invasões para detectar vulnerabilidades.
9) Nmap (Network Mapper) – Ferramente de código aberto para exploração de ede e auditoria de
segurança. Ela foi desenhada para escanear rapidamente redes amplas, embora também funcione
muito bem contra hosts individuais. COBIT (Guia) para gestão de TI recomendado pelo ISACF
(Information Systems Audit and Control Foundation).
Vantagens:
O software pode processar vários arquivos ao mesmo tempo
Pode processar vários tipos de arquivos com formatos distintos
Pode fazer integração sistêmica com vários tipos de softwares e hardwares
O auditor não precisa ser especislista em informática para desenvolver aplicativos para testar seus
dados.
Desvantagens:
As aplicações não podem ser feitas online, já que gravam diversos arquivos para serem analisados
em separado
Não provê cálculos específicos para sistemas específicos (Como cartão de crédito, por exemplo)
2) Softwares especializados – São programas desenvolvidos pelos auditores (ou sob sua
encomenda) a fim de testar particularidades de sistemas auditados que possuem características
incomuns, como por exemplo, sistemas de leasing, crédito imobiliário, câmbio, etc.
Vantagens:
Inclusão de testes de controles internos específicos tais como dígito verificador, controle de lote,
personalizando o que se quer testar.
Inclusão de hash total (campos de controle colocados nos header ou trailler labels a fim de assegurar
a integridade dos dados. Pode ser um algoritmo sem sentido funcional como por exemplo, somar
dia e mês de nascimento dos clientes atualizados na base de dados)
Header label – registro de controle (primeiro registro do arquivo).
Trailler label – registro de controle (último registro do arquivo)
Desvantagens:
Necessita que o auditor esteja familiarizado com o desenvolvimento de TI
Há custos de desenvolvimento de programas
3) Softwares utilitários – São programas utilitários para funções básicas de proessamento como:
somar determinados campos de um arquivo, classificar o arquivo, listar determinados campos de
registros de um arquivo. Normalmente os sitemas operacionais ou os bancos de dados possuem um
certo número desses programas que não são específicos de auditoria, podendo ser utilizados para
debug e testes de sistemas.
Vantagens:
São fáceis de serem aprendidos
São fáceis de serem utilizados
Desvantagens: Executam apenas funções padrões.
Algumas técnicas de auditoria
Nem todas as auditorias de sistemas requerem as mesmas técnicas. Tudo dependerá do escopo da
auditoria (o conjunto de controles internos, processos e controles de negócios) do sistema a ser
auditado. 
1) Programa de computador para auditoria – São programas especializados, correlacionando
dados e arquivos, tabulando e imprimindo seus conteúdos. Podem ser arquivos sequenciais,
indexados, banco de dados, tanto para alta plataforma (mainframe) como para baixa plataforma
(microcomputadores). Algumas funções que podem ser incluídas em programas para auditoria:
Tabulação de campos – Somatório de datas de vencimento de títulos, gerando hash total que deverá
ser confrontado com o campo correspondente no header ou trailler label. Somatório de campos
quantitativos para efeito de confrontação ou acompanhamento de acumulados, inclusive controle de
lote.
Contagem de campos/ registros – Apuração de totais por tipo de registro ou campo.
Análise de conteúdo de campos/ registros – Verificação da existência de campos ou registros de m
arquivo. Correlação entre campos de um arquivo para verificação da coerência e validade desses
campos. Cruzamento horizontal entre campos em um registro com vistas à integridade do registro.
Correlação de arquivos – Confronto de campos entre registros com vistas à garantia de ambos os
arquivos. 
Estatísticas dos campos dos arquivos – Apuração de média, desvio padrão, moda e/ou outras
medidas estatísticas em um universo de registros/campos de um arquivo para análise de
comportamento desse universo.
Análises:
Verificar se cada campo de cada registro está preenchido. Caso contrário, listar, exibir o campo em
tela ou gravar em arquivo de saida. 
Listar código do item e código da localização física dos itens para efeito de verificação física,
conforme os seguintes critérios: a) Não movimento há mais de 1 ano, b) Quantidade em estoque
menor que ponto de ressuprimentio, c) Quantidade em estoque zero ou negativo, d) Valor total do
item em estoque 2x maior que valor médio do item em estoque.
Enquadramento do item segundo tabela de números aleatórios
Somar data da última movimentação de cada item em estoque e verificar se o total cruza com o total
correspondente gravado no registro trailler. 
Multiplicar, a cada registro do item, o campo quantidade em estoque pelo campo unitário do item e
verificar se é igual ao campo valor total do item em estoque (este é um exemplo de controle
cruzado)
*Controle cruzado = Chegarao mesmo resultado por mais de um meio.
O auditor pode testar um sistema de 2 maneiras:
1) Constrói os programas e roda com massa de dados real
2) Prepara a massa de dados e roda com programas de produção
2) Questionários para auditoria – Para cada ponto de controle, deverá existir um questionário
contendo perguntas relevantes ao ponto de controle e espaço para o auditor assinalar se o sistema
satisfaz ou não aquele ponto de controle, além de um local para escrever observações e referências
sobre papéis de trabalho. Para os quesitos que obtiverem resposta negativa,o auditor deverá agir no
sentido de solicitar acertos. A auditoria guardará os questionários em um banco de questionários e a
cada auditoria, ao selecionar os pontos de controle, recuperará os respectivos questionários para o
trabalho de campo.
Os questionários poderão ter perguntas relacionadas à vários pontos de controle:
Segurança de redes de computadores
Segurança física dos equipamentos
Segurança lógica e confidencialidade dos programas e informações que trafegam nos canais de
comunicação
Segurança do centro de computação
Controle de acesso físico e lógico das instalações
Segurança ambiental com relação à infraestrutura de combate à incêndio, inundações, situações de
greve, etc.
Eficiência no uso de recursos computacionais
Tempo médio de resposta em terminal
Tempo de uso dos equipamentos a cada dia
Quantidade existente de rotinas catalogadas
Eficácia de sistemas aplicativos
Quantidade de informações geradas pelo computador e consumidas pelos usuários
Prazo de atendimento de novos sistemas aos usuários
Tempo médio de solução dos problemas dos usuários provida pelo help desk
*A técnica de questionário é normalmente aplicada em conjunto com outras técnicas como
entrevistas e visitas in loco. 
3) Visita in loco – É a presença do auditor na área do auditado para verificação dos pontos de
controle. A visita do auditor é marcada formalmente e é importante para que os pontos nebulosos
sejam esclarecidos. Nessa visita o auditor poderá obter dados, seja por observação, por teste, por
documentação ou informação coletada. Caso seja encontrada alguma fraqueza, o auditor informará
verbalmente na hora ao auditado e posteriormente, por escrito.
São verificados:
Inventário de arquivos magnéticos (discos, fitas, CDs) armazenados na fitoteca com respectivos
períodos de retenção de cada volume
Inventário de suprimentos armazenados (fitas e cartuchos de impressora, formulários contínuos,
formulários pré-impressos, etc)
Utilização dos computadores com o objetivo de verificação de controle de acesso, uso de ordem de
serviço, arquivos magnéticos, schedule de produção, distribuição de relatórios, etc.
Acompanhamento das rotinas de backup e atualização da biblioteca externa. 
A Presença do auditor in loco também é importante para:
Constatação física da existência de ativos computacionais da empresa, bem como seu estado de
conservação
Constatação da eficiência dos procedimentos de uso, incluindo segurança física. 
4) Entrevista
Visa obter evidências do trabalho do auditor para que ele possa opinar sobre o sistema. Pode ser
pessoal, por telefone ou por vídeoconferência. De qualquer forma, é necessário fazer um roteiro
prévio do que se pretende abordar na entrevista, preferencialmente classificado por ponto de
controle. 
A entrevistas pode ser:
Estruturada – Aquela que utiliza formulários na coleta de dados
Não estruturada – Aquela que não utiliza formulários na coleta de dados
A entrevista deve seguir uma sequência lógica, orientada pelo fluxo de eventos do processo.
Perguntar às pessoas o que elas fazem, quais informações recebem e quais passam adiante. Sempre
que possível utilizar perguntas abertas (aquelas em que o entrevistado fala livremente). É necessário
saber escolher as perguntas e administrar bem o tempo, não ultrapassar o limite de 1 hora e meia.
Evitar perguntas sobre áreas irrelevantes. Cruzar as informações para confirmar as evidências. O
clima de cordialidade e cooperação deve ser mantido e a entrevista deve ser conduzida como uma
conversa e não como um interrogatório. Informar previamente ao entrevistado que suas respostas
serão anotadas de forma precisa. 
AULA 5
Mais técnicas de auditorias
Uma técnica sempre presente nas auditorias é o teste do sistema auditado. Há 2 tipos: o teste de
observância e o teste substantivo.
Teste de observância - É aquele empregado pelo auditor a fim de determinar se os procedimentos
internos da empresa estão sendo cumpridos pelos seus colaboradores. É largamente aplicado em
auditorias operacionais, onde o objetivo do auditor é verificar se os padrões, metodologias, políticas
e normas internas estão sendo respeitadas. Requer muita atenção e normalmente são aplicados sem
que os envolvidos no processo auditado percebam. 
Teste substantivo – Este tipo de teste é empregado pelo auditor quando se deseja obter provas
suficientes sobre as transações para fundamentar sua opinião sobre determinados fatos. Sobre este
teste, há diversas constatações:
Existência real – que as transações comunicadas/ registradas realmente tenham ocorrido.
Integridade – que não existam transações além daquelas registradas/ comunicadas e que as
informações permanecem inalteradas nos registros, desde sua gravação.
Parte interessada – que os interessados naquele registro / comunicação tenham obtido as
informações na sua totalidade.
Avaliação e aferição – que o itens que compõem determinada transação / registro tenham sido
avaliados e aferidos corretamente.
Divulgação – que as transações/ registros tenham sido corretamente divulgados.
*Os testes substantivos são imprescindíveis em trabalhos de auditoria, pois é através dele que o
auditor obtém evidências sobre os saldos/ transações apresentadas pela empresa. É fundamental
também como complementação dos testes de observância, pois através dele o auditor tem condições
de constatar sobre a fidedignidade das transações e registros. 
Dados de teste (test data ou test deck) – É aplicada em ambiente batch e o auditor prepara um
conjunto de dados com o objetivo de testar os controles programados e os controles do sistema
aplicativo para rotinas sistêmicas ou manuais. Esta massa de dados deve contemplar um
determinado número de transações, com dias úteis de processamento suficiente para que o resultado
seja conclusivo. Depois de executar o sistema com esta massa de dados, o auditor irá comparar o
resultado com aquele predeterminado. Para a efetividade do teste, esta massa de dados deve conter
várias possibilidades de simulações do processamento real, cobrindo os controles internos que a
auditoria pretende verificar. Os dados simulados no teste devem prever situações corretas e
incorretas de natureza:
Transações com campos incorretos
Transações com valores ou quantidades nos limites de tabelas de cálculos
Transações incompletas
Transações incompatíveis
Transações em duplicidade 
A mecânica de aplicação do test deck tem as seguintes etapas:
1 – Compreensão do módulo do sistema a ser avaliado, identificação de programas e arquivos
2 – Simulação dos dados de teste pertinentes, com foco nos pontos de controle que se quer testar
3 – Elaboração de formulários de controle de teste, o que significa apurar resultados esperados e
pré-calculados para a confrontação com os resultados alcançados no teste e gravado em arquivos.
4 – Transcrição dos dados de teste para um meio aceito pelo computador 
5 – Preparação do ambiente necessário para a execução do teste
6 – Processamento dos dados de teste com a utilização do programa real que contém rotinas do
sistema sob auditoria a serem validadas
7 – Avaliação dos resultados do teste via análise de listagens obtidas a partir do arquivo magnétic
gerado
8 – Emissão de opinião sobre o ponto de controle testado com adevida documentação.
Facilidade do teste integrado
Esta técnica, também conhecida por Integrated Test Facility (ITF), somente pode ser processada
com maior eficiência em ambiente online e real time. Os dados são integrados aos ambientes reais
de processamento. A execução da técnica envolve aplicação de entidades fictícias (como
funcionários fantasmas na folha de pagamento ou clientes inexistentes em saldos bancários)
Confrontamos os dados no processamento de transações reais com esses dados e os resultados são
comparados com aqueles predeterminados. Essa facilidade evita que se atualizem as bases reais da
organização com os dados fictícios, mas criam-se arquivos de resultado em separado. Este
procedimento é utilizado em ambiente de produção normal, sem o consentimento dos operadores de
computador. 
Simulação paralela
É a elaboração de um programa de computador (pelo auditor) para simular as funções de rotina do
sistema sob auditoria, com foco nos pontos de controle a serem verificados. Esta técnica utiliza
dados de produção alimentados à rotina do sistema sob auditoria como entrada.
*Enquanto no test deck simulamos dados e os submetemos ao programa de computador que
normalmente é processado na produção, na simulação paralela, simulamos o programa e o
processamento com a massa real. 
Estrutura de aplicação dessa técnica:
1 – Levantamento e identificação via documentação do sistema, da rotina a ser auditada e
respectivos arquivos de dados
2 – Elaboração de software com a lógica da rotina a ser auditada. 
3 – Preparação do ambiente de computação para processamento do software elaborado pelo auditor.
Lógica de auditoria embutidas nos sistemas
Nesta técnica podem ser incluídas as rotinas para gravação de logs (histórico). Devem ser incluídas
as rotinas realmente necessárias. Relatórios de exceção também podem ser incluídos nesta
categoria. 
Mapeamento estatístico dos softwares (mapping)
Técnica que pode ser utilizada por auditores para efetuar verificações durante o processamento de
programas, flagrando situações tais como: 
– Rotinas não utilizadas – quantidade de vezes que cada rotina foi utilizada quando submetida
a processamento de uma quantidade de dados.
– Rotinas existentes em programas já desativados ou de uso esporádico
– Rotinas mais utilizadas
– Rotinas fraudulentas e de uso em situações irregulares
– Rotinas de controle acionadas a casa processamento.
Para a utilização do mapping há a necessidade de ser processado um software de apoio em conjunto
com o processamento do sistema aplicativo ou rotinas específicas deverão ser embutidas no sistema
operacional utilizado. Há também a necessidade de inclusão de instruções especiais junto aos
programas em processamento na produção. Além de um custo possivelmente alto, essa técnica pode
degradar desenvolvimento do sistema. Pode ser utilizada tanto em ambiente de teste como de
produção. 
Rastreamento dos programas de computador (tracing)
Técnica que possibilita seguir o caminho de uma transação durante o processamento do programa.
Ao testar determinada transação podemos acompanhar sua lógica de instruções e identificar
problemas na lógica de um programa. Essa abordagem possibilita a identicação de rotinas
fraudulentas pela alimentação de transações particulares. 
Análise da lógica de programação
Esta técnica implica na análise visual do código fonte, buscando a verificação da lógica dos
programas, normalmente feita de modo manual a fim de verificar que as instruções dos programas
são as mesmas já identificadas na documentação do sistema aplicativo. Ela verifica: 
A efetividade dos controles programados
Se o programador cumpriu as normas de padronização de código de rotinas, arquivos, programas,
relatórios.
Analisa a qualidade da estrutura do programa. 
Identifica vícios de programação e o nível de atendimento às características da linguagem de
programação utilizada. 
*Para aplicação desta técnica é imprescindível que o auditor tenha conhecimento em programação. 
Análise do log/ accounting 
O log/ accounting é um arquivo gerado por uma rotina do sistema operacional que contém registros
da utilização do hardware e software. A tabulação desse arquivo Log/ accounting permite a
verificação da intensidade de uso dos dispositivos componentes de uma configuração ou rede de
computadores, bem como o uso do software aplicativo de apoio em vigência.
Funções dessa análise:
Identificação de ineficiência no uso do computador
Apuração do desbalanceamento da configuração do computador, através da verificação dos
dispositivos que estão com mais folgas ou mais sobrecarregados.
Verificação de erros de programas ou de operação do computador 
Flagrar o uso de programas fraudulentos ou de utilização indevida
Captar tentativas de acesso a arquivo indevidas (senhas não autorizadas)
Indicadores de qualidade, através do monitoramento do computador 
*Construir um software para trabalhar com registros de:
a) Contabilização – Mostrar quais usuários utilizaram quais programas e por quanto tempo 
b) Atividade do data set (data set é um arquivo) – Providenciar informações acerca de quais
arquivos de dados foram utilizados durante o processamento e que usuário solicitou. Informações
que devem estar contidas neste arquivo: Nome do data set, tamanho do registro, número de série do
volume e o usuário do data set. 
Existem 2 tipos de arquivos Log:
1 – Aqueles que registram o uso da CPU, dos arquivos magnéticos, da carga e do nível de utilização
dos dispositivos do computador.
2 – Log de transações – Um arquivo registra todos os dados que foram processados / transmitidos.
Este tipo de arquivo Log é comum em ambientes online. 
AULA 6
Apenas controles garantem a segurança de uma empresa. Segurança na empresa significa proteção
de informações, recurso (materiais, humanos, tecnológicos, financeiros), serviços e acesso, no
intuito de diminuir a probabilidade de dano. Segurança é responsabilidade de todos, é necessário
que o comportamento das pessoas seja um reflexo de suas responsabilidades. Por esta razão a
empresa cria políticas administrativas, para homogeneizar o comportamento de todos em relação a
algo que ela quer preservar. As políticas administrativas (também conhecidas por políticas
organizacionais) assegura que o comportamento das pessoas será estabelecido em relação a
determinado tópico, elas devem tratar de princípios éticos. 
A política deve conter o mínimo de informação, mas o bastante para que seja entendida sem
dúvidas. 
Políticas administrativas ou organizacionais → São compulsórias e seu descumprimento pode
justificar uma demissão por justa causa.
Exemplos de políticas administrativas:
Não se admitir funcionários com até o terceiro grau de parentesco (política de RH)
Todo funcionário deverá portar crachá com foto recente ao circular dentro da empresa (política de
segurança)
Processo de implantação de uma política de segurança da informação:
1) Identificação dos recursos críticos – Identificar recursos críticos significa definir o que precisa
ser protegido: Hardware, software, dados, pessoas, documentação, suprimentos, etc.
2) Classificação das informações:
Públicas ou uso irrestrito - Pode ser divulgada para qualquer pessoa. Exemplo: Informações na
internet, jornal.
Internas ou uso interno – Não devem sair do âmbito da organização, se saírem, não são críticas.
Exemplo: Comunicação interna aos colaboradores, house organ (jornal interno da empresa)
Confidenciais – Devem ser protegidas contra o acesso externo. Só as acessam se seu uso for
fundamental para o exercício da função. Sua violação pode comprometer ofuncionamento da
empresa, causar danos financeiros, quebra de imagem e perda de clientes para a concorrência.
Exemplo: Dados de clientes, senhas, contratos.
Secretas – Sua violação interna ou externa é extremamente crítica. O número de pessoas autorizadas
é minimo (2 ou 3). Exemplo: Dados militares, dados de segurança nacional, fórmula da Coca-cola.
3) Identificação das possíveis ameaças e análise de risco – Similar ao que fazemos na definição
de um plano de contingência,também na definição das políticas administrativas devemos levantar as
ameaças possíveis e traçar uma matriz de risco para que possamos identificar as piores ameaças.
4) Objetivos de segurança a serem alcançados – Nem sempre deixamos claros para o público
externo, o real objetivo da política. Por exemplo, uma política de RH em que se proíbe parentes
trabalhando na mesma empresa é uma política de segurança a fim de evitar fraudes.
5) Elaboração da proposta política – Uma vez identificados os recursos que se quer proteger,
desenvolvemos estratégias para controlar o ambiente vulnerável. Devemos pensar em 4 linhas de
ação:
Eliminar o risco, se possível
Reduzir o risco a um nível aceitável
Limitar o dano, reduzindo o impacto
Compensar o dano, por meio de seguros
*A fim de minimizar a possibilidade de ameaças, a estratégia de controles em camada é mais
adequada, devido à complexidade do ambiente computacional. A disposição de várias camadas de
segurança entre a ameaça e o recurso diminui consideravelmente a vulnerabilidade deste, já que,
mesmo que uma das camadas seja quebrada, as outras o protegerão. É o caso de termos senha para
entrar na rede e senha para o aplicativo, além de autorizações de só leitura e de leitura-gravação
para a base de dados (controle de acesso). 
6) Discussão com os envolvidos – Após termos o rascunho da política de segurança pronto,
discutimos com o time de segurança e as pessoas que trabalham com os recursos (gerente das áreas
de sistemas, RH, recepção, portaria, etc). 
7) Apresentação do documento formal à gerência superior – Uma vez que a política foi
aprovada pelo grupo mencionado no item anterior, a política é encaminhada à gerência superior da
empresa para aprovação. 
8) Aprovação – A gerência superior (diretoria executiva) aprova a política, já que o
comprometimento da direção é fundamental para o cumprimento da mesma.
9) Divulgação e implementação – Devemos fazer um treinamento com todos os colaboradores e
pessoas que seriam afetadas pela política. 
10) Avaliação da política e identificação das mudanças necessárias – Nesta fase, cujo período
pode variar de 6 meses a um ano, as pessoas podem reportar como estão sendo os resultados da
política: se está fácil de usar, se dificultou o processo operacional da empresa, etc. Qualquer
alteração será estudada e, se necessária, implementada com a devida divulgação. 
11) Revisão e implementação definitiva – Após a revisão, a política é implementada em
definitivo. Ela representa os valores e crenças da empresa, não devendo ser alterada. A política de
segurança diz o que deve ser feito, por essa razão não devemos acrescentar detalhes de
implementação nela, isso fica por conta dos procedimentos, que dirá como a política será
implementada. 
*Caso o modo de operar seja alterado, a política fica intacta e só mudamos os procedimentos. 
*Para melhor controle administrativo devemos classificar as política em subgrupos
interrelacionados, por exemplo: políticas de backup, políticas de senhas, políticas de acesso,
políticas de instalação de equipamentos, etc.
O que fazer em casos de violação da política de segurança da informação
Como nem sempre é fácil detectar violação da política de segurança, os procedimentos de
segurança devem ser implementados de forma a minimizar a possibilidade de ocorrência sem que
essa seja detectada. 
Ao detectar uma violação, a primeira coisa a fazer é determinar sua razão (ocorreu por negligência,
acidente ou erro, desconhecimento da política de segurança ou ação deliberada?) O processo
investigativo deve determinar as circunstâncias da violação, como e por que ela ocorreu. 
É recomendável que a política de segurança mostre o que fazer em cada tipo de violação, de acordo
com a sua severidade, visando ações corretivas e punição dos infratores, se for o caso. Dependendo
da violação e de quem cometeu, a punição pode variar desde uma advertência verbal à demissão por
justa causa ou até mesmo um processo judicial. 
Descrição de cargos na área de TI
As descrições de cargos e funções possibilitam uma implementação consistente de controles
organizacionais na área de TI. 
Supervisão da infraestrutura de TI – Atua junto à gerência de TI definindo e propondo metas e
soluções. Planeja e avalia a capacidade da estrutura existente, indicando melhorias. Garante o
perfeito funcionamento do ambiente de TI através de equipes técnicas.
Administração de redes – Administra, supervisiona e acompanha as facilidades das instalações de
redes. Instala, administra e fornece suporte aos diversos servidores da empresa. Administra de
forma adequada as contas de usuários e permissões de acesso às informações. Monitora o
desempenho da rede e soluciona possíveis falhas na conectividade. Traça diretrizes para um perfeito
funcionamento da rede e administra os serviços a serem contratados para a área.
Administração de banco de dados – Administra todo o ambiente de BD, Oracle, SQL server, etc.
Planeja e implementa as estratégias de utilização dos bancos pelas pessoas, sistemas ou programas.
Realiza suporte técnico aos usuários do ambiente. Planeja e executa o backup dos servidores de BD.
Administra as contas da empresa para o acesso ao ambiente de BD. Auxilia o administrador de
segurança de sistemas na alocação de acessos aos arquivos de dados para aplicações a acesso
interno e remoto.
Administração de segurança – Implementa política de segurança na empresa. Detecta possíveis
invasões ou ameaças, realizando ações corretivas. Testa e determina pontos de vulnerabilidade na
rede e na política de segurança adotada, realizando ações corretivas e/ou informando os
administradores responsáveis. Pesquisa novas falhas de segurança dos SOs e produtos utilizados
pela empresa. 
Análise, programação e manutenção de sistemas – Elabora e especifica os requisitos juntos aos
clientes. Analisa e projeta sistemas de informações. Corrige falhas decorrentes de erros humanos ou
técnicos de sistemas, mantendo um serviço permanente de acompanhamento e verificação dos
programas. Executa a programação, os testes de validação e a implantação dos sistemas
desenvolvidos, respeitando a segregação de funções. Mantém a documentação funcional dos
sistemas sempre atualizada. Implementa ajustes, melhorias e modificações quando surgem
atualizações ou em consequência de mudanças da regra de negócios. Realiza suporte aos usuários
do ambiente e de aplicações desenvolvidas. 
Design para web – Analisa o site da internet a ser implementado e propõe linhas de design
adequado aos objetivos e público-alvo. Realiza manutenções de páginas dos sites da empresa.
Pesquisa, avalia e propõe a adoção das novas ferramentas de design disponibilizadas no mercado.
Operador de console – Executa a operação dos sistemas conforme manual e schedule de produção.
Carrega dados, monta dispositivos de armazenamento e opera equipamentos.
Operador de conversão de dados – Executa tarefas de preparação de dados e transmissão. 
Bibliotecário – Mantém controle sobre a responsabilidade de se documentar programas e arquivos
de dados.
Suporte técnico – Realiza a manutenção preventiva e corretiva dos equipamentosinstalados na
empresa. Realiza todo o inventário de hardware e software. Instala e conecta à rede novos Pcs bem
como mudanças de localização dos conectados. Instala, remaneja e mantém a estrutura de
cabeamento da empresa. Instala, configura e dá suporte em todos os sistemas operacionais,
utilitários e aplicativos utilizados pelos usuários da empresa. Controla a disponibilidade de licenças
de uso dos softwares. Acompanha cada chamado aberto até sua solução. Assessora a gerência de TI
em discussões internas de definição de políticas e ações de TI a serem adotadas pela empresa.
Supervisão de help desk – Documenta os problemas operacionais. Soluciona problemas
secundários e encaminha a quem de direito quando problemas mais sérios aparecerem. Efetua o
controle de qualidade dos serviços prestados, através do acompanhamento da solução apresentada
pelos técnicos e da satisfação do usuário.
Grupo de controle de dados – Recebe entradas dos usuários, as registra e transfere ao CPD.
Monitora o processo de conversão de dados. Recebe mensagens de erros e promove as de revisão,
comparando totais de controle. Distribui resultados. Certifica que as correções de erros foram feitas
pelos usuários.
Supervisão de restart / recovery – Define procedimentos para recuperar dados em caso de parada
inesperada dos equipamentos. Grava backups, atentando para enfoque de avô-pai-filho. Implementa
procedimentos de ponto de checagem. Recupera banco de dados. Instalar nobreaks e antivírus.
Implementa o hot site e providencia o cold site (facilidade em que o usuário pode instalar
equipamento de computador depressa em caso de contingência. O local já é preparado para receber
os equipamentos). 
AULA 7
Auditoria de redes
Hoje em dia há uma tendência de se medir a empresa pelo acervo de informações que ela possui.
Tais informações estão nas redes de comunicação da empresa, seja via intranet, extranet ou internet.
Proteger esstas informações que refletem a vida da empresa tornou-se crucial. 
A gestão efetiva das redes concentra-se nos controles relacionados com comunicação de dados e
informações nas camadas físicas e de enlace, utilizando-se dos protocolos de camada de rede IP e
OSI, de camada de transporte TCP e UDP e dos protocolos de aplicação DNS, SNMP, HTTP e
outros. 
Também devemos considerar os seguintes processos na auditoria de redes:
1) Planejamento da concepção da rede com visão estratégica ao integrar o plano diretor de
informática
2) Desenho das arquiteturas e da topologia da rede
3) Implementação dos projetos físicos e lógicos
4) Monitoramento dos desempenhos e possíveis interceptações nas redes
5) Replanejamento de capacidade
6) Levantamento dos problemas operacionais e sua resolução
O auditor de redes deve avaliar com atenção questão relacionadas à:
Vulnerabilidade do TCP/IP e aplicações
Deficiências
Ataques à rotas
ICMP, UDP, sequência, TCP, DNS, fragmentação ou saturação de portas ou buffer/ stack overflow
Avaliação específica da capacidade computacional da wokstation em relação ao time-out interval.
O principal objetivo da auditoria de redes é assegurar a confiabilidade da rede no tocante à:
1) Segurança física – Equipamentos e periféricos, arquitetura da rede, sua construção e
distribuição.
2) Segurança lógica – Customização de recursos de software, desempenho, acompanhamento e
rendimento operacional.
3) Segurança de enlace – Assegurar as linhas e canais de transmissão entre unidades e localidades
remotas obedecendo aos limites estabelecidos.
4) Segurança da aplicação – Disponibilidade da rede, isto é, poder confiar que ela estará
disponível quando necessária, mesmo em situações adversas.
Programa de auditoria de redes
Questionário para verificação – Requerem as respostas:
Sim
Não
Não aplicável
Documentados em forma de papéis de trabalho (work papers) guardados em uma pasta
administrativa do projeto de auditoria em questão. Esses documentos devem ser codificados
conforme sua origem. Por exemplo: ata seria AT-nn, nota de contato seria NC-nn, etc. Esta
codificação deve ser preenchida na coluna Ref. W/P do questionário. 
*Todo o trabalho do auditor deve ser documentado para que possamos ter evidências do que
escreveremos nos relatórios. Nosso trabalho é baseado em fatos e não em opiniões. 
Abaixo os controles em níveis mais gerais:
C1 – Políticas empresariais que garantem implementação efetiva dos controles relacionados ou
ambiente de rede.
C2 – Controles sobre o ambiente e informações com relação a definição da plataforma de hardware,
sistema operacional e mitigação de riscos inerentes.
C3 – Controles sobre softwares
C4 – Controles de segurança
C5 – Informações gerais sobre implementação de firewall
C6 – Procedimentos específicos de controles de operação de firewall
Auditoria de hardware
A idéia é implantar procedimentos de segurança física sobre os equipamentos instalados na
empresa. Inclui funções que possuem mecanismo para restringir acessos de pessoas ao computador
bem como controles referentes à proteção de vida das pessoas (segurança física). Entre os recursos
utilizados para amenizar os riscos de segurança física temos: extintores de incêndio, detectores de
fumaça e aumento de temperatura, sprinklers, etc. 
Os controles de hardware podem ser físicos ou automatizados. 
Programa de controle interno de hardwares
Da mesma forma que na auditoria de redes, há um programa detalhado para levantamento de
controles internos de hardware. Resumo do programa:
C1 – Controles de acesso físico
C2 – Controle de acionamento e desligamento de máquinas
C3 – Controle de acesso físico a equipamentos de hardware
C4 – Localização e infraestrutura do CPD
C5 – Controle de backup e off-site
C6 – Controles de aquisição e disposição do equipamento
C7 – Controles sobre o ambiente e informações com relação à definição da plataforma de hardware,
software, sistema operacional e os riscos inerentes. 
C8 – Controles sobre os recursos instalados.
C9 – Garantia de integridade de transmissão
Controle de acesso
Pode ser de 2 tipos: Físico ou lógico.
Controle de acesso físico – É referente ao controle de entrada dos indivíduos nos recintos da
empresa. Pode ser feito de várias formas: 
Crachá com tarja magnética
Bottom de identificação
Biometria
etc.
Além da identificação das pessoas, é necessário o controle de porte de metais. (Um simples imã
pode desmagnetizar uma CPU)
Controle de acesso lógico – Referente ao manuseio de informações em meios magnéticos. A forma
mais comum de garantia ao acesso lógico à pessoas autorizadas é o uso de senhas. 
Programa de controle de acesso
C1 – Políticas de segurança que forneçam, de forma geral, diretrizes e forma de implementação de
normas de segurança
C2 – Rotinas e procedimentos estabelecidos para atribuição ou modificação do nível de acesso.
C3 – Software para controle de acesso
C4 – Controle de acesso a transações
C5 – Controle sobre utilização de software
C6 – Controle sobre utilização de redes locais. 
AULA 8
Auditoria de aquisição, desenvolvimento, manutenção e documentação de sistemas
Uma das maiores dúvidas de um gestor de sistemas é decidir sobre comprar ou desenvolver um
determinado aplicativo. Vários pontos podem ser considerados, principalmente em relação aos
riscos envolvidos e ao custo-benefício de ambas as alternativas. Em qualquer das opção
(desenvolvimento ou aquisição) é necessário se fazer um estudo preliminar considerando a
viabilidade econômica, operacional e técnica. Lembrando que a aquisição de software pode ser um
sistema novo ou a alteração de algum software já existente na empresa. 
Segundo o PMBOK, os grandes grupos de processos a serem seguidos para que uma empresafaça
uma aquisição de bem ou serviço são:
1) Planejamento de aquisições – O que adquirir e quando adquirir. Defini-se as declarações de
trabalho (descreve a aquisição a ser feita detalhadamente para que os fornecedores possam avaliar
se atendem).
2) Planejamento das solicitações – Documenta os requisitos dos produtos ou bens e identifica
fontes potenciais.
3) Solicitação – Obtém a cotação, ofertas, propostas.
4) Seleção da fonte – Escolhe a melhor proposta.
5) Administração do contrato – gerencia e relaciona-se com o fornecedor.
6) Fechamento do contrato – Finaliza o contrato, incluindo itens abertos.
Programa de teste de controles
Questionário para testes de controles para aplicação pelo auditor, com respostas que podem ser sim,
não ou não aplicável:
Aquisição de sistemas
Há rotinas e procedimentos estabelecidos para o envolvimento do usuário na seleção, especificação
ou modificação de sistemas?
Há rotinas e procedimentos estabelecidos para determinar prioridades de desenvolvimento e
manutenção de sistemas?
Há rotinas e procedimentos estabelecidos para rever as especificações dos projetos por pessoal
apropriado de processamento de dados, fora da área de desenvolvimento e manutenção de sistemas
(por exemplo: operação, segurança e suporte)?
Programação
A empresa faz desenvolvimento ou modificações de sistemas aplicativos internamente?
Teste
Há rotinas e procedimentos estabelecidos para testar aplicativos novos ou que sofreram mudanças
significativas?
Documentação
A empresa mantém documentação para a totalidade dos sistemas contábeis significativos, que
atenda às necessidades do usuário e do pessoal de processamento de dados?
Auditoria de operação de sistemas
A operação do computador envolve as funções de acionar o Inicial Program Loader (IPL) e os
programas que ligam e desligam os computadores. O auditor precisa conhecer todas as operações e
serviços disponibilizados pelos centros de processamento de dados e documentar os controles
organizacionais. As operações mais comuns são:
Planejamento, controle e monitoração das operações
Planejamento da capacidade
Monitoramento de todos os sistemas e redes
Inicialização do sistema e desligamento
Gravação (logging), rastreamento (tracking) dos problemas e monitoramento do tempo de resposta
Gerenciamento de mudanças estruturais e pessoais
Gestão das unidades, dos periféricos e equipamentos remotos
Gerenciamento de bibliotecas
Programação dos serviços (jog scheduling – quadro de horários dos serviços a serem executados
diariamente) e acompanhamento das operações
Automação da produção
Backup dos sistemas, programas e banco de dados
Gerenciamento do help desk
Coordenação e programação de upgrades dos equipamentos
Gestão de restart/ recovery
Auditoria de suporte técnico 
A função de suporte refere-se aos usuários de TI. Dividem-se em 2 grandes grupos: O de funções
rotineiras e o de funções esporádicas. 
Funções rotineiras:
Gerenciamento de help desk
Socorro aos problemas de instalação de redes
Monitoramento da ocorrência de problemas
Treinamento de usuários dos softwares
Revisão preventiva de equipamentos
Substituição dos equipamentos antigos
Segurança da informação quando não há administrador específico da área.
Funções esporádicas:
Dimensionamento de banco de dados
Instalações de softwares
Manutenção dos sistemas operacionais
Upgrades
Avaliação de software para fins de compra
Padronização dos recursos de tecnologia da informação
Ativação de redes (estações, etc)
Auditoria de sistemas aplicativos
Os controles internos, processos e controles de negócios devem ser verificados, não só em sistemas
novos (em desenvolvimento ou adquiridos), mas também nos sistemas em produção. Alguns pontos
de controle são fundamentais e serão aplicados em todos os sistemas, como por exemplo, controle
de acesso. Outros controles, específicos, serão identificados e aplicados conforme o sistema sob
auditoria. 
O COBIT define 7 critérios de informações que podemos adotar como sendo objetivo de uma
auditoria de sistemas:
Efetividade
Eficiência
Confidencialidade
Integridade
Disponibilidade
Conformidade
Confiança
A avaliação dos sistemas aplicativos geralmente usa a entrevista, a observação, a revisão
documental, o teste dos controles internos e programados como ferramentas de auditoria. Podemos
dividir as avaliações em 2 enfoques:
- Verificação da estrutura dos sistemas e seus controles
- Testes substantivos das transações executadas pelos sistemas.
Ao analisarmos a documentação do sistema a ser auditado, devemos atentar para:
Descrição do sistema
Descrição do perfil do sistema
Documentação da visão geral do processamento
Objetivos gerais da auditoria:
Integridade
Confidencialidade
Privacidade
Acuidade
Disponibilidade
Auditabilidade
Versatilidade
Manutenibilidade
AULA 9
Comunicando resultados
Há 2 momentos em que a auditoria emite documentos:
1) Durante o processo de auditoria de sistemas, ao detectar uma falha, enquanto estiver verificando
um ponto de controle.
2) Ao final do trabalho.
*Caso a auditoria seja extensa, podemos também emitir um relatório parcial (draft) sobre nossas
preocupações a respeito das falhas encontradas.
Tão logo uma falha seja detectada , ela deve ser comunicada verbalmente à gerência auditada. O
objetivo dessa comunicação verbal é a breve solução e o acordo de viabilidade de correção da ação
a ser tomada. Após a verificação do fato levantado, uma referência deve ser preparada e aprovada
pela gerência de auditoria. Essa referência é um comentário ou registro do fato encontrado.
Após o término do trabalho de campo, devemos preparar um relatório que comentará o resultado do
trabalho. Esse relatório será baseado nas falhas e recomendações emitidas nas referências. Todas as
referências materiais que não forem resolvidas devem ser incluídas no relatório como falhas e serão
elas que servirão de base para a nota do relatório. Se uma referência foi resolvida, ela será citada no
relatório como tendo sido levantada e resolvida a contento durante a auditoria, na parte do Sumário
e Conclusões do relatório. 
Não emitimos o relatório final sem uma prévia discussão com o auditado. Para tanto, emitimos um
relatório DRAFT (rascunho) sem a parte das conclusões e enviamos para os envolvidos (auditado e
sua gerência). Somente após a reunião, onde o draft foi discutido e chegou-se a um consenso é que
emitimos a versão final do relatório.
Os relatório devem ser construídos em linguagem impecável, devem ser sucintos e objetivos. 
Devemos descrever uma falha de forma clara, direta e sucinta.
Usar voz ativa
Frases curtas
Não misturar fatos com opinião
Não usar nomes próprios
Sempre que possível, quantificar (se a amostra for pequena, não mencionar percentual)
Siglas devem ser explicitadas
Audiência do relatório de auditoria
Quanto mais perto do alto escalão, mais resumidas as informações devem ser. Lembrar que os
executivos não tem muito tempo pra ler, eles gostam de gráficos, pela facilidade de visualização.
Deixe os detalhes para os técnicos. 
Primeira audiência – Vai atuar na recomendação. Valoriza o comentário detalhado e a
recomendação.
Segunda audiência – Nível mais alto que lê o relatório com as falhas e recomendações resumidas.
Regras para um bom relatório:
Evite linguagem pomposa e dura.
Evite linguagem técnica desnecessária. Mantenha o linguajar técnico para os técnicos.
Use linguagem concreta e específica.
Forneça detalhes suficientes
Evite uso excessivo de generalidades (vários, muitos, todos, etc)
Seja claro.
Seja objetivo na escrita.
Escrita deve ser não abrasiva (escrita que faz críticas ou recomendações sem ofender o leitor. Uma
crítica deve ser direcionada ao problema, não a um indivíduo, departamento ou posição).
Use verbos ativos, se puder.
Seja específico, concreto.