Estrutura Nacional de
Segurança da Informação (ENSI)
Política de Segurança da Informação
Detalhada da Entidade
Fevereiro 2005
Versão 1.0
Confidencial
Público
ENSI
Política de Segurança da Informação Detalhada da Entidade
O PRESENTE DOCUMENTO NÃO PRESTA QUALQUER GARANTIA, SEJA QUAL FOR A SUA
NATUREZA. Todo e qualquer produto e materiais aqui relacionados e revelados são exclusivamente fornecidos
nos termos e sujeitos às cláusulas e condições de uma licença ou contrato de aquisição ou locação de equipamento
devidamente celebrados. As únicas garantias prestadas pela Unisys, caso existam, referentes aos produtos descritos
no presente documento estão indicadas na licença ou no contrato supra mencionado. A Unisys não poderá aceitar
qualquer responsabilidade financeira ou outra que possa resultar do vosso uso da informação contida no presente
material em forma de documento ou software, incluindo responsabilidade por qualquer tipo de danos.
A informação aqui contida está sujeita a alteração sem prévio aviso. Podem ser emitidas revisões para avisar sobre
as referidas alterações e/ou aditamentos.
A Unisys é uma marca registada da Unisys Corporation.
Público
2
ENSI
Política de Segurança da Informação Detalhada da Entidade
ÍNDICE
1
2
3
4
5
6
7
Objectivo ...............................................................................................................7
Audiência ..............................................................................................................8
Termos e Definições .............................................................................................9
3.1
Segurança da Informação ...............................................................................9
3.2
Análise de Risco ............................................................................................9
3.3
Gestão de Risco..............................................................................................9
3.4
Princípio do Privilégio Mínimo .....................................................................9
Organização da Segurança ..................................................................................10
4.1
Infra-estrutura da Segurança da Informação ................................................10
4.1.1 Arquitectura da Segurança da Informação ...............................................10
4.1.2 Coordenação da Segurança da Informação ..............................................10
4.1.3 Responsabilidades na Segurança da Informação .....................................13
4.1.4 Autorização para Utilização de Equipamento..........................................15
4.1.5 Consultoria Especializada em Segurança da Informação ........................15
4.1.6 Cooperação Entre Entidades ....................................................................15
4.1.7 Análise Independente da Segurança da Informação ................................15
4.1.8 Custos dos Controlos da Segurança da Informação .................................16
4.2
Segurança no Acesso de Terceiros ..............................................................16
4.3
Outsourcing ..................................................................................................16
Classificação e Controlo dos Activos da Informação .........................................17
5.1
Inventário dos Activos da Informação .........................................................17
5.2
Classificação da Informação ........................................................................17
5.2.1 Orientações para a Classificação .............................................................17
5.2.2 Identificação e Tratamento da Informação ..............................................18
Segurança Pessoal ...............................................................................................19
6.1
Segurança na Definição e Recursos da Função ...........................................19
6.2
Formação dos Utilizadores ..........................................................................19
6.3
Resposta a Incidentes de Segurança e Falhas ..............................................20
Segurança Física e Ambiental .............................................................................21
7.1
Áreas Seguras...............................................................................................21
7.1.1 Perímetros da Segurança Física ...............................................................21
7.1.2 Controlos de Acesso Físico ......................................................................22
7.1.3 Protecção do Local de Trabalho e Instalações .........................................22
7.1.4 Trabalho em Áreas Seguras .....................................................................23
7.1.5 Isolamento das Áreas de Cargas e Descargas ..........................................24
7.2
Segurança do Equipamento..........................................................................24
7.2.1 Localização e Protecção de Equipamentos ..............................................24
7.2.2 Instalação Eléctrica ..................................................................................25
7.2.3 Segurança da Cablagem ...........................................................................25
7.2.4 Manutenção de Equipamentos .................................................................26
7.2.5 Segurança dos Equipamentos Fora das Instalações .................................26
7.2.6 Reutilização e Alienação Segura de Equipamento ..................................27
7.3
Controlos Gerais ..........................................................................................27
Público
3
ENSI
Política de Segurança da Informação Detalhada da Entidade
8
Gestão das Comunicações e Operações ..............................................................29
8.1
Responsabilidades e Procedimentos Operacionais ......................................29
8.1.1 Documentação dos Procedimentos Operacionais ....................................29
8.1.2 Controlo de Alterações Operacionais ......................................................29
8.1.3 Procedimentos para a Gestão de Incidentes .............................................30
8.1.4 Segregação de Funções ............................................................................30
8.1.5 Separação dos Ambientes de Desenvolvimento e de Produção...............31
8.1.6 Outsourcing ..............................................................................................31
8.2
Planeamento e Aceitação de Sistemas .........................................................32
8.2.1 Planeamento de Capacidade ....................................................................32
8.2.2 Aceitação de Sistemas..............................................................................32
8.3
Protecção Contra Software Malicioso .........................................................32
8.3.1 Controlos Contra Software Malicioso .....................................................33
8.4
Salvaguarda ..................................................................................................34
8.4.1 Cópias de Segurança ................................................................................34
8.4.2 Registos de Operação ...............................................................................34
8.4.3 Registos de Falhas....................................................................................35
8.5
Gestão de Redes ...........................................................................................35
8.6
Manuseamento e Segurança de Meios de Suporte .......................................35
8.6.1 Gestão dos Meios de Suporte Informáticos Removíveis .........................35
8.6.2 Destruição de Meios de Suporte ..............................................................36
8.6.3 Procedimentos para o Manuseamento de Informação .............................36
8.6.4 Segurança da Documentação do Sistema ................................................37
8.7
Trocas de Informação e Software ................................................................37
8.7.1 Acordos para Troca de Informação e Software .......................................37
8.7.2 Segurança dos Meios de Suporte em Trânsito .........................................38
8.7.3 Segurança do Comércio Electrónico ........................................................38
8.7.4 Segurança do Correio Electrónico ...........................................................39
8.7.5 Segurança dos Sistemas de Escritório Electrónico ..................................40
8.7.6 Sistemas Disponíveis ao Público .............................................................40
8.7.7 Outras Formas de Troca de Informação...................................................41
9
Controlo de Acessos ...........................................................................................42
9.1
Requisitos de Negócio para Controlo de Acessos .......................................42
9.2
Gestão de Acesso dos Utilizadores ..............................................................42
9.2.1 Registo de Utilizadores ............................................................................42
9.2.2 Gestão de Privilégios ...............................................................................43
9.2.3 Gestão de Senhas de Utilizador ...............................................................43
9.2.4 Revisão dos Direitos de Acesso dos Utilizadores ....................................44
9.3
Responsabilidades dos Utilizadores.............................................................44
9.3.1 Utilização de Senhas ................................................................................44
9.3.2 Protecção de Equipamento Não Vigiado .................................................44
9.4
Controlo de Acesso de Rede ........................................................................44
9.4.1 Políticas na Utilização dos Serviços de Rede ..........................................44
9.4.2 Utilização de Caminhos Predefinidos ......................................................45
9.4.3 Autenticação de Utilizadores para Ligações Externas .............................45
9.4.4 Autenticação do Nó..................................................................................46
9.4.5 Acesso Para Gestão Remota ....................................................................46
9.4.6 Segregação das Redes ..............................................................................46
9.4.7 Controlo de Acesso às Redes ...................................................................46
9.4.8 Controlo de Rotas Internas.......................................................................47
Público
4
ENSI
Política de Segurança da Informação Detalhada da Entidade
9.4.9 Segurança dos Serviços de Rede..............................................................47
9.5
Controlo de Acessos ao Sistema Operativo .................................................47
9.5.1 Identificação Automática de um Terminal ..............................................47
9.5.2 Procedimentos de Logon em Sistemas ....................................................47
9.5.3 Identificação e Autenticação do Utilizador..............................................48
9.5.4 Sistema de Gestão de Senhas ...................................................................48
9.5.5 Utilização de Utilitários de Sistema.........................................................48
9.5.6 Alarme de Coacção para Protecção dos Utilizadores ..............................49
9.5.7 Time-out de um Terminal ........................................................................49
9.5.8 Limitação do Tempo de Ligação .............................................................49
9.6
Controlo de Acesso às Aplicações ...............................................................49
9.7
Monitorização da Utilização e Acesso ao Sistema ......................................50
9.7.1 Registo de Eventos ...................................................................................50
9.7.2 Utilização do Sistema de Monitorização .................................................50
9.7.3 Sincronização do Relógio ........................................................................50
9.8
Computação Móvel e Tele-trabalho.............................................................51
9.8.1 Computação Móvel ..................................................................................51
9.8.2 Tele-trabalho ............................................................................................51
10 Desenvolvimento e Manutenção de Sistemas .....................................................53
10.1 Requisitos de Segurança dos Sistemas ........................................................53
10.2 Segurança nos Sistemas Aplicacionais ........................................................53
10.2.1
Validação de Dados de Entrada ...........................................................54
10.2.2
Controlos de Validação dos Processos Internos ..................................54
10.2.3
Autenticação de Mensagens .................................................................54
10.2.4
Validação dos Resultados Produzidos .................................................55
10.3 Controlos Criptográficos ..............................................................................55
10.3.1
Política de Utilização de Controlos Criptográficos .............................55
10.3.2
Criptografia ..........................................................................................56
10.3.3
Assinatura Digital ................................................................................56
10.3.4
Não Repúdio ........................................................................................56
10.4 Segurança dos Ficheiros de Sistema ............................................................56
10.4.1
Controlo de Software em Produção .....................................................56
10.4.2
Protecção de Dados de Teste dos Sistemas..........................................57
10.4.3
Controlo de Acesso ao Código Fonte ..................................................57
10.5 A Segurança nos Processos de Desenvolvimento e Suporte .......................58
10.5.1
Procedimentos de Gestão de Alterações ..............................................58
10.5.2
Revisão Técnica de Alterações aos Sistemas em Produção.................59
10.5.3
Restrições às Alterações de Pacotes de Software ................................59
10.5.4
Canais Escondidos e Códigos do Tipo Cavalo de Tróia ......................60
10.5.5
Outsourcing de Desenvolvimento de Software....................................60
11 Gestão da Continuidade do Negócio...................................................................61
11.1 Aspectos da Gestão da Continuidade do Negócio .......................................61
12 Conformidade .....................................................................................................62
12.1 Conformidade com Requisitos Legais .........................................................62
12.1.1
Identificação da Legislação Aplicável .................................................62
12.1.2
Direitos de Propriedade Intelectual ......................................................62
12.1.3
Salvaguarda de Registos da Entidade ..................................................62
12.1.4
Protecção e Privacidade de Dados Pessoais.........................................63
12.1.5
Prevenção Contra o Uso Indevido de Equipamento ............................63
12.1.6
Regulamentação de Controlos de Criptografia ....................................63
Público
5
ENSI
Política de Segurança da Informação Detalhada da Entidade
12.1.7
Registo de Evidências ..........................................................................63
12.2 Revisão das Políticas de Segurança e Conformidade Técnica.....................64
12.3 Considerações sobre Auditoria de Sistemas ................................................64
Público
6
ENSI
Política de Segurança da Informação Detalhada da Entidade
1 Objectivo
O objectivo deste documento é orientar as entidades no desenvolvimento das suas
políticas, normas e procedimentos relativamente à Segurança da Informação.
Com base na norma internacional ISO/IEC 17799, são dadas orientações nos
seguintes domínios:
•
Política de Segurança
•
Organização da Segurança
•
Classificação e Controlo dos activos de informação
•
Segurança pessoal
•
Segurança física e ambiental
•
Gestão de comunicações e operações
•
Controlo de acessos
•
Desenvolvimento e manutenção de sistemas
•
Gestão da continuidade de negócio
•
Conformidade
Este documento não deverá ser utilizado tal como está mas sim adaptado às
actividades desenvolvidas pelas entidades. No entanto, é importante que a Política de
Segurança de Informação Detalhada da Entidade (PSIDE) se mantenha em
conformidade com a Política de Segurança da Informação da Entidade (PSIE). A
PSIDE deverá ser utilizada como guia para o desenvolvimento e a implementação da
Segurança da Informação na entidade.
Quando apropriado, a ENSI providenciará modelos para o desenvolvimento de
normas e procedimentos a serem utilizados para estruturar e guiar a implementação
das políticas. As políticas, normas e procedimentos finais deverão ser desenvolvidos
pela própria entidade.
Público
7
ENSI
Política de Segurança da Informação Detalhada da Entidade
2 Audiência
Este documento deverá ser utilizado pelo Responsável pela Segurança ou cargo
equivalente que seja responsável pelo desenvolvimento das políticas de Segurança da
Informação ao nível da entidade.
A audiência final será definida durante a elaboração da política de segurança geral (a
ser aplicada a todos os recursos ou indivíduos da entidade) e das políticas de
segurança específicas (aplicada somente a grupos específicos).
Público
8
ENSI
Política de Segurança da Informação Detalhada da Entidade
3 Termos e Definições
Para os efeitos deste documento, aplicam-se as seguintes definições:
3.1
Segurança da Informação
Preservação da confidencialidade, integridade e disponibilidade da informação.
•
Confidencialidade: Garantia de que o acesso à informação seja obtido somente
por pessoas autorizadas;
•
Integridade: Salvaguarda de que a informação e os métodos de processamento
são exactos e completos;
•
Disponibilidade: Garantia de que os utilizadores autorizados obtenham acesso
à informação e aos activos correspondentes sempre que necessário.
3.2
Análise de Risco
Análise das ameaças, impactos e vulnerabilidades da informação e das instalações de
processamento da informação e análise da probabilidade da sua ocorrência.
3.3
Gestão de Risco
Processo de identificação, controlo e minimização ou eliminação dos riscos de
segurança que podem afectar os sistemas de informação, a um custo aceitável.
3.4
Princípio do Privilégio Mínimo
Princípio que dita que um sujeito só deve ter o conjunto de direitos de acesso
estritamente necessários para a execução de tarefas autorizadas.
Público
9
ENSI
Política de Segurança da Informação Detalhada da Entidade
4 Organização da Segurança
4.1
Infra-estrutura da Segurança da Informação
A Direcção da entidade é responsável pela Segurança da Informação. Para suportá-la,
deve ser criada uma equipa de Segurança da Informação constituída por membros de
diferentes áreas, de modo a assegurar que os requisitos de segurança são traduzidos
em estratégias, orientações obrigatórias e conceitos de segurança.
4.1.1
Arquitectura da Segurança da Informação
A arquitectura da Segurança da Informação consiste em três níveis, com um
crescimento ao nível de detalhe de cima para baixo. A Política de Segurança da
Informação da Entidade (PSIE), cujo objectivo principal é definir o valor da
Segurança da Informação para a entidade e descrever a sua importância, encontra-se
no topo.
PSIE
PSIDE
Manual
Manual
2
Manual
....
3
1
Nos próximos capítulos serão apresentadas e definidas as normas de Segurança da
Informação ao nível da entidade (PSIDE). A PSIDE, descrita neste documento,
protege a entidade e garante a consistência do ambiente de segurança de acordo com a
ENSI. As referências do capítulo 12 são de especial importância, como a intenção de
aderir a todas as leis aplicáveis sobre a área de operação da entidade.
Todas as normas e procedimentos existentes, e a serem criados, devem estar em
conformidade com a PSIDE.
4.1.2
Coordenação da Segurança da Informação
A Segurança da Informação é de particular importância para todos os projectos,
sistemas e utilizadores das Tecnologias de Informação e Comunicações (TIC) da
entidade. Este processo de Segurança da Informação não se encontra limitado a um
departamento, pelo que é necessário definir claramente as responsabilidades de forma
a garantir que todos os aspectos importantes serão levados em consideração e que
todas as tarefas serão cumpridas adequadamente.
Público
10
ENSI
Política de Segurança da Informação Detalhada da Entidade
Estão consideradas três funções distintas:
•
Comité de Segurança – responsável pela Segurança da Informação ao nível
da entidade;
•
Departamento de Segurança – apoia o Comité de Segurança em todos os
assuntos relacionados com Segurança da Informação;
•
Equipa de Segurança – apoia o Departamento de Segurança a tempo parcial.
4.1.2.1
Comité de Segurança
A experiência demonstra que o Departamento de Segurança necessita de um grande
suporte a nível das operações para estar apto a implementar e manter um Sistema de
Gestão de Segurança da Informação (SGSI), especialmente se o Departamento de
Segurança não reportar à Direcção da entidade. Com este objectivo, deverá então ser
estabelecido um comité de Segurança com representantes dos seguintes
grupos/departamentos:
•
Recursos Humanos
•
Legal
•
Auditoria
•
Comunicações
•
Sistemas
•
Operações
•
Departamento de Segurança
•
Consultores, caso necessário
O Comité de Segurança decide as políticas ao nível da entidade, providencia
informações para a elaboração de análises de risco, revê as acções relacionadas com
incidentes de segurança e supervisiona as actividades do Departamento de Segurança.
Este representa o nível de decisão mais elevado para assuntos relacionados com a
Segurança da Informação. Ao Comité de Segurança deverão ser atribuídas as
responsabilidades necessárias para este poder tomar decisões relativas à Segurança da
Informação, em nome da entidade.
O Comité de Segurança deverá efectuar reuniões trimestrais e de urgência para os
casos onde existam falhas sérias na segurança da entidade (por exemplo, no caso de
um ataque de Negação de Serviço). As operações são coordenadas pelo Departamento
de Segurança.
4.1.2.2
Processos de Segurança da Informação
Os processos de Segurança da Informação abrangem todas as áreas da entidade, no
entanto, podem-se considerar três estruturas verticais distintas: Organização (marcada
Público
11
ENSI
Política de Segurança da Informação Detalhada da Entidade
a vermelho na figura), Organização da Segurança (marcada a azul) e um Grupo
Virtual/Interface (marcado a verde) constituído por elementos da Organização que
reportam ao Departamento de Segurança.
Estes grupos gerem as responsabilidades entre si, providenciam feedback e actuam
como facilitadores. Isto é representado pelas setas no diagrama com o seguinte código
de cores:
Feedback: O processo de dar informação sobre o estado da Segurança da
Informação da entidade. Um exemplo é o envio de um relatório com o
estado actual do SGSI ao Comité de Segurança, com periodicidade
trimestral.
Facilitador: O processo de iniciar, conduzir, sugerir ou prestar serviços
de segurança para uma entidade. Exemplos são a criação de uma agenda
para o Comité de Segurança ou orientação de um departamento durante a
criação dos seus procedimentos de segurança.
Responsabilidade: A responsabilidade das partes ou de todos na
Segurança da Informação não pode ser delegada. No entanto, a
responsabilidade pode ser transferida para outros departamentos que
terão de obedecer a determinadas regras na manutenção da Segurança da
Informação.
As setas mais estreitas representam um menor feedback, intervenção do facilitador ou
delegação de responsabilidade.
Processo de Gestão de Segurança da Informação
Feedback
Facilitador
Responsabilidade
Direcção
Comité de
Segurança
Entidade
Depart. de
Segurança
Organização da
Segurança
Equipa de
Segurança
Depart.
Gestão de
Segurança
Suporte
Recursos
Empregados
Grupo Virtual/Interface
Organização
Público
12
ENSI
Política de Segurança da Informação Detalhada da Entidade
Explicação:
Depart. de
Segurança
Comité de
Segurança
Departamento de Segurança: este departamento é responsável pelo
processo de implementação de um Sistema de Gestão de Segurança
da Informação (SGSI) ao nível da entidade. Este grupo é constituído
por uma equipa de segurança a tempo inteiro (representado pelo
padrão de fundo da caixa). As tarefas e responsabilidades deste
departamento estão detalhadas na secção 4.1.3 (Responsabilidades na
Segurança da Informação).
Comité de Segurança: é o grupo de mais alto nível de Segurança da
Informação da entidade. Decide sobre todos os assuntos relacionados
com a Segurança da Informação e controla as actividades do
Departamento de Segurança. Transfere a responsabilidade pela
segurança para os Departamentos e a responsabilidade de facilitar e
auditar os processos de segurança para o Departamento de
Segurança. Para detalhes, ver a secção do Comité de Segurança na
secção 4.1.3.
Equipa de
Segurança
Equipa de Segurança: A maior parte deste grupo é virtual e
encontra-se vinculada à Segurança da Informação a tempo parcial. A
equipa é constituída por membros de todos os principais
departamentos de modo a garantir que todas as áreas da entidade
estão representadas no Grupo Virtual de Segurança.
Gestão de
Segurança
Gestão de Segurança: Os membros deste grupo virtual são
envolvidos na alteração e manipulação de componentes de
segurança. Exemplos disso são a criação ou modificação de
utilizadores (user-IDs), a actualização de listas de controlo de acesso
(Access Control Lists, ACL) e a criação de regras no Firewall.
Depart.
Organização: Todos os departamentos da entidade são responsáveis
por implementar a Segurança da Informação conforme definido pelas
normas e política de segurança da entidade. Estes documentos
encontram-se de acordo com as normas internacionais e devem ser
aprovados pelo Comité de Segurança.
4.1.2.3
Delegação de Responsabilidades
A responsabilidade pela Segurança da Informação permanece com a Direcção da
entidade. Esta responsabilidade é partilhada e atribuída aos directores (através do
Comité de Segurança).
O Departamento de Segurança recorre à Equipa de Segurança da Informação para
gerir e controlar o SGSI da entidade. Esta equipa virtual de segurança deve participar
em reuniões regulares e providenciar feedback sobre o nível de conformidade da
entidade.
4.1.3
Responsabilidades na Segurança da Informação
O Comité de Segurança define as orientações estratégicas e é responsável por:
Público
13
ENSI
Política de Segurança da Informação Detalhada da Entidade
•
Estabelecer os objectivos de Segurança da Informação e desenvolver uma
política para atingir estes objectivos;
•
Definir as funções do Departamento de Segurança;
•
Desenvolver um plano de implementação das salvaguardas declaradas no
conceito de Segurança da Informação;
•
Monitorizar e verificar se os objectivos de segurança foram atingidos;
•
Promover o conhecimento da Segurança da Informação através da entidade;
•
Monitorizar a eficácia dos controlos de segurança;
•
Providenciar aconselhamento à Direcção em assuntos relacionados com a
Segurança da Informação;
•
Identificar os recursos (pessoas, orçamento, conhecimento etc.) que podem ser
utilizados nos processos de Segurança da Informação.
O Departamento de Segurança é responsável por todos os assuntos relacionados com
Segurança da Informação na entidade. Os deveres do Departamento de Segurança
incluem:
•
Ajudar na criação do conceito Segurança da Informação na entidade;
•
Reportar ao Comité de Segurança;
•
Gerir a informação proveniente da equipa de Segurança da Informação e
garantir o correcto processamento da mesma;
•
Ser responsável pela implementação dos controlos de Segurança da
Informação;
•
Planear e coordenar a formação e os programas de consciencialização da
segurança;
•
Garantir a segurança no dia a dia;
•
Organizar e coordenar as investigações dos incidentes relacionados com a
Segurança da Informação;
•
Organizar e conduzir a equipa de Segurança da Informação (tanto os membros
directos quanto os virtuais).
A equipa de Segurança da Informação é um subgrupo do Departamento de Segurança
e é administrada por este. As suas principais responsabilidades são:
•
Criar e actualizar manuais e instruções em cooperação com os diferentes
departamentos baseados na PSIE e na PSIDE;
Público
14
ENSI
Política de Segurança da Informação Detalhada da Entidade
•
Rever a eficácia das medidas de segurança regularmente e executar as
alterações requeridas de modo a garantir um elevado nível de segurança;
•
Coordenar as acções de segurança com os departamentos;
•
Seleccionar e testar ferramentas de segurança;
•
Coordenar e desenvolver formação em conjunto com os departamentos;
•
Apoiar desde o princípio os projectos internos da entidade assim como os
projectos relevantes de clientes/parceiros de modo a atingir os requisitos de
segurança;
•
Desenvolver e coordenar as formações relevantes para a segurança e sua
consciencialização;
•
Administração da Segurança (por exemplo, contas de utilizadores, direitos de
acesso).
4.1.4
Autorização para Utilização de Equipamento
O uso de equipamento pessoal para processamento de informação no ambiente de
trabalho pode trazer novas vulnerabilidades e, por esta razão, deve ser analisado e
autorizado. Excepções para determinados tipos de equipamento como, por exemplo,
agendas electrónicas, devem ser aprovadas pelo Departamento de Segurança.
4.1.5
Consultoria Especializada em Segurança da Informação
O Departamento de Segurança da Informação poderá ter de recorrer a especialistas em
determinadas áreas o que se traduz em recorrer a serviços de consultoria internos ou
externos.
4.1.6
Cooperação Entre Entidades
Devem ser definidos e mantidos meios de contacto apropriados de forma a garantir
uma resposta rápida e adequada em caso de incidente. Estes contactos deverão incluir
Policia Judiciária, organismos reguladores, prestadores de serviços e operadores de
telecomunicações. De forma similar, é recomendada a presença em grupos de
segurança e em áreas de actividade própria.
As trocas de informação de segurança devem ser restritas de forma a garantir que
informações confidenciais da entidade não sejam entregues a pessoas não autorizadas.
4.1.7
Análise Independente da Segurança da Informação
Os documentos das políticas de Segurança da Informação e sua implementação
devem ser analisadas de forma independente, de forma a assegurar que as práticas
implementadas na entidade estão em conformidade com a ENSI (ver 12.2).
Esta análise pode ser executada através de uma auditoria interna ou externa.
Público
15
ENSI
Política de Segurança da Informação Detalhada da Entidade
4.1.8
Custos dos Controlos da Segurança da Informação
De forma a obter economias de escala e controlar custos, e tendo em conta que os
controlos de segurança a implementar não se encontram limitados a departamentos
específicos, há a necessidade de criar condições, sob a coordenação do Departamento
de Segurança, que permitam uma adopção e aplicação coerente dos controlos de
segurança por toda a entidade.
4.2
Segurança no Acesso de Terceiros
De forma a manter a segurança dos activos de informação e processos associados da
entidade quando acedidos por terceiros, os seguintes princípios devem ser tidos em
conta:
•
O acesso de terceiros aos recursos de processamento de informação da
entidade deve ser controlado e regulado pelo princípio do privilégio mínimo;
•
Caso exista necessidade de disponibilizar acesso a terceiros, deverá ser
realizada uma análise de risco para determinar as possíveis implicações na
segurança e identificar os controlos necessários. As medidas a adoptar e as
condições através das quais o acesso é providenciado deverão estar reflectidas
no contrato com os terceiros;
•
O acesso dado a terceiros às vezes implica o acesso a subcontratados. Esta
transmissão de acesso deve ser contemplada no contrato assinado com estes;
•
Deve ser dada especial atenção às cláusulas relativas às penalidades a aplicar
no caso do incumprimento dos contratos (ex. acesso não autorizado, abuso de
confiança, violação do acordo de confidencialidade…) (ver secção 6.1);
•
O acesso à informação só deve ser facultado a terceiros caso os controlos de
segurança apropriados tenham sido implementados e um contrato que
estabelece as condições de acesso tenha sido assinado;
•
O contrato não deve conter ambiguidades e deve-se garantir o seu correcto
entendimento pelas partes envolvidas.
4.3
Outsourcing
Em caso da responsabilidade pelo processamento da informação (inteira ou parcial)
ser transferida para outra entidade, tem de se garantir que a Segurança da Informação
é mantida ao nível do estipulado na PSIE e PSIDE.
Os acordos de outsourcing devem ter em conta os riscos bem como os controlos de
segurança para as TIC e as penalidades em caso de incumprimento.
Os princípios apresentados na secção 4.2 também devem ser aplicados ao contrato de
outsourcing. O contrato deve permitir que os requisitos e procedimentos de segurança
sejam mapeados num plano de gestão da segurança a ser acordado entre ambas as
partes.
Público
16
ENSI
Política de Segurança da Informação Detalhada da Entidade
5 Classificação e Controlo dos Activos da
Informação
5.1
Inventário dos Activos da Informação
A existência de um inventário dos activos da informação permite à entidade assegurar
um nível de protecção em função do valor e da importância dos activos. Deve ser
também criado e mantido um inventário que relacione os sistemas de informação com
os principais activos da informação. Para cada activo deve-se identificar e documentar
o responsável, a classificação de segurança e a sua localização.
5.2
Classificação da Informação
Todos os activos da informação da entidade tem de ser classificados, de modo que
seja possível indicar a importância, a prioridade e o nível de protecção. O objectivo é
assegurar que os activos de informação da entidade recebam um nível de protecção
adequado contra o acesso e divulgação não autorizados. Devem ser definidas
instruções para a classificação do valor da informação bem como a nomenclatura e o
manuseio de informação classificada (ver o “ENSI – Guia da Segurança da
Informação para o Gestor” e as secções a seguir para mais detalhes).
As orientações para a classificação de um determinado activo de informação devem
antecipar e permitir a alteração da classificação uma vez que esta não é fixa e pode
mudar de acordo com alguma política predeterminada (ver 9.1).
A classificação da informação na Administração Pública tem de estar de acordo com a
Lei de Acesso aos Documentos Administrativos (LADA).
5.2.1
Orientações para a Classificação
A classificação da informação em Portugal é feita com base nos SEGNACS. O
SEGNAC 1 (Resolução de Conselho de Ministros n.º 50/88 de 3 de Dezembro) define
que os graus de segurança a atribuir às matérias são os seguintes:
•
«Muito secreto»;
•
«Secreto»;
•
«Confidencial»;
•
«Reservado».
Quando for conveniente, poderá um documento levar a indicação de «Não
Classificado».
5.2.1.1
Grau de Classificação de «Muito Secreto»
O grau de classificação de «Muito secreto» é limitado a informações, documentos e
materiais que necessitem do mais elevado grau de protecção uma vez que o seu
conhecimento ou divulgação a pessoas não autorizadas pode implicar consequências
Público
17
ENSI
Política de Segurança da Informação Detalhada da Entidade
excepcionalmente graves para a Nação, em virtude de afectarem as condições de
defesa do País ou comprometerem a segurança da Nação.
5.2.1.2
Grau de Classificação de «Secreto»
O grau de classificação de «Secreto» abrange as informações, documentos e materiais
cuja divulgação ou conhecimento por pessoas não autorizadas possa ter consequências
graves para a Nação, em resultado de afectarem a concretização de empreendimentos
importantes para a Nação, comprometerem a segurança dos planos civis e militares ou
revelarem procedimentos em curso relacionados com assuntos civis e militares de alta
importância.
5.2.1.3
Grau de Classificação de «Confidencial»
O grau de classificação de «Confidencial» deve ser aplicado às matérias cujo
conhecimento por pessoas não autorizadas possa ser prejudicial para os interesses do
País.
5.2.1.4
Grau de Classificação de «Reservado»
O grau de classificação de «Reservado» deve ser aplicado às matérias cuja divulgação
a pessoas não autorizadas possa ser desfavorável para os interesses do País.
5.2.1.5
Grau de Classificação de «Não classificado»
O grau de classificação de «Não classificado» significa que a matéria foi alvo de uma
apreciação sob o ponto de vista da segurança, mas foi considerado não ser necessário
atribuir-lhe qualquer classificação de segurança.
5.2.2
Identificação e Tratamento da Informação
A utilização identificação física é geralmente a forma mais apropriada de identificar a
classificação a informação. No entanto, alguns activos de informação, como
documentos em forma electrónica, não podem ser fisicamente identificados sendo
necessário usar uma identificação electrónica.
Público
18
ENSI
Política de Segurança da Informação Detalhada da Entidade
6 Segurança Pessoal
6.1
Segurança na Definição e Recursos da Função
As estatísticas de mercado demonstram que uma elevada percentagem de incidentes
de segurança é causada pelos colaboradores da própria entidade. Torna-se assim
intenção da entidade a redução dos riscos de erro humano, roubo, fraude ou uso
indevido das instalações e recursos.
As responsabilidades pelas medidas de precaução de segurança devem:
•
Ser atribuídas na fase de recrutamento;
•
Ser incluídas em todos os contratos de trabalho;
•
Ser actualizadas regularmente. A consciência de todos os colaboradores para
com este objectivo tem ser melhorada anualmente. Por exemplo: através de
publicações na intranet; sessões de divulgação e informação agendadas e
coordenadas pela equipa de Segurança da Informação.
Todos os funcionários e prestadores de serviços, utilizadores das instalações dos
sistemas de informação, devem assinar um acordo de sigilo antes de ter acesso.
Na admissão de novos colaboradores da entidade, a verificação dos seus antecedentes
é requerida no momento da selecção de candidatos, assim como referências dos
empregadores anteriores.
Para colaboradores externos à entidade (por exemplo, consultores), um processo de
revisão semelhante deve ser conduzido pelo respectivo requerente (ou pessoa
responsável pelo orçamento do departamento). Isto aplica-se também aos recursos
fornecidos por agências externas, onde a responsabilidade pela verificação é da
agência e tem de ser documentada nos respectivos contratos.
A entidade tem de estabelecer o tipo de supervisão necessária para os novos
funcionários ou sem experiência que necessitem de autorização de acesso a
informação sensível.
Em termos gerais, todos os dados e informação tratados pelos funcionários no
decorrer do seu trabalho estão sujeitos a uma obrigação de não divulgação, excepto no
caso de dados ou informações que estejam publicamente disponíveis ou acessíveis.
Colaboradores externos à entidade que ainda não se encontrem abrangidos por um
contrato (que contenha um acordo de sigilo), devem assinar um acordo de
confidencialidade antes de ter acesso a dados ou sistemas de informação da entidade.
6.2
Formação dos Utilizadores
Os utilizadores devem estar cientes das ameaças e preocupações relacionadas com a
Segurança da Informação e estar preparados para aplicar a Política de Segurança da
Público
19
ENSI
Política de Segurança da Informação Detalhada da Entidade
Informação da Entidade (PSIE) no decorrer do seu trabalho. O Departamento de
Segurança tem de criar todos os regulamentos apropriados.
Todos os funcionários da entidade e, se necessário, terceiros devem ser informados
sobre a lei de protecção de dados, actualizações à mesma e sobre qualquer requisito
particular de protecção de dados da entidade. O funcionário deve acusar a recepção da
formação por escrito. Cada funcionário tem o direito de ser informado ou perguntar
pelos controlos implementados e requisitos da protecção de dados.
Para mais informação sobre a protecção de dados pessoais consultar a Comissão
Nacional de Protecção de Dados.
6.3
Resposta a Incidentes de Segurança e Falhas
Todos os incidentes de segurança têm de ser reportados o mais rapidamente possível
através dos procedimentos apropriados. O objectivo é limitar os danos causados pelos
incidentes e falhas de segurança, assegurar a correcta e apropriada reacção, bem como
recolher informação para futuras medidas preventivas.
Os utilizadores que violarem as instruções, normas, procedimentos e políticas de
segurança serão responsabilizados disciplinar e/ou judicialmente.
Devem ser mantidos registos e estatísticas para a monitorização e a quantificação do
tipo, magnitude e custo dos incidentes e falhas de segurança. Esta informação permite
a análise de incidentes e falhas sérios e recorrentes. Além disso, a necessidade de
medidas extras ou mais extensas é determinada. Este processo limita a frequência, o
impacto e os custos de futuros incidentes.
Os utilizadores dos sistemas de informação são obrigados a registar e comunicar todas
as falhas e ameaças à segurança observadas ou identificadas. Estas observações
devem ser comunicadas ao departamento/equipa de segurança o mais rapidamente
possível.
Têm de estar definidos procedimentos para a comunicação de falhas de software. Os
utilizadores que não possuam as permissões adequadas não podem remover o
software suspeito. Apenas os empregados experientes e treinados devem ter
permissões para executar o processo de restauro.
Público
20
ENSI
Política de Segurança da Informação Detalhada da Entidade
7 Segurança Física e Ambiental
O objectivo da entidade é prevenir o acesso não autorizado, dano, roubo e
manipulação da informação e dos equipamentos que processam, ou estão envolvidos
com o processamento da informação.
7.1
Áreas Seguras
O equipamento de processamento de informação crítica ou sensível para o negócio
deve ser mantido em áreas seguras, protegidas por um perímetro de segurança
definido, com barreiras de segurança apropriadas e controlo de acessos. As
instalações têm de ser fisicamente protegidas contra acessos não autorizados, danos
ou interferências.
A protecção deve ser adequada aos riscos identificados. Recomenda-se a
implementação de políticas restritas em relação a este ponto (por exemplo, políticas
de mesa limpa e ecrã limpo) de modo a reduzir o risco de acesso não autorizado ou
danos a papéis, meios de suporte de dados, recursos e equipamento de processamento
de dados.
7.1.1
Perímetros da Segurança Física
As áreas onde se encontram o negócio ou equipamentos de processamento de
informação devem ser protegidas por zonas de segurança através de diversos pontos
de controlo físicos (ver 7.1.3). Cada ponto de controlo, por exemplo, uma parede, uma
porta com controlo de entrada baseado em cartão ou mesmo um balcão de controlo de
acesso com registo manual, representa um perímetro de segurança que aumenta a
protecção total. A posição e o tipo de ponto de controlo dependem dos resultados da
análise de risco. As seguintes orientações e controlos devem ser tidos em conta:
•
As zonas de segurança devem estar claramente definidas;
•
O perímetro de um prédio ou local que contenha equipamentos de
processamento de informação deve ser fisicamente intacto. Isto é, não podem
existir falhas que permitam a exploração de vulnerabilidades. Todas as
paredes externas do local devem ser de construção sólida e todas as portas
externas devem ser protegidas de forma apropriada contra acessos não
autorizados, como, por exemplo, mecanismos de controlo, trancas, alarmes,
grades…;
•
Deve existir uma área de recepção ou outro meio de controlo de acesso físico
ao local. O acesso aos locais deve ser restrito apenas ao pessoal autorizado;
•
As barreiras físicas devem, se necessário, ser estendidas da laje do piso até a
laje superior, de modo a prevenir acessos não autorizados ou contaminação
ambiental, como as causadas por fogo e inundações;
•
Todas as portas de incêndio no perímetro de segurança devem possuir
sensores de alarme e devem fechar automaticamente em caso de incêndio;
Público
21
ENSI
•
Política de Segurança da Informação Detalhada da Entidade
Deve ser seguido o princípio “Four-Eyes” para o acesso às áreas sensíveis.
7.1.2
Controlos de Acesso Físico
As áreas de segurança têm de ser protegidas por controlos de entrada apropriados de
modo a assegurar que apenas pessoas autorizadas tenham acesso às mesmas. Pessoas
não autorizadas não devem ter acesso às instalações da entidade. As entradas de salas
que dêem acesso directo a dados, armazenamento de dados, equipamentos de
processamento de informação ou transferência de dados (redes) têm de ser
severamente controladas. O acesso é dado de acordo com regras e responsabilidades
acordadas. Salas com acesso indirecto a dados, como aquelas que contém estações de
trabalho sem protecção ou consolas com ligações abertas aos bancos de dados, têm de
ser protegidas exactamente da mesma maneira. Os seguintes controlos devem ser
considerados:
•
Visitantes que se encontrem em áreas de segurança devem ser supervisionados
ou conduzidos e a data e hora da sua entrada e saída deverá ser registada (por
exemplo, registo de visitantes). O acesso é fornecido a estas pessoas apenas a
áreas específicas, com propósitos autorizados e acompanhamento adequado.
Adicionalmente, os visitantes devem receber instruções relacionadas com os
requisitos específicos de segurança e procedimentos de emergência próprios
da área a que irão aceder;
•
O acesso a informação sensível, instalações e recursos de processamento de
informação deve ser controlado e restrito apenas ao pessoal autorizado. Os
controlos de autenticação devem ser usados para autorizar e validar qualquer
acesso. O registo de ocorrências, contendo todos os acessos e tentativas de
acesso, deve ser mantido em segurança;
•
Todos os funcionários têm de utilizar uma identificação visível e devem ser
incentivados a informar a segurança sobre a presença de qualquer pessoa não
identificada ou de qualquer estranho não acompanhado;
•
O direito de acesso a áreas seguras deve ser regularmente revisto e
actualizado.
7.1.3
Protecção do Local de Trabalho e Instalações
Uma área segura pode ser um escritório ou diversas salas dentro de um perímetro de
segurança física, que estão fechados ou podem conter armários fechados ou cofres. A
escolha de uma área segura deve ter em consideração as possibilidades de danos
causados por fogo, inundações, explosões, manifestações civis e outras formas de
desastres naturais ou causados pelo homem.
Devem ser tidas em consideração as normas de segurança e saúde. Devem ser
consideradas também quaisquer ameaças com origem nas propriedades vizinhas, por
exemplo, infiltrações de água provenientes de outras áreas. Se as medidas não
puderem ser aplicadas nesse local, deve ser ponderada a hipótese de uma mudança
para outro local. Recomenda-se que sejam tidos em conta os seguintes controlos nas
áreas seguras:
Público
22
ENSI
Política de Segurança da Informação Detalhada da Entidade
•
As instalações críticas deverão ficar localizadas de forma a evitar o acesso
público;
•
Os prédios não devem ter obstruções no seu acesso e devem ter indicações
mínimas do seu propósito. Devem evitar sinais óbvios da presença de
actividades de processamento de informação, tanto fora como dentro do
prédio;
•
As funções e equipamentos de suporte, como por exemplo, fotocopiadoras e
máquinas de fax, devem ser instalados de forma apropriada dentro de áreas
seguras de forma a evitar acessos que possam comprometer a informação;
•
As portas e janelas devem ser mantidas fechadas quando não utilizadas.
Devem ser consideradas protecções externas (por exemplo, barras metálicas),
principalmente quando essas portas e janelas se localizarem em andar térreo;
•
Os sistemas de detecção de intrusos (alarmes) devem ser instalados de forma a
cobrir todas as portas externas e janelas acessíveis e testados com
regularidade;
•
Os directórios e listas de telefones internos que identificam locais de
processamento da informação sensível não devem ser de acesso público;
•
Os materiais combustíveis ou perigosos devem ser guardados, e devidamente
protegidos, a uma distância segura das zonas de segurança. Uma zona de
segurança não deve ser utilizada como armazém de bens não sensíveis (ex.
material de escritório, resmas de papel);
•
Os equipamentos de contingência e suportes magnéticos de cópias seguras
(backup) devem ser guardados a uma distância segura da instalação principal
(por exemplo, em outro prédio) de forma a evitar que desastres ocorridos neste
local os afectem;
•
As instalações de processamento da informação administradas pela entidade
devem ficar fisicamente separadas daquelas que administradas por terceiros.
7.1.4
Trabalho em Áreas Seguras
São necessários controlos adicionais numa área segura. Estes incluem controlos tanto
para o pessoal da entidade como para terceiros que trabalham em áreas seguras, assim
como para actividades de terceiros que possam ocorrer nessa área. Os seguintes
controlos devem ser tidos em conta:
•
Princípio “Four-Eyes” para trabalho sensível;
•
Os funcionários só devem ter conhecimento da existência da área segura ou
das actividades dentro dela, quando estritamente necessário;
•
Trabalho sem supervisão em áreas seguras deve ser evitado, tanto por razões
de segurança como para evitar oportunidades para actividades maliciosas;
Público
23
ENSI
Política de Segurança da Informação Detalhada da Entidade
•
As áreas seguras desocupadas devem ser mantidas fisicamente fechadas e
verificadas periodicamente;
•
O pessoal de terceiros só deve ter acesso às áreas seguras ou instalações de
processamento de informação sensível quando as suas actividades assim o
exijam. Este acesso deverá ser autorizado, monitorizado e registado;
•
O uso de equipamentos fotográficos, de vídeo, de áudio ou de outro
equipamento de gravação, como computadores portáteis, são proibidos, a
menos que seja dada uma autorização especial.
7.1.5
Isolamento das Áreas de Cargas e Descargas
As áreas de cargas e descargas deverão ser controladas e isoladas das instalações de
processamento da informação, com o objectivo de evitar acessos não autorizados. Os
requisitos de segurança devem ser determinados a partir de uma análise de risco. Os
seguintes controlos devem ser tidos em conta:
•
O acesso à área de carga e descarga deve ser restrito ao pessoal identificado e
autorizado;
•
A área de carga e descarga deve ser projectada de forma a ser possível a
descarga de material sem que o pessoal responsável pela entrega tenha acesso
às outras partes das instalações;
•
O material de entrada deve ser inspeccionado contra potenciais perigos, antes
de ser transportado dessa área para a área na qual será utilizado (ver 7.2.1);
•
A(s) porta(s) externa(s) destas áreas devem ser mantida(s) fechada(s) enquanto
as portas internas para a área segura estiverem abertas.
7.2
Segurança do Equipamento
O acesso físico aos equipamentos possibilita frequentemente, que uma pessoa
tecnicamente experiente (por exemplo, um técnico informático) aceda aos dados. O
objectivo da entidade é prevenir perda, dano, acesso não autorizado, alteração da
informação e a interrupção das actividades do negócio. O equipamento deve ser
fisicamente protegido contra ameaças à sua segurança e perigos ambientais.
A segurança do equipamento também deve ser tida em consideração na activação,
desactivação e alienação do equipamento. Em algumas circunstâncias, podem ser
exigidos controlos especiais para protecção contra perigos ou acessos não autorizados
e para salvaguardar as instalações de infra-estrutura, como o fornecimento de energia
eléctrica e cablagem.
7.2.1
Localização e Protecção de Equipamentos
Os equipamentos devem ser instalados e protegidos de forma a reduzir o risco de
ameaças ambientais, perigos e oportunidades de acesso não autorizado. Os seguintes
controlos devem ser tidos em conta:
Público
24
ENSI
Política de Segurança da Informação Detalhada da Entidade
•
Os equipamentos devem ser instalados de forma a evitar acessos
desnecessários;
•
As instalações que processem ou armazenem informação sensível devem ser
posicionadas de forma a minimizar o risco de visualização não autorizada da
informação;
•
Os activos que necessitem de protecção especial deverão encontrar-se isolados
de forma a reduzir o nível de protecção geral exigida;
•
Caso necessário, devem ser adoptados controlos de forma a minimizar
ameaças potenciais, como fogo, explosivos, fumo, água, poeira, vibração,
efeitos químicos, interferência no fornecimento eléctrico, radiação
electromagnética e roubo;
•
Deverá ser tido em conta o impacto de um desastre que ocorra nas
proximidades da instalação, como por exemplo, um incêndio, infiltrações de
água no telhado ou em andares abaixo do nível do chão ou explosões na rua.
7.2.2
Instalação Eléctrica
A instalação eléctrica deverá ser feita de modo a estar em conformidade com as
especificações do fabricante, prevenir danos aos equipamentos e garantir um
fornecimento seguro de energia. Algumas medidas para maximizar a continuidade de
serviço da instalação eléctrica são: alimentação múltipla para evitar um único ponto
de falha; fonte de alimentação ininterrupta (UPS), gerador de emergência. A
necessidade destas medidas tem de ser definida no contexto de uma análise de risco.
A instalação eléctrica deve estar em conformidade com as normas e legislação
vigentes em Portugal.
Adicionalmente, devem estar instalados perto das saídas das salas de computadores
interruptores de emergência que desligam os sistemas. Todas as áreas de
processamento de informação deverão ter iluminação de emergência. Deve ser
utilizada protecção contra relâmpagos se houver a possibilidade destes acontecerem.
7.2.3
Segurança da Cablagem
As cablagens eléctricas e de telecomunicações que transmitam dados ou suportem os
serviços de informação devem ser protegidas contra interceptação ou dano. Os
seguintes controlos devem ser considerados:
•
As linhas eléctricas e de telecomunicações das instalações de processamento
da informação devem ser subterrâneas, onde tal for possível, ou serem
submetidas à protecção alternativa adequada.
•
A cablagem da rede deve ser protegida contra intercepções não autorizadas ou
danos, por exemplo pelo uso de calhas ou evitando a sua instalação ao longo
de áreas públicas.
Público
25
ENSI
Política de Segurança da Informação Detalhada da Entidade
•
Os cabos eléctricos devem ficar separados dos cabos de comunicação para
prevenir interferências.
•
Devem ser utilizados alguns controlos adicionais para os sistemas críticos ou
sensíveis, de modo a eliminar a intercepção de dados:
o Instalação de calhas
electromagnéticos;
blindadas
e
redução
dos
campos
o Protecção dos pontos de inspecção e terminais;
o Uso de rotas e meios de transmissão alternativos, como cabos ópticos;
o Verificação automática para identificar dispositivos não autorizados
conectados aos cabos.
7.2.4
Manutenção de Equipamentos
Deve existir uma manutenção correcta dos equipamentos, de forma a garantir a
disponibilidade e integridade contínua dos mesmos. Os seguintes itens devem ser
considerados:
•
A manutenção dos equipamentos deve ser feita de acordo com os intervalos e
as especificações recomendados pelo fabricante;
•
As reparações e serviços nos equipamentos devem ser executados apenas por
pessoal autorizado;
•
Devem ser mantidos registos de todas as falhas suspeitas ou ocorridas e de
toda a manutenção correctiva e preventiva;
•
Os controles apropriados (ver também 7.2.6, considerando dados apagados,
modificados ou sobrepostos) devem ser utilizados quando o equipamento é
enviado para manutenção fora da instalação física (por exemplo, no caso de
envio ou reparação sob garantia).
7.2.5
Segurança dos Equipamentos Fora das Instalações
Quando são utilizados equipamentos para processamento de informações fora das
instalações da entidade, o funcionário é responsável pela salvaguarda do equipamento
e pelas informações nele contidas, independente do uso ou do ambiente.
A segurança fornecida deve ser equivalente àquela oferecida aos equipamentos
utilizados dentro da entidade para o mesmo propósito, tendo em consideração os
riscos de se trabalhar fora das instalações da entidade.
Neste sentido, os equipamentos de processamento de informação incluem todas as
formas de computadores pessoais, agendas electrónicas, telefones móveis, papéis ou
outros, que tiverem sido retirados para fora do ambiente normal de trabalho. Os
seguintes itens devem ser considerados:
Público
26
ENSI
Política de Segurança da Informação Detalhada da Entidade
•
Os equipamentos e os suportes físicos levados para fora das instalações não
devem ser deixados desprotegidos em áreas públicas. Se possível, os dados
devem ser cifrados. Os computadores portáteis devem ser carregados como
bagagem de mão e disfarçados sempre que possível;
•
As instruções dos fabricantes para protecção do equipamento devem ser
sempre observadas, como por exemplo, a protecção contra exposição a
campos magnéticos intensos;
•
Devem ser determinados controlos apropriados através de uma análise de
risco, como por exemplo, gabinetes de arquivo fechados, política de mesa
limpa e controles de acesso aos computadores. A legislação de
responsabilidade do utilizador (ver 9.3) deve ser estritamente seguida;
•
Deve ser usada uma cobertura de seguro adequada para proteger os
equipamentos existentes fora das instalações da entidade.
Os riscos de segurança, como por exemplo, dano, roubo e espionagem, podem variar
consideravelmente conforme a localização e devem ser considerados na determinação
dos controlos mais apropriados. Mais informações sobre a protecção de equipamentos
móveis podem ser encontradas em 9.8.
7.2.6
Reutilização e Alienação Segura de Equipamento
A informação pode ser exposta pelo descuido na alienação ou reutilização de
equipamentos (ver também 8.6). Todos os dispositivos de armazenamento que
contenham informação sensível, como por exemplo discos duros, devem ser
verificados de forma a garantir que os dados sensíveis e o software licenciado foram
eliminados ou sobrescritos.
Ao invés da utilização de funções padrão para a remoção (delete/format), os
dispositivos de armazenamento que contenham informação sensível devem ser
destruídos fisicamente ou sobrescritos diversas vezes de forma a estarem
irrecuperáveis. Dispositivos de armazenamento danificados contendo informações
sensíveis, devem ser individualmente analisados para se determinar se tais itens
deveriam ser destruídos, reparados ou descartados.
7.3
Controlos Gerais
De modo a proteger a informação e o equipamento de processamento de informação
contra acesso, modificação ou roubo por pessoas não autorizadas, devem ser
adoptados controlos considerando o manuseamento em geral.
Portanto devem ser adoptados os seguintes procedimentos:
•
Os documentos e suportes físicos de computador quando não estiverem a ser
utilizados devem ser guardados em gavetas adequadas com fechaduras e/ou
outra forma segura de mobiliário, especialmente fora dos horários de trabalho;
Público
27
ENSI
Política de Segurança da Informação Detalhada da Entidade
•
A informação sensível ou crítica do negócio, quando não for necessária, deve
ser guardada, em local distante, especialmente quando se abandona o
escritório;
•
Os computadores pessoais, terminais de computador e impressoras não devem
ser deixados ligados quando não supervisionados e devem ser protegidos por
senhas, chaves ou outros controlos quando não estiverem em uso;
•
Os pontos de recepção e envio de correio electrónico e máquinas de fax não
supervisionados devem ser protegidos;
•
Informações sensíveis e classificadas, depois de impressas, devem ser
imediatamente retiradas da impressora.
O equipamento, informação ou software não devem ser retirados da entidade sem
autorização da administração. Sempre que necessário e apropriado, os equipamentos
devem ser desligados e ligados novamente no seu retorno. Devem ser realizadas
inspecções pontuais de forma a detectar a remoção não autorizada de propriedade. As
pessoas devem estar cientes de que serão realizadas estas inspecções pontuais.
Público
28
ENSI
Política de Segurança da Informação Detalhada da Entidade
8 Gestão das Comunicações e Operações
8.1
Responsabilidades e Procedimentos Operacionais
O objectivo da operação é garantir o funcionamento seguro e correcto dos sistemas de
TIC e aplicações da entidade. Os procedimentos e as responsabilidades pela operação
e gestão de todos os sistemas de processamento da informação e aplicações têm de ser
definidos.
8.1.1
Documentação dos Procedimentos Operacionais
Tem de ser identificada uma pessoa responsável por cada sistema de TIC da entidade.
Essa pessoa é a responsável pela implementação e execução de todas as medidas
requeridas pela operação do sistema. A operação dos sistemas e aplicações deve de
ser documentada num manual de operações. As alterações ao manual de operações
têm de ser aplicadas imediatamente após qualquer mudança. As alterações de
segurança nos manuais de operações só podem ser realizadas após a notificação da
Administração de Segurança.
O manual de operações deve conter no mínimo os seguintes itens de segurança:
•
Processamento e manuseamento da informação;
•
Requisitos de sincronismo, incluindo interdependências com outros sistemas, a
hora mais cedo de início e a hora mais tarde de término das tarefas;
•
Instruções (ex. backup, recuperação de dados, procedimentos de reinício,
mensagens de erro) e contactos de técnicos de suporte para o caso de
dificuldades técnicas ou operacionais;
•
Instruções para manipulação de dados extraídos (ex. armazenamento especial
e destruição de informações confidenciais);
•
Procedimentos para organização (ex. manutenção e segurança do centro de
computação).
8.1.2
Controlo de Alterações Operacionais
Tem de ser estabelecido um procedimento para a documentação de mudanças no
âmbito da segurança. Os seguintes pontos tem de ser considerados:
•
Em cada caso, uma pessoa responsável deve aprovar as mudanças propostas;
•
Todas as modificações têm de ser registadas;
•
Análise de impacto potencial de tais mudanças;
•
Procedimento formal de aprovação das mudanças propostas;
Público
29
ENSI
Política de Segurança da Informação Detalhada da Entidade
•
Comunicação dos detalhes das modificações para todas as pessoas com
envolvimento relevante;
•
Procedimentos que identifiquem os responsáveis para a suspensão e
recuperação de mudanças no caso de insucesso.
8.1.3
Procedimentos para a Gestão de Incidentes
Para o caso de incidentes no âmbito da segurança (tentativas sem sucesso, falha num
componente de segurança, etc.) têm de ser estabelecidos procedimentos de modo a
garantir uma reacção apropriada ao incidente. As seguintes instruções tem de ser
consideradas:
•
Têm de ser criados planos de contingência para todos os incidentes relevantes
no âmbito da Segurança da Informação (falhas dos sistemas de informação e
serviços, ataques de Negação de Serviço, incidentes de vírus, erros resultantes
de dados incompletos ou inconsistentes, violação de confidencialidade);
•
Além dos planos de contingência, as causas para o incidente têm de ser
determinadas de modo que seja possível tomar medidas preventivas para evitar
futuros incidentes e informar as autoridades responsáveis;
•
Os registos de ocorrências e outras evidências têm de ser recolhidos e
mantidos em segurança. Estes são usados em análises internas dos problemas,
como prova legal ou para negociações de ressarcimento por perdas e danos;
•
Durante os procedimentos de recuperação e correcção de falhas do sistema
somente as pessoas explicitamente autorizadas têm acesso aos sistemas de
produção. As medidas aplicadas tem de ser documentadas e reportadas à
administração responsável. Após a administração verificar o funcionamento
do sistema, este tem de ser imediatamente aceite como funcional pela
administração e têm de ser terminados os procedimentos de recuperação.
8.1.4
Segregação de Funções
As responsabilidades têm de ser apropriadamente distribuídas de forma a eliminar as
oportunidades de modificações não autorizadas. Se não for possível uma separação,
têm de ser fornecidos outros tipos de controlo, como a monitorização pela
administração ou o registo das actividades. É importante que a auditoria da segurança
permaneça como uma actividade independente. A entidade que organiza um processo
de negócios tem de ser separada da entidade que o executa.
Deve ser garantido que as áreas, cuja responsabilidade seja apenas de uma pessoa, não
venham a ser alvo de fraudes que não possam ser detectadas. Para tal os seguintes
controlos devem ser considerados:
•
É importante segregar actividades que requeiram cumplicidade para a
concretização de uma fraude, por exemplo a emissão de um pedido de compra
e a confirmação do recebimento da compra.
Público
30
ENSI
Política de Segurança da Informação Detalhada da Entidade
•
Se existir o perigo de conluios, então é necessário o planeamento de controlos
de modo que duas ou mais pessoas necessitem estar envolvidas, diminuindo
assim a possibilidade de conspirações.
8.1.5
Separação dos Ambientes de Desenvolvimento e de
Produção
Para garantir um nível de serviço de alta qualidade para a gestão de alterações, tem de
se disponibilizar diversos ambientes de processamento. Os sistemas de
desenvolvimento, testes e aceitação e respectivos dados tem de estar separados dos
sistemas de produção.
•
A mudança da classificação de um software do estado de desenvolvimento
para o estado de produção tem estar claramente definida e documentada;
•
Tem de ser definida uma forma de separação apropriada entre sistemas com
diferentes funções;
•
As actividades de desenvolvimento, testes e produção têm de ser separadas,
idealmente com recurso a diferente hardware;
•
O acesso às ferramentas de desenvolvimento não é possível a partir dos
sistemas de produção e o uso de software de análise de problemas tem de ser
autorizado individualmente;
•
O controlo de acessos aos sistemas e aplicações com diferentes funções (por
exemplo, testes) tem de ser configurado de maneira diferente e de modo
evidente para o utilizador. Os utilizadores têm de ser incentivados a usar
diferentes senhas para sistemas e aplicações com diferentes funções;
•
O acesso da equipa de desenvolvimento aos sistemas de produção tem de ser
limitado ao período absolutamente necessário.
8.1.6
Outsourcing
Caso seja planeada a contratação de terceiros, todos os riscos associados têm de ser
identificados e têm de ser estabelecidos os mecanismos de controlo como parte do
contrato com o terceiro (ver também 4.2 e 4.3). A PSIE também deve ser aplicada
para os terceiros. Adicionalmente devem ser tomadas as seguintes medidas:
•
Identificação das aplicações críticas e sensíveis que devem continuar a operar
na entidade;
•
Obtenção da aprovação dos gestores ou responsáveis pelos processos e
sistemas;
•
Têm de ser consideradas as implicações nos planos de continuidade do
negócio;
•
Estabelecimento de normas de segurança e um processo de aferição de
conformidade a esses padrões;
Público
31
ENSI
Política de Segurança da Informação Detalhada da Entidade
•
Definição de procedimentos
responsabilidades;
•
Procedimentos e responsabilidades para reportar e gerir incidentes de
segurança.
8.2
de
monitorização
e
das
respectivas
Planeamento e Aceitação de Sistemas
O objectivo principal do planeamento é minimizar o risco de falhas nos sistemas.
8.2.1
Planeamento de Capacidade
É fundamental um planeamento proactivo para garantir que os recursos necessários
estão disponíveis. Tem de ser sempre possível executar todo o software de segurança
em paralelo.
8.2.2
Aceitação de Sistemas
Devem ser estabelecidos critérios de aceitação para os novos sistemas e aplicações de
TIC, actualizações e novas versões. Devem ser efectuados testes apropriados aos
sistemas antes da sua aceitação. Devem ser considerados os seguintes critérios de
aceitação:
•
Requisitos de desempenho e capacidade computacional;
•
Recuperação de erros, procedimentos de reinicialização e planos de
contingência;
•
Elaboração dos procedimentos operacionais e testes de acordo com o critério
de aceitação;
•
Concordância sobre o conjunto de controlos de segurança;
•
Procedimentos manuais eficazes;
•
Acções de continuidade de negócio (ver também 11.1);
•
Evidências de que a instalação do novo sistema não afectará de forma adversa
os sistemas e aplicações já existentes;
•
Evidências de que tenha sido considerado o impacto do novo sistema na
segurança da entidade como um todo;
•
Formação dos administradores e utilizadores na operação do novo sistema.
8.3
Protecção Contra Software Malicioso
Tem de ser sempre garantida a integridade do software, da informação e dos dados
utilizados.
Público
32
ENSI
Política de Segurança da Informação Detalhada da Entidade
Exemplos de software perigoso são os vírus de computador, vermes, “cavalos de
Tróia”, canais de comunicação encobertos e mecanismos escondidos de controlo
remoto como os utilizados para ataques de Negação de Serviço a terceiros. Devem ser
iniciadas pela administração de segurança medidas de prevenção à intrusão e de
descoberta do software perigoso actualmente disponíveis
8.3.1
Controlos Contra Software Malicioso
Devem ser implementados controlos para a detecção e prevenção de programas
maliciosos, assim como os procedimentos para a devida consciencialização dos
utilizadores. A protecção contra programas maliciosos deve ser baseada na
consciencialização de segurança, no controlo de acessos adequado e nos mecanismos
de gestão de alterações.
Devem ser considerados os seguintes controlos:
•
Tem de ser nomeada uma pessoa responsável pelos assuntos relacionados com
software malicioso;
•
Os utilizadores devem ser informados regularmente sobre as técnicas e riscos
associados ao uso de software perigoso;
•
A conformidade com as regulamentações de licenciamento de software deve
ser observada;
•
O uso de software não autorizado é proibido na entidade;
•
Uma política formal para protecção contra os riscos associados à importação
de ficheiros obtidos de, ou através de, redes externas ou por qualquer outro
meio, indicando quais as medidas preventivas que devem ser adoptadas;
•
Se possível, a instalação e actualização regular de programas de detecção e
remoção de vírus em todos os computadores e meios magnéticos. Devem ser
instaladas as últimas actualizações em intervalos regulares;
•
Os sistemas críticos têm de ser auditados em intervalos regulares;
•
O software não autorizado tem de ser removido e a sua origem determinada;
•
A verificação, antes do uso, da existência de software malicioso em todos os
ficheiros recebidos através de correio electrónico ou através de download;
•
Devem ser executadas verificações da existência de software maliciosos,
principalmente nos sistemas os mais expostos ao exterior, por exemplo, no
servidor de correio electrónico ou no firewall.
•
Tem de ser definidas as medidas e responsabilidades no caso de detecção de
software perigoso;
•
Têm de ser implementados procedimentos para a verificação de toda a
informação relacionada com programas maliciosos e garantia de que os alertas
Público
33
ENSI
Política de Segurança da Informação Detalhada da Entidade
sejam precisos e informativos. Os gestores devem garantir que sejam
utilizadas fontes qualificadas para diferenciar hoaxes de notícias reais de vírus,
como, por exemplo, jornais com reputação idónea, sites confiáveis ou
fornecedores de software antivírus. Os utilizadores devem estar capacitados a
lidar com hoaxes.
8.4
Salvaguarda
O objectivo principal da manutenção dos sistemas é manter a integridade e
disponibilidade dos sistemas e aplicações de TIC. Entre outros, incluem
procedimentos de salvaguarda regulares de dados (backups) e registos (logs) de erros
durante a operação.
8.4.1
Cópias de Segurança
As cópias dos dados (backups) devem ser realizadas automaticamente e regularmente
conforme definido no plano de continuidade de negócios. As seguintes especificações
têm de ser implementadas:
•
As cópias de segurança, juntamente com o controlo consistente e actualizado
dessas cópias e com a documentação dos procedimentos de recuperação, têm
de ser mantidos em local remoto e a uma distância suficiente para protegê-los
de qualquer dano que possa ocorrer na instalação principal;
•
As cópias de segurança têm de ter um nível adequado de protecção física e
ambiental, compatível com os padrões utilizados no ambiente principal;
•
O intervalo de tempo necessário para actualização das cópias de segurança
depende da importância e da velocidade de alteração do seu conteúdo;
•
No mínimo, têm de ser mantidas três gerações ou ciclos de cópias de
segurança dos dados das aplicações críticas;
•
O período de retenção dos dados (ver secção 12.1.3) tem de ser considerado;
•
Quando aplicável, os suportes físicos utilizados para as cópias devem ser
periodicamente testados de modo a garantir a sua fiabilidade. Um teste de
recuperação de uma parte significativa (nem sempre a mesma) dos dados tem
de ser executado pelo menos quatro vezes por ano, de modo a atender aos
requisitos do plano de continuidade (ver capítulo 11).
•
As recomendações de auditoria têm de ser implementadas sob a consideração
dos itens acima descritos;
•
As precauções formais de continuidade estão descritas no capítulo 11.
8.4.2
Registos de Operação
O registo das actividades de operação é obrigatório. No mínimo, devem ser registados
os seguintes dados:
Público
34
ENSI
Política de Segurança da Informação Detalhada da Entidade
•
Horário de início e fim de funcionamento dos sistemas de processamento;
•
Erros e acções correctivas adoptadas para a recuperação dos sistemas;
•
Identificação de quem está a efectuar a operação.
Os registos de operação devem estar sujeitos a verificações regulares e independentes
dos procedimentos de operação.
8.4.3
Registos de Falhas
Os erros reportados pelos utilizadores e as acções correctivas adoptadas devem ser
registados. Estes registos são verificados em revisões regulares de modo a garantir
que os erros foram corrigidos. As ocorrências no âmbito da segurança devem ser
reportadas imediatamente à Administração de Segurança.
8.5
Gestão de Redes
O objectivo da gestão de comunicações no âmbito da Segurança da Informação é
garantir a salvaguarda da informação na rede e a protecção da infra-estrutura de
suporte. Os seguintes passos são necessários:
•
A responsabilidade operacional da rede deve ser segregada da operação
computacional;
•
Devem ser definidos os procedimentos operacionais e as responsabilidades
para o equipamento que se encontre fora do Centro de Processamento de
Dados (CPD);
•
Têm de ser estabelecidos controlos para salvaguardar a confidencialidade e a
integridade dos dados transferidos pelas redes e proteger os respectivos
sistemas (ver 9.4 e 10.3). Também têm de ser implementados controlos
adequados para manter a disponibilidade dos serviços de rede e manutenção
dos dispositivos.
8.6
Manuseamento e Segurança de Meios de Suporte
É necessário prevenir danos dos activos (como dados críticos) e a consequente
interrupção das actividades da entidade. A gestão dos meios de suporte de dados tem
de ser implementada. Os meios de suporte de armazenamento, tais como disquete,
CD, DVD e discos rígidos, que contêm informação sensível, e documentos (listagem
de programas, etc.) têm de ser fisicamente protegidos.
8.6.1
Gestão dos Meios de Suporte Informáticos Removíveis
As seguintes linhas de orientação devem ser seguidas:
•
Se a informação já não é necessária, os meios de suporte só de leitura devem
ser destruídos; o conteúdo dos meios de suporte removíveis e que permitem a
reescrita tem de ser apagado antes de abandonar a entidade;
Público
35
ENSI
Política de Segurança da Informação Detalhada da Entidade
•
A remoção dos meios de suporte que contenham informação sensível tem de
ser autorizada e documentada pela autoridade competente (ver também 8.7.2);
•
Os meios de suportes devem ser mantidos num ambiente seguro;
•
As autorizações e sequências operacionais relacionadas com segurança devem
ser documentadas;
•
Antes dos meios de suporte dos dados serem novamente utilizados, os dados
têm de ser efectivamente apagados (ver 8.6.2 para mais detalhes);
•
Isto também se aplica ao seguimento de sistemas que contêm meios de suporte
de dados.
8.6.2
Destruição de Meios de Suporte
Relativamente à destruição de meios de suporte de dados, as seguintes orientações
devem ser seguidas:
•
Os meios de suporte de dados, que contenham informação sensível, têm de ser
destruídos com cuidado e profissionalmente. As opções são, por exemplo
queimar ou triturar. Por vezes é mais fácil destruir todos os meios de suporte
de forma segura do que identificar aqueles que realmente contêm informação
sensível. Deve ser ainda mencionado que uma grande quantidade de
informação não classificada pode potencialmente revelar informação sensível
devido à possibilidade de se efectuarem correlações dessa informação;
•
A destruição dos meios de suporte de dados deve ser registada;
•
Quando a destruição dos meios de suporte de dados é feita por companhias
externas, a regulamentação contratual que cobre a segurança dos dados deve
ser iniciada e controlada regularmente.
8.6.3
Procedimentos para o Manuseamento de Informação
A informação encontra-se dispersa por muitos lugares diferentes por toda a entidade.
A informação crítica da entidade pode estar contida, por exemplo em documentos,
sistemas informáticos, redes, computadores móveis, rádio portáteis, agendas
electrónicas, telefones, cartas, pacotes e dispositivos de fax. De modo a prevenir o uso
abusivo ou o acesso não autorizado a essa informação, as seguintes medidas para o
manuseamento da informação devem ser introduzidas:
•
A informação deve ser sempre tratada de acordo com a sua classificação
(ver 5.2);
•
Os meios de suporte de dados removíveis devem ser marcados (ver
também 5.2.2) a não ser que haja um sistema que garanta que estes não
possam ser reescritos, revelados ou removidos erroneamente – mesmo
num ponto no futuro;
•
A manutenção de um registo formal da recepção dos dados;
Público
36
ENSI
Política de Segurança da Informação Detalhada da Entidade
•
A verificação da autorização para a recepção dos dados;
•
A garantia de comprovativos de entrega aquando do envio de informação
sensível;
•
Sempre que possível, deve se garantir que os dados introduzidos e os
dados extraídos estão completos;
•
Dados em filas (ex. num servidor de impressão) devem ser protegidos de
acordo com a sua classificação;
•
Armazenamento seguro e profissional dos meios de suporte de dados;
•
A duplicação e distribuição de dados deve ser restringida;
•
Identificação clara dos destinatários e revisão regular das mailing lists.
8.6.4
Segurança da Documentação do Sistema
Como os sistemas de documentação pertencentes à entidade normalmente contêm
informação sensível, devem ser introduzidas as seguintes precauções de segurança:
•
Os sistemas de documentação devem ser mantidos em local seguro;
•
O acesso ao sistema de documentação deve ser o mínimo e sempre
autorizado pelo proprietário da aplicação;
•
O sistema de documentação, que se encontre ou interaja com uma rede
pública, deverá ser protegido adequadamente.
8.7
Trocas de Informação e Software
A perda, modificação e uso abusivo da informação devem ser prevenidos durante a
troca de informação entre a entidade e outras organizações. A troca de dados deve ser
executada com base em acordos especificados. A troca de informação e software entre
organizações deve ser controlada e estar em conformidade com todas as leis
aplicáveis e orientações da entidade.
8.7.1
Acordos para Troca de Informação e Software
Antes da informação ser trocada, devem ser definidas declarações e acordos que
tenham em conta a sensibilidade dos dados a serem trocados com outras organizações.
Isto contém em particular:
•
A implementação de um método para identificar o envio, transferência e
recepção de informação (procedimentos de reporting);
•
Definição de normas para o encapsulamento, transferência, gravação e
leitura da informação, bem como uma identificação adequada do sistema
responsável pela entrega;
Público
37
ENSI
Política de Segurança da Informação Detalhada da Entidade
•
Definição de responsabilidades e obrigações no caso de perda de dados;
•
Colocação dos rótulos relativos à classificação da informação sensível (de
acordo com 5.2.2);
•
Protecção da informação durante a troca, de acordo com a classificação;
•
Clarificação da propriedade e responsabilidades referentes aos dados bem
como o cumprimento das regulações de direitos de cópia de software (ver
também 12.1.2 e 12.1.4);
•
Precauções extra de segurança para a troca de dados altamente sensíveis
como por exemplo dados cifrados.
8.7.2
Segurança dos Meios de Suporte em Trânsito
Devem ser seguidos os seguintes passos para o transporte dos meios de suporte:
•
Deve ser utilizado transporte fiável ou serviços de mensageiro. Deve ser
acordada com a gestão uma lista de mensageiros aprovados e ser
implementado um procedimento para a identificação dos mensageiros;
•
Deve ser efectuado o empacotamento adequado, de acordo com as
instruções do fabricante, de modo a proteger contra danos físicos;
•
A informação sensível deve ser protegida com medidas adequadas, como
recipientes passíveis de serem fechados e/ou transferência pessoal.
8.7.3
Segurança do Comércio Electrónico
Um conjunto de riscos está associado ao comércio electrónico como actividades
fraudulentas, disputas sobre a validade dos contratos bem como exposição ou
modificação não autorizada de informação. De modo a cobrir esses riscos, têm de ser
implementadas precauções de segurança, cobrindo no mínimo, as seguintes áreas:
•
Autenticação;
•
Autorização;
•
Processos de contrato e fornecimento;
•
Informação de preços;
•
Encomendas;
•
Verificação das especificações e detalhes do cliente;
•
Métodos de pagamento;
•
Responsabilidade.
Público
38
ENSI
Política de Segurança da Informação Detalhada da Entidade
Muitas das necessidades das áreas enumeradas acima podem ser satisfeitas por
métodos criptográficos (ver também 10.3). Os aspectos legais também têm de ser
considerados (ver 12.1, em particular 12.1.6) e tem de ser especificada uma política
separada para os sistemas de Comércio Electrónico com orientações de segurança
válidas para os sistemas em causa.
8.7.4
Segurança do Correio Electrónico
Para a troca de mensagens via correio electrónico, devem ser considerados os
seguintes riscos:
•
Acesso não autorizado de leitura ou escrita de mensagens;
•
Falso endereçamento ou encaminhamento de mensagens;
•
Baixa fiabilidade e/ou disponibilidade do serviço de correio electrónico
(ex. devido a ataques de Negação de Serviço);
•
Efeitos nos processos de negócio (ex. por troca de dados mais rápida ou
comunicação directa entre pessoas ao invés de entidades);
•
Considerações legais, tais como a necessidade potencial de prova de
origem, despacho, entrega e aceitação;
•
Efeitos da publicação da lista de empregados;
•
Acesso ao sistema de correio electrónico da entidade por utilizadores
externos;
•
Responsabilidade da entidade por mensagens difamatórias enviadas de
fora da companhia.
As orientações de segurança para o correio electrónico têm de ser definidas num
manual em separado. Este deve conter, no mínimo, os seguintes regulamentos:
•
Protecção contra ataques a mensagens de correio electrónico (ex. por vírus
ou intercepção das mensagens);
•
Protecção dos anexos das mensagens;
•
Orientações sobre quando não utilizar o correio electrónico;
•
Responsabilidade dos utilizadores sobre o conteúdo das mensagens por
eles escritas;
•
Utilização de métodos de criptografia para proteger a privacidade e a
integridade das mensagens de correio electrónico (ver também 10.3);
•
Armazenamento e registo das mensagens de correio electrónico
considerando que estas podem ser descobertas durante um litígio;
Público
39
ENSI
Política de Segurança da Informação Detalhada da Entidade
•
Reencaminhamento de correio electrónico para sistemas externos (ex.
contas privadas).
8.7.5
Segurança dos Sistemas de Escritório Electrónico
Um sistema de escritório electrónico resulta geralmente da integração de diferentes
componentes tais como documentos, computadores, correio electrónico, fax, etc. Para
proteger esses sistemas, os seguintes pontos devem ser considerados:
•
Protecção contra o uso abusivo e modificação da informação nos sistemas
electrónicos no local de trabalho, por exemplo gravação ilegal de
chamadas telefónicas;
•
Orientações e medidas para a utilização comum da informação, por
exemplo boletins electrónicos corporativos e sistemas de ficheiros;
•
Proibição do uso de informação sensível nos sistemas electrónicos do
escritório caso esses sistemas não ofereçam protecção suficiente;
•
Controlo de acessos;
•
Acesso a calendários e diários centralizados (ex. para coordenação on-line
de datas);
•
Protecção e armazenamento de dados (ver também 12.1.3 e 8.4.1);
•
Lista de discos lógicos do servidor;
•
Procedimentos de contingência (ver 11.1).
8.7.6
Sistemas Disponíveis ao Público
A modificação não autorizada de conteúdos em sistemas públicos (ex. servidores
Web) tem de ser prevenida:
•
Se os dados são recolhidas nesses sistemas, por exemplo pela entrada de
dados directa do utilizador, tem de ser garantido que o armazenamento
dessa informação respeita os respectivos regulamentos legais (ver 12.1.4);
•
O conteúdo dos dados sensíveis tem de ser apropriadamente protegido
durante a entrada de dados pelo utilizador, durante o transporte, bem como
depois do armazenamento no sistema;
•
Tem de ser garantida a impossibilidade de penetração noutros sistemas
utilizando o acesso público.
Os conteúdos dos dados devem ser verificados antes da publicação pelo proprietário
dos dados tendo em conta os critérios legais e corporativos (ver 5.2). O proprietário é
responsável pela informação e pelo seu uso consistente e deve instruir o pessoal
responsável pelo servidor para qualquer circunstância especial.
Público
40
ENSI
Política de Segurança da Informação Detalhada da Entidade
8.7.7
Outras Formas de Troca de Informação
Mesmo com outros tipos de troca de dados (ex. fax, telefone, vídeo conferência), tem
de ser garantida a segurança da entidade tanto pela disponibilização de informação
aos empregados como pela criação de mecanismos de protecção adequados. Devem
ser implementadas as seguintes medidas:
•
Disponibilização de informação aos empregados e consciencialização de
uma cultura de segurança apropriada. Por exemplo, ao marcar
inadvertidamente um número errado de fax, documentos sensíveis podem
ir parar nas mãos erradas;
•
Informação aos empregados sobre as armadilhas e riscos existentes
enquanto utilizam dispositivos para troca de informação (possibilidades de
espionagem, armazenamento de mensagens);
•
Verificação ou retorno de chamada se a outra pessoa não é conhecida ou
reconhecida.
Público
41
ENSI
Política de Segurança da Informação Detalhada da Entidade
9 Controlo de Acessos
9.1
Requisitos de Negócio para Controlo de Acessos
As necessidades da entidade, relativamente ao controlo de acessos, têm de ser
definidas, documentadas e publicadas. As regras e direitos do controlo de acessos para
cada utilizador ou grupo de utilizadores têm de estar descritas de um modo claro na
declaração das políticas de acesso. Consequentemente, o acesso aos activos de
informação da entidade tem de estar limitado. A política deve ter em conta:
•
Requisitos de segurança de aplicações individuais de negócio;
•
Políticas de disseminação bem como de classificação da informação e a
implementação de níveis de segurança;
•
Perfis padrão de acesso para utilizadores e grupos de utilizadores específicos;
•
Estabelecimento de regras baseado na premissa “Negar tudo a não ser que
explicitamente permitido”.
Os utilizadores e fornecedores de serviços devem receber uma declaração clara dos
requisitos de negócio a serem respeitados pelos controlos de acesso.
9.2
Gestão de Acesso dos Utilizadores
É necessário prevenir o possível acesso não autorizado aos sistemas de informação da
entidade. Devem estar implementados procedimentos formais que cubram todas as
fases do ciclo de vida do acesso do utilizador, desde o registo inicial de novos
utilizadores até à remoção de utilizadores que já não necessitam de acesso aos
serviços e sistemas de informação. Os direitos de acesso de cada utilizador aos
sistemas ou dados devem estar explicitamente documentados.
9.2.1
Registo de Utilizadores
Deve existir um procedimento formal de registo e remoção de utilizadores para
garantir o acesso a todos os serviços e sistemas de informação. O processo formal de
registo de um utilizador deve incluir:
•
A utilização de ID único para cada utilizador do sistema. A utilização de IDs
para grupos tem de ser aprovada pela equipa de segurança de TIC (ver 9.5.3);
•
A verificação de que o utilizador tem autorização do proprietário do sistema
para utilização do serviço ou sistema de informação. A aprovação separada
dos direitos de acesso pela gestão pode ser apropriada;
•
A verificação periódica e remoção imediata de direitos de acesso e IDs de
utilizadores redundantes. Garantia de que os IDs de utilizadores redundantes
não são tornados públicos a, ou encontrados por, outros utilizadores;
Público
42
ENSI
Política de Segurança da Informação Detalhada da Entidade
•
As contas de utilizador padrão incluídas nos sistemas por defeito (ex. guest,
administrator, root) devem ser renomeadas e bloqueadas imediatamente. Se a
renomeação não é apropriada, a conta deve ser protegida por uma senha
cifrada forte;
•
A manutenção de um registo formal de todas as pessoas registadas para
utilizar o serviço.
9.2.2
Gestão de Privilégios
Os privilégios apenas devem ser concedidos à medida que o utilizador tenha
necessidade de utilizar os recursos, por exemplo devem ser satisfeitos os requisitos
mínimos para o seu papel funcional e atribuir privilégios adicionais apenas quando
necessário. Deve ser mantido um registo de todos os privilégios concedidos e do
processo de autorização. Deve ser reforçado o desenvolvimento e utilização de rotinas
de sistema que evitem a necessidade de garantir privilégios de sistema a utilizadores.
Os privilégios devem ser concedidos a um ID de utilizador diferente do utilizado
habitualmente para o para o negócio.
9.2.3
Gestão de Senhas de Utilizador
A distribuição de senhas deve ser controlada através de um processo de gestão formal
(identificação e verificação da autoridade do utilizador, geração segura da senha
inicial, transmissão segura ao utilizador).
O sistema deve forçar o utilizador a mudar a sua senha inicial para uma senha pessoal
segura. Além disso, o utilizador deve ser forçado a alterar a sua senha pelo menos seis
vezes por ano. O tempo entre mudanças não deve exceder os dois meses. Os
utilizadores devem seguir boas práticas de segurança na selecção e utilização das
senhas.
As senhas devem:
•
Não possuir sequências consecutivas de caracteres idênticos ou grupos só
numéricos ou alfabéticos;
•
Não ser baseadas em algo facilmente descoberto por terceiros ou obtido
através de informação pessoal, ex. nomes, números de telefone, datas de
nascimento, etc;
•
Devem conter caracteres especiais (ex.! / % ? $ &);
•
Não ter menos de 8 caracteres de comprimento;
•
Não ser reutilizada com um formato semelhante (ex. senha1! e senha2!);
Devem ser desenhadas linhas de orientação formais. Podem ser vistos exemplos de
orientações no guia de Segurança de Informação para o Cidadão. Os dados referentes
às senhas devem estar cifrados com um algoritmo irreversível e armazenados
separadamente das aplicações.
Público
43
ENSI
Política de Segurança da Informação Detalhada da Entidade
9.2.4
Revisão dos Direitos de Acesso dos Utilizadores
Para manter um controlo efectivo sobre o acesso aos dados e serviços de informação,
deve existir um processo formal que garanta que são efectuadas revisões periódicas
aos direitos dos utilizadores. Os direitos dos utilizadores devem estar documentados e
armazenados centralmente.
Os direitos de acesso dos utilizadores devem ser revistos numa base regular e,
principalmente, após qualquer mudança efectuada. Os privilégios concedidos devem
ser tratados do mesmo modo (pelo menos a cada seis meses).
As autorizações de direitos de acesso especiais devem ser revistas mais
frequentemente. O recomendado é um período de três meses.
9.3
Responsabilidades dos Utilizadores
Deve ser prevenido o acesso de utilizadores não autorizados. Os utilizadores devem
ter consciência das suas responsabilidades na manutenção de controlos efectivos de
acesso, particularmente no que diz respeito à utilização da sua senha e à segurança do
seu equipamento.
9.3.1
Utilização de Senhas
As senhas devem ser mantidas confidenciais. Não devem ser comunicadas a
Administradores de Sistema ou outro pessoal de Help Desk. Deve ser evitada a
existência de um registo em papel da senha. As senhas devem ser alteradas sempre
que haja uma indicação de um possível comprometimento do sistema ou senha, e não
devem estar incluídas num processo automático de logon, ex. guardadas numa macro.
As senhas temporárias têm de ser alteradas no primeiro logon. As senhas individuais
dos utilizadores não devem ser partilhadas.
9.3.2
Protecção de Equipamento Não Vigiado
Os utilizadores devem garantir que o equipamento não vigiado tem uma protecção
adequada. Os postos de trabalho e servidores de ficheiros requerem um nível mínimo
de protecção, ex. protectores de ecrã protegidos com senha, key lock ou senha de
BIOS. As sessões activas devem ser terminadas quando o trabalho é terminado. Se
possível, as salas de trabalho devem ser trancadas quando não estão ocupadas.
9.4
Controlo de Acesso de Rede
O acesso aos serviços internos e externos de rede têm de ser controlados.
9.4.1
Políticas na Utilização dos Serviços de Rede
Só devem ser concedidos acessos directos aos serviços aos utilizadores
especificamente autorizados. As ligações não seguras aos serviços de rede podem ter
um impacto negativo nas operações de negócio da entidade. Devem ter especial
atenção as ligações de rede às aplicações sensíveis ou críticas para o negócio. Devem
ser definidos procedimentos de autorização para determinar quem está autorizado a
Público
44
ENSI
Política de Segurança da Informação Detalhada da Entidade
aceder a que redes e serviços. Esta política deve ser consistente com a política de
controlo de acessos do negócio (ver 9.1)
9.4.2
Utilização de Caminhos Predefinidos
As redes são desenhadas de forma a maximizar o âmbito da partilha de recursos e
flexibilidade de caminhos de comunicação. Essas funcionalidades também
disponibilizam oportunidades para o acesso não autorizado a aplicações do negócio,
ou utilização não autorizada das instalações. O caminho do terminal/cliente ao serviço
do computador/servidor precisa de ser controlado. Tem de ser implementado um
caminho predefinido para prevenir que um utilizador seleccione rotas fora do caminho
esperado entre o terminal do utilizador e os serviços que o utilizador está autorizado a
aceder. As possibilidades para proteger o acesso são:
•
Uso de linhas ou números de telefone dedicados;
•
Uso de métodos fortes de autorização de utilizadores, por exemplo senhas oneway ou controlos de acesso biométricos;
•
Uso de sistemas aplicacionais específicos e/ou gateways de segurança;
•
Controlo activo dos caminhos e acessos de comunicação permitidos através de
gateways de segurança, ex. firewalls;
•
Limitação do acesso à rede ao configurar diferentes domínios lógicos, por
exemplo redes privadas virtuais para grupos de utilizadores (ver 9.4.6).
9.4.3
Autenticação de Utilizadores para Ligações Externas
As ligações externas representam um potencial acesso não autorizado à informação de
negócio da entidade. Consequentemente, o acesso remoto de utilizadores deve ser
sujeito à autenticação. É importante determinar o nível de protecção necessário, para
tal podemos recorrer a uma análise de risco.
A autenticação de utilizadores remotos pode ser efectuada utilizando:
•
Serviços de Firewall;
•
Técnicas criptográficas;
•
Senhas one-way, geradas através da utilização de hardware ou software
especifico;
•
Protocolos de Desafio/Resposta;
•
Linhas privadas dedicadas;
•
Controlos e procedimentos de dial-back;
•
Técnicas biométricas, ex. impressões digitais;
Público
45
ENSI
Política de Segurança da Informação Detalhada da Entidade
•
Smart cards
•
Utilização de sub-redes lógicas protegidas (virtual private network – VPN)
9.4.4
Autenticação do Nó
Uma infra-estrutura de acesso remoto tem associado um risco de acesso não
autorizado a aplicações de negócio da entidade. Uma ligação automática a um nó de
rede, que esteja fora do controlo da gestão de segurança da entidade, só deve ser
permitida através de linhas dedicadas. Alternativamente, a utilização de ligações
remotas com certificação segura (ex. IPSEC via uma infra-estrutura de chaves
públicas – PKI Public Key Infrastructure) pode ser aceitável.
9.4.5
Acesso Para Gestão Remota
Muitos computadores e sistemas de comunicação são instalados com uma infraestrutura de manutenção remota por dial-up que é utilizada pelos engenheiros de
manutenção. O acesso aos pontos de manutenção deve ser controlado. Se eles
estiverem desprotegidos, disponibilizam um modo de obter acesso não autorizado. Os
pontos de diagnóstico devem estar protegidos por mecanismos de segurança
adequados, por exemplo uma fechadura e um procedimento que garante que eles
apenas estão acessíveis através de um acordo entre o fornecedor do serviço do
computador e o pessoal de suporte que requer o acesso.
9.4.6
Segregação das Redes
Com a utilização da Internet e com os alguns requisitos de parceiros de negócio as
redes estão a assumir uma maior dimensão e a interligação ou partilha de
processamento de informação e infra-estruturas de rede é crescente. Tais dimensões
aumentam o risco de acesso não autorizado a sistemas de informação já existentes e
que utilizam a rede.
Para controlar a segurança de redes de grande dimensão, elas devem ser divididas em
domínios lógicos de rede separados, ex. um domínio da rede interna da organização e
vários domínios de rede externos, cada um protegido por parâmetros de segurança
definidos. Isso deve ser implementados a partir da instalação de um gateway seguro
entre os dois domínios de rede. Este gateway (ex. firewall) deve ser configurado para
filtrar o tráfico entre esses domínios e para bloquear o acesso não autorizado de
acordo com a política de controlo de acessos da entidade.
9.4.7
Controlo de Acesso às Redes
Os requisitos das políticas de controlo de acesso de redes partilhadas, especialmente
aqueles que ocorrem para além das fronteiras da organização, requerem a
implementação de controlos para restringir a capacidade de ligação dos utilizadores.
Esses controlos podem ser implementados a partir de gateways de redes (ex.
firewalls) que filtram o tráfego através de tabelas ou regras predefinidas. Exemplos de
serviços de rede para os quais as restrições devem ser aplicadas são:
•
Correio electrónico;
Público
46
ENSI
Política de Segurança da Informação Detalhada da Entidade
•
Transferência de ficheiros (ex. FTP, HTTP);
•
Acesso remoto a servidores (ex. utilizando Telnet, Remote Access Software);
•
Acesso de rede associado à hora do dia ou data;
9.4.8
Controlo de Rotas Internas
As redes partilhadas, especialmente aquelas que atravessam as fronteiras
organizacionais, devem ser separadas umas das outras com mecanismos apropriados.
O isolamento de rede é atingido com o uso de sistemas de rede dedicados (ver 9.4.6)
bem como com controlos de rotas e tradução de endereços de rede (NAT). O
spanning de acesso de rede é apenas permitido a utilizadores e sistemas com
autorização especial. O controlo de rede é implementado pelo uso de soluções de
software e hardware.
9.4.9
Segurança dos Serviços de Rede
Os serviços de rede da entidade (ex. HTTP, correio electrónico) devem ter
características de segurança únicas e complexas. É necessária uma descrição clara dos
atributos de segurança de todos os serviços utilizados pela entidade. Esta
documentação tem de ser classificada como “sensível” (ver classificação em 5.2).
9.5
Controlo de Acessos ao Sistema Operativo
Devem ser utilizadas infra-estruturas de segurança ao nível do sistema operativo para
restringir ou prevenir o acesso não autorizado a computadores.
9.5.1
Identificação Automática de um Terminal
A identificação automática de um terminal é uma técnica que pode ser utilizada se é
importante que a sessão só possa ser iniciada de um determinado local ou terminal de
computador. Um identificador que está no terminal, ou ligado a este, pode ser
utilizado para indicar se este terminal particular tem permissão para iniciar ou receber
transacções específicas. Sempre que possível, esta técnica deve ser utilizada. É
preferível a utilização de certificados digitais para identificar o terminal/cliente.
9.5.2
Procedimentos de Logon em Sistemas
O procedimento para logon num computador deve ser desenhado para minimizar a
oportunidade de acesso não autorizado. O procedimento de logon deve
consequentemente dar o mínimo de informação sobre o sistema, de modo a evitar
fornecer a um utilizador não autorizado informação desnecessária. O procedimento de
logon deve seguir as seguintes linhas de orientação:
•
Os sistemas não devem mostrar identificadores do sistema ou aplicação
enquanto o processo de logon não tiver sido completado com sucesso;
•
Nunca mostrar a senha em texto em claro enquanto esta está a ser introduzida;
Público
47
ENSI
Política de Segurança da Informação Detalhada da Entidade
•
Nunca fornecer informação de ajuda durante o procedimento de logon que
possa dar assistência a um utilizador não autorizado;
•
Mostrar um aviso que indique que o acesso é restrito a utilizadores
autorizados;
•
Validar a informação de logon só depois de completa toda a informação de
entrada. Se ocorrer um erro, o sistema nunca deve indicar qual a parte da
informação que estava correcta ou incorrecta;
•
Limitar o número de tentativas de logon mal sucedidos a três. Gravar todas as
tentativas de acesso mal sucedido. Forçar um intervalo de tempo no qual
novas tentativas não são permitidas e desligar a ligação à rede;
•
Limitar o tempo máximo e mínimo permitido para a operação de logon. Se
esse intervalo for ultrapassado, o sistema deve terminar o logon, do mesmo
modo quando o processo é demasiado rápido, o que acontece normalmente
quando é utilizada uma ferramenta para adivinhar senhas;
•
Mostrar no logon bem sucedido, informação sobre a data e hora do último
logon bem sucedido bem como os detalhes de qualquer logon mal sucedido
desde o último logon bem sucedido.
9.5.3
Identificação e Autenticação do Utilizador
Todos os utilizadores têm de ter e utilizar um identificador único (ID de utilizador)
(ver 9.2.1).Os IDs de utilizador não podem dar qualquer tipo de informação sobre o
nível de privilégios do utilizador, ex. gestor, administrador. Em circunstâncias
excepcionais, pode ocorrer a utilização de um ID de um utilizador partilhado por um
grupo de utilizadores ou por um trabalho específico. A aprovação pela gestão de
Segurança de TIC deve estar documentada em tais casos (ver 9.2.1).
Existem vários mecanismos de autenticação possíveis. Senhas, métodos
criptografia, protocolos de autenticação, tokens de memória, smart cards
autenticação biométrica são permitidos. Uma combinação de tecnologias
mecanismos ligados de modo seguro resulta numa autenticação mais forte.
possível, deveria ser evitada a autenticação apenas por senha.
9.5.4
de
ou
e
Se
Sistema de Gestão de Senhas
As senhas são um dos principais meios de validação da autoridade de um utilizador
para aceder ao serviço de um computador. Deve ser implementado um sistema de
gestão de senhas para garantir a qualidade das senhas e disponibilizar um audit trail
para a manutenção de senhas. O acesso ao sistema de gestão de senhas só é permitido
a um pequeno grupo de pessoas. Os requisitos da secção 9.2.3 têm de ser cumpridos.
9.5.5
Utilização de Utilitários de Sistema
Os programas utilitários de sistema (gestor de utilizador, gestor de processos) podem
ser capazes de alterar ou contornar os controlos de sistema e aplicacionais. É essencial
Público
48
ENSI
Política de Segurança da Informação Detalhada da Entidade
que o seu uso seja restrito e cuidadosamente controlado. Têm de ser implementados
os seguintes controlos:
•
Utilização de procedimentos de autenticação para os utilitários de sistema (ex.
limite por utilizador);
•
Segregação de utilitários de sistema de software aplicacional;
•
Limitação do uso de utilitários de sistema aos administradores de sistema;
•
Registo de toda a utilização de utilitários de sistema;
•
Restrição da janela de tempo durante a qual um utilitário de sistema pode ser
utilizado;
•
Definição e documentação dos níveis de autenticação para os utilitários de
sistema;
•
Remoção de todos os utilitários e softwares de sistemas desnecessários.
9.5.6
Alarme de Coacção para Protecção dos Utilizadores
Tem de ser implementado um alarme de coacção para aplicações de alta segurança ou
para utilizadores que possam ser alvo de coacção, seguindo uma prévia análise de
risco.
9.5.7
Time-out de um Terminal
Os terminais inactivos devem ser desligar depois de um período de inactividade
definido para prevenir o acesso por pessoas não autorizadas. O mecanismo de timeout deve limpar o ecrã do terminal e fechar as sessões de aplicações e rede depois de
um período de inactividade definido, se permitido pelo sistema operativo.
9.5.8
Limitação do Tempo de Ligação
Em locais de alto risco, ex. áreas públicas ou externas, o período durante o qual as
ligações do terminal a serviços de computadores devem ser limitadas. Isto é alcançado
através da restrição da duração máxima de uma ligação ou de acordo com
determinada hora do dia.
9.6
Controlo de Acesso às Aplicações
O acesso a software e informação críticos tem de ser restrito a utilizadores
autorizados. O acesso a aplicações críticas tem de ser controlado na rede, no front end
(ex. Single-Sign-On, Sistema de Controlo de Acessos, Menu de Acesso) e na
aplicação. A sensibilidade do sistema aplicacional tem de ser explicitamente
identificada e documentada pelo proprietário da aplicação (ver 5.1).
Público
49
ENSI
Política de Segurança da Informação Detalhada da Entidade
9.7
Monitorização da Utilização e Acesso ao Sistema
Os sistemas têm de ser monitorizados para detectar desvios face à política de controlo
de acessos (ver 9.1) e gravar eventos monitorizáveis para fornecer evidência no caso
de existirem incidentes de segurança.
9.7.1
Registo de Eventos
Para suportar investigações futuras e monitorização de controlo de acessos, têm de ser
produzidos e mantidos os registos de ocorrência de excepções e outros eventos de
segurança relevantes por um período acordado. Os registos de ocorrência devem
incluir:
•
IDs de utilizador;
•
Datas e horas de logon e logoff;
•
Identificação do terminal ou localização, se possível;
•
Registo das tentativas, bem e mal sucedidas, de acesso ao sistema, dados e
outros recursos.
9.7.2
Utilização do Sistema de Monitorização
Devem ser consideradas as seguintes áreas na monitorização da utilização das infraestruturas de processamento de informação:
•
A monitorização deve respeitar a regulação (ex. a Legislação do Trabalho) se
necessário;
•
A monitorização deve incluir acesso autorizado, operações privilegiadas,
tentativas de acesso não autorizado e alertas e falhas de sistema;
•
A frequência da revisão deve depender apenas dos riscos envolvidos;
•
O mecanismo de registo tem de ser seguro e não permitir alterações de
entradas de registo;
•
Os controlos devem proteger contra problemas operacionais, incluindo a
desactivação do mecanismo de registo;
•
As pessoas que revêem o registo devem ser diferentes daquelas cujas
actividades estão a ser monitorizadas.
9.7.3
Sincronização do Relógio
É importante a correcta configuração dos relógios do computador para assegurar a
precisão dos registos de ocorrência (hora e data) que podem ser necessário para
investigações. Consequentemente é necessária uma sincronização automática,
nomeadamente um processo que verifica e corrige a hora em todos os sistemas. Os
Público
50
ENSI
Política de Segurança da Informação Detalhada da Entidade
relógios sincronizados são também necessários para a sincronização segura de dados
numa rede.
9.8
Computação Móvel e Tele-trabalho
Quando o trabalho é remoto, ex. fora das instalações da entidade, os riscos de
trabalhar num ambiente desprotegido devem ser considerados e a protecção adequada
aplicada. A protecção do acesso à rede também tem de ser considerada (ver 9.4.3).
9.8.1
Computação Móvel
Para garantir que a informação de negócio não é comprometida, devem ser tidos
cuidados especiais quando são utilizados dispositivos remotos, ex. notebooks,
palmtops, portáteis e telemóveis. As medidas necessárias são:
•
As infra-estruturas de computação remota devem estar fisicamente protegidas
contra o roubo; se não forem supervisionadas pelo utilizador remoto, devem
estar trancadas;
•
A protecção contra acesso não autorizado através do uso de senhas e técnicas
criptográficas para os suportes de dados;
•
Utilização da protecção contra vírus mais recentes;
•
Execução regular de cópias de segurança;
•
Criação de uma consciencialização sobre as áreas de segurança relevantes aos
utilizadores das infra-estruturas remotas;
•
Estabelecimento de regras e conselhos sobre a ligação de equipamentos
móveis às redes e orientação sobre o uso desses equipamentos em lugares
públicos.
A utilização de infra-estruturas remotas é uma excepção e tem de ser aprovada pela
gestão.
9.8.2
Tele-trabalho
O tele-trabalho tem de ser autorizado e controlado pela gestão, e têm de existir
acordos adequados para este modo de trabalho. Devem ser considerados os seguintes
acordos de segurança:
A segurança física existente do local de tele-trabalho deve ter em conta a segurança
física do edifício e do ambiente envolvente (ver 7.1);
•
Controlos referentes aos acessos externos aos sistemas internos da entidade
(ver 9.4.3);
•
Regras e orientações para o acesso de familiares e visitantes ao equipamento e
informação;
Público
51
ENSI
Política de Segurança da Informação Detalhada da Entidade
•
Procedimentos de cópias de segurança e continuidade do negócio;
•
A disponibilização de suporte e manutenção do hardware e software;
•
Monitorização de ocorrências e segurança.
Público
52
ENSI
Política de Segurança da Informação Detalhada da Entidade
10 Desenvolvimento e Manutenção de
Sistemas
Inicialmente, os requisitos do capítulo 10 foram desenvolvidos apenas para orientação
dos sistemas desenvolvidos pela entidade. Contudo, o seu cumprimento é também
recomendado a todos os fornecedores de software.
10.1 Requisitos de Segurança dos Sistemas
Os sistemas de informação e aplicações têm de incluir mecanismos de segurança. A
infra-estrutura, aplicações de negócio e desenvolvimento local por utilizadores
individuais têm de estar igualmente cobertos. Os requisitos de segurança têm de ser
fundamentados, definidos e documentados antes do desenvolvimento de uma
aplicação. As especificações dos sistemas têm de considerar a implementação de
controlos automatizados e o suporte a controlos manuais. Quando forem utilizados
sistemas e aplicações comerciais, aqueles que foram testados e certificados a nível de
segurança têm de ser preferidos.
Os requisitos e controlos de segurança têm de estar adequados à importância, para o
negócio, dos activos de informação envolvidos e ao dano potencial ao negócio, que
pode ser um resultado da falha ou da ausência de segurança. A metodologia para se
analisar os requisitos de segurança e identificar os controlos que os satisfazem
encontra-se na análise e gestão de risco.
10.2 Segurança nos Sistemas Aplicacionais
É necessário prevenir a perda, modificação ou uso incorrecto de dados do utilizador
em sistemas aplicacionais. Medidas de controlo apropriadas, opções de auditoria ou
registo de actividades têm de ser implementadas no processo de desenho das
aplicações. A protecção de ficheiros da aplicação ou de programas está descrita no
capítulo 10.4.1.
A aplicação tem de controlar, entre outros, a entrada de dados, os processos internos e
a saída de dados. As seguintes medidas gerais têm de ser tomadas em todas as áreas:
•
Determinação automática de permissão para alteração dos dados;
•
Validação dos dados introduzidos, tratados ou produzidos;
•
Definição de procedimentos para os casos em que as discrepâncias não
estejam a ser cobertas por verificações manuais.
Para áreas sensíveis, requisitos adicionais de segurança têm de ser tidos em conta e as
medidas correspondentes tornam-se necessárias. Estes têm de determinados nos
processos de análise de risco.
Público
53
ENSI
Política de Segurança da Informação Detalhada da Entidade
10.2.1
Validação de Dados de Entrada
Os dados de entrada dos sistemas aplicacionais (nomes, endereços, números de
cliente) têm de ser validados para garantir a sua correcção.
Para efectuar essa validação, os seguintes controlos adicionais são introduzidos:
•
Validação dos dados durante a entrada (ex. caracteres inválidos nos campos de
dados, valores fora dos limites aceitáveis, dados ausentes ou incompletos);
•
Revisões periódicas do conteúdo dos campos chave e ficheiros de dados
importantes para assegurar sua validade e integridade.
10.2.2
Controlos de Validação dos Processos Internos
Dados que foram introduzidos correctamente podem ser corrompidos por erros de
processamento ou através de acções intencionais. Mecanismos de validação têm de
ser incorporados no sistema para detectar tais corrupções, de modo a reduzir o risco
de falhas de processamento que possam levar à perda da integridade.
As seguintes medidas a serem implementadas incluem:
•
O processamento de dados deve usar funções separadas e encapsuladas (ex.
macros, funções, objectos de programas), que devem ser o mais restritos
possíveis e com funcionalidades de detecção de erros;
•
Teste de conformidade com uma correcta sequência de procedimentos
(especialmente, em caso de existência de erros);
•
Fornecimento de rotinas de recuperação, que restaurem um correcto e
consistente estado dos dados após um erro de processamento;
•
Controlos batch e de sessão;
•
Reconciliação de contas (armazenamento de registo duplo);
•
Controlo e reconciliação de bases de dados, no caso de existirem bases de
dados distribuídas;
•
Utilização de algoritmos de hashing;
•
Controlo do tempo e da sequência de execução de rotinas aplicacionais;
•
Teste do correcto comportamento em caso de existência de erros (ex. aborto,
recuperação etc.).
10.2.3
Autenticação de Mensagens
A autenticação de mensagens é uma técnica utilizada para detectar modificações não
autorizadas no conteúdo das mensagens transmitidas electronicamente ou então
corrupção deste conteúdo, que pode ser implementada em hardware ou software (ex.
Público
54
ENSI
Política de Segurança da Informação Detalhada da Entidade
mecanismos de criptografia). Os requisitos de autenticação de mensagens devem ser
validados num processo de análise de risco.
10.2.4
Validação dos Resultados Produzidos
Os resultados produzidos por uma aplicação devem ser validados relativamente à sua
consistência. As seguintes medidas têm de ser implementadas:
•
Reconciliação dos resultados produzidos (todos os dados foram processados
correctamente?);
•
Disponibilização de documentação relativa à classificação dos dados
produzidos, e se estes são completos e precisos, de modo a permitir que um
utilizador (ou um processo seguinte) avalie o sucesso do processamento;
•
Definição de todas as pessoas envolvidas no processo de produção dos
resultados.
10.3 Controlos Criptográficos
Com o objectivo de proteger a confidencialidade, autenticidade ou integridade da
informação, as técnicas e métodos criptográficos podem ser usados na protecção da
informação considerada de risco e para a qual os outros controles não fornecem o
nível de protecção adequado.
10.3.1
Política de Utilização de Controlos Criptográficos
Um procedimento de análise de risco deve preceder a decisão de utilização de um
método de criptografia. Devido à complexidade e variedade de meios para
implementação de métodos de criptografia, deve ser criada uma política de segurança
separada (política de criptografia) para esta área, no contexto de um guia de
implementação. Esta é única forma de prevenir a utilização de métodos de
criptografia inseguros ou insuficientes:
•
A equipa de Segurança da Informação é a autoridade responsável pela
implementação de uma política de criptografia e pela administração das
chaves criptográficas. A responsabilidade também se estende a decisões
relativas à aplicabilidade das medidas de criptografia e a selecção de normas e
soluções de criptografia;
•
Deve ser estabelecido um mecanismo de recuperação de chaves para
descodificar os dados protegidos dos utilizadores. Esta tarefa é da
responsabilidade da equipa de Segurança da Informação. Devido à
possibilidade de utilização indevida, esta tarefa deve ser coordenada com as
autoridades responsáveis;
•
Deve ser implementado um sistema de administração de chaves com o
objectivo de proteger as chaves da entidade. O propósito deste sistema é
proteger as chaves contra a manipulação, destruição e acesso não autorizado.
A protecção da chave é baseada em métodos de criptografia e na protecção
física do sistema de administração de chaves;
Público
55
ENSI
Política de Segurança da Informação Detalhada da Entidade
•
A administração das chaves tem de ser baseada em normas aceites para a
geração, distribuição, modificação, remoção, destruição, recuperação e
armazenamento de chaves e deve incorporar a possibilidade de auditoria e
registo. Para além disso, a duração da validade das chaves deve ser restringida.
O período de validação das chaves depende do risco de acesso não autorizado
ou modificação da chave. De igual forma, um procedimento de investigação
pela divulgação de chaves secretas deve ser determinado por questões legais;
•
De forma a proteger as chaves internas da entidade deve ser utilizada uma
Certificate Authority (CA). Esta autoridade deve ser reconhecida como o
centro de excelência dentro da entidade.
•
No caso de serem utilizados serviços de criptografia externos (ex. outsourced
CA), a responsabilidade legal, a disponibilidade e o tempo de resposta têm de
ser previamente estabelecidos no contrato.
10.3.2
Criptografia
A política de criptografia deve determinar as questões de segurança da criptografia
(ex. tamanho das chaves, algoritmos, administração da chave) e ter em consideração
as regulamentações nacionais relativas a criptografia (ex. utilização, objectivo da
implementação, importação, exportação). As medidas preventivas devem utilizar
processos e tecnologias de ponta (“estado da arte”) de forma a garantir o nível de
protecção geral.
10.3.3 Assinatura Digital
As assinaturas digitais protegem a autenticidade e integridade de documentos
electrónicos. As bases de implementação são procedimentos no campo da criptografia
de chaves públicas. As regulamentações legais acerca da aplicabilidade e aceitação
das assinaturas digitais devem ser consideradas (questões de segurança relacionadas
com o tamanho das chaves, algoritmos e armazenamento das chaves).
10.3.4 Não Repúdio
Algumas transacções electrónicas (ex. comércio electrónico) têm de ser comprovadas
que realmente ocorreram. Portanto, os procedimentos apropriados devem ser
utilizados, baseados na criptografia de chaves públicas.
10.4 Segurança dos Ficheiros de Sistema
O acesso aos ficheiros de sistema deve ser controlado. A integridade do sistema deve
ser da responsabilidade da função ou grupo de desenvolvimento do utilizador, a quem
o sistema aplicacional ou software pertence.
10.4.1
Controlo de Software em Produção
De forma a controlar os sistemas e aplicações de produção, devem ser tomadas as
seguintes medidas:
Público
56
ENSI
Política de Segurança da Informação Detalhada da Entidade
•
As actualizações só podem ser feitas pela pessoa responsável com permissão
de administração. Consultar a secção 10.5.1 – Procedimentos de Gestão de
Alterações;
•
O código executável apenas pode ser instalado nos sistemas de produções após
os testes terem sido realizados com sucesso e existir a aceitação suficiente
pelos utilizadores. Antes disso, a reconciliação das bibliotecas de código fonte
tem de ser realizada;
•
As actualizações das bibliotecas de código fonte em sistemas e aplicações de
produção devem ser documentadas;
•
A administração de código fonte deve ser feita através do controlo de versões;
•
Versões antigas do software devem ser armazenadas como reserva para o caso
de emergências.
A manutenção de produtos de software comercial depende dos serviços oferecidos;
Quando se efectua uma actualização aos sistemas ou aplicações, a alteração da
segurança dos sistemas deve ser tida em consideração. As actualizações de segurança
devem ser implementadas assim que estiverem disponíveis. O acesso por terceiros
deve ser supervisionado.
10.4.2
Protecção de Dados de Teste dos Sistemas
Os dados de testes também devem ser protegidos e controlados. Se possível, para
efeito de testes, não devem ser utilizados dados do ambiente de produção. Caso seja
necessário o seu uso, devem ser tomadas as seguintes precauções:
•
Quando os dados de produção são carregados no sistema de testes, um
mecanismo de autorização diferente deve ser utilizado em cada caso;
•
Os mesmos mecanismos de controlo de acessos devem ser utilizados no
ambiente de teste;
•
Após os testes, os dados dos sistemas de teste devem ser eliminados;
•
A utilização de dados de produção no sistema de testes deve ser registada;
•
Qualquer referência pessoal deve ser removida. Se tal não for possível, então a
utilização deve ser autorizada pela pessoa referenciada.
10.4.3
Controlo de Acesso ao Código Fonte
De forma a reduzir a possibilidade de manipulação não autorizada de software, o
acesso ao código fonte deve ser rigorosamente controlado.
•
Dentro do possível, o código fonte não deve ser mantido em sistemas de
produção e deve ser protegido contra acesso não autorizado;
Público
57
ENSI
Política de Segurança da Informação Detalhada da Entidade
•
A responsabilidade pelo código fonte é do respectivo departamento de
desenvolvimento. Para os programas desenvolvidos externamente, a
responsabilidade recai sobre o departamento, dentro da entidade, que efectuou
a encomenda;
•
Os códigos fonte de desenvolvimento devem ser armazenados separadamente
dos códigos fonte de produção;
•
As actualizações de código fonte e a distribuição de código fonte aos
programadores devem ser aprovadas pela Administração de TIC;
•
As impressões de código fonte devem ser protegidas;
•
O acesso ao código fonte deve ser registado;
•
Deve ser usada uma gestão de alterações (ver 10.5.1) com data, início de
produção, dependências, etc.
•
A manutenção e cópia de bibliotecas de programas fonte devem ser sujeitas a
controlos de alterações restritos (ver 10.4.1). As opções utilizadas na
compilação bem como os parâmetros do programa devem ser registados, uma
vez que podem ter uma influência muito significativa no produto executável.
10.5 A Segurança nos Processos de Desenvolvimento e
Suporte
Recomendações para a manutenção da Segurança da Informação e do software
aplicacional devem ser implementadas. Os ambientes de projecto e de suporte devem
ser restritamente controlados. Para cada sistema aplicacional deve ser definida uma
pessoa responsável. Uma das suas responsabilidades é a de assegurar de que todos os
eventos relacionados com Segurança da Informação são validados antes das
modificações no sistema serem aprovadas (ver também as notas em 8.1.1). Aplicações
e sistemas críticos devem ser desenvolvidos e mantidos apenas por pessoas com
orientação em Segurança da Informação.
10.5.1
Procedimentos de Gestão de Alterações
Os seguintes controlos formais devem ser implementados para proteger sistemas de
gestão da informação (gestão de alterações):
•
Todas as autorizações atribuídas devem ser documentadas e controladas; e
deve ser garantido que a alterações apenas são efectuadas por pessoal
autorizado;
•
Os procedimentos de controlo e integridade devem ser periodicamente revistos
para assegurar que não serão comprometidos por uma alteração no sistema ou
ambiente de operação.
Público
58
ENSI
Política de Segurança da Informação Detalhada da Entidade
Procedimentos específicos de alterações de aplicações e workflow devem conter os
seguintes pontos:
•
As alterações, relativas à funcionalidade e capacidade de entrar em produção,
têm de ser testadas em ambiente de testes;
•
Entre o ambiente de testes e o ambiente de produção não são admitidas
alterações;
•
A configuração do sistema de testes deve corresponder o mais possível a
configuração do sistema de produção;
•
As alterações solicitadas e as alterações realmente efectuadas devem ser
registadas e documentadas;
•
Deve existir uma gestão de versões;
•
As actualizações da documentação necessárias relativamente a alterações
devem ser efectuadas o mais rápido possível.
10.5.2
Revisão Técnica de Alterações aos Sistemas em
Produção
Após as alterações terem sido efectuadas à plataforma principal do sistema
(tipicamente alterações no sistemas operativo ou de hardware), a funcionalidade e
segurança de todo o sistema, incluindo todas as aplicações, têm de ser testadas e
reconfirmadas. Todos os departamentos envolvidos (em particular a equipa que faz a
revisão) devem ser informados atempadamente sobre as modificações planeadas.
Adicionalmente, deve ser ajustado o plano de continuidade (ver capitulo 11).
10.5.3
Restrições às Alterações de Pacotes de Software
As modificações a pacotes de software comercial são proibidas. Se alterações ao
produto de terceiros forem inevitáveis, devem ser considerados os seguintes pontos:
•
As validações internas de segurança podem ser afectadas ou, no pior dos
casos, desactivadas pelas modificações;
•
O fabricante deve concordar antes das alterações serem implementadas;
•
O suporte contínuo deve ser garantido;
•
Se possível, as alterações devem ser efectuadas pelo fabricante;
•
O software original deve ser mantido protegido contra acessos não
autorizados. As alterações devem ser testadas, documentadas e as versões
modificadas marcadas;
•
Se as alterações são essenciais para o funcionamento do software então o
software original tem de ser retido para referência. Modificações futuras
devem ser efectuadas numa cópia marcada.
Público
59
ENSI
Política de Segurança da Informação Detalhada da Entidade
10.5.4
Canais Escondidos e Códigos do Tipo Cavalo de Tróia
Para minimizar o risco de software perigoso (vírus, “Cavalo de Tróia” e canais
escondidos), as seguintes medidas devem ser implementadas (ver também a secção
8.3 – Protecção Contra Software Malicioso):
•
O software deve ser comprado apenas de origens fiáveis e se possível com o
código fonte incluído;
•
Utilizar apenas software certificado (certificado em papel ou electrónico);
•
Em sistemas e aplicações críticos todo o código fonte tem de ser validado
contra manipulação antes do uso em produção;
•
O software já instalado tem de ser protegido.
10.5.5
Outsourcing de Desenvolvimento de Software
Se a tarefa de desenvolvimento de software é delegada a terceiros, então os seguintes
pontos têm de ser considerados:
•
Licenciamento, detenção do código fonte e direitos de propriedade intelectual;
•
Certificação da qualidade e da correcção do trabalho (secção 12.1);
•
Indemnização em caso de falha causada por terceiros;
•
Requisitos contratuais de qualidade do software;
•
Processos definidos contratualmente para a auditoria da qualidade e exactidão
do trabalho efectuado;
•
Etapa de testes antes da instalação para detectar código suspeito ou “Cavalo de
Tróia” (ver 8.3e 10.5.4).
O software desenvolvido por terceiros tem de ser instalado pela equipa responsável
pela gestão das alterações. O acesso ao computadores de desenvolvimento apenas
pode ocorrer durante o horário normal de trabalho e os utilizadores externos (pessoal
do desenvolvimento de software) apenas podem aceder a um computador dedicado
para o efeito.
Público
60
ENSI
Política de Segurança da Informação Detalhada da Entidade
11 Gestão da Continuidade do Negócio
O processo de Gestão da Continuidade do Negócio minimiza as interrupções nas
actividades do negócio e protege os processos críticos de negócio de falhas ou
catástrofes.
Para garantir a manutenção das actividades de negócio é necessário localizar os
eventos que lhe podem causar falhas. Estes eventos podem ser desastres naturais,
acidentes, avarias técnicas e sabotagem. O efeito destas possíveis avarias deve ser
avaliado na análise de risco. A equipa de gestão de risco de TIC e o pessoal
responsável pela respectiva divisão devem executar as análises. Dos resultados desta
análise de risco é desenvolvido um plano estratégico, que determina os procedimentos
para assegurar as actividades de continuidade do negócio. A responsabilidade pela
coordenação deve estar localizada num nível apropriado dentro da organização, por
exemplo na equipa de segurança de TIC (ver 4.1).
11.1 Aspectos da Gestão da Continuidade do Negócio
Os planos de continuidade servem para manter ou restabelecer as actividades do
negócio dentro de um intervalo de tempo após a ocorrência de uma avaria. Para cada
nível do plano de recuperação de desastres deve ser considerado:
•
Definições claras das responsabilidade e procedimentos de emergência no
caso de existir uma situação de crise e nomeação dos empregados
responsáveis pela execução das secções individuais do plano de recuperação;
•
O restabelecimento das actividades de negócio dentro de um dado tempo pela
utilização de procedimentos de recuperação. Durante uma falha devem ser
consideradas as dependências de negócio externas e contratos associados;
•
Definição das condições necessárias para a activação de um determinado
plano (se existirem vários);
•
Um plano de continuidade de negócio que descreva a mudança temporária de
áreas fundamentais para instalações alternativas e a definição dos
procedimentos para a reposição da operação regular das actividades de
negócio no actual local de operação;
•
Formação apropriada do pessoal relativamente aos procedimentos e processos
de emergência acordados incluindo a gestão de situações de crise;
•
Os planos de recuperação devem ser documentados, testados e actualizados.
Deve ser desenvolvido um calendário, que indique quando e como deve ser
testado cada ponto do plano de recuperação.
Neste contexto, os servidores e a rede são tratados como um único elemento. A
sequência de salvaguarda (ex. entre os diferentes níveis) deve ser definida com
precisão.
Público
61
ENSI
Política de Segurança da Informação Detalhada da Entidade
12 Conformidade
12.1 Conformidade com Requisitos Legais
Adicionalmente aos interesses da entidade, todas as regulamentações legais devem ser
consideradas aquando da implementação de um Sistema de Gestão de Segurança da
Informação.
12.1.1
Identificação da Legislação Aplicável
Todos os requisitos legais relevantes, devem ser determinados e documentados, bem
como as medidas (inclusive responsabilidades) a implementar para satisfazer esses
requisitos.
12.1.2
Direitos de Propriedade Intelectual
Serão considerados neste capítulo as regulamentações de direitos de cópia, o registo
de nomes de marcas e direitos de design. Em particular, devem ser tomados os
seguintes passos para estar em conformidade com as regulamentações de licença e
direitos de cópia de software:
•
Criação de uma lista de requisitos para o cumprimento das regulamentações de
direitos de cópia (inclusive a monitorização do respectivo nível de licença,
transferência e destruição de software);
•
Consciencialização do pessoal sobre regulamentações de direitos de cópia de
software e respectivas consequências pela violação desses direitos;
•
Introdução de uma gestão de licenças (incluindo a retenção de licenças em
disquete, CDs, DVDs, certificados, etc.);
•
Verificação do licenciamento do software instalado relativamente as licenças
disponíveis (se possível, a execução desta verificação deve ser automatizada);
•
Apenas podem ser utilizados desenvolvimentos de software próprio ou
produtos correctamente licenciados, que carecem sempre de autorização;
•
Autorização do uso de software e informação obtida a partir de redes públicas
(ex. Internet).
12.1.3
Salvaguarda de Registos da Entidade
A entidade é obrigada a reter certos registos. As seguintes medidas têm de ser
tomadas:
•
Devem ser estabelecidas recomendações que regulem o período de retenção,
armazenamento, manuseamento e destruição dos registos;
•
Os registos têm de ser classificados (base de dados de clientes, transacções,
entradas de registos etc.);
Público
62
ENSI
Política de Segurança da Informação Detalhada da Entidade
•
Os dados devem ser rotulados num formato próprio (ver 5.2.2). Para cada
classe deve ser documentado o tempo e meio de armazenamento;
•
O dano dos meios de armazenamento deve ser evitado através de métodos de
armazenamento adequados e cautelosos;
•
Com meios de armazenamento electrónicos, deve ser garantido que os dados
ainda estão legíveis no fim do período de retenção, mesmo após uma alteração
na tecnologia ou hardware utilizados;
•
Deve ser garantido que os dados possam estar acessíveis dentro de um período
de tempo definido;
•
Se os dados estiverem cifrados, as chaves devem ser protegidas e deve ser
assegurado que o acesso por pessoal autorizado é possível;
•
Deve ser estabelecido um processo apropriado para estar em conformidade
com os requisitos do Data Protection Act (dever de disponibilizar a
informação conforme requerido);
•
Os registos têm de ser protegidos contra perda, destruição e manipulação.
12.1.4
Protecção e Privacidade de Dados Pessoais
Devem ser implementadas as regulamentações das leis de protecção de dados. Deve
existir um responsável pela protecção de dados que cria, altera e controla as
recomendações que asseguram o cumprimento das regulamentações legais. Deve
existir uma cooperação próxima com a equipa de segurança de TIC se os requisitos
coincidirem com os da Segurança da Informação.
12.1.5
Prevenção Contra o Uso Indevido de Equipamento
O uso dos sistemas de TIC apenas é permitido para processamento de informação da
entidade. Deve ser prevenido o uso com outros fins. Os utilizadores devem ser
informados das regulamentações relevantes e dos seus deveres respectivos.
12.1.6
Regulamentação de Controlos de Criptografia
Devido à complexidade da legislação internacional existente actualmente (alguns
países proíbem a criptografia) devem ser definidas as recomendações exactas
conjuntamente com um advogado especializado em legislação sobre criptografia.
12.1.7
Registo de Evidências
Quando se efectuam recolhas de evidências electrónicas devem ser criadas cópias de
todos os dados antes do seu processamento ou impressão. Este processo deve ser
documentado e acompanhado por testemunhas. Pelo menos uma cópia deve ser
guardada num local seguro. Deve ser consultado um advogado, logo que possível,
assim que ocorra um incidente que requeira evidência electrónica.
Público
63
ENSI
Política de Segurança da Informação Detalhada da Entidade
12.2 Revisão das Políticas de Segurança e Conformidade
Técnica
Para determinar se todos os controlos no Sistema de Gestão de Segurança da
Informação estão a trabalhar, devem ser efectuadas auditorias regulares de todo o
ambiente.
A base destas auditorias é a política de segurança com todas as normas e
regulamentações relacionadas com segurança.
Os sistemas de informação devem ser validados com auditorias regulares para avaliar
o cumprimento das normas de segurança. Durante as revisões automáticas, os
relatórios extraídos devem ser analisados por pessoal qualificado.
12.3 Considerações sobre Auditoria de Sistemas
Durante a auditoria, os sistemas de produção e as ferramentas de auditoria devem ser
protegidos. A integridade e prevenção do abuso das ferramentas de auditorias devem
ser garantidas. As medidas de controlo dos sistemas contêm:
•
Os requisitos e o âmbito da análise devem ser coordenados com a equipa de
gestão de Segurança da Informação;
•
Os dados devem ser apenas de leitura. A possibilidade de manipulação dos
dados por estas acções deve ser nula;
•
Contudo, se os dados tiverem de ser armazenados no sistema a validar para
investigações temporárias, deve ser limitada a escrita em ficheiros
temporários, que serão apagados após a auditoria;
•
O acesso a sistemas ou dados sensíveis deve ser monitorizado e registado para
todos os utilizadores;
•
Devem ser documentados todos os processos, solicitações e respectivas
responsabilidades.
Devem ser criadas protecções de controlo de acesso para as ferramentas de auditoria e
respectivos dados. Após a auditoria, as ferramentas e dados da auditoria devem ser
instalados e guardados em sistemas específicos de auditoria e removidos dos sistemas
de produção.
Público
64