U NIVERSIDADE DE COIMBRA

FACU LDADE DE CIÊNCIA S E TECNOLOGIA

DE PA RTA ME NTO DE E NGE NHA R IA INFOR MÁ TIC A

AU D I TO R I A E M
S I ST E M AS D E
I N FO R M A Ç ÃO
GESTÃO DE SISTEMAS D E INFORMAÇÃO

PEDRO SANTOS
CARLOS FAIM
P E D R O S I L VA
RUI MONTEIRO
AU D I T O R I A E M S I S T E M A S D E
INFORMAÇÃO

ii
 ÍNDICE

ÍNDICE ............................................................................................................................................... III

ÍNDICE DE FIGURAS ...........................................................................................................................IV
ÍNDICE DE TABELAS ............................................................................................................................V
1. INTRODUÇÃO ........................................................................................................................ - 1 -
2. CONTEXTUALIZAÇÃO ............................................................................................................. - 3 -
2.1. DEFINIÇÕES ....................................................................................................................... - 3 -
2.2. EVOLUÇÃO HISTÓRICA ......................................................................................................... - 3 -
3. CONCEITOS CONTEMPORÂNEOS ........................................................................................... - 5 -
3.1. CONTROLO ....................................................................................................................... - 5 -
3.2. ENCRIPTAÇÃO E CRIPTOGRAFIA .............................................................................................. - 5 -
3.3. FORENSE COMPUTACIONAL ................................................................................................... - 6 -
3.4. ASPECTOS HUMANOS .......................................................................................................... - 6 -
4. A FUNÇÃO AUDITORIA .......................................................................................................... - 8 -
4.1. O QUE PROCURAR NUMA AUDITORIA ...................................................................................... - 8 -
4.2. A ORGANIZAÇÃO A GESTÃO DE SI E A AUDITORIA DE SI ................................................................ - 9 -
5. REFERENCIAIS METODOLOGICOS......................................................................................... - 13 -
5.1. PORQUE ......................................................................................................................... - 13 -
5.2. FRAMEWORKS (COBIT, ITIL E ISO) ....................................................................................... - 13 -
5.3. GESTÃO DE RISCO ............................................................................................................. - 14 -
6. TÉCNICAS DE AUDITORIA ..................................................................................................... - 17 -
6.1. CONTROLOS AO NÍVEL DA ENTIDADE ..................................................................................... - 17 -
6.2. CENTROS DE DADOS E RECUPERAÇÃO DE DESASTRES ................................................................. - 19 -
6.3. SWITCHS, ROUTERS, E FIREWALLS ......................................................................................... - 23 -
6.4. SISTEMAS OPERATIVOS ...................................................................................................... - 24 -
6.5. SERVIDORES WEB ............................................................................................................ - 25 -
6.6. BASES DE DADOS .............................................................................................................. - 26 -
6.7. APLICAÇÕES .................................................................................................................... - 27 -
6.8. WLAN E DISPOSITIVOS MÓVEIS........................................................................................... - 28 -
6.9. PROJECTOS ..................................................................................................................... - 31 -
7. CONCLUSÕES ....................................................................................................................... - 34 -
8. BIBLIOGRAFIA ...................................................................................................................... - 35 -

iii
 Í N D I C E DE FI GU RA S

Figura 1 - O âmbito da auditoria de SI: Níveis e Dimensões dos Controlos de SI .................... - 10 -

Figura 2- Ciclo de vida de Gestão de Risco (Davis, Schillerand, & Wheeler, 2007)................... - 15 -

Figura 3- Exemplo de uma WLAN .................................................................................................... - 29 -

iv
 Í N D I C E DE TAB E L A S

Tabela 1- O Âmbito da Auditoria de SI: Tipos de Controlos de SI ............................................. - 12 -

Tabela 2 - Actividades de Auditoria de SI previstas nos Referenciais (Silva, 2007) ................... - 14 -

Tabela 3 - Tecnologias 802.11 ............................................................................................................. - 29 -

Tabela 4 - Métodos de Autenticação .................................................................................................. - 30 -

v
 1. I N T RO DU Ç Ã O

Existe cada vez mais nos tempos que correm, a necessidade de conhecer o passado, saber o que
acontece no presente e prevenir/prever o que poderá acontecer no futuro. Para isso, é necessário
um correcto controlo dos acontecimentos, um conhecimento e gestão correctos com total
supervisionamento por parte de uma autoridade competente e dedicada ao mesmo.

Dentro da Gestão de Sistemas de Informação (GSI), existe uma área de exploração e trabalho
que envolve todas as outras, e é seu propósito gerar conformidades, pareceres e relatórios sobre o
funcionamento do Sistema de Informação (SI). É daqui que deverão sair as propostas ou os
alertas para melhorias, assim como para prevenções a levar a cabo para a preservação do Sistema
implementado.

“A evolução, complexidade e predominância dos Sistemas de Informação (SI) nas organizações

actuais fazem com que a Informação e os Sistemas que a suportam devam ser cada vez mais
controlados. “ (Silva, 2007)

Assim a Auditoria a SI, e mais concretamente a função de Auditoria que irá ser estudada,
trabalhada ao longo deste documento é realmente cada vez mais uma necessidade ao correcto
funcionamento dos departamentos de Sistemas e Tecnologias de Informação existentes nas
empresas e instituições. A Auditoria, deixa aqui de ser algo a temer, algo externo e com carácter
de perseguição e caça, mas passa a ser vista como parceira de trabalho, essencial e influenciável
no trabalho diário e melhoria deste. Os CIO, passam a ter a necessidade de criar, e gerir dentro
dos departamentos de Sistemas de Informação (SI), equipas de Auditoria SI para controlo
interno das funções a estes adjacentes.

Uma definição para Auditoria a (SI), é-nos dada por Ron Weler e citada por Oliveira no seu livro
Método de Auditoria a SI, “processo de recolha e avaliação de evidência para determinar se um
sistema computorizado salvaguarda os bens, mantém a integridade dos dados, permite atingir os
objectivos da organização de forma eficaz e utiliza os recursos de forma eficiente” (Oliveira,
2006).

Os objectivos, também segundo Oliveira, J. A. serão:

 Verificar a existência de medidas de controlo interno aplicáveis, com carácter

generalizado, a qualquer SI da instituição, ente, organismo ou qualquer outro objecto de
auditoria;
 Avaliar a adequação do SI às directrizes básicas de uma boa gestão informática;
 Oferecer uma descrição do SI com base nas suas especificações funcionais e nos
resultados que proporciona;
 Verificar se o SI cumpre os normativos legais aplicáveis;
 Verificar se a informação proporcionada pelo SI é fiável, íntegra e precisa;
 Determinar se o SI atinge os objectivos para os quais foi desenhado, de forma eficaz e
eficiente;
 Propor as recomendações oportunas para que o SI se adapte às directrizes consideradas
como essenciais para o seu bom funcionamento.

(Oliveira, 2006)

Hoje em dia, e derivado à enorme evolução das TIC, e complexidade dos sistemas, torna-se
quase impossível pensar na existência de Departamentos de Informática sem a implementação de
uma FrameWork testada e de comprovada eficácia, existem para isso algumas, sendo as mais
usadas o ITIL IT Infrastructure Library o COBIT Control Objectives for Information and related Technology
e o ISO 17799 Information Technology - Code of Practice for Information Security Management, contando
-1-
que se pode efectuar um alinhamento entre as três de forma a obter, digamos uma nova
Framework, que seja completa pois de certa forma as três complementam-se entre si.

“…que o CobiT é o referencial mais abrangente para a Auditoria de SI, tomou-se o CobiT como
ponto de partida para a identificação das actividades de Auditoria de SI. Recorreu-se igualmente
aos referenciais ITIL e ISO 17799 para a identificação dessas actividades uma vez que estes
referenciais são mais específicos em alguns aspectos.” (Silva, 2007)

-2-
 2. C O N T E X TUA L I ZA ÇÃ O

2.1. DEFINIÇÕES

“The challenge of Information System Auditing, as it is known nowadays, is a consequence of a

most important current trend, namely the change from a industrial to a information society.”
(Piattini, 1999)

Hoje em dia é cada vez mais necessário associar sempre à GSI, a Auditoria a SI. Faz já parte das
funções principais de uma boa gestão, o controlo da mesma, a averiguação de resultados e a
garantia de qualidade.

Define-se Auditoria a Sistemas de Informação como sendo a forma que os CIO têm de garantir a
qualidade, garantir o serviço e prever as melhoras do sistema em tempo útil. Auditoria é controlo,
é o QOS na gestão de SI.

“Internal Auditing is an independent, objective assurance and consulting activity designed to add
value and improve an organization's operations. It helps an organization accomplish its objectives
by bringing a systematic, disciplined approach to evaluate and improve the effectiveness of risk
management, control, and governance processes.” (IIA, 2004)

2.2. EVOLUÇÃO HISTÓRICA

Para falarmos da evolução da Auditoria a SI, temos obrigatoriamente de falar do surgimento da

própria função de auditoria. O termo, Auditoria, remonta aos tempos medievais, esta surge em
formato público de audição das contas das fazendas privadas e feudos, esta audição é
exactamente como a palavra diz “audire” ouvir, o povo ouvia a leitura das contas.

O desenvolvimento empresarial realizado pela Revolução Industrial vai fazer com que a
actividade de auditoria seja potenciada. Até finais do século XIX, os objectivos principais da
auditoria eram a detecção de fraudes e os processos contabilísticos da empresas e instituições, a
partir dai, inícios do século XX vemos uma readaptação dos objectivos da Auditoria no aspecto
em que começa a preocupar-se com os relatos financeiros das organizações e a sua fiabilidade em
relação à posição financeira e operacional destas.

A partir de 1940 e 1950, é firmado o conceito de Auditoria Interna, passando o controlo interno
a ter um papel chave nas grandes Organizações, iniciando a evolução paralela com os objectivos
destas Organizações.

A partir de 1980, vê-se o âmbito da Auditoria alargar-se progressivamente, passando a incluir

análises às operações, recursos e controlos administrativos. É em 1990 que a Auditoria assume o
aspecto que tem actualmente, é mais abrangente e sistemática e a sua actividade baseia-se na
identificação e gestão dos riscos das Organizações.

“O desenvolvimento da Auditoria de SI está em primeiro lugar relacionado com a necessidade

de, em determinado momento, se passarem a efectuar Auditorias à própria Informação.” (Silva,
2007)

O surgimento da Auditoria a SI, terá acompanhado o desenvolvimento na própria área das

ciências da informação, das ciências económicas e Tecnologias de Informação e Comunicação
(TIC), e que se terá tido início entre 1970 e 1980. Entre 1980 e 1990 a prática de Auditorias a SI
terá sido consolidada devido à proliferação dos estudos de mercado, dos consumidores e das suas
necessidades no âmbito das ciências socioeconómicas.

Consegue-se inclusive afirmar que é partir daqui que surge o conceito de GSI, alavancado pelo
elevado valor que as Organizações atribuíam aos SI associados às áreas financeiras contabilísticas.
-3-
A crescente necessidade em valorizar os recursos de informação, faz com que a Auditoria a SI
passa-se além da identificação das fontes, dos serviços e sistemas, também o como da sua
utilização, a relação com as actividades criticas da Organização e o alinhamento com os seus
objectivos estratégicos.

“No fundo, podemos dizer que a Auditoria da Informação deixou de estar centrada em si
própria, (ou seja, estritamente na Informação), passando a estabelecer elos de ligação com as
necessidades da organização e com os Sistemas de Informação que as suportam.” (Silva, 2007)

“Information technology affected, and continues to affect, auditing. It became necessary to add
new standards, affecting the body of auditing standards. The audit process itself has become
different from traditional audits prior to 1954 (e.g., audit tools and techniques). It was possible
for an auditor to retire in the 1950s having used similar audit programs throughout one’s career.
That will never happen again! The effects of IT on auditing have culminated in a set of
knowledge, skills, and standards necessary to conduct the contemporary audit that were
nonexistent in 1954.” (Cangemi & Tommie, 2003)

Com o aumento das TIC e crescente computorização das grandes Organizações, passa a existir
uma maior dependência das capacidades técnicas de terceiros, razão pela qual o acesso à
informação estava a ficar longe dos Auditores. É aqui, neste mesmo período 1955 a 1965 que os
Auditores começam a admitir e a escrever artigos sobre as potencialidades das tecnologias da
informação como meios a utilizar nas auditorias financeiras, levando assim em 1967 ao
desenvolvimento do primeiro software para Auditoria (GAS – Generalized Audit Software) com
a ferramenta AUDITAPE.

No que diz respeito a marcos institucionais ou metodológicos relevantes para a actividade da

Auditoria de SI, (Asthon, 2001) identifica a primeira norma (standard) geralmente aceite,
publicada nos EUA em 1983 pelo Department of Defense, vulgarmente conhecida como The Orange
Book e intitulada de “DOD STD - Trusted Computer System Evaluation Criteria (TCSEC)”. Dado que
a Segurança dos SI foi o primeiro dos domínios da Auditoria a SI a ser explorado, esta norma
tratava de medidas de salvaguarda dos computadores com vista à protecção de informação
classificada, existente em ambientes com acesso remoto e sistemas com partilha de recursos.
Outros marcos importantes são também referidos por (Cangemi & Tommie, 2003): a fundação
em 1969 nos EUA da EDPAA - Electronic Data Processing Auditors Association; a publicação em
1977, por esta Associação, da primeira edição dos Control Objectives (“compilation of guidelines,
procedures, best practices and standards for EDP Audits”); várias revisões deste documento, entre as
quais a de 1996 em que foi renomeado para CobiT - Control Objectives for Information and related
Technology; e a introdução em 1978 de um programa de certificações para Auditores de SI, iniciado
com a certificação CISA - Certified Information Systems Auditor. (Silva, 2007)

-4-
 3. C O N CE I TO S C O N TE M POR Â N EO S

3.1. CONTROLO

“Control Self-Assessment (CSA) is a leading edge process in which auditors facilitate a group of
staff members who have expertise in a specific process, with the objective of identifying
opportunities for internal control enhancement pertaining to critical operating areas designated
by management. “ (Champlain, 2003)

“One of the first lessons we learned at Gulf Canada in the 1980s speaks to this point. We decided
that the mission of an audit department was not to perform audits. Our job was to provide
assurance to management, staff, the board, and others on a wide variety of end-result business
objectives, including - but in no way limited to - compliance with policies, reliable financial
information, and economy and efficiency.” (McCuaig, 1998)

O valor em realizar uma auditoria não está na elaboração de um relatório onde se afirma que
existe controlo sobre determinada situação ou não. As Auditorias só vão agregar valor apenas
quando fornecem a garantia de que os objectivos finais da Organização serão atingidos. A
existência de controlos não deverá afectar negativamente o nível de segurança com que um
determinado objectivo será atingido, mas a existência destes, também não garante que o mesmo
seja atingido.

Os controlos servem para ter a garantia de que os processos são implementados correctamente,
vigiando os passos e assegurando o seu correcto funcionamento.

As auditorias tradicionais e o CSA diferem na medida em que na auditoria tradicional o auditor

em cada recomendação que faz, apresenta um risco de aceitação e decisão, enquanto na CSA é
um grupo de trabalho e gestão que efectua esse risco de aceitação e decisão. O trabalho do
auditor é determinar se chegou à conclusão correcta e sólida baseado em informações completas
sobre os actuais níveis de controlo e risco baseados nos critérios pré-determinados.

3.2. ENCRIPTAÇÃO E CRIPTOGRAFIA

Encriptação é um método de protecção de dados que deverá ser implementado. Se bem

implementado, um sistema de encriptação conseguirá anular a maioria das tentativas de ataques
ao SI. A encriptação pode conferir segurança a dados quer estes estejam depositados num normal
sistema de armazenamento, ou mesmo que estes estejam a circular numa qualquer via de
comunicação.

“Proper cryptographic controls can help ensure the confidentiality, integrity, authenticity, and
nonrepudiation of electronic messages transmitted or transported between or among various
computing systems. Policies, procedures, physical security over devices, logical security controls,
and cryptography all play critical roles in the overall information systems (IS) security
environment. Without effective cryptographic controls, the other IS controls are simply
supporting a weak infrastructure.” (Champlain, 2003)

“Because of the importance of cryptography in helping to secure electronic information in

virtually all computer systems, a basic understanding of this concept is essential for IS auditors to
effectively perform their jobs.” (Champlain, 2003)

A implementação de controlos criptográficos é importante na medida em que se consegue

garantir um elevado nível de confidencialidade, integridade, e autenticidade nos dados
transmitidos, ao mesmo tempo que se providencia um sistema de não repúdio dos mesmos. A
utilização conjunta de vários métodos de encriptação, hashing e assinaturas digitais tornou-se o
meio mais comum e aceitável de transmissão de informação por meios electrónicos.

-5-
A criptografia ajuda a garantir a confidencialidade da informação que é transmitida. A
confidencialidade é alcançada somente quando os destinatários das informações transmitidas
possam lê-la. A criptografia é utilizada também para proteger os dados armazenados nos diversos
dispositivos de armazenamento existentes.

O hashing ajuda a garantir a integridade da mensagem. A integridade é alcançada quando a

informação transmitida não foi alterada, ou seja não foi adicionada nem retirada informação à
informação inicialmente transmitida.

As assinaturas digitais ajudam a garantir a autenticidade de transmissões electrónicas e ajudam a

garantir o não repúdio por parte dos emissores. A autenticidade é alcançada quando o
destinatário da mensagem pode estar razoavelmente certo que a mensagem foi enviada pela
entidade, que diz ser a emissora e não por alguma outra entidade desconhecida. O não repúdio é
alcançado quando o remetente de uma mensagem não pode refutar o facto de a ter enviado.

3.3. FORENSE COMPUTACIONAL

A forense computacional é a identificação, preservação, colecta, interpretação e documentação de

evidências digitais.

“Forense Computacional pode ser definida como a inspeção científica e sistemática em

ambientes computacionais, com a finalidade de angariar evidências derivadas de fontes digitais
para que seja possível promover a reconstituição dos eventos encontrados (podendo assim,
determinar se o ambiente em análise foi utilizado na realização de atividades ilegais ou não
autorizadas) ” (Pereira, Fagundes, Neukamp, Ludwig, & Konrath, 2007)

Passa sempre por fazer parte de uma auditoria a ideia de inspecção forense aos computadores.
Esta ideia não está de todo errada, mas não se pode dizer que esteja correcta, pois é possível
efectivar uma auditoria ao SI sem necessariamente executar uma inspecção forense na verdadeira
ascensão do termo. Ou seja, é efectuado um controlo de inventário, de software, provavelmente
de logs, mas só irá ser efectuado uma verdadeira inspecção forense a determinado computador,
quando houver indícios da existência de fraude. Claro que também esta inspecção está sujeita a
legislação e procedimentos próprios, que importa referir não estar directamente ligados às
auditorias internas.

No obstante, pode-se também considerar ou falar em forense computacional, a análise que os

auditores poderão efectuar a determinado computador para avaliar o seu grau de segurança. Esta
análise forense só irá incidir sobre os aspectos técnicos em que a máquina trabalha, e não sobre
aspectos de documentos nela contidos.

3.4. ASPECTOS HUMANOS

“An effective internal audit function serves multiple roles within an organization. The primary
function of internal audit is to assist management of an organization in achieving strategic
business objectives within a framework of sound internal control practices. All internal auditors,
including information systems (IS) auditors, play key roles in this ongoing process. Depending on
the process or system being evaluated, internal auditors must be able to perform the role of a
consultant, mediator, negotiator, investigator, facilitator, and educator. The ability of internal
auditors to effectively fill these roles benefits management and therefore provides a valuable
resource to many organizations. On an individual basis, auditors who are flexible enough to
effectively perform multiple roles should be highly valued by their companies” (Champlan, 2003)

Consegue-se aferir daquilo que Champlain diz na sentença anterior que as Instituições/Empresas
deverão ou devem dar bastante valor aos auditores que possuem pois estes devem poder
conseguir ser consultores, mediadores, negociadores, investigadores facilitadores e formadores na
medida em que um auditor não deve só apontar o que existe, bem ou mau, deverá também dizer
o porque e o como.
-6-
Um auditor de SI, deverá ser alguém com competências de gestão e com competências técnicas,
ou então a equipa de auditoria deverá ter no seu quadro, pessoas com capacidades de gestão
assim como pessoas com capacidade técnicas na área das tecnologias da informação, forma esta
que será a mais correcta de encarar a situação, pois será inconcebível a efectuação real de uma
auditoria completa a um SI por parte de apenas um auditor.

“Managers no longer just manage. They must be "hands on" working managers and have the
knowledge to participate in their audits. Seniors must be able to handle their own audits on a
stand alone basis when required.” (Poore, 2000)

A afirmação anterior, retirada de um artigo de recolha de opiniões sobre o que procurar numa
pessoa quando se pretende recrutar um auditor, este mostra bem que um auditor deverá hoje em
dia ser auto-proeficiente, deverá ser um bom comunicador e saber trabalhar em equipa, alguém
que não só gere mas também “põe a mão na massa”, não só trabalha mas também sabe por a
trabalhar.

Outra parte importante que um auditor deverá possuir como capacidade, ou conhecimentos, é o
conhecimento das operações da Instituição/Empresa que audita. Hoje em dia estar dentro das
diversas áreas e conhecer como funcionam vai ajudar a uma melhor auditoria ao SI. A área onde
os SI se implementam é tão vasta, que é necessário o conhecimento também este vasto de
competências além das TI, é preciso conhecer onde estas se aplicam.

-7-
 4. A FU N ÇÃ O AU D I TOR I A

4.1. O QUE PROCURAR NUMA AUDITORIA

A função de auditoria, serve então para ajudar na gestão do SI, e dever-se-á procurar assim tudo
o que a esta diga respeito.

Assim, para saber o que se deve procurar numa auditoria ao SI, devem-se identificar quais as
principais competências na Gestão de Informação dentro de uma organização.

Pode-se então iniciar a tarefa identificando as três grandes áreas ou meios. Assim teremos em
qualquer SI meios humanos, meios físicos e meios aplicacionais.

Dentro dos meios humanos, e aqui meios humanos são os utilizadores do sistema, a auditoria irá
procurar os riscos que estes representam para a organização, assim como quais os controlos
implementados para os gerir. Ter-se-á por exemplo aqui a implementação de normas de conduta
na utilização dos meios, normas estas que devem estar devidamente divulgadas pelos utilizadores
que deverão ser conhecedores de como utilizar correctamente o sistema, de como não o devem
fazer, e quais as implicações do uso incorrecto ou indevido do mesmo.

“Para garantir a segurança da informação de qualquer empresa é necessário que haja Normas e
Procedimentos claros, que deverão ser seguidos por todos os usuários da empresa. A maior
dificuldade das grandes empresas é garantir que todos os usuários conheçam e sigam as normas e
procedimentos da mesma e entendam a sua importância.” (Araujo, 2005)

Em relação aos meios físicos, deverá também aqui a auditoria estar atenta a uma panóplia de
condições. Por exemplo, deverá ser observado as condições físicas em que se encontram os
sistemas críticos (servidores, routers, switch…), ambiente envolvente, segurança no acesso físico
aos mesmos. Também em relação aos meios físicos será importante observar a condição de
conservação, actualizações, manutenção… enfim o estado de conservação dos equipamentos.
Também deverá ser sujeito a auditoria a rede existente e o seu estado físico, cablagens e restantes
equipamentos activos.

Nos meios aplicacionais, a auditoria deverá expandir-se na identificação das aplicações existentes
e a sua utilização, legalidade dos meios usados e necessidades por parte dos utilizadores. Também
em relação a meios aplicacionais, uma parte importante é a dos Sistemas Operativos, quais e
como são usados, sistemas de protecção de anti-vírus, firewall, motores de bases de dados,
controladores de domínios…

A auditoria deverá procurar encontrar problemas e dar soluções para os mesmos, ou então
simplesmente comprovar que o sistema se encontra em perfeito estado e após auditado deverá
manter o rumo. Uma Auditoria a um SI, não serve para fazer policiamento, deverá servir para
saber se o sistema de policiamento está implementado e a funcionar. Deverá comprovar que os
objectivos para os quais o sistema foi criado estão a ser conseguidos e da melhor forma, assim
como identificar os objectivos da organização com os objectivos do SI, e comprovar se estes
estão em concordância.

“O verdadeiro contributo da função surge quando os problemas são resolvidos, sendo o relatório
de Auditoria apenas um meio para atingir um fim que é a melhoria do estado dos controlos dos
SI da organização. Na sua relação directa e privilegiada com aqueles órgãos de governo da
organização, a Auditoria tem a oportunidade de apresentar relatórios que dão o devido ênfase aos
problemas graves, conquistando assim a atenção dos responsáveis e facilitando a obtenção dos
recursos necessários para a sua resolução.” (Silva, 2007)

-8-
Assim deve-se procurar com a auditoria ao SI, poder influenciar de forma positiva a gestão de
uma organização para a melhoria do seu sistema de informação e dos controlos a este afectos.

“In summary, the internal audit department's mission is twofold:

 To provide independent assurance to the audit committee (and senior management) that
internal controls are in place at the company and are functioning effectively.

 To improve the state of internal controls at the company by promoting internal controls
and by helping the company to identify control weaknesses and develop cost-effective
solutions for addressing those weaknesses.” (Davis, Schillerand, & Wheeler, 2007)

4.2. A ORGANIZAÇÃO A GESTÃO DE SI E A AUDITORIA DE SI

“Independence is one of the cornerstone principles of an audit department. It is also one of the
biggest excuses used by audit departments to avoid adding value.” (Davis, Schillerand, &
Wheeler, 2007)

Existe ou poderá ser pensado por muitos a discussão da independência ou imparcialidade da

parte da Auditoria a SI quando esta função é feita internamente na Organização. Mas, é aqui que
as ideias expostas no ponto anterior “O que Procurar numa Auditoria” vão fazer a diferença na
interpretação e implementação da função de auditoria interna ao SI como parte da gestão do
Sistema de Informação numa Organização.

A missão de auditoria ao SI é deveras providenciar à Gestão de Topo da Organização e aos

comités de auditoria uma garantia independente de que os controlos de SI estão implementados e
que funcionam eficazmente, mas também contribuir para a melhoria do estado dos controlos de
SI através da promoção destes ao ajudar a organização a identificar vulnerabilidades nos
controlos e sobre tudo no desenvolvimento de soluções eficientes para gerir essas
vulnerabilidades.

Assim, deixa-se de encarar a auditoria como algo mau, e que procura erros e culpados destes para
poder incriminar, e passa a fazer sentido e a ter interesse implementar a função de auditoria
dentro da própria organização, não para policiamento mas para controlo e melhoria do sistema.
Esta poderá estar implementada num departamento de auditoria, ou no caso específico da
auditoria a SI, poderá estar implementada dentro do departamento de Sistemas de Informação.

A Organização deverá poder beneficiar através da identificação e avaliação por parte da função
de auditoria ao SI, de exposições ao risco que sejam significativas, bem como na melhoria de
mecanismos de controlo.

Pedro Silva na sua tese de mestrado em Tecnologias e Sistemas de Informação (Silva, 2007) fala
em níveis, dimensões e tipos de controlo sujeitos à auditoria de SI. Vendo esses controlos dentro
da perspectiva do autor será mais fácil identificar o âmbito da auditoria de SI.

-9-
 Figura 1 - O âmbito da auditoria de SI: Níveis e Dimensões dos Controlos de SI

De seguida ir-se-á mostrar a tabela que Pedro Silva criou para os tipos de controlos de SI baseada
no conceito da imagem anterior que o mesmo adaptou de uma versão original. (IIA, 2005)

Controlos de Governo Ao nível do Governo das Sociedades, os controlos de SI

pretendem garantir que uma eficaz Gestão da Informação e dos
SI é enquadrada e suportada por adequadas Políticas, devendo
estas estar relacionadas com os objectivos e as estratégias da
organização. Não cabe à gestão de topo da organização efectuar
a Gestão da Informação e dos SI, nem executar Auditorias aos
seus controlos, mas sim supervisionar e criar condições para que
sejam executadas.
- Políticas  Dado que os SI são vitais para a operacionalidade
de muitas organizações, deverão existir Políticas escritas
relativas a todo o âmbito dos SI, devidamente aprovadas pela
gestão de topo e divulgadas por toda a organização.
Exemplos de Políticas: níveis globais de segurança e
privacidade; classificação da Informação; distinção da
responsabilidade sobre os dados e os sistemas
(ownership); requisitos gerais para o plano de
contingência/ recuperação dos SI, etc.
Controlos de Gestão A Gestão deve garantir que os controlos de SI necessários para
atingir os objectivos da organização onde estão implementados.
A Gestão deve reconhecer os riscos da organização, os seus
processos e os activos e deve implementar diversos tipos de
mecanismos para mitigar esses riscos:
- Normas  As normas (standards) servem para suportar os
requisitos das Políticas e definem formas de operar na
organização, compatíveis com os objectivos desta. Permitem à
organização manter a totalidade do ambiente operacional dos SI
de forma mais eficiente.
Exemplos de Normas: desenvolvimento de sistemas;
configuração de software; controlo de aplicações;
estruturas de dados; documentação de SI; etc.
- Organização e Gestão  Como em qualquer outra função da
organização, o modo como se estrutura e gere a função SI é
determinante para a definição de linhas de reporte e de
responsabilização e para uma eficaz implantação dos controlos
de SI.

- 10 -
 Exemplos de controlos de Organização e Gestão:
segregação de funções; controlo financeiro; gestão da
mudança (change management); gestão de
formação; etc.
- Controlos Físicos e da Envolvente  Todos os equipamentos
de SI e as respectivas infra-estruturas físicas em que se
encontram deverão estar devidamente protegidos.
Exemplos de controlos Físicos e da Envolvente:
servidores localizados em centros de dados
(DataCenters); procedimentos de recuperação
(disaster recovery); etc.
Controlos Técnicos Os controlos Técnicos são os pilares dos restantes controlos dos
SI da organização. São mecanismos que permitem automatizar
controlos e implementar na prática algumas das Políticas para a
Informação e para os SI definidas pela gestão da organização,
através de:
- Controlos de Software  São os controlos relativos à
utilização das redes, dos sistemas e, em última instância, do
próprio software pelos utilizadores (users).
Exemplos de controlos de Software: gestão de
acessos; intrusão; encriptação; alterações; etc.
- Controlos de Desenvolvimento de Sistemas  Dizem
respeito ao desenvolvimento e aquisição de sistemas tendo por
base um método comum com controlos eficazes em cada uma
das fases desse processo.
Exemplos de controlos de Desenvolvimento de
Sistemas: documentação de requisitos de utilizadores;
formalização de desenho de arquitectura; processos
de manutenção e gestão de alterações; técnicas de
gestão de projectos; etc.
- Controlos baseados em Aplicações  São controlos internos
às próprias aplicações que garantem a integridade dos processos
de negócio que estão automatizados e que se baseiam nessas
aplicações.
Exemplos de controlos baseados em Aplicações:
controlos de entrada; controlos de processamento;
controlos de saída; histórico de transacções; etc.
Controlos Gerais Os Controlos Gerais, também designados de Controlos Infra-
estruturais, referem-se ao como é gerida a generalidade dos
sistemas, dos processos e dos dados que numa organização
fazem parte do domínio dos SI.
Exemplos de controlos Gerais: segurança da
Informação; gestão de acessos; aquisição e
desenvolvimento de sistemas; procedimentos de
backup; etc.
Controlos Aplicacionais Os Controlos Aplicacionais referem-se ao domínio de uma
aplicação ou processo de SI específico.
Exemplos de Controlos Aplicacionais: edição de
dados; balanceamento de totais; relatórios de erros;
etc.
Controlos Preventivos Os Controlos Preventivos são aplicados para prevenir a
ocorrência de erros, omissões ou incidentes de segurança.
Exemplos de controlos Preventivos: validadores de
inserção de dados; antivírus; firewalls; etc.
Controlos Detectivos Os Controlos Detectivos são aplicados para detectar erros ou
incidentes que trespassaram eventuais controlos Preventivos.
Exemplos de controlos Detectivos: identificação de
utilizadores (users) que excederam determinados
limites autorizados; identificação de padrões de dados

- 11 -
 incorrectamente manipulados; etc.
Controlos Correctivos Os Controlos Correctivos são aplicados para corrigir erros,
omissões ou incidentes quando estes são detectados.
Exemplos de controlos Correctivos: correcção de
dados incorrectamente inseridos; remoção de software
ilegal; recuperação de sistemas ou dados; etc.
Tabela 1- O Âmbito da Auditoria de SI: Tipos de Controlos de SI

Esta é uma forma de abordar a classificação dos controlos de SI, existirão outras com certeza,
mas consegue-se vislumbrar aqui a importância da auditoria a SI e como ela se integra na gestão
dos mesmos e mesmo na gestão de topo da organização.

“De acordo com a teoria de auditoria, uma organização não só precisa de um sistema de
informação, mas também de um sistema de controlo interno para assegurar a credibilidade da
informação registada e para controlo de potenciais erros. Face ao exposto podemos concluir que
uma organização, em simultâneo com os objectivos estratégicos e operacionais, precisa de
cumprir objectivos de controlo suportados por processos de controlo.” (Santos, Vasconcelos, &
Tribolet, 2004)

- 12 -
 5. R E FER E NC I A I S ME TO D O L OG I CO S

Como foi possível observar na secção anterior existem vários níveis de associação dos controlos
de SI. Sabemos que no topo devem ser definidas as políticas de gestão da Organização a partir
das quais se irão organizar os controlos/normas a nível da gestão e das questões técnicas.

Esta parte de definição de controlos/normas para os sistemas de informação é hoje em dia

facilitado pela existência internacional de standards conhecidos por frameworks.

5.1. PORQUE

As organizações têm neste momento duas hipóteses de escolha, ou continuam a efectuar a

implementação dos SI de uma forma ad-hoc, ou optam por utilizar um standard internacional.
Estes standards tendem a ser melhores e com melhores resultados pois foram/são desenvolvidos
recorrendo à experiencia acumulada ao longo dos anos por um grande conjunto de organizações
e de profissionais que apoiam as melhorias técnicas e acreditam no sucesso estando na vanguarda
dos sistemas de informação.

5.2. FRAMEWORKS (COBIT, ITIL E ISO)

“CobiT, do inglês, Control Objectives for Information and related Technology, é um guia, formulado como
framework, dirigido para a gestão de tecnologia de informação (TI). Recomendado pelo ISACA
(Information Systems Audit and Control Association), possui uma serie de recursos que podem servir
como um modelo de referência para gestão da TI, incluindo um sumário executivo, um framework,
controle de objetivos, mapas de auditoria, ferramentas para a sua implementação e
principalmente, um guia com técnicas de gerenciamento. Especialistas em gestão e institutos
independentes recomendam o uso do CobiT como meio para otimizar os investimentos de TI,
melhorando o retorno sobre o investimento (ROI) percebido, fornecendo métricas para avaliação
dos resultados (KPIs, KGIs e CSFs).

O CobiT independe das plataformas de TI adotadas nas empresas, tal como independe do tipo
de negócio e do valor e participação que a tecnologia da informação tem na cadeia produtiva da
empresa.;” (Wikipedia, 2008)

“ISO/IEC 27001 é um padrão para sistema de gerência da segurança da informação (ISMS -

Information Security Management System) publicado em Outubro de 2005 pelo International Organization
for Standardization e pelo International Electrotechnical Commision. Seu nome completo é ISO/IEC
27001:2005 - Tecnologia da informação - técnicas de segurança - sistemas de gerência da
segurança da informação - requisitos mas conhecido como "ISO 27001".

Seu objetivo é ser usado em conjunto com ISO/IEC 17799, o código de práticas para gerência
da segurança da informação, o qual lista objetivos do controle de segurança e recomenda um
conjunto de especificações de controles de segurança. Organizações que implementam um ISMS
de acordo com as melhores práticas da ISO 17799 estão simultaneamente em acordo com os
requisitos da ISO 27001, mas uma certificação é totalmente opcional.” (Wikipédia, ISO 27001,
2008)

“Information Technology Infrastructure Library (ITIL) é uma biblioteca de boas práticas (do inglês best
practices) nos serviços de tecnologia da informação (TI), desenvolvida no final dos anos 80 pela
CCTA (Central Computer and Telecommunications Agency) e atualmente sob custódia da OGC (Office
for Government Commerce) da Inglaterra. A ITIL busca promover a gestão com foco no cliente
e na qualidade dos serviços de tecnologia da informação (TI). A ITIL endereça estruturas de
processos para a gestão de uma organização de TI apresentando um conjunto abrangente de
processos e procedimentos gerenciais, organizados em disciplinas, com os quais uma organização
pode fazer sua gestão tática e operacional em vista de alcançar o alinhamento estratégico com os
negócios.” (Wikipédia, Information Technology Infraestruture Library, 2008)
- 13 -
Das definições dadas as estas três frameworks, podemos observar que a única que faz menção à
auditoria a SI é o Cobit, não quer no entanto dizer, e de forma alguma, que para uma organização
poder ter auditoria ao SI, deverá estar implementada dentro do Cobit.

Qualquer uma das frameworks, disponibiliza ferramentas e controlos a serem auditados, facilita
assim o trabalho das equipas de auditores que têm um guia, um mapa a seguir e comprovar o
funcionamento.

Na tabela seguinte, elaborada por Pedro Silva na sua tese de mestrado em Tecnologias e Sistemas
de Informação, podemos ver todos os casos em que existe actividade de auditoria a SI que são
referidos nos referenciais.

Tabela 2 - Actividades de Auditoria de SI previstas nos Referenciais (Silva, 2007)

5.3. GESTÃO DE RISCO

“Although information technology infra-struture is an area that many consider “operations”, that
has a major impact on orgazinational risks and the control enviroment.”, “Those who understand
the interconnected world know that assessing, addressing and monitoring overall business risk
must include technologies inssues” (Parker & Grahan, 2008)

Depois de tudo o que já foi visto ao longo dos capítulos anteriores, podemos afirmar que
realmente o que uma auditoria ao sistema de informação deve fazer, é na realidade fazer o
controlo da gestão de risco da organização.

Tudo numa organização gira à volta do risco, nos sistemas de informação também o deve
acontecer. Na implementação de um sistema, dever-se-á avaliar todos os riscos inerentes ao
mesmo, as formas de os minimizar e como os controlar, é esta gestão do risco que deve ser
avaliada.

- 14 -
“As decisões relativas ao que é considerado materialmente relevante e ao risco de auditoria
aceitável irão influenciar a quantidade de trabalho que é necessário efectuar e, consequentemente,
a economia, eficiência e eficácia da auditoria.” (Oliveira, 2006)

Ao se efectuar uma auditoria, as bases de risco admitidas deverão ser bem ponderadas pois ao se
efectuarem avaliações de risco de forma errada, poderá comprometer o resultado da auditoria.
Ao se efectuarem ponderações de risco, devem-se ter em conta as várias vertentes, o risco em si,
e os custos a ele associados.

Oliveira (Oliveira, 2006) fala da existência de três componentes de risco:

 Risco Inerente  é a susceptibilidade dos recursos de informação ou dos recursos

controlados pelo sistema de informação serem roubados, destruídos, ignorados,
modificados sem autorização, ou sofrer outros danos, assumindo que não existem
controlos internos relacionados;
 Risco de Controlo  é o risco de que um erro materialmente relevante nos dados da
entidade não será prevenido ou detectado e corrigido atempadamente pela estrutura de
controlo interno da entidade;
 Risco de Detecção  é o risco de o auditor não detectar um erro materialmente
relevante nas declarações financeiras da entidade.

Podemos deduzir então da leitura das definições dadas por Oliveira aos tipos de risco existentes
numa auditoria, que até o próprio auditor faz parte integrante do risco. Ou seja, deverá haver
além do controlo do risco, um controlo da auditoria, esta deverá ser elaborada de forma sóbria e
profissional, quer por parte dos gestores como dos técnicos.

Figura 2- Ciclo de vida de Gestão de Risco (Davis, Schillerand, & Wheeler, 2007)

Segundo (Davis, Schillerand, & Wheeler, 2007) pode-se identificar um ciclo na gestão de risco,
este ciclo é definido nas cinco fases que se podem observar na Figura 2- Ciclo de vida de Gestão
de Risco proposto pelos próprios autores.

- 15 -
Na primeira fase que será a do levantamento e identificação dos pontos de informação activos,
ou seja identificar o valor que determinada informação tem para empresa (baixo, media ou alto)
do ponto de vista da confidencialidade, integridade e disponibilidade.

“The best way to identify information assets is to take a top-down approach beginning with
organization functions, identifying the processes that support those business functions, and
drilling down to the information assets that are processed.” (Davis, Schillerand, & Wheeler, 2007)

Numa segunda fase devem-se quantificar e qualificar ameaças, é aqui que se deve identificar os
custos associados à perca de dados e à sua recuperação assim como processos legais e normas de
acção. Não esquecer que como fazendo parte do ciclo de vida da gestão de risco, esta fase esta
intimamente ligada à anterior.

“In order to identify threats to our information effectively, we need to complete the first phase of
the risk-management process: identifying information assets. This is so because properly
identified threats are associated with an information asset or a group of information assets.
Threats associated with systems flow through to the information assets that they process.”
(Davis, Schillerand, & Wheeler, 2007)

Na terceira fase deve-se então efectuar a avaliação das vulnerabilidades.

“In examining threats, the common denominator is the information asset because each threat is
tied to an information asset. When assessing vulnerabilities, on the other hand, the common
denominator is the information process.” (Davis, Schillerand, & Wheeler, 2007)

Deve-se aqui efectuar a identificação das vulnerabilidades nos componentes que fazem parte dos
processos de informação, depois de identificadas, serão combinadas para identificar as
vulnerabilidades dos processos, depois serão as vulnerabilidades de processos combinadas para
identificar as vulnerabilidades inerentes às funções da instituição.

Numa quarta fase, iremos efectuar o controlo de reposição de falhas, ou seja implementar
controlos de forma a que os riscos identificados sejam mitigados. Importante aqui ter em atenção
que depois de se efectuar a implementação de controlos, a avaliação de risco deverá ser
novamente recalculada.

“By now our risks should be categorized as high, medium, or low. Initially, we will focus on
mitigating the most severe risks because we most likely will see the highest return on our
investment. In essence, we are likely to mitigate more risk with less money.” (Davis, Schillerand,
& Wheeler, 2007)

Por fim na quinta fase será necessário gerir o aparecimento de novos riscos, e claro está o
desaparecimento de alguns actualmente existentes.

“Risk is inherently dynamic in nature, especially the threat component of risk. As a result, we will
need to measure risk continually and invest in new controls to respond to emerging threats.”
(Davis, Schillerand, & Wheeler, 2007)

- 16 -
 6. T É C N I CA S DE AUD I TO R I A

6.1. CONTROLOS AO NÍVEL DA ENTIDADE

O objectivo destes controlos é estabelecer e promover uma atitude generalizada por parte dos
elementos da organização de forma a obter uma uniformidade de controlo interno.

Para além de identificar e avaliar os detalhes das actividades ao nível dos processos da
Organização, existem muitas mais aplicações por vezes menos tangíveis, mas que constituem
pontos importantes para a mesma.

Os controlos de identidade podem/devem estender-se a todas as áreas da Organização de forma

a obter um melhor trabalho. Um problema que o auditor encontra neste item é a definição do
que deve ou não ser considerado uma entidade, podendo variar de organização para organização.

Uma estrutura organizacional mal definida pode levar a uma indefinição das responsabilidades
e/ou das funções causando falhas em algumas actividades que poderão ser executadas
redundantemente ou suprimidas.

Para melhor definir quais os controlos de entidade a aplicar às entidades das Organização são
indicados a seguir alguns controlos que o auditor deverá ter em conta.

 Analisar a estrutura organizacional para compreender se esta fornece uma clara

distribuição de poderes e responsabilidades nas operações efectuadas. A indefinição
destas funções pode levar ao aparecimento de actividades fraudulentas.

 Analisar o planeamento de processos para ter a certeza de que estes vão ao encontro dos
objectivos da organização. Ao reavaliar estes processos o auditor está a monitorizar se
estes convergem de acordo com o plano estratégico da Organização.

 Avaliar se as tecnologias e as aplicações existentes assim como o manuseamento das

mesmas estão a evoluir de acordo com um plano estratégico de longo prazo. A área das
tecnologias de informação é uma área em rápida e constante evolução, pelo que é
necessário que as organizações tenham planos de mudança para compreender
antecipadamente as suas necessidades.

 Avaliar indicadores de performance e comparar com os Service Level Agreements (SLAs)

(em português pode traduzir-se para níveis de aceitação do serviço) existentes para cada
processo na área das TI. As TIs são a base de muitos processos existentes nas
organizações e se não existirem medidores de performance e SLAs adequados é difícil
determinar se a infra-estrutura de TI está a dar uma boa resposta às necessidades
impostas.

 Verificar os processos existentes de forma a estabelecer necessidades e prioridades para

novos projectos. Esta verificação atribuição de prioridades deve ser feita de uma forma
estruturada para que os recursos sejam disponibilizados de forma eficiente satisfazendo
as necessidades e objectivos estabelecidos.

 Avaliar normas de decisão da execução de projectos na área das TIs garantido a boa
qualidade dos produtos adquiridos pela organização.

 Garantir que as políticas de seguranças existentes são eficazes e aplicadas correctamente,

para isso é importante definir mecanismos que garantam o conhecimento e o
cumprimento das mesmas dentro da organização.

- 17 -
 Analisar processos de avaliação de riscos inerentes às TIs. Sem esta avaliação a
Organização desconhece os riscos que corre para atingir os seus objectivos. A tomada de
consciência destes riscos deverá influenciar a tomada de decisões para atenuar esses
mesmos riscos.

 Avaliar processos para se assegurar que os colaboradores da Organização têm as

competências e o conhecimento necessários à execução das suas funções. Colaboradores
indevidamente preparados e qualificados vão ter uma influência negativa sobre o
desempenho das TIs na Organização.

 Analisar políticas e processos de atribuição responsabilidades sobre os dados da empresa

com que cada colaborador vai lidar. A classificação correcta dos dados, a sua protecção
de acordo a importância e ainda a definição do seu ciclo de vida, leva a uma
racionalização dos custos necessários à manutenção e à prevenção de extravio.

 Assegurar que existem processos eficazes que obrigam ao cumprimento das regras
existentes para a área das TIs.

 Analisar e avaliar e criar processos que garantam que os utilizadores têm a capacidade de
reportar os problemas encontradas na execução das suas tarefas de interacção com as
TIs. Estes utilizadores devem estar em consonância com as decisões tomadas nesta área
e satisfeitos com o serviço prestado pela mesma.

 Avaliar processos de gestão de serviços prestados por outras organizações na área das
TIs, garantido que as suas funções e responsabilidades estão claramente definidas.

 Analisar e avaliar acessos efectuados por organizações externas ao SI. Estes acessos estão
normalmente associados ao suporte de alguns serviços na área das TIs. Tratando-se de
entidades externas à organização estas podem não conhecer ou não compactuar com as
políticas da Organização colocando em risco o seu bom funcionamento.

 Avaliar processos que garantam que a Organização tem as licenças de software

regularizadas. A facilidade com que um colaborador pode copiar um software a partir da
internet ou de qualquer tipo de suporte de armazenamento de dados é imensa. Para
prevenir é necessário que exista uma listagem das licenças válidas na Organização e
efectuar uma procura de software não listado numa amostra de computadores
permitindo assim avaliar todo o universo da empresa. Em caso de falha os processos
devem ser novamente revistos.

 Analisar e avaliar os processos de controlo sobre os acessos remotos efectuados à

Organização. Ao disponibilizar este tipo de acessos a rede da Organização fica alarga-se
para além do perímetro normal de funcionamento. Este tipo de acessos deve ser alvo de
uma especial atenção, porque o uso indevido dos mesmos pode levar ao
comprometimento da segurança na rede.

 Assegurar que os processos de contratação e cessação de serviços são claras e estão de

acordo com o objectivo dos mesmos. A falha num destes processos pode levar a que a
Organização seja alvo de acessos indevidos e abuso de privilégios que podem
comprometer a segurança da informação.

 Avaliar as políticas de gestão que controlam as mudanças e aquisições de hardware. Esta

gestão deve monitorizar os movimentos do hardware e também prevenir a acumulação
de recursos desnecessários e alocação ou aquisição de novos onde estes são mais
necessários.

- 18 -
  Assegurar o controlo e a gestão de configurações de todos os SIs de acordo com as
mudanças efectuadas na estrutura de forma a evitar indisponibilidades.

 Garantir que os meios de transporte, armazenamento e reutilização e eliminação de

dados são efectuados de acordo com as políticas da Organização. Os dados de uma
Organização são vitais para a sua sobrevivência, a sua perda ou extravio pode ter graves
consequências.

 Verificar se os processos de monitorização e planeamento de mudanças dos processos

na área das TIs vão ao encontro das políticas e necessidades da organização.

(Champlain, 2003)

6.2. CENTROS DE DADOS E RECUPERAÇÃO DE DESASTRES

Devido à expansão das tecnologias da informação, o negócio da grande maioria das empresas
está dependente dos seus sistemas de informação, e se por algum motivo estes deixarem de
funcionar isso pode representar milhões de euros de prejuízo ou levar a empresa a deixar de
fornecer serviços, cumprir contratos, legislação e no extremo, mesmo ir á falência. Como tal, é
crucial manter os sistemas de informação (dependendo da do ponto critico) a funcionar 24 horas
por 7 dias por semana. Além de manter os serviços sempre a funcionar a segurança da
informação também é uma preocupação, e os Centros de Dados são uma boa resposta pois
garantem um ambiente seguro o que minimiza as possibilidades de surgir uma quebra de
segurança. Um Centro de Dados deve, portanto, seguir e manter altos padrões de forma para
garantir a integridade e a funcionalidade dos seus servidores e dos serviços mantidos por estes.

O objectivo de um Centro de Dados é hospedar os sistemas de informação que são críticos para
a organização. Estes sistemas são constituídos pelo hardware e software (sistema operativo e
aplicações) e estes podem ser afectados por todo o ambiente que os rodeiam (rede, edifício, etc).
As maiores ameaças que podem surgir são:

 Naturais: acontecimentos meteorológicos, inundações, sismos ou fogo;

 Causados pelo homem: tais como actos terroristas, roubo, sabotagem;

 Causadas devido ao ambiente que rodeia o Centro de Dados, tais como temperaturas
extremas ou humidade;

 Falha de utilitários como a electricidade ou telecomunicações.

Vai-se em seguida analisar as várias situações/pontos que um auditor tem que ter em conta.

A primeira coisa se um auditor deve analisar numa auditoria a um Centro de Dados é o ambiente
que o rodeia. A meta a atingir será identificar as ameaças mais críticas que poderão surgir, para o
conseguir o auditor deverá avaliar: a orientação do edifício, sinalização, vizinhança, iluminação
externa, perigos ambientais e a proximidade com serviços de emergência.

Começando pela vistoria do edifício, o auditor deverá verificar se existem limites e controlo na
proximidade de veículos e entrada de pessoas no edifício, o recinto externo deverá mesmo ter
barreiras para os veículos. As barreiras deverão também limitar os acidentes ou ataques com
carros bomba. Pensar-se-á se eventualmente este é um cenário inimaginável, o facto é que antes
do 11 de Setembro ninguém imaginaria um ataque com aviões às duas torres de escritórios.
Definir o piso onde o Centro de Dados se encontra é importante, pois se for rés-do-chão ou
pisos subterrâneo esta susceptível a inundações, se por outro lado forem pisos superiores, estes
estão mais vulneráveis a trovoadas, vento, chuva torrencial e a outros danos.

- 19 -
A sinalização não deverá existir, pois os Centros de Dados devem ser anónimos, longe das vias
de comunicação principais e sem serem (ou evitarem ser) vistosos, i.e., passarem despercebidos.

Vizinhança, aqui a questão é, que entidades estão localizadas na zona do edifício. Estão perto do
edifício? A que tipo de serviços/produtos estão associados? O facto de estar perto de uma
fábrica ou armazém, por exemplo, pode aumentar o risco do Centro de Dados ser afecto por
fugas de materiais venenosos ou incêndios. O ideal seria um edifício só para esse efeito e isolado.

Outra situação a analisar é a iluminação exterior. Uma iluminação adequada pode evitar crimes e
mesmo que as pessoas vagueiem por ali. Edifícios críticos devem ter muros/vedações e o seu
perímetro ser bem iluminado e com uma boa intensidade de modo a permitir ver bem a uma
distância razoável.

O edifício deve estar preparado para lidar com inundações, mais uma vez evitar áreas de risco
além de evitar que o piso de entrada no edifício esteja ao nível do solo. Deve igualmente evitar
colocar um Centro de Dados em áreas com elevado risco de sismos ou de tempo inconstante,
que permita tempestades e furacões. Aconselhável como há se referiu é localizar o Centro de
Dados numa área que seja possível um rápido socorro pelos serviços de emergência.

Existem muitos acessos a informação crítica e acidentes no Centro de Dados devido a um

deficiente controlo ao acesso ao mesmo. Logo a forma como é feito o controlo e identificação
das pessoas que acedem ao Centro de Dados é fundamental. Podemos identificar os seguintes
mecanismos de controlo de acesso: portas e paredes exteriores; procedimento de acesso;
mecanismos de autenticação física; seguranças e outros usados para protecção de zonas
específicas e sensíveis.

A primeira linha de defesa são as paredes e portas usadas na construção do edifício, logo os
auditores têm que analisar de forma aprofundada se estas protegem contra intrusão. As paredes
devem ser feitas de cimento e reforçadas com aço. O auditor deve ter especial atenção ás
condutas de ar condicionado e de cablagens e verificar se estão devidamente protegidas contra
tentativas de acesso ao Centro de Dados.

Devem ser usadas armadilhas do tipo corredores, onde há uma porta de entrada onde se deve
autenticar, quando entra a porta fecha-se. Apresenta-se então outra porta, onde a pessoa terá de
autenticar-se novamente, se não conseguir fica presa no corredor.

Para autenticação da pessoa devem-se usar tecnologias como cartões magnéticos, biometria,
leitores de impressões digitais, leitura da íris, cartões de proximidade (usando a raio frequência
para autenticação) etc. O auditor deve validar os registos dessas entradas, que além da
identificação das pessoas que entraram, deve verificar horas de entrada, sítio onde entrou e se
houve falhas na autenticação.

Como já se referiu o auditor deve dar atenção espacial a sítios onde a segurança é mais sensível
ou frágil, tais como geradores, e apontar formas de melhorar essas situações.

Como é sabido, os computadores e material informático requerem condições ambientais

específicas para o seu funcionamento, como a temperatura e humidade. O auditor deve verificar
o aquecimento, ventilação e o ar condicionado e garantir que se conseguem manter temperaturas
constantes. Há que ter em atenção a humidade, se for alta pode corroer os aparelhos, por outro
lado se for baixa pode causar o aparecimento de electricidade estática.

A temperatura idealmente deve estar entre os 18ºC e os 21ºC, a partir de 30ºC a temperatura
poderá danificar os equipamentos. Por sua vez a humidade deverá andar entre os 45 e os 55 por
cento.

- 20 -
Deverá analisar também se existe protecção electrónica dos equipamentos que impeçam a
ocorrência de interferências magnéticas/eléctricas.

Os sistemas informáticos necessitam de alimentação eléctrica contínua e limpa (sem picos de

tensão). Os Centros de Dados usam diferentes tipos de controlos para garantir esse tipo de
alimentação eléctrica:

 Fontes de alimentação redundantes alimentadas partir de duas ou mais centrais eléctricas;

 Ligação à terra para enviar excessos de corrente;

 Transformadores para controlar picos de tensões eléctricas;

 UPS para garantir corrente por períodos curtos

 Geradores para produzirem energia eléctrica na existência de falhas mais prolongadas.

O auditor dever verificar se os controlos para a manutenção da corrente eléctrica são os

recomendados e estão a funcionar.

Os Centros de Dados devem estar equipados com diversos tipos de alarme que permitam
monitorizar e evitar o acesso aos sistemas, fogo, água, temperatura e humidade.

Provavelmente o alarme mais importante será o que impede o acesso físico ao Centro de Dados,
para isso podemos ter sensores em sítios estratégicos e nas portar e entradas. Poderemos ter
também detectores de movimento, sensores por contacto, por exemplo nas portar e janelas, e
áudio sensores que detectam quebra de vidros, por exemplo, e outras alterações ao nível do
ambiente sonoro normal.

Quanto aos sensores de incêndio o auditor poderá ter que analisar:

 Sensores de calor – que são activados quando se atinge determinada temperatura;

 Sensores de fumo – activados assim que seja detectado fumo;

 Sensores de chamas – activados quando acusam energia de infravermelhos ou a vacilação

de uma chama.

Os sensores de calor e fumo são os mais comuns. Quando o auditor proceder à auditoria dos
sensores deve verificar o tipo usado, a sua colocação, a manutenção dos registos e os
procedimentos de testes.

Devem ser colocados em sítios estratégicos e lógicos, sensores de água para assim tentar evitar
inundações. Neste caso o auditor deverá detectar e se necessário indicar sítios onde estes
sensores devem ser colocados.

Também no que diz respeito á humidade, esta também deverá ser verificada através de sensores.
Os sensores de humidade devem ser configurados de modo que enviem alertas para as pessoas
que estarão de prevenção. Mais uma vez, cabe ao auditor verificar que estes alarmes estão
colocados no sítio correcto.

Devido ao grande rico de incêndios num Centro de Dados ser grande, este deverá possuir um
sofisticado sistema de prevenção contra incêndios, baseado logo na construção do edifício, na
existência de extintores nos pontos-chave, e lidar eficazmente com materiais perigosos.

- 21 -
O auditor nesta situação deve verificar as portas e paredes (não devem deixar passar o fogo para
outras divisões), verificar a localização e a validade dos extintores. Se necessário poderá mesmo
efectuar testes.

A maior parte dos Centros de Dados possuem vigilância de vídeo, mas poderão ter também
vigilância áudio ou uma combinação dos dois. O auditor aqui tem que validar a qualidade do
vídeo/som, a posição da câmara e o arquivo do vídeo/som.

Tarefas a executar no Centro de Dados devem ter procedimentos, políticas e planos bem
definidos e cumpridos. Deve estar documentado quem tem acesso, ao que tema acesso e
procedimentos de segurança e de emergência a seguir. As áreas que deverão ter processos bem
definidos são: o acesso físico, a monitorização do edifício, funções e responsabilidade do pessoal,
os deveres de cada pessoa, a forma de responder a desastres e emergências, a manutenção do
edifício e do equipamento, planeamento da capacidade do Centro de Dados e a
coordenação/gestão do Centro de Dados. O auditor deverá verificar todos estes procedimentos e
verificar na prática, por exemplo através de registos, que estes estão a ser cumpridos.

Qualquer Centro de Dados por muito que cumpra todas as regras e procedimentos, esta sempre
sujeito a desastres naturais ou humanos. Antes desta secção foi analisada a forma de prevenir
desastres, mas se estes acontecem como proceder? Analisasse em seguida as formas de
recuperação de desastres, sistemas com redundância, cópia e restauro de dados (backup e restore),
plano de recuperação de desastres.

Os Centros de Dados devem possuir sistemas redundantes, de forma a recuperar rapidamente de

problemas e de disponibilizar alta disponibilidade. Exemplos de redundância são os sistemas de
discos em RAID e mais do que uma fonte de alimentação. O auditor deverá validar que os
componentes críticos do sistema possuem redundância. Em situações em que os sistemas são
muito críticos, onde não é permitido nenhum tempo de espera para recuperação de avarias, deve-
se ter redundância dos sistemas em localizações diferentes.

A cópia de dados dever ser realizada regularmente, e deve ser validada, para assegurar que não
houve falhas na cópia. Devido a serem tarefas críticas, elas devem ter associado um
procedimento que deverá ser sempre metodicamente seguido. O auditor deve começar por
validar os referidos procedimentos (de cópia e restauro de dados), depois deverá verificar que a
periodicidade de execução da cópia de segurança é a ideal para determinado sistema (sistemas
críticos devem ter uma periodicidade menor). Deverá ser validada o tempo de armazenagem das
cópias. O auditor poderá mesmo solicitar que se efectue um teste de recuperação de dados,
validar a qualidade da cópia e validar o procedimento na prática.

O objectivo do plano de recuperação de desastres é de uma forma eficiente e rápida conseguir

repor os sistemas depois de desastres como furacões ou cheias por exemplo. Para o auditor a
tarefa de auditar um plano de recuperação de desastres é muito complexa, mas poderá seguir o
seguinte: a) assegurar que o plano existe; b) verificar que o plano cobre todos os sistemas e áreas;
c) verificar se na última ameaça o plano correspondeu ao pretendido e assim validar se continua
relevante; d) assegurar que as responsabilidades e funções descritas no plano então bem
definidas; e) verificar se os procedimentos de reconstituição e recuperação são abordados; f)
assegurar que as operações de emergência têm o material necessário (computadores, rede, etc.)
para serem executadas, g) verificar que as comunicações de emergência estão garantidas; h)
verificar os resultados do último exercício de recuperação de desastres.

Deve ser assegurado que os planos são sempre actualizados e mantêm-se válidos, efectuando
testes regularmente.

- 22 -
 6.3. SWITCHS, ROUTERS, E FIREWALLS

Para auditar equipamentos de rede o auditor não precisa de ser um especialista mas tem de ter
alguma base teórica em relação ao seu funcionamento. O modelo de camadas OSI (Open System
Interconnection) da ISO (International Standard Organization) pode ajudar a compreender
melhor como funciona uma rede de computadores e como é que estes comunicam entre si.

Os switchs actuam normalmente não camada 2 do modelo OSI (ligação) e a sua função básica é a
de comutação das tramas que lhe chegam através da rede e a segmentação da mesma. Nos
switchs mais modernos já podemos fazer uma segmentação virtual da rede ou criar VLANs
(Virtual Local Area Networks) em que um único switch pode comportar vários domínios de
difusão de tramas de broadcast. Se a comunicação entre as mesmas for possível ainda com o
mesmo switch então este switch passa a actuar também na camada 3 (rede) que é onde actuam
nativamente os routers.

Os routers por sua vez actuam sobretudo na camada 3 e têm como função o encaminhamento de
pacotes entre redes distintas ou domínios diferentes. Para melhor desempenhar estas funções os
routers utilizam tabelas de encaminhamento (dinâmicas nalguns casos) de pacotes, e usam
protocolos como o OSP (Open Shortest Path First) ou o BGP (Border Gateway Protocol) para
as manter actualizadas.

As firewalls servem essencialmente para estabelecer políticas de segurança distintas para cada
segmento de rede, delimitando zonas em que o nível de segurança é semelhante. Para garantir
segurança uma firewall necessita de filtrar o tráfego que lhe chega e através de ACLs (Access
Control Lists)

Dada esta pequena introdução teórica vamos passar a enumerar algumas tarefas gerais que o
auditor deverá ter em conta neste capítulo.

 Avaliar os controlos sobre o desenvolvimento e manutenção das configurações dos

equipamentos.

 Assegurar o controlo de vulnerabilidades associadas com as versões de software. Estes

controlos podem incluir actualizações de software, mudanças de configuração, ou outros
processos que se julguem pertinentes de ser monitorizado.

 Verificar se todos os serviços desnecessários estão realmente inabilitados.

 Assegurar que uma boa gestão via SNMP (Simple Network Management Protocol).

 Avaliar processos de criação e eliminação de utilizadores, e assegurar que essa

criação/eliminação só é feita quando é realmente necessário.

 Garantir processo de validação e controlo de passwords.

 Verificar se a gestão da segurança é a mais correcta e eficaz.

 Garantir que existe salvaguarda dos ficheiros de configuração.

 Verificar se os logs estão feitos e activos na rede. Os logs devem depois ser centralizados
de forma a obter uma maior uniformidade.

 Avaliar o uso de NTP (Network Time Protocol)

 Verificar o uso e funcionamento de do protocolo NTP (Network time protocol).

- 23 -
  Verificar se as ACLs estão a funcionar de acordo com o esperado.

 Verificar se todos os equipamentos de rede estão localizados em áreas de segurança

apropriadas.

 Garantir normas de convenção de nomes a usar para todos os dispositivos na rede.

 Verificar as normas anteriores e documentar processos existentes para expandir a rede.

(Champlain, 2003)

6.4. SISTEMAS OPERATIVOS

Os sistemas operativos (SO) fazem a interacção entre todas as aplicações da Organização e os

respectivos hardwares onde estão instalados e como tal deve-se garantir o seu bom
funcionamento.

Para assegurar um bom desempenho dos SO estes têm de estar actualizados e correctamente
configurados para o fim a que se destinam.

De seguida são enumerados os controlos gerais que auditor deve ter em conta neste capítulo.

 Obter as configurações do sistema e quais as actualizações que estão instaladas e verificar

se estas se encontram de acordo com as normas e políticas estabelecidas para que o SO
seja mais seguro, fácil de gerir e de auditar.

 Determinar se o SO tem instalado configurado e actualizado um software de firewall e

aprovado pelas políticas da Organização e do fornecedor do SO.

 Determinar se o SO tem instalado configurado e actualizado um software de antivírus e

aprovado pelas políticas da Organização e do fornecedor do SO.

 Garantir que todas as actualizações previamente aprovadas estão instaladas.

 Determinar se o SO está a executar um gestor de actualizações acreditado pela

Organização.

 Analisar todo a informação relativa ao processo de iniciação do SO para verificar se algo

se há comportamentos incorrectos em alguma fase.

 Determinar quais os serviços que estão activos no sistema e validar a sua pertinência
junto do administrador do sistema. Nos serviços necessários terão de ser analisados os
procedimentos de avaliação de vulnerabilidades associados a esses serviços e fazer a sua
manutenção casa seja necessário.

 Garantir que estão instaladas todas e apenas as aplicações necessárias e aprovadas pela
Organização, evitando conflitos entre aplicações e problemas de dependências.

 Analisar e avaliar procedimentos de criação de utilizadores assegurar que esses

utilizadores apenas são criados quando há uma razão legítima para tal. Devem ser
revistos também os processos que garantem que os utilizadores são removidos logo que
não haja necessidade de existirem.

 Analisar e avaliar o uso de grupos de utilizadores e ainda determinar as permissões que

esse grupo necessita.
- 24 -
  Analisar e avaliar a resistência das passwords existentes.

 Avaliar e estabelecer políticas que previnam o uso de passwords frágeis a ataques.

Características como o tempo de validade, o número de caracteres, complexidade e
passwords não baseadas num histórico recente de uso das mesmas.

 Analisar e avaliar o uso e as necessidades de acesso remoto como o RAS (Remote Access
Service), FTP (File Transfer Protocol), SSH (Secure Shell), VPN (Virtual Private
Network) e outros.

 Garantir que o SO tem configurado políticas que permitam que o mesmo seja auditado
de acordo com o que é definido pela Organização.

 Analisar e avaliar os procedimentos de administração do SO para que este seja

monitorizado adequadamente.

(Champlain, 2003)

6.5. SERVIDORES WEB

No que diz respeito a Servidores Web, estes são normalmente diferentes uns dos outros, embora
haja semelhanças que um auditor deverá cuidadosamente verificar, segundo algumas normas.
Seguidamente são apresentados alguns passos que um auditor (após analisar a sua situação em
concreto) poderá ou não seguir, dependendo do caso com que se depara:

 Verificar se o servidor web está a executar num sistema dedicado e não em conjunto
com outras aplicações críticas

 Verificar se o servidor Web está totalmente corrigido e actualizado com as últimas

actualizações aprovadas.

 Determinar se o servidor Web deve estar a executar ferramentas adicionais para auxiliar
na protecção do servidor Web.

 Verificar se serviços ou módulos desnecessários estão desactivados. Ao executar serviços

e módulos, devem operar sob as contas menos privilegiadas.

 Verificar se apenas portas e protocolos adequados, estão autorizados a aceder ao

servidor Web.

 Verificar se as contas que têm acesso ao servidor Web são geridas de forma adequada, e
estão fortemente protegidas com palavras-chave.

 Assegurar que existam controlos adequados para arquivos, directórios e directórios

virtuais.

 Assegurar que o servidor Web tem o próprio “logging” activo e seguro.

 Assegurar que as extensões de script são mapeadas adequadamente.

 Verificar se os filtros ISAPI desnecessários ou não utilizados, são removidos do servidor.

 Verificar a validade e o uso de todos os certificados de servidor em utilização.

- 25 -
Após a execução dos passos referidos anteriormente, e dependendo da situação que se esteja a
enfrentar, o auditor poderá aplicar estes testes nos componentes de um servidor Web, podendo
consequentemente obter resultados positivos. É essencial numa auditoria de servidores Web,
compreender como organizar a tarefa e, em seguida, especificar correctamente o alcance de
trabalho que se pretende atingir. É de realçar que os auditores, tanto como seria desejado
acreditar, não são uma ciência exacta, mas quando se trata de uma auditoria a servidores Web,
associa-se uma área em que isto é aparente.

6.6. BASES DE DADOS

As bases de dados são normalmente uma área negligenciada das auditorias. Normalmente, uma
auditoria inclui uma revisão bastante profunda de várias áreas, incluindo o seu perímetro, o
sistema operativo, as políticas, entre outras… A falta de conhecimento sobre auditorias de bases
de dados torna conveniente negligenciar esta área.

As bases de dados enquadram-se numa área bastante complexa, exigindo paciência e know-how
técnico para realizar uma auditoria adequada e segura. Presumindo que o auditor tem
conhecimentos na área de bases de dados, será necessário um plano para a realização de uma
auditoria, onde muitos dos passos são idênticos aos passos que se iriam realizar sobre um sistema
operativo ou uma rede informática. Contudo, há uma necessidade de colocar esses passos no
contexto da base de dados, visto que alguns destes são exclusivos para a base de dados. Segue-se
uma lista de alguns passos importantes na auditoria de uma base de dados:

 Verificar se as permissões da base de dados são concedidas adequadamente para o nível

exigido de autorização;

 Rever as permissões da base de dados concedidas para indivíduos, em vez de grupos;

 Assegurar que as permissões da base de dados não são concedidas implicitamente de

uma forma incorrecta;

 Analisar a execução de SQL dinâmico em “stored procedures” (procedimentos

armazenados);

 Assegurar que os níveis de acesso aos dados das tabelas estão implementados
correctamente;

 Revogar as permissões públicas onde estas não são necessárias;

 Restringir o acesso ao sistema operativo;

 Restringir as permissões no directório na qual a base de dados está instalada;

 Restringir as permissões nas chaves de registo usadas pela base de dados;

 Verificar os nomes de utilizador e palavras-passe atribuídas por defeito;

 Verificar palavras-passe fáceis de adivinhar;

 Verificar se a capacidade de gestão de palavras-passe está activada;

 Verificar se a auditoria está habilitada;

 Verificar se a encriptação da rede está implementada;

- 26 -
  Verificar se a encriptação dos “dados-fronteira” está implementado no local apropriado.
Assegurar que a gestão de encriptação de chaves é parte do plano de recuperação de
desastre (“disaster-recovery”);

 Verificar se as últimas actualizações para a base de dados estão devidamente instaladas;

 Verificar se a base de dados está a executar uma versão segura como suporte;

 Verificar se as políticas e procedimentos estão no lugar, de modo a identificar quando

um “patch” (actualização) está disponível e para aplicar esse patch;

 Verificar a integridade da base de dados, analisando os kits de raiz, vírus, “backdoors” e

“trojans”.

Seguindo os pontos referidos, há uma enorme segurança na base de dados auditada. Muitas das
soluções de sistemas de bases de dados não se preocupam com a segurança do lado de dentro do
firewall, definindo apenas políticas de segurança no router, servidor web, etc. Esta
despreocupação com a segurança interna é normalmente uma das principais causas de fracasso
nas organizações, pois grande parte das invasões ao sistema é interna.

(Champlain, 2003)

6.7. APLICAÇÕES

A auditoria de aplicações informáticas, é um procedimento em que o auditor se pode certificar da

correcta utilização dos meios informáticos, através da verificação do conteúdo dos ficheiros que
integram as aplicações, a conformidade dos processamentos e dos resultados, bem como, a
adequação dos procedimentos de controlo e segurança, e da sua conformidade legal.

Como foi referido na secção anterior (bases de dados), hoje em dia, a grande ameaça a nível de
segurança nas organizações é interna, pelo que as organizações têm a necessidade de proteger,
quer os clientes, quer o seu negócio, relativamente a quebras na privacidade de dados. Mesmo
que uma organização tenha um plano para evitar que utilizadores não autorizados acedam a
dados, esta necessita de uma solução capaz de fornecer informação sobre as acções dos
utilizadores autorizados.

Para que um processo de auditoria de aplicações informáticas tenha o devido sucesso, este deverá
seguir determinadas passos, nomeadamente:

 Analisar e avaliar os controlos de dados de entrada;

 Determinar a necessidade de relatórios de erro/excepções relacionados com a

integridade dos dados e avaliar se esta necessidade está a ser preenchida;

 Analisar e avaliar os controlos sobre os “data feeds”, de e para os sistemas de interface;

 Nos casos em que os mesmos dados são mantidos em múltiplas bases de dados e/ou
sistemas, garantir que os processos periódicos de sincronização são executados para
detectar quaisquer incoerências nos dados;

 Analisar e avaliar as pistas de auditoria presentes no sistema, bem como os controlos

sobre elas;

 Assegurar que o sistema fornece um meio para detectar a transacção ou dados, do início
ao fim do processo activado pelo sistema;

- 27 -
  Assegurar que a aplicação fornece um mecanismo que efectua a autenticação dos
utilizadores, com base, no mínimo, num único identificador para cada utilizador e uma
chave confidencial;

 Analisar e avaliar o mecanismo de autorização das aplicações para assegurar que os

utilizadores não estão autorizados a aceder a qualquer transacção sensível, ou a dados,
sem primeiro serem autorizados pelo mecanismo de segurança do sistema;

 Assegurar que o mecanismo de sistemas de segurança/autorização, têm uma função

administrativa com controlos e funcionalidades apropriados;

 Determinar se o mecanismo de segurança permite eventuais processos de aprovação;

 Assegurar que um mecanismo ou processo tenha sido colocado no lugar que suspende o
acesso ao utilizador, na rescisão da empresa ou na mudança de posto de trabalho dentro
da empresa;

 Verificar se a aplicação possui controlos adequados de palavras-passe;

 Analisar e avaliar processos de concessão de acesso aos utilizadores. Assegurar que o

acesso é permitido apenas quando existe uma necessidade de negócio legítimo;

 Garantir que os utilizadores são automaticamente desconectados da aplicação, após um

certo período de inactividade;

 Avaliar o uso de técnicas de encriptação para proteger os dados da aplicação;

 Avaliar o acesso de desenvolvimento da aplicação para alterar a produção de dados;

 Garantir que o software não pode ser alterado sem passar pelo processo standard
“checkout/staging/testing/approval”, após este ser colocado em produção;

 Avaliar controlos em torno do teste do código da aplicação, antes de ele ser colocado
num ambiente de produção;

 Assegurar que há controlos de backup apropriados;

 Assegurar que há controlos de recuperação apropriados;

 Avaliar controlos em torno da retenção de dados da aplicação;

 Avaliar controlos em torno da classificação de dados, dentro da aplicação.

(Champlain, 2003)

6.8. WLAN E DISPOSITIVOS MÓVEIS

A WLAN (ou Wi-Fi) já é muito usada nas empresas, por permite a mobilidade, i.e. permite-nos
andar com o portátil de uma sala para outra sem perder ligação ao nosso email por exemplo. Põe
outro lado a WLAN colocou dificuldades aos administradores devido ao baixo custo dos pontos
de acesso e facilidade com que os utilizadores comprometem a segurança da rede. Mas
entretanto, os standards das WLAN têm evoluído assim como a formação dos administradores
para manterem a segurança da rede. Segue uma tabela com as especificações IEEE 802.11
actualmente desenvolvidas, estando na calha novas especificações como a 802l.11n.

- 28 -
 Protocolo Lançamento Frequência Largura de banda

IEEE 802.11 1997 2.4 GHz 2 Mbps

IEEE 1999 5 GHz 6, 9, 12, 18, 24, 36, 48,

802.11a 54 Mbps

IEEE 1999 2.4 GHz 5.5, 11 Mbps

802.11b

IEEE 2003 2.4 GHz 6, 9, 12, 18, 24, 36, 48,

802.11g 54 Mbps

Tabela 3 - Tecnologias 802.11

Os cliente wireless são denominados supplicants. Os pontos de acesso ligam á rede sem fios á rede
com fios, e os clientes sem fio ou supplicants ligam-se á rede sem fio através de um dispositivo
móvel. Dispositivos móveis podem ser um portátil, um telemóvel, um PDA, ou outro dispositivo
configurado para se comunicar com o ponto de acesso. O conjunto de estações comunicando
uns com os outros é o conjunto de serviços básicos (BSS).

Figura 3- Exemplo de uma WLAN

Podemos dividir a auditoria de uma WLAN em duas partes: a parte técnica e a parte operacional.

No que diz respeito á auditoria da WLAN na sua componente técnica, deve-se logo confirmar
que os pontos de acesso têm a ultima versão do software instalado. Ao auditor deve avaliar isso
com a ajuda do administrador e verificando mesmo a página do fabricante dos pontos de acesso.
Depois verificar se existem ferramentas para gerir de forma centralizada a WLAN. Validar com o
administrador as politicas usadas na definição de palavras chave (se se usar este tipo de
autenticação), verificar a sua politica de autenticação. Do lado dos clientes móveis, verificar se
têm os sistemas básicos de protecção (no mínimo antivírus e firewall pessoal) quando se vão ligar
na WLAN.

- 29 -
Método de autenticação Descrição

EAP-TLS (Transport Layer Security) Este método requer um certificado digital do cliente e
servidor, e é baseada numa forte autenticação mútua.

EAP-TTLS (Tunneled Transport Layer Este método não usa certificados do lado do cliente, usado
Security) em estruturas como o Microsoft Active Directory, usando um
servidor TTLS á frente do servidor de RADIUS.

PEAP (Protected EAP) PEAP é parecido ao EAP-TTLS; no entanto, o PEAP é

suportado pelo Windows XP e 2000 de forma nativa.

EAP-MD5 Este método não suporta uma autenticação mútua, nem é

recomendado para nenhuma rede sem fio. Só deve ser
usado em casos de emergência, quando o resto tudo não
funciona.

LEAP (Cisco-EAP Wireless) Este método é só para implementações Cisco. Atenção que
este método deu graves problemas de segurança no
passado.

Tabela 4 - Métodos de Autenticação

Deve ser avaliado de forma correcta o método de autenticação que é usado. Verificar com o
administrador o uso de software de monitorização e de processos. O auditor deve também
verificar com o administrador se existem pontos de acesso não autorizados, através de software
de monitorização ou através dos registos de tráfego na rede: através de software de wardriving –
procura sinais de pontos de acesso não autorizados, e softwares de busca através de endereços
MAC.

Quanto á auditoria da WLAN na sua vertente operacional, devem-se verificar e analisar

problemas que acontecem do lado do cliente móvel.

Têm que se assegurar que os diversos procedimentos de segurança são seguidos:

 Todas as transmissões sem fios devem ser criptografadas para evitar escutas;

 Todos os pontos devem ter acesso firmware actualizado;

 Apenas pessoas autorizadas no grupo xyz (inserir nome) pode ter acesso directo ao
controlo administrativo dos pontos de acesso;

 Apenas pessoas autorizadas no grupo xyz (inserir nome) pode instalar pontos de acesso;

 As senhas dos pontos de acesso devem seguir as políticas de segurança da empresa;

 Os nomes dos SSID, por defeito, não são permitidos ou difundidas;

 Todos os esforços serão feitos para reduzir a propagação das ondas de rádio fora da
instalação; h) equipamentos móveis que tenham acesso á rede devem utilizar programas
antivírus e firewalls pessoais;

 Os dispositivos cliente devem usar IPSec nas VPN’s da empresa;

 Só dispositivos da empresa se podem ligar á rede móvel e só para uso laboral.

- 30 -
O auditor deve ainda avaliar processos de recuperação de desastres de modo a ser possível
restaurar o acesso sem fios em caso de acontecer um desastre.

Começando novamente por analisar a auditoria na área técnica, deve-se avaliar o gateway com
um administrador e verificar se o código em execução no gateway é a versão mais recente, e
proceder a essa validação consultando o site do fabricante. Deve-se verificar também se o
dispositivo móvel tem algumas opções de protecção e se estas estão activadas caso sejam
requisitas pela política de segurança da empresa. Determinar se a segurança dos equipamentos
móveis são efectivas: devem estar protegidos com senha e devem ficar inactivas a partir de certo
número de tentativas; os aparelhos devem poder ser bloqueados e desligados remotamente., uma
senha deve ser pedida sempre que se ligue algo ao porto USB.

Deve-se usar também um software de controlo e gestão da segurança para equipamentos móveis.

Na auditoria, parte operacional, devemos assegurar a aplicação das regras de segurança em vigor
na empresa, como: devem ser usados somente os equipamentos móveis definidos na empresa,
sincronização do aparelho e transferência de dados como nosso computador pessoal não ser
permitido, só com equipamentos aprovados. Devem ser sempre usados software de antivírus e
ferramentas de criptografia Além do já referido, recomenda-se que o equipamento, tenha o
tempo limite de 30 minutos de inactividade.

Também neste caso deverá ter-se um processo de recuperação de desastres.

(Champlain, 2003)

6.9. PROJECTOS

Uma correcta gestão de projectos numa organização é essencial para atingir os objectivos
propostos, é garantido o levantamento dos requisitos mais pertinentes, e também o seu teste e
validação. Contribui também para a gestão eficiente de recursos e para o levantamento de todos
os elementos/pessoas associadas ao projecto. Uma boa gestão de projecto não garante o sucesso
da execução do projecto, mas melhore significativamente essa probabilidade.

A autoria a projectos tem como objectivos fundamentais, assegurar:

 Todas as partes interessadas estão envolvidas no desenvolvimento de requisitos e testes

do sistema e nesta fase garantir uma comunicação eficaz entre todos os intervenientes. A
incapacidade de recolher as necessidades dos clientes e obter envolvimento do cliente,
leva ao desenvolvimento de software, sistemas e processos não se alinham com
necessidades de negócio.

 Questões, orçamentos, metas, entre outros são registados, uma linha base (baseline) é
construída e monitorizada no desenrolar do projecto. Sem estes mecanismos, mais
facilmente se cometem falhas, ultrapassar prazos e/ou o orçamento.

 Ocorrem e são programados testes efectivos, que são validados segundo o documento
de requisitos. Testes inadequados levam a sistemas instáveis de fraca qualidade, sem
corresponder as exigências dos clientes.

 Documentação apropriada é desenvolvida e mantida.

 A formação adequada é fornecida aos utilizadores finais. Formação inadequada conduz a

sistemas, processos e software que são utilizados indevidamente

Uma auditoria de projecto pode ser dividida em sete fases principais:

- 31 -
  Gestão contínua de projecto - esta fase abrange os mecanismos que devem ser utilizadas
ao longo do projecto, tais como a monitorização, os documentos relativos ao projecto, e
mudanças na gestão.

 Arranque do projecto - requisitos para a recolha e concepção inicial. Este tópico cobre o
nascimento de um projecto, quando a necessidade de que o projecto está estabelecido, as
exigências são recolhidas, bem como a concepção inicial e estudos de viabilidade são
realizados.

 Desenho detalhado e desenvolvimento do sistema – esta parte abrange a parte laboriosa

do projecto, onde o código é escrito, o produto é adquirido ou implementado, os
processos são desenvolvidos, etc.

 Testes - esta é a parte do projecto onde o sistema, o software, ou processo é testado para
garantir que ele cumpre os requisitos.

 Implementação - esta parte do projecto implica, obviamente, a execução ou a instalação

do sistema, o software, ou processo em um ambiente de produção.

 Formação - este tópico cobre as actividades de formação para utilizadores finais sobre a
utilização do sistema, o software, ou processo que tem sido desenvolvido e
implementado.

 Manutenção - Este tópico cobre actividades pós implementação.

O auditor deve avaliar cada fase do projecto se fizer sentido, depende muito de como o projecto
é gerido. É crítico que o auditor compreenda a metodologia de projecto que esta a ser usada, para
assim ajustar a sua avaliação e análise. Põe exemplo, no caso de se usar desenvolvimento
incremental, onde cada fase do projecto é executada várias vezes, o auditor poderá ter de avaliar
as fases paralelamente e provavelmente várias vezes. A formas de avaliação de um projecto em
geral são semelhantes independentemente da metodologia de projecto usada, porém a
correspondência entre determinada fase de projecto e o coordenar o timing de avaliação é mais
difícil nuns projectos do que em outros. Parte do planeamento da auditoria deverá ser entender a
metodologia de projecto usada e determinar a melhor calendarização para executar o plano de
auditoria.

Os auditores devem averiguar qual a ferramenta de gestão de projecto é usada e familiarizar-se

com ela e com a sua terminologia. Isto irá permitir que o auditor fale a mesma linguagem que as
pessoas que ele vai auditar.

O auditor deverá avaliar a documentação do projecto e verificar se a produzida é a suficiente e

que as regras de gestão de projectos da empresa estão a ser seguidas. O auditor deverá realizar
entrevistas com os elementos da equipa de projecto e averiguar os processos de actualização da
documentação e verificar evidências de que essas actualizações estão a ser realizadas. Deve
também verificar que a edição da documentação só está disponível para as pessoas que podem
proceder a essa edição, i.e. verificar a segurança de acesso aos documentos e avaliar os processos
de alteração de documentos.

Deve ser verificado se existem processos efectivos de detecção de falhas no projecto e que estas
são escaladas para o destinatário correcto e que é possível avaliar o estado das mesmas em
qualquer altura. Também terá de existir um processo de gestão de alterações ao projecto, bem
como a atribuição de prioridades.

Verificar se o plano de calendarização do projecto é suficientemente detalhado. Assegurar que

existe um acompanhamento permanente da execução do projecto, que permita detectar os custos

- 32 -
e a progressão das tarefas. O auditor deve garantir que na equipa de projecto há um
balanceamento entre pessoas da área do negócio e pessoas das tecnologias de informação.

O documento de requisitos devera ser revisto e reavaliado, para confirmar se os requisitos do

cliente estão a ser cumpridos. Em conjunto com esta tarefa o auditor poderá avaliar o processo
que estabelece a prioridade de cada um dos requisitos.

Se o projecto envolve a aquisição de produtos ou software, o auditor deverá auditar o processo

de selecção do vendedor e os contratos associados.

Verificar que todos os patrocinadores do projecto fizeram o sign-off do documento detalhado do

desenho do projecto. Revisão dos processos que asseguram o envolvimento do cliente na
prioritização das tarefas do projecto. Verificar evidências de reuniões de equipa na fase de
desenho e desenvolvimento.

Quanto aos testes o auditor deverá confirmar que os estes estão a ser realizados num ambiente de
desenvolvimento/teste e nunca no sistema de produção. Rever e avaliar o processo de realização
de testes. Assegurar-se de que o projecto tem um plano de testes adequado e que o mesmo esta a
ser seguido. O auditor deverá verificar que todos os requisitos estão mapeados, têm
correspondência no documento de casos de teste. Assegurar o envolvimento dos utilizadores na
realização dos testes e concordam que o sistema tem os requisitos mínimos para os poderem
efectuar. Estes testes devem ser acompanhados, numa fase inicial, por um elemento da área das
TI. Verificação dos testes de aceitação efectuados pelos utilizadores e que os procedimentos de
segurança foram cumpridos.

O auditor deve assegurar-se de que existe um processo que regista, avalia e escala os problemas
encontrados na fase de implementação e que são resolvidos. Verificar que existe um processo de
passagem do projecto para suporte e que existe uma equipa de suporte já definida. O auditor
deve confirmar que existe a documentação necessária para as operações do dia-a-dia, bem como
para a realização de suporte e manutenção do sistema. Avaliação dos processos de actualização
da documentação que permitam que esta sempre actualizada.

Por fim, deverá ser verificado o planeamento de formação e que este corresponde a uma
formação válida e eficaz no novo sistema para os utilizadores. Confirmar a existência de manuais
de formação e de outros documentos que permitam os utilizadores efectuar as suas tarefas diárias
e que esclareçam algumas dúvidas que porventura surjam.

(Champlain, 2003)

- 33 -
 7. C O N C LU SÕ E S

Para se poderem tirar conclusões sobre Auditoria a SI é necessário falar em primeiro da

necessidade da existência da função de Gestão de SI e aqui é nos nossos dias irrefutável a ideia da
não existência da mesma. O enquadramento dos sistemas de informação dentro das
Organizações na actualidade, e a importância para que os objectivos das mesmas sejam
alcançados, faz da boa gestão dos sistemas de informação uma necessidade de primeira ordem no
topo da gestão da própria Organização. Esta necessidade e premência em possuir uma boa gestão
dos sistemas de informação, já advém de alguns anos a esta parte e como qualquer
departamento/divisão/secção importante de uma Organização, também a Gestão de Sistemas de
Informação começou a ter necessidades de ser controlada (atenção à evolução da auditoria a SI).

“Gestão de Sistemas de Informação é a Gestão do Recurso Informação e de todos os recursos

envolvidos no planeamento, desenvolvimento, exploração e manutenção do SI” (Amaral, 1994)

Por esta afirmação de Amaral, podemos então passar à conclusão da necessidade da existência do
departamento ou função de auditoria interna. Pela definição à qual chegámos de que uma
auditoria a SI, será uma componente de controlo de risco, uma garantia de funcionalidade e de
resultados pretendidos assim como de qualidade de informação, consegue-se ver que fará
nitidamente parte da gestão de SI.

Agarrando na definição de Amaral podemos então fazer as seguintes identificações:

 Gestão do Recurso Informação: Aqui através de uma auditoria a SI conseguir-se-ão

identificar as informações pertinentes e importantes na Organização, os métodos e
riscos, assim como controla-las e tirar o máximo partido.

 Recursos de planeamento, desenvolvimento, exploração e manutenção: Neste aspecto,

depois da identificação dos pontos de informação e dos riscos, implementação de
controlo, deverá existir ou é imaginável a existência de auditoria interna, da função
constante de controlo de controlos para garantia de funcionamento, qualidade e
poupança.

Pois, conclui-se que auditoria interna a SI, foge da ideia de perseguição, e aproxima-se da ideia de
controlo e consultadoria, conseguindo garantir a manutenção da qualidade do SI, assim como a
sua constante melhoria derivado a todas as particularidades faladas ao longo deste trabalho.

“All one has to do is take the initiative and begin the fascinating and rewarding journey through
the profession of helping organizations control the risks posed by the never-ending supply of
new IS technologies being introduced in the marketplace. In fact, one of the biggest challenges IS
auditors face is keeping knowledge current with rapidly changing technology while still
monitoring the controls and security over existing technologies.” (Champlain, 2003)

- 34 -
 8. B I B L I OG R A FI A

Amaral, L. A. (1994). PRAXIS Um Referencial para o Planeamento de Sistemas de Informação. Braga:

Universidade do Minho.

Araujo, E. E. (2005). A vulnerabilidade humana na segurança da informação. Uberlandia Minas Gerais:

UniMinas.

Asthon, B. (Dezembro de 2001). A view of International IT Security Standards: The EDP Audit.
Control and Security Newsletter , p. 29:6.

Cangemi, M. P., & Tommie, S. (2003). Managing the Audit Function: A Corporate Audit Department
Procedure. Wiley, John & Sons, Incorporated.

Champlain, J. J. (2003). Auditing Information Systems. John Wiley & Sons.

Davis, C., Schillerand, K., & Wheeler, K. (2007). IT Auditing: Using Controls to Protect Information
Assets. McGraw-Hill.

IIA. (2005). Guide 1: Information Technology Controls. Obtido em 18 de Novembro de 2008, de The
Institute of Internal Auditors: http://www.theiia.org/download.cfm?file=70284

IIA. (2004). What is internal auditing? Obtido em 18 de Novembro de 2008, de The Institute of
Internal Auditores: http://www.theiia.org/theiia/about-the-profession/internal-audit-
faqs/?i=1077

McCuaig, B. (Junho de 1998). Auditing, assurance, & CSA - control self-assessment - includes related
articles on CSA approaches, assurance strategies and definition of controls. Obtido em 12 de Novembro de
2008, de Bnet Business Network:
http://findarticles.com/p/articles/mi_m4153/is_n3_v55/ai_20860224

Oliveira, J. A. (2006). Método de Auditoria a Sistemas de Informação. Porto: Porto Editora.

Parker, X. L., & Grahan, L. (2008). Information Technology Audits (2008). CCH Incorporated .

Pereira, E. D., Fagundes, L. L., Neukamp, P., Ludwig, G., & Konrath, M. (2007). Forense
Computacional: fundamentos, tecnologias e desafios atuais. Universidade do Vale do Rio dos
Sinos.

Piattini, M. (1999). Auditing Information Systems. Idea Group Publishing.

Poore, R. S. (2000). What Recruiters and Staffing Agencies Say about Trends in IS Auditing - Information
Systems Control Journal, Volume 5, 2000. Obtido em 18 de Novembro de 2008, de ISACA - Serving
IT Governance Professionals:
http://www.isaca.org/Template.cfm?Section=Journal&CONTENTID=17575&TEMPLATE=/
ContentManagement/ContentDisplay.cfm

Santos, C., Vasconcelos, A., & Tribolet, J. (Novembro de 2004). Da Framework CEO à
Auditoria de Sistemas de Informação. 5ª CAPSI . Lisboa: INESC-ID Instituto de Engenharia de
Sistemas e Computadores Investigação e Desenvolvimento em Lisboa.

Services, T. E. (nd). Training Education Services - Downloads e Simulados. Obtido em 10 de Outubro

de 2008, de Training Education Services:
http://www.trainning.com.br/download/Apostila_ITIL_Cobit.pdf

- 35 -
Silva, P. M. (2007). A Função Auditoria de Sistemas de Informação: Modelo Funcional e de Competências.
Braga: Universidade do Minho - Escola de Engenharia.

Wikipedia. (2008). Cobit. Obtido em 20 de Novembro de 2008, de Wikipédia - A enciclopédia é

livre: http://pt.wikipedia.org/wiki/Cobit

Wikipédia. (2008). Information Technology Infraestruture Library. Obtido em 20 de Novembro de

2008, de Wikipédia - A enciclopédia é livre: http://pt.wikipedia.org/wiki/ITIL

Wikipédia. (2008). ISO 27001. Obtido em 20 de Novembro de 2008, de Wikipédia - A

enciclopédia é livre: http://pt.wikipedia.org/wiki/ISO_27001

- 36 -