298 Redes
117
UNEB – UNIÃO EDUCACIONAL DE BRASILIA COPEX – COORDENAÇÃO DE ESTUDOS, PESQUISAS, PÓS-GRADUAÇÃO E EXTENSÃO REDES DE COMPUTADORES - TURMA B DANIELE FERREIRA DENIS N. LOPES JOSE WALDEMAR POMPOLO LUCIANO TEIXEIRA ANDRADE MARIA DO SOCORRO B. HENRIQUES PROPOSTA PARA UMA POLÍTICA DE SEGURANÇA DE DADOS APLICADA ÀS SECRETARIAS DE RECEITA Brasília – DF 2001
-
Upload
negogrummt -
Category
Documents
-
view
28 -
download
0
Transcript of 298 Redes
UNEB – UNIÃO EDUCACIONAL DE BRASILIA COPEX – COORDENAÇÃO DE ESTUDOS, PESQUISAS, PÓS-GRADUAÇÃO
E EXTENSÃO REDES DE COMPUTADORES - TURMA B
DANIELE FERREIRA DENIS N. LOPES
JOSE WALDEMAR POMPOLO LUCIANO TEIXEIRA ANDRADE
MARIA DO SOCORRO B. HENRIQUES
PROPOSTA PARA UMA POLÍTICA DE SEGURANÇA DE DADOS APLICADA ÀS SECRETARIAS DE
RECEITA
Brasília – DF 2001
UNEB – UNIÃO EDUCACIONAL DE BRASILIA COPEX – COORDENAÇÃO DE ESTUDOS, PESQUISAS, PÓS-GRADUAÇÃO
E EXTENSÃO REDES DE COMPUTADORES - TURMA B
DANIELE FERREIRA DENIS N. LOPES
JOSE WALDEMAR POMPOLO LUCIANO ANDRADE
MARIA DO SOCORRO HENRIQUES
PROPOSTA PARA UMA POLÍTICA DE SEGURANÇA DE DADOS APLICADA ÀS SECRETARIAS DE
RECEITA
Projeto apresentado à COPEX – Coordenação de Estudos, Pesquisas, Pós-Graduação e Extensão da UNEB – União Educacional de Brasília, parte dos requisitos para obtenção do título de Pós-Graduado em Redes de Computadores
Orientador: Prof. César de Souza Machado
Brasília – DF 2001
iii
DANIELE FERREIRA DENIS N. LOPES
JOSE WALDEMAR POMPOLO LUCIANO ANDRADE
MARIA DO SOCORRO HENRIQUES
PROPOSTA PARA UMA POLÍTICA DE SEGURANÇA DE DADOS APLICADA ÀS SECRETARIAS DE RECEITA
Este projeto foi julgado adequado para obtenção do título de Pós-Graduado em Redes de Computadores e aprovado em sua forma final pela COPEX – Coordenação de Estudos, Pesquisas, Pós-Graduação e Extensão da UNEB – União Educacional de Brasília.
___________________________________ Prof. …………………….
Coordenador Banca Examinadora:
___________________________________ Prof. César de Souza Machado.
Orientador
___________________________________ Prof. Joaquim Gomide
___________________________________ Prof. Alex Delgado Casañas
iii
Aos nossos familiares e companheiros, que durante todo o curso de pós graduação e elaboração do projeto final entenderam nossas faltas e
ausências nos incentivando com palavras e atos. Graças a estas pessoas tão especiais, estamos neste momento concluindo mais uma
importante etapa em nossa jornada profissional. Agradecemos a todos de coração.
iv
SUMÁRIO
PÁGINA
LISTA DE ILUSTRAÇÕES...................................................................................VII
LISTA DE TABELAS........................................................................................... VIII
LISTA DE ABREVIATURAS E SIGLAS ............................................................. IX
1. INTRODUÇÃO .....................................................................................................12
2. OBJETIVOS ..........................................................................................................15 2.1. OBJETIVO GERAL ...............................................................................................15 2.2. OBJETIVOS ESPECÍFICOS:....................................................................................15
3. FUNDAMENTAÇÃO TEÓRICA........................................................................17 3.1. SEGURANÇA DA INFORMAÇÃO............................................................................17 3.2. PROJETO DE SEGURANÇA ...................................................................................17 3.3. PLANO DE SEGURANÇA ......................................................................................18 3.4. NORMA DE SEGURANÇA .....................................................................................19 3.5. PROCEDIMENTOS DE SEGURANÇA ......................................................................19 3.6. ARQUITETURA DE SEGURANÇA ..........................................................................20 3.7. MODELO DE SEGURANÇA ...................................................................................21 3.8. HISTÓRICO DAS NORMAS DE PADRONIZAÇÃO DE SEGURANÇA...........................22 3.9. POLÍTICA DE SEGURANÇA...................................................................................26
3.9.1. Visão Geral de uma Política de Segurança................................................27 3.9.2. Identificação dos Recursos .........................................................................29 3.9.3. Considerações Importantes .......................................................................29 3.9.4. Premissas Básicas.......................................................................................30 3.9.5. Conteúdo Essencial.....................................................................................31 3.9.6. Principais Atores ........................................................................................31 3.9.7. Flexibilidade ...............................................................................................33 3.9.8. Classificação das Informações ...................................................................34 3.9.9. Análise de Riscos ........................................................................................35 3.9.9.1. Riscos Externos .......................................................................................36 3.9.2.2. Riscos Internos ........................................................................................39 3.9.10. Análise de Ameaças ..................................................................................39 3.9.11. Auditoria ...................................................................................................41 3.9.12. Plano de Contingência..............................................................................42
3.10. FERRAMENTAS DE SEGURANÇA........................................................................45 3.10.1. Criptografia ..............................................................................................45 3.10.1.1. Algoritmos Criptográficos.....................................................................45 3.10.1.2. Criptografia Simétrica ...........................................................................46 3.10.1.3. Algoritmos de Chave Simétrica.............................................................46 3.10.1.4. Criptografia Assimétrica .......................................................................47 3.10.1.5. Algoritmos de Chave Assimétrica.........................................................48 3.10.1.6. Algoritmos para Geração de Assinatura Digital....................................49 3.10.2. PKI (Public Key Infrastructure) ...............................................................49
v
3.10.3. Firewall.....................................................................................................51 3.10.4. Anti-Vírus..................................................................................................53 3.10.4.1. Softwares de Prevenção.........................................................................53 3.10.4.2. Softwares de Detecção ..........................................................................54 3.10.4.3. Software de Identificação ......................................................................54 3.10.4.4. Requisitos Básicos de um Antivírus......................................................54 3.10.5. VPN (Virtual Private Network).................................................................55 3.10.5.1. IPSec......................................................................................................57 3.10.6. IDS (Intrusion Detection System ) ............................................................58 3.10.7. Backup.......................................................................................................59 3.10.8. RADIUS (Remote Authentication Dial In User Service) ..........................60 3.10.9. Biometria...................................................................................................61 3.10.10. Call Back.................................................................................................62 3.10.11. Token Card..............................................................................................62
4.1. OBJETIVO GERAL DAS ORGANIZAÇÕES DE ADMINISTRAÇÃO TRIBUTÁRIA.........68 4.2. OBJETIVOS ESPECÍFICOS.....................................................................................68 4.3. ORGANOGRAMA PADRÃO...................................................................................69 4.4. COMPETÊNCIAS GENÉRICAS ...............................................................................70
4.4.1. Coordenação de Administração .................................................................70 4.4.2. Coordenação de Informática ......................................................................71 4.4.3. Departamento de Tributação......................................................................71 4.4.4. Departamento de Arrecadação...................................................................72 4.4.5. Departamento de Fiscalização ...................................................................72 4.4.6. Departamento de Atendimento ao Contribuinte .........................................72
4.5. PERFIL DO USUÁRIO ...........................................................................................73 4.6. INTERAÇÃO COM OUTRAS ORGANIZAÇÕES ........................................................73 4.7. PERSPECTIVAS DE EVOLUÇÃO ............................................................................73 4.8. MATRIZ DE USO DE DADOS ................................................................................78
5. POLÍTICA DE SEGURANÇA.............................................................................81 5.1. ANÁLISE DE RISCOS ...........................................................................................81
5.1.1. Vulnerabilidades .........................................................................................83 5.1.1.1. Vulnerabilidades Externas.......................................................................83 5.1.1.2. Vulnerabilidades Internas........................................................................84 5.1.1.3. Vulnerabilidades Referentes a Correio Eletrônico .................................85 5.1.1.4. Vulnerabilidades Referentes a Aplicações ..............................................85 5.1.1.5. Outras Vulnerabilidades ..........................................................................86
5.2. NORMAS DE SEGURANÇA ...................................................................................86 5.3. POLÍTICA DE SEGURANÇA APLICADA A PESSOAS EM CONFORMIDADE COM A ISO/IEC 17799:2000...............................................................................................................87 5.4. POLÍTICA DE SEGURANÇA LÓGICA .....................................................................89 5.5. POLÍTICA DE SEGURANÇA FÍSICA E DO AMBIENTE EM CONFORMIDADE COM A ISO/IEC 17799:2000................................................................................................91 5.6. APLICABILIDADE ................................................................................................94 5.7. RESPONSABILIDADE ...........................................................................................94 5.8. SANÇÕES ............................................................................................................94 5.9. PLANO DE CONTINGÊNCIA..................................................................................95
5.9.1.1 Plano de Ação para Emergências .............................................................95 5.9.1.2 Contagem dos Recursos e Avaliação de Criticidade................................96 5.9.3 Identificação de Ameaças e Contramedidas................................................97
vi
5.9.2 Procedimento de Resposta Imediata............................................................99 5.9.3 Plano de Recuperação de Desastre ...........................................................100
5.10. AUDITORIA.....................................................................................................100 5.10.1. Recomendações ISO/IEC 17799:2000....................................................101 5.10.2. Tipos de Auditoria Propostos .................................................................102 5.10.3. Quando Devem ser Feitas as Auditorias ................................................103 5.10.4. Como Auditar..........................................................................................104 5.10.5. Metodologia ............................................................................................106
6. CONCLUSÃO......................................................................................................109
REFERÊNCIAS BIBLIOGRÁFICAS ..................................................................111
ANEXO I ..................................................................................................................114
ANEXO II.................................................................................................................115
ANEXO III ...............................................................................................................116
vii
LISTA DE ILUSTRAÇÕES
PÁGINA
Figura 1 – Requisitos do Modelo de Segurança. ............................................................. 22
Figura 2 – Processo de uma Política de Segurança ......................................................... 27
Figura 3 - Metodologia CobiT......................................................................................... 42
Figura 4 - Funcionamento do Processo Real-time Online Certificate Status Checking:. 50
Figura 5 – Autenticação desafio/resposta com ficha ....................................................... 63
Figura 6 – Autenticação com Sincronismo...................................................................... 64
Figura 7 - Estrutura Básica das Secretarias de Receita .................................................. 70
Figura 8 – Modelo observado no final da década de 1980 na maioria das Secretarias de
Receita. .................................................................................................................... 74
Figura 9 – Modelo observado na primeira metade da década de 1990 ........................... 75
Figura 10 – Modelo implantado a partir da segunda metade da década de 1990 e
observado até hoje num grande número Secretarias de Receita.............................. 76
Figura 11 – Modelo tendência para implantação ainda na década de 2000. ................... 77
Figura 12 – Modelo de organograma observado como tendência para as Secretarias de
Receita a ser implantado nos próximos anos........................................................... 78
Figura 13 - Formação da Cultura de Segurança ............................................................ 101
Figura 14 – Estrutura da Metodologia COBIT.............................................................. 108
viii
LISTA DE TABELAS
PÁGINA
Tabela 1 - Matriz de Uso de dados .................................................................................. 80
Tabela 2 – Análise de Ameaças....................................................................................... 82
Tabela 3 – Contagem de Recursos .................................................................................. 97
Tabela 4 – Identificação de Ameaças .............................................................................. 98
Tabela 5 – Ameaças e Contramedidas............................................................................. 99
ix
LISTA DE ABREVIATURAS E SIGLAS
ATM Asynchronous Transfer Mode ACK Acknowledgement AES Advanced Encryption Standard AH Authentication Header BS British Standard CA Certificate Authorities CC Common Criteria CCITSE Common Criteria for Information Technology Security Evaluation CCSC Centro Comercial de Segurança na Computação CD-Rom Compact Disc-Read Only Memory CHAP Challenge Handshake Authentication Protocol CNPJ Cadastro Nacional de Pessoa Jurídica CO2 Gás Carbônico CobiT Control Objectives for Information and Related Technology COSO Committee of Sponsoring Organizations of the Treadway
Commission CPD Centro de Processamento de Dados CPF Cadastro de Pessoa Física CPU Central Process Unit CRL Lista de Certificados Revogados CSI/FBI Computer Crime and Security Survey/Federal Bureau of
Investigation CTCPEC Canadian Trusted Computer Product Evaluation Criteria CTN Código Tributário Nacional CVM Comissão de Valores Mobiliários DES Data Encryption Standard DTI Departamento de Comércio Britânico ESP Encapsulating Security Payload FD Floppy Disk FTP File Transfer Protocol GB Gigabyte HD Hard Disk HP Hewlett Packard HTTP Hypertext Transfer Protocol IBM International Business Machines ICMS Imposto sobre Circulação de Mercadorias e Serviços ID Identification IDEA International Data Encryption Algorithm IDS Intrusion Detective System IETF Internet Engineering Task Force IKE Internet Key Exchange INC. Incorporated IP Internet Protocol IPSec Internet Protocol Security IPVA Imposto sobre Propriedade de Veículos Automotores ISO/IEC International Organization for Standardization/International Engineer
Committee IT Information Technology ITSEC Information Technology Security Evaluation Criteria LAN Local Area Networks MB Megabyte MD5 Message Digest 5 MS-Office Microsoft Office
x
NAS Network Access Server NBS National Bureau of Standards NCC National Computing Center NIC Network Interface Card NIST National Institute of Standards in Technology NSA National Security Agency OSI Open System Interconnect PAP Password Authentication Protocol PKI Public Key Infrastructure PNAFEM Programa Nacional de Apoio à Administração dos Estados e
Municípios POP3 Post Office Protocol versão 3 PPP Point to Point PPTP Point to Point Tunneling Protocol RA Registration Authorities RADIUS Remote Access Dial In User Service RAM Random Access Memory RAS Remote Access Server RC2, RC4 Rivest Cipher RFC Request for Comments RIP Routing Information Protocol RSA Rivest, Shamir, Adleman RSA/DSI Rivest, Shamir, Adleman Data Security Inc. SAC Systems Auditability and Control SAS Statements on Auditing Standards SMTP Simple Mail Transfer Protocol SP Service Pack SSL Secure Sockets Layer TCP Transport Control Protocol TCSEC Trusted Computer System Evaluation Criteria TFTP Trivial File Transfer Protocol TI Tecnologia da Informação UDP User Datagrama Protocol UNEB União Educacional de Brasília UPS Uninterruptable Power System VB Visual Basic VPN Virtual Private Network WAN Wide Area Networks Web ( WWW, W3) World Wide Web
xi
Abril/2001
“... é atitude de um desequilibrado...”
Fernando Néri
Presidente da Módulo Security, qualificando
um ex funcionário de sua empresa que
divulgou para a imprensa esquemas das redes
de grandes clientes para os quais prestava
consultoria
Maio/2001
“... nós sempre nos preocupamos com possíveis invasões externas, não
imaginamos que alguém da casa pudesse cometer tal desatino ... “
Regina Peres Teles Borges
Ex Diretora do PRODASEN tentando explicar a
violação do painel de votações do Senado
Federal
Junho/2001
“... nunca imaginamos que um servidor de nossa carreira pudesse cometer um crime
destes ...”
Altair Lemos Moura
Diretor de administração do Ministério da
Fazenda em São Paulo justificando as fraudes
no sistema de pagamento de pensionistas do
Ministério
12
1. INTRODUÇÃO
No âmbito do Governo existem perdas que podem causar danos irreparáveis.
Recentes fatos noticiados na imprensa coincidiram com a conclusão do curso de Redes de
Computadores 2000/2001 – UNEB, turma B, levando-nos a propor uma discussão sobre a
formulação de uma política de segurança da informação aplicada às instituições
governamentais de administração tributária, que doravante chamaremos de Secretarias de
Receita. Tal preocupação decorreu do fato destas instituições terem passado recentemente
por grandes revoluções no campo da informática aplicada quando decidiram caminhar na
direção da autonomia e se libertar das Companhias Estaduais/Municipais de
Processamento de Dados.
O Governo Federal, em diversas oportunidades, tem se manifestado no sentido de
assegurar a proteção da informação sob sua guarda e aquelas de interesse do cidadão. É
fundamental garantir o direito dos cidadãos à privacidade, além do direito à consulta sobre
os dados disponibilizados nos sistemas governamentais, previsto na Constituição. Os sites
de Internet devem comprometer-se em garantir a confiabilidade das informações de caráter
pessoal que são armazenadas em suas bases de dados, sejam elas relativas aos usuários ou
às pessoas que compõem a Administração Pública. A distribuição da massa informacional,
garantida através de mecanismos de segurança para as diversas linhas de aplicação e
suporte às atividades dentro e fora do governo, é uma diretriz que se materializa
gradativamente.
Com a chegada dos computadores pessoais e das redes de computadores que se
conectam ao mundo inteiro, os aspectos de segurança atingiram tamanha complexidade que
há a necessidade do desenvolvimento de equipes cada vez mais especializadas para sua
implementação e gerência. Paralelamente, os sistemas de informação também adquiriram
uma importância vital para a sobrevivência da maioria das organizações modernas, já que,
sem computadores e redes de comunicação, a prestação de serviços com qualidade pode se
tornar inviável.
Logo depois que as organizações começaram a utilizar intensamente os ambientes
de computação em rede para aprimorar sua capacidade de criar, armazenar, comunicar e
usar informações vitais, a preocupação em relação à proteção destas contra o acesso não
autorizado e possível destruição cresceu de forma acentuada. Como ocorreu na evolução de
vários outros produtos, a indústria de segurança de rede inicialmente concentrou seus
13
esforços em proteger os pontos fracos mais óbvios, partindo, em seguida, para identificar
outras áreas vulneráveis que necessitavam de atenção.
A variedade e a complexidade das redes levaram ao desenvolvimento de
mecanismos mais sofisticados para identificar áreas vulneráveis que exigiam atenção
constante. Diante da nova situação surgiu uma nova categoria de produtos que consistia em
sistemas de “verificação e teste”. Estes produtos tinham como principal objetivo identificar
pontos fracos na rede através da aplicação de uma variedade de cenários de invasão.
Em um primeiro momento, o conceito de verificação e teste surgiu em produtos
direcionados ao mercado de invasores potenciais e, por fim, deram origem a vários
produtos comerciais. O principal objetivo da verificação era identificar o maior número
possível de vulnerabilidades no sistema, simulando invasões em vários pontos diferentes.
Embora a maioria dos produtos comerciais de verificação fizessem um trabalho confiável
de identificação das vulnerabilidades e das medidas de segurança que podiam ser utilizadas
para solucioná-las, seus mecanismos de classificação não iam muito além de graduações
relativamente grosseiras, como o tradicional sistema de prioridades: Alta, Média e Baixa.
Para oferecer suporte à decisão, estes sistemas de segunda geração também raramente
incluíam recursos para simular diferentes cenários de proteção e/ou realizar uma análise de
custo/benefício das medidas de segurança propostas.
O grande mérito das soluções de segurança de rede de terceira geração é reunir
todos os recursos já existentes em um único recurso abrangente, orientado para
gerenciamento, que permite tomar decisões de segurança de forma racional, levando em
consideração a missão geral, as metas e os objetivos comerciais da empresa. Sua principal
meta é tornar o gerenciamento de risco de segurança da rede parte integrante do conjunto
de ferramentas básicas da organização para um gerenciamento “24 X 7” ou seja,
disponibilidade da rede 24 horas dos 7 dias da semana, compatível com as suas metas
estratégicas. Em vez de ser uma atividade de escopo limitado ou um evento periódico, um
gerenciamento de segurança realmente eficaz deve ser capaz de fornecer um contexto
amplo para a aplicação mais apropriada de métodos de verificação, testes e análises,
proteções e outras medidas de segurança.
Nos últimos anos, as organizações reguladoras e padronizadoras do setor de
segurança têm dado ênfase à definição e à implantação de sistemas de gerenciamento de
risco abrangentes.
14
Considerando a organização como um todo, o gerenciamento estruturado dos riscos
deve invariavelmente começar com a compreensão da importância e do valor relativos de
todas as informações. Apenas através da identificação, da catalogação e análise iniciais dos
ativos de informação será possível avaliar os impactos de sua possível destruição ou
comprometimento. O inventário de informações (ativos) oferece um contexto apropriado
para julgar os riscos reais decorrentes das possíveis vulnerabilidades e ameaças a estes
ativos.
Como as organizações, tanto públicas quanto privadas, perceberam que se tornaram
vulneráveis, procuraram implementar metodologias e ferramentas de segurança, sendo o
grande desafio desta questão a criação de um ambiente controlado e confiável, mas que não
retirasse do usuário a agilidade necessária ao bom funcionamento do negócio.
A tendência de negligência quanto aos procedimentos de segurança até que ocorra
algum problema grave é muito comum nos ambientes denominados “cliente-servidor”.
Para evitar que isto ocorra, devem-se adotar políticas de segurança que determinem quais
itens devem merecer atenção e com quais custos.
15
2. OBJETIVOS
2.1. OBJETIVO GERAL
Este trabalho tem por objetivo apresentar uma proposta de política de segurança
baseada na norma ISO/IEC 17799:2000 às Secretarias de Receita.
Atualmente, as grandes organizações e instituições estão cada vez mais
dependentes de novas tecnologias, sendo quase impossível manter seus negócios sem o
auxílio do computador.
Cada vez mais estas organizações, seus sistemas de informação e redes de
computadores são colocados a prova por diversos tipos de ameaças à segurança da
informação, incluindo fraudes eletrônicas, espionagem, sabotagem, vandalismo, fogo e
inundação.
A realidade das Secretarias de Receita ainda baseia-se em Sistemas Corporativos
voltados para ambientes fechados (mainframe).
A excessiva demanda da comunidade por acesso às informações residentes e
tratadas nestas instituições levou seus administradores a buscarem novos meios para dar
vazão a esta demanda.
Considerando que os dados e informações residentes nas Secretarias de Receita
podem refletir a vida financeira e contábil de pessoas e empresas e são legalmente
protegidas pelo Código Tributário Nacional - CTN, que garante o sigilo fiscal, surge a
necessidade de se implementarem mecanismos eficientes que possam garantir a
integridade, confidencialidade, autenticidade, disponibilidade da informação e não repúdio
dos dados.
2.2. OBJETIVOS ESPECÍFICOS:
• Levantar as necessidades das Secretarias de Receita quanto à segurança das
informações em seu poder;
• Apresentar os riscos, ameaças e vulnerabilidades que podem afetar a segurança da
informação e as contramedidas pare prevenir ataques;
• Conscientizar os funcionários e prestadores de serviço quanto à segurança das
informações, apresentando controles físicos, lógicos e pessoais;
• Desenvolver controles de segurança física, lógica e pessoal;
16
• Apresentar uma proposta de política de segurança à alta administração das Secretarias
de Receita buscando comprometimento e apoio para implementação da mesma;
• Propor uma metodologia de auditoria como elemento de apoio à administração de
segurança da informação;
• Elaborar um plano de contingência visando garantir a continuidade do negócio das
Secretarias de Receita.
17
3. FUNDAMENTAÇÃO TEÓRICA
A fim de facilitar o entendimento geral, serão descritos a seguir alguns conceitos
básicos importantes para a discussão do tema.
3.1. SEGURANÇA DA INFORMAÇÃO
A segurança da informação de uma instituição passa primeiramente por uma
relação considerável de normas que regem os comportamentos de seu público interno e
suas próprias atitudes em relação aos clientes externos, além disso, consideram-se as
ferramentas de hardware e software utilizadas e o domínio da aplicabilidade das mesmas
pela organização.
A segurança da informação consiste na preservação dos seguintes atributos:
• Confidencialidade - garantia de que a informação é acessível somente por
pessoas autorizadas.
• Integridade - garantia de que as informações e métodos de processamento
somente sejam alterados através de ações planejadas e autorizadas.
• Disponibilidade - garantia de que os usuários autorizados tenham acesso à
informação e aos ativos correspondentes quando necessário (ISO/IEC
17799:2000).
Conforme o caso, também podem ser fundamentais para garantir a segurança da
informação:
• Autenticação - garantia da identidade da origem e do destinatário de uma
informação.
• Não repúdio - garantia de que o emissor não negará um procedimento por ele
realizado.
3.2. PROJETO DE SEGURANÇA
A estratégia de segurança da informação de uma empresa exige a elaboração de
um projeto de segurança que descreva todos os aspectos da segurança da informação na
empresa. Um desses aspectos consiste na elaboração de um plano de segurança.
(FRASER, 1997; OPPENHEIMER, 1999).
18
O projeto de segurança, segundo Oppenheimer (1999), envolve várias etapas de
trabalho:
• Identificação dos ativos da empresa em termos de informações;
• Análise dos riscos de segurança;
• Análise dos requisitos de segurança e compromissos;
• Desenvolvimento de um plano de segurança;
• Definição de uma norma de segurança;
• Desenvolvimento de procedimentos para implantar a norma e uma estratégia
de implementação; e
• Implementação, gerenciamento e auditoria dos procedimentos de segurança.
3.3. PLANO DE SEGURANÇA
Plano de Segurança é um documento de alto nível que propõe o que uma
organização deve fazer para satisfazer os requisitos de segurança, contendo a relação dos
serviços de TI disponibilizados, quais áreas da empresa disponibilizam os serviços, quem
terá acesso aos serviços, a descrição detalhada de sua implementação, dos procedimentos
de controle dos ambientes, incidentes e contingências. O plano especifica o tempo, as
pessoas e outros recursos que serão necessários para desenvolver uma norma de
segurança e alcançar a implementação técnica da norma.
O plano deve estar baseado na análise de ativos de redes e riscos. Deve fazer
referência à topologia de rede e incluir uma lista de serviços de rede que serão fornecidos,
como por exemplo, FTP, Web, correio eletrônico e outros. Esta lista deve especificar quem
fornecerá os serviços, quem terá acesso aos serviços, o modo como o acesso será
fornecido e quem irá administrar os serviços.
Um dos aspectos mais importantes do plano de segurança é uma especificação das
pessoas que devem estar envolvidas na implementação da segurança de rede:
• Serão contratados administradores de segurança especializados?
• Como os usuários finais e seus gerentes estarão envolvidos?
• Como os usuários finais, gerentes e pessoal técnico serão treinados sobre
normas e procedimentos de segurança?
Para ser útil, um plano de segurança precisa ter o apoio de todos os níveis de
funcionários dentro da organização. É muito importante que a administração corporativa
19
apoie plenamente o plano de segurança. O pessoal técnico da rede e de locais remotos
deve se envolver no plano, da mesma forma que os usuários finais (Oppenheimer, 1999).
3.4. NORMA DE SEGURANÇA
Norma de segurança é uma declaração formal das regras às quais as pessoas que
têm um determinado acesso à tecnologia e aos ativos de informações de uma organização
devem obedecer. (RFC 2196, The Site Security Handbook).
Pode-se definir ainda, norma de segurança como sendo um estatuto no qual estão
transcritas regras de nível intermediário, ou seja, entre o nível estratégico e o de
descrição de procedimentos, cujo cumprimento visa garantir a segurança das informações
e recursos de uma instituição, dentro de um segmento particular do ambiente desta
corporação.
A norma de segurança informa aos usuários, gerentes e ao pessoal técnico de suas
obrigações para proteger os ativos de tecnologia e informações. A norma deve especificar
os mecanismos pelos quais estas obrigações podem ser cumpridas. Da mesma forma que o
plano, a norma de segurança deve ter o comprometimento de funcionários, gerentes,
executivos e pessoal técnico. O desenvolvimento de uma norma de segurança é trabalho
dos administradores de redes.
Uma vez desenvolvida, a norma de segurança deve ser explicada a todos pela
gerência superior. Muitas empresas exigem que o pessoal assine uma declaração
indicando que leu, compreendeu e concorda em cumprir as normas.
A norma de segurança é um documento vivo. Pelo fato de as organizações
mudarem continuamente, as normas de segurança devem ser atualizadas com
regularidade a fim de refletirem novas orientações comerciais e mudanças tecnológicas
(Oppenheimer, 1999).
3.5. PROCEDIMENTOS DE SEGURANÇA
Os procedimentos de segurança implementam normas de segurança, definem
processos de configuração, login, auditoria e configuração.
Podem-se definir procedimentos de segurança como sendo um estatuto no qual
estão transcritas regras de nível operacional, ou seja, a nível de descrição de execução de
20
ações, cujo cumprimento visa garantir a segurança das informações de uma instituição,
dentro de um segmento particular do ambiente da corporação.
Devem ser escritos procedimentos de segurança para usuários finais,
administradores de redes e administradores de segurança. A divulgação deve ser restrita
aos funcionários diretamente envolvidos.
Os procedimentos de segurança devem especificar como controlar incidentes (quer
dizer, o que fazer e quem contatar se uma intromissão for detectada), fazer auditoria e
desenvolver o plano de contingência com objetivo de manter o negócio da Secretaria de
Receita sempre ativo.
Os procedimentos de segurança podem ser comunicados aos usuários e
administradores em turmas de treinamento lideradas por instrutores qualificados.
3.6. ARQUITETURA DE SEGURANÇA
Com base na norma de segurança, é criado um documento denominado política de
segurança para ser divulgado em toda empresa. Para implementar a política de segurança
deve ser criada uma arquitetura de segurança que consiste na aplicação de todos os
controles físicos, lógicos, técnicos e administrativos necessários para a garantia da
segurança da informação (ROBERTI, 2001). Com base nessa arquitetura, são criados o
plano de contingência e o processo de auditoria.
Uma arquitetura de segurança representa um elenco de recomendações que define
os princípios e fundamentos que devem ser observados na implementação de um ambiente
considerado seguro em relação aos riscos, impactos e custos ao qual ele está submetido.
Em um ambiente como o da Secretaria de Receita, baseado na arquitetura cliente-
servidor, deve existir uma arquitetura de segurança com potencial necessário para atingir
todas as metas e objetivos de segurança desejáveis sem comprometer a capacidade de
adaptabilidade e a independência dos recursos de TI (Tecnologia da Informação).
Para tanto, a arquitetura de segurança recomendada deve fornecer as bases para os
aspectos de segurança dos seguintes elementos: aplicações, dados, comunicação de dados e
gerência de sistemas e rede.
Uma arquitetura de segurança deve levar em consideração três elementos básicos:
pessoas, o modelo de segurança e a junção de padrões e tecnologias.
21
É importante salientar que a arquitetura de segurança proposta deve conduzir a
implementações que sejam financeiramente possíveis para a organização. Para tanto, a
arquitetura deve possuir as seguintes qualidades:
• Ser independente de plataforma operacional, aplicação de rede;
• Ser alavancada por tecnologias de segurança amadurecidas, por exemplo:
criptografias e cartão inteligente;
• Estar em conformidade com padrões infacto, como por exemplo a norma
ISO/IEC 17799:2000 e CobiT;
• Definir relacionamentos entre os componentes de segurança: autenticação e
permissão de acesso, por exemplo;
• Ter performance e disponibilidade dos mecanismos de segurança;
• Possuir um modo consistente de gerenciamento; e
• Obter a conscientização de usuários finais.
Ambientes de TI como os da Secretaria de Receita geralmente são dinâmicos e
sujeitos a muitas pressões da sociedade. Uma arquitetura de segurança eficiente e eficaz
deve levar em conta o trinômio: pessoas, padrões e tecnologias usadas em um Modelo de
Segurança.
3.7. MODELO DE SEGURANÇA
O conjunto de todos os controles, procedimentos e mecanismos de segurança,
denomina-se modelo de segurança que, se corretamente implementado, pode reduzir o
custo do desenvolvimento e do gerenciamento da segurança.
Um modelo de segurança deve prover a habilidade de proteger adequadamente a
informação. Em um ambiente confiável, antes de qualquer entidade (usuários, funcionários,
programas) confiar em um sistema, é necessário saber quais recursos podem ser utilizados
com segurança e quais informações são confidenciais.
Um modelo de segurança endereça os requisitos técnicos de segurança exigidos
conforme figura a seguir.
22
Figura 1 – Requisitos do Modelo de Segurança.
Fonte: Arquitetura de Segurança desenvolvido pela HP para o Tribunal Superior Eleitoral
A fundação consiste de declarações claras e concisas, políticas e procedimentos de
segurança da instituição que servirão como guia para a gerência de riscos, proteção de
dados e recursos, recuperação e para assegurar conformidade às leis e regulamentos
aplicáveis à arquitetura de segurança.
Os princípios de segurança são declarações particulares que definem o que a
segurança significa para a organização e como será administrada. É através dos princípios
que a Arquitetura de Segurança será definida. Os princípios indicam itens como
identificação, requisitos de autenticação e os controles.
Entende-se por ambiente confiável a combinação de segurança, performance e
disponibilidade dentro dos limites aceitáveis e definidos nos princípios e na política de
segurança.
Os controles referem-se a gerência e mensuração das operações sobre sistemas e
dados no ambiente.
3.8. HISTÓRICO DAS NORMAS DE PADRONIZAÇÃO DE SEGURANÇA
Nas últimas duas décadas, países como Estados Unidos, França, Alemanha,
Holanda, Reino Unido e Canadá têm se empenhado no desenvolvimento de Padrões de
MODELO DE SEGURANÇA
AMBIENTE CONFIÁVEL
SEGURANÇA
AUTORIZAÇÃO
CONFIDENCIALIDADE
INTEGRIDADE
AUTENTICAÇÃO
NÃO REPÚDIO
PERFORMANC
DISPONIBILIDADE RECUPERAÇÃO
CONTINUIDADE
DURABILIDADE
CONSISTÊNCIA
ACESSO FÍSICO CONTROLES
ACESSO À REDE
GERÊNCIA
MONITORAÇÃO E DETECÇÃO
GERÊNCIA DE MUDANÇAS
AUDITORIA
FUNDAÇÃO
POLÍTICAS DE SEGURANÇA
PRINCÍPIOS DE SEGURANÇA
PADRÕES E CRITÉRIOS DE SEGURANÇA
EDUCAÇÃO
23
Segurança para Tecnologia da Informação. A enorme disponibilidade de produtos no
mercado internacional gerou a necessidade de padrões que pudessem ter ampla aceitação e
aplicabilidade no mercado. Como o comércio não poderia dispor e avaliar produtos em
múltiplos países com múltiplos padrões, tornou-se necessária uma normatização e
posteriormente uma harmonização.
O Departamento de Defesa dos Estados Unidos lançou em 1983 o Trusted
Computer System Evaluation Criteria - (TCSEC), conhecido como o Orange Book, cuja
versão final saiu em 1985.
O Orange Book (TCSEC) define a Política de Segurança e conceitos de
responsabilidade, garantia e documentação. Este último descreve o tipo, a evidência escrita
na forma de guias de usuário, testes, manuais, e modelo de documentação requerido a cada
tipo de evento. Os sistemas de administração de redes, banco de dados e periféricos não
foram suficientemente conceituados por esta norma.
A primeira tentativa de desenvolver um critério padrão foi o Information
Technology Security Evaluation Criteria - (ITSEC), lançado em junho de 1991, elaborado
pela França, Alemanha, Holanda e Reino Unido e adotado pelos países membros do
Mercado Comum Europeu.
O ITSEC faz a primeira tentativa de desenvolver critérios padronizados para a
Comunidade Européia. Esta norma européia introduz o conceito de separar as exigências
funcionais e as exigências de garantia, e permite a seleção arbitrária da segurança funcional
a níveis de graus de garantia.
A norma canadense, a Canadian Trusted Computer Product Evaluation Criteria -
(CTCPEC), passou a ser o critério de normatização do Canadá (janeiro de 1993, última
edição).
A canadense, CTCPEC, alarga o horizonte para incluir sistemas monolíticos,
sistemas multi-processados, bancos de dados, subsistemas, sistemas distribuídos, sistemas
de rede, e outros. Os critérios divididos anteriormente em funcionalidade e confiabilidade
passam a serem divididos na CTCPEC, em quatro critérios: a confidencialidade, a
integridade, a disponibilidade e a legitimidade, estes critérios são definidos como critérios
da garantia em TI.
O Federal Criteria for Information Technology Security foi elaborado em conjunto
pelo National Institute of Standards and Technology (NIST) e o National Security Agency
(NSA) dos Estados Unidos, Vol. 1 em dezembro de 1992 e vol. 2 em janeiro de 1993.
24
O Federal Criteria tem como característica a especificação, o desenvolvimento e a
avaliação de produtos de segurança para TI. A chave deste esforço é o avanço do estado da
arte da segurança em TI e a harmonização de esforços internacionais.
Em Janeiro de 1996, os Estados Unidos, Reino Unido, Alemanha, França, Canadá e
Holanda publicaram uma avaliação de padrões desenvolvida em conjunto para um mercado
multinacional. Este padrão é conhecido como Common Criteria for Information
Technology Security Evaluation - CCITSE (Critério Comum para Avaliação de Segurança
da Tecnologia da Informação), geralmente referido apenas como “Common Criteria” (CC).
O Common Criteria pode ser usado por consumidores para ajudá-los a decidir quais
produtos de segurança comprar baseados nas classificações do CC, e também para publicar
suas exigências de segurança de forma que os vendedores possam desenvolver produtos
que estejam de acordo com as mesmas. O CC pode ser útil para os desenvolvedores
auxiliando na escolha de quais requisitos de segurança vão incluir em seus produtos, para
desenvolver e criar produtos de forma a provar aos avaliadores que tais produtos
preenchem os requisitos, e para determinar suas responsabilidades em apoiar e avaliar seus
produtos. O CC também serve para auxiliar os avaliadores a julgar se um produto preenche
ou não os requisitos de segurança e para fornecer dados quando estiver formando métodos
específicos de avaliação.
O Common Criteria é um esforço multinacional de escrever um sucessor para o
TCSEC e ITSEC, que combina os melhores aspectos de ambos. Uma versão inicial (v. 1.0)
foi publicada em Janeiro de 1996, a versão 2.0 em maio de 1998 e a última versão em
agosto de 1999.
O modelo de referência OSI/ISO/IEC inicialmente foi elaborado para permitir a
interconexão entre sistemas baseados em diferentes plataformas. O modelo básico foi ao
longo do tempo sendo complementado com adição de outros documentos, dentre eles o
ISO/IEC 7498-2 que trata dos aspectos relativos à segurança e sua forma de aplicação em
circunstâncias onde é necessário proteger os dados, a comunicação, os recursos e os
usuários do ambiente.
A arquitetura de segurança ISO estabelece, em conjunto com o esquema básico
definido no modelo de referência, orientações e restrições para o aperfeiçoamento dos
padrões existentes além de guiar o desenvolvimento de novos padrões, visando permitir
comunicações cada vez mais seguras e prover uma abordagem consistente para segurança
em ambiente ISO.
25
A arquitetura de segurança apresentada no modelo ISO/IEC 7498-2 possui os
seguintes objetivos:
• Descrever os serviços de segurança e os mecanismos a eles relacionados e
• Definir a posição dos serviços de segurança e dos mecanismos associados no
modelo de referência.
A arquitetura ISO trata exclusivamente dos aspectos de segurança relacionados à
comunicação entre os sistemas finais não abrangendo medidas de segurança que devem ser
adotadas nos sistemas complementares necessárias para garantir a proteção completa dos
recursos e dados do sistema.
A origem da ISO/IEC 17799:2000 remonta aos dias do Centro Comercial de
Segurança na Computação (CCSC) do Departamento de Comércio Britânico (DTI).
Fundado em maio de 1987, o CCSC tinha duas principais tarefas: a primeira era auxiliar os
vendedores de produtos de segurança de TI a estabelecer um conjunto de critérios de
avaliação de segurança reconhecido internacionalmente, bem como um esquema associado
de avaliação e certificação; a segunda tarefa era ajudar os usuários a produzirem um código
de boas práticas de segurança que resultou em um “Código de Práticas para Usuários”,
publicado em 1989. O National Computing Center (NCC) e posteriormente um consórcio
de usuários, principalmente da Indústria Britânica, deram continuidade ao seu
desenvolvimento para garantir que o Código era tanto significativo quanto prático do ponto
de vista dos usuários. O resultado final foi publicado, a princípio, como um documento de
orientação dos Padrões Britânicos, o PD 0003. Consistia em um código de práticas para
gerenciamento de segurança da informação. Seguindo um período de mais consultas
públicas, foi posteriormente relançado como a British Standard BS7799:1995. Uma
segunda parte, a BS 7799-2:1998 foi adicionada em fevereiro de 1998. Após um período
de extensivas revisões e consultas públicas que iniciou em novembro de 1997, a primeira
revisão do padrão, a BS7799:1999, foi publicada em abril de 1999. A parte 1 do padrão foi
proposta como um padrão ISO em outubro de 1999 e aprovada por maioria em votação
internacional em agosto de 2000. Em outubro de 2000, oito pequenas modificações ao
texto da BS foram aprovadas e o padrão foi publicado como ISO/IEC 17799:2000 em 1 de
dezembro de 2000. Neste ínterim, o comitê responsável pelo desenvolvimento da BS 7799
está se preparando para atualizar a parte 2 de forma a ser proposta como padrão ISO.
A ISO/IEC 17799:2000 tem como objetivo permitir que companhias que cumprem
a norma demostrem publicamente que podem resguardar a confidencialidade, integridade
a disponibilidade das informações de seus clientes.
26
A ISO/IEC 17799:2000 fornece mais de 127 orientações de segurança estruturadas
em 10 títulos principais para possibilitar aos leitores identificarem os controles de
segurança apropriados para sua organização ou áreas de responsabilidade. Além de
fornecer controles detalhados de segurança para computadores e redes, a ISO/IEC
17799:2000 dá orientações sobre políticas de segurança, conscientização sobre segurança
para os funcionários, plano de continuidade dos negócios e requisitos legais.
3.9. POLÍTICA DE SEGURANÇA
A política de segurança tem por objetivo prover à administração uma direção e
apoio para a segurança da informação. A administração deve estabelecer uma política
clara e demonstrar apoio e comprometimento com a segurança da informação através da
emissão e manutenção de uma política de segurança da informação para toda a
organização (ISO/IEC 17799:2000).
Uma política de segurança é a expressão formal das regras pelas quais é fornecido
acesso aos recursos tecnológicos da empresa.
O principal propósito de uma política de segurança é informar aos usuários,
equipe e gerentes, as suas obrigações para a proteção da tecnologia e do acesso à
informação. A política deve especificar os mecanismos através dos quais estes requisitos
podem ser alcançados. Outro propósito é oferecer um ponto de referência a partir do qual
se possa adquirir, configurar e auditar sistemas computacionais e redes, para que sejam
adequados aos requisitos propostos. Portanto, uma tentativa de utilizar um conjunto de
ferramentas de segurança na ausência de pelo menos uma política de segurança implícita
não faz sentido (RFC 2196).
A política deve especificar as metas de segurança da organização, onde as
responsabilidades recaem, e qual o comprometimento da organização com a segurança.
Uma vez que a política é um estatuto, é necessário que a sua elaboração, aprovação e
aplicação sigam os ritos internos da instituição na qual será aplicada.
O caráter estratégico de uma política de segurança deve garantir que a mesma
aborde questões que são essenciais para a corporação como um todo. Cada regra da política
serve como referência básica para a elaboração do conjunto de regras particulares e
detalhadas que compõem as normas e os procedimentos de segurança.
Com o intuito de tornar a política de segurança um instrumento que viabilize a
aplicação prática e a manutenção de uma infra-estrutura de segurança para a instituição, é
27
necessário que a política seja desdobrada em estatutos mais detalhados. Estes estatutos
podem ser referidos como políticas específicas, normas, regras complementares, ou
controles. Outros níveis podem existir, tal qual numa hierarquia, sendo que o limite será
ditado pelas necessidades e conveniências da instituição para a qual são elaborados as
regras de segurança. Cabe ressaltar que, quanto mais baixo o nível hierárquico de um
documento de segurança em relação à política, mais detalhado e de caráter operacional
será.
É importante lembrar que toda regra aplicada a uma instituição deve estar em
consonância com os objetivos fins da mesma. A segurança não é um fim em si mesma, mas
um meio para se chegar a um objetivo maior.
A política de segurança como um elemento institucional da organização possui um
ciclo de vida indefinido e deve prever todos os mecanismos de defesa contra qualquer
ameaça conforme estabelecido no estudo de custos x benefícios. Considerando a
mutabilidade de tais elementos e dos próprios objetivos e metas da organização, uma
política só apresentará efetividade ao longo do tempo se sofrer constantes reavaliações e
atualizações conforme o ciclo de etapas mostrado a seguir.
Figura 2 – Processo de uma Política de Segurança
3.9.1. Visão Geral de uma Política de Segurança
A elaboração de um programa sistematizado de segurança de informações parte da
análise das seguintes indagações:
Administração
Auditoria Implementação
Diretrizes e normas
28
• O que se deseja proteger?
• Contra que ou quem?
• Quais são as ameaças mais prováveis?
• Qual a importância de cada recurso?
• Qual o grau de proteção desejado?
• Quanto tempo, recursos financeiros e humanos se pretendem gastar para atingir
os objetivos de segurança desejados?
• Qual a expectativa dos usuários e clientes em relação à segurança das
informações?
• Quais as conseqüências no caso dos recursos serem corrompidos ou roubados?
Obtidas as respostas às indagações acima, deve-se atentar para os seguintes
princípios que norteiam um bom programa de segurança de informação:
• Confidencialidade – garantia contra o acesso de qualquer pessoa/entidade não
explicitamente autorizada;
• Integridade – garantia de que os dados não sejam apagados ou de alguma forma
alterados sem a permissão competente;
• Disponibilidade – garantia de que os serviços e os dados estejam disponíveis no
momento em que são requisitados por pessoa ou entidade autorizada.;
É preciso conhecer os riscos, saber quais as conseqüências da falta de segurança,
identificar os pontos vulneráveis e determinar uma solução adequada para a organização. O
primeiro passo para isto é avaliar o valor do bem ou recurso a ser protegido e sua
importância para a organização, o que ajuda a definir quanto vale a pena gastar com
proteção. Custo neste contexto significa incluir perdas expressas em moeda corrente real,
reputação, confiança e outras medidas menos óbvias.
Uma das razões mais importantes de criar uma política de segurança da informação
é assegurar que esforços despendidos em segurança renderão benefícios efetivos. Embora
isto possa parecer óbvio, é possível se enganar sobre onde os esforços são necessários.
Como por exemplo, existe muita publicidade sobre intrusos externos em sistemas de
computadores, mas a grande parte das pesquisas sobre segurança mostram que, para a
maioria das organizações, a maior perda ocorre com intrusos internos.
A análise de risco envolve determinar o que se deve proteger, do que se deve
proteger, e como proteger. Este é o processo de examinar todos os riscos e ordenar esses
29
riscos por nível de severidade. Este processo envolve a tomada de decisão sobre o custo
benefício do que se deve proteger.
3.9.2. Identificação dos Recursos
O primeiro passo de uma análise de risco é a identificação de todos os elementos
que necessitam de proteção. Alguns são óbvios, tais como informações proprietárias,
propriedade intelectual e todos os vários componentes de hardware; mas, alguns são
negligenciados, tal como as pessoas que de fato usam os sistemas. O ponto de partida é a
lista de todos as partes que podem ser afetadas por um problema de segurança. Conforme
sugerido por Pfleeger (Pfleeger, 1989), a seguir está uma lista de categorias:
• Hardware: CPUs, boards, teclados, terminais, estações de trabalho,
computadores pessoais, impressoras, discos, drives, linhas de comunicação,
servidores de terminais, roteadores;
• Software: programas fonte, programas objeto, utilitários, programas de
diagnóstico, sistemas operacionais e programas de comunicação;
• Dados: durante execução, armazenados on-line, arquivados off-line, backups,
logs de auditoria, bancos de dados e mídia de comunicação;
• Pessoas: usuários, administradores e suporte de hardware;
• Documentação: programas, hardware, sistemas, local, procedimentos
administrativos; e
• Materiais: papel, formulários, fitas e mídia magnéticas.
3.9.3. Considerações Importantes
O domínio das ferramentas de proteção disponíveis no mercado aliado a uma
consistente análise dos riscos constituem a base para a formação de um sólido programa
destinado à segurança institucional dos dados de uma organização e irá determinar quão
segura é a rede de comunicação e os dados nela residentes. Uma política de segurança não
deve prejudicar os processos de produção da organização, sendo assim, deve preocupar-se
com as funcionalidades que irá manter e qual será a facilidade de utilizá-las. No entanto,
não é possível tomar boas decisões sobre segurança, sem antes determinar quais são as suas
metas de segurança.
30
Uma política de segurança deve nortear seus objetivos a partir das seguintes
considerações:
• Serviços oferecidos versus segurança fornecida - Cada serviço oferecido para os
usuários carrega seu próprio risco de segurança. Para alguns serviços, o risco é
superior ao benefício do mesmo, e o administrador deve optar por eliminar o
serviço ao invés de tentar torná-lo menos inseguro;
• Facilidade de uso versus segurança - O sistema mais fácil de usar deveria
permitir acesso a qualquer usuário e não exigir senha, isto é, não haveria
segurança. Solicitar senhas torna o sistema um pouco menos conveniente, mas
mais seguro. Requerer senhas one-time geradas por dispositivos, torna o sistema
ainda mais difícil de utilizar, mas bastante mais seguro; e
• Custo da segurança versus o risco da perda - Há muitos custos diferentes para
segurança: monetário (o custo da aquisição de hardware e software como
Firewalls, e geradores de senha one-time), performance (tempo de cifragem e
decifragem), e facilidade de uso. Há também muitos níveis de risco: perda de
privacidade (a leitura de uma informação por indivíduos não autorizados), perda
de dados (corrupção ou deleção de informações), e a perda de serviços (ocupar
todo o espaço disponível em disco, impossibilidade de acesso à rede). Cada tipo
de custo deve ser contrabalançado ao tipo de perda.
Os objetivos, metas e regras devem ser comunicados indistintamente a todos os
usuários, pessoal operacional, e gerentes através de um conjunto de regras de segurança,
chamado de Política de Segurança.
3.9.4. Premissas Básicas
Uma política de segurança deve ser elaborada visando toda a organização a que se
prestará e suas concepções institucionais, desta forma, necessita observar alguns princípios
elementares elencados a seguir:
• Apoiar-se sempre nos objetivos da organização e nunca em ferramentas e
plataformas;
• Descrever o programa geral de segurança da rede, dados, ambientes e pessoas;
• Demonstrar os riscos e ameaças que está combatendo e as proteções propostas;
• Definir responsabilidades para implementação e manutenção de cada proteção;
31
• Definir normas e padrões comportamentais para usuários, para que o documento
seja utilizado como prova se ocorrer alguma violação; e
• Definir sanções e penalidades.
3.9.5. Conteúdo Essencial
Como instrumento de caráter institucional, uma política de segurança deve
apresentar em seu contexto, no mínimo, os seguintes elementos:
• Justificativa da importância da adoção dos procedimentos de segurança
explicando-os junto aos usuários para que o entendimento dos mesmos leve ao
comprometimento com todas as ações de segurança;
• Identificação precisa de quem desenvolveu as orientações, quem as aprovou,
quem detém privilégios e determina autorizações, e quem é afetado pelas
orientações;
• Descrição dos procedimentos para fornecimento e revogação de privilégios,
informação de violação de segurança;
• Determinação da gerência específica e responsabilidades dos envolvidos no
controle e manuseio do ambiente operacional;
• Identificação dos recursos que se quer proteger e que software são permitidos
em quais locais; e
• Descrição dos procedimentos para os casos de exceção.
3.9.6. Principais Atores
Para que uma política de segurança se torne apropriada e efetiva, ela deve ter a
aceitação e o suporte de todos os níveis de empregados dentro da organização. É
especialmente importante que a gerência corporativa suporte de forma completa o processo
da política de segurança, caso contrário haverá pouca chance que ela tenha o impacto
desejado. A seguinte lista de indivíduos deve estar envolvida na criação e revisão dos
documentos da política de segurança:
• Representante da administração superior da organização;
• Administrador de segurança do site;
• Suporte técnico;
32
• Desenvolvedores de softwares;
• Administradores de grandes grupos de usuários dentro da organização;
• Representantes de todos os grupos de usuários afetados pela política de
segurança; e
• Help-Desk.
Vários fatores podem trazer efetividade para uma política de segurança, dentre
outros, destacam-se:
• Ser implementável por meio de procedimentos administrativos anteriormente
instituídos;
• Possuir regras de uso aceitáveis;
• Ser implementada por meio de ferramentas de segurança quando apropriado, e
aplicar sanções onde a prevenção efetiva não for tecnicamente possível;
• Possuir definições claras das áreas de responsabilidade para os usuários,
administradores e gerentes;
• Possuir guias para a compra de tecnologia computacional que especifiquem os
requisitos ou características que os produtos devem possuir;
• Conter a indicação de uma política de privacidade que defina expectativas
razoáveis de privacidade relacionadas a aspectos como a monitoração de correio
eletrônico, logs de atividades, e acesso aos arquivos dos usuários;
• Discriminar uma política de acesso que defina os direitos e os privilégios para
proteger a organização de danos, através da especificação de linhas de conduta
dos usuários, pessoal e gerentes. Ela deve oferecer linhas de condutas para
conexões externas, comunicação de dados, conexão de dispositivos a uma rede,
adição de novos softwares, entre outros. Também deve especificar quaisquer
mensagens de notificação requeridas (por exemplo, mensagens de conexão
devem oferecer aviso sobre o uso autorizado e monitoração de linha, e não
simplesmente welcome);
• Definir uma política de contabilidade que indique as responsabilidades dos
usuários. Deve especificar a capacidade de auditoria, e oferecer a conduta no
caso de incidentes (por exemplo, o que fazer e a quem contatar se for detectada
uma possível intromissão);
33
• Viabilizar uma política de autenticação que estabeleça confiança por meio de
uma política efetiva de senhas, através da linha de conduta para autenticação de
acessos remotos e o uso de dispositivos de autenticação;
• Possuir um documento de disponibilidade que defina as expectativas dos
usuários para a disponibilidade de recursos. Ele deve endereçar aspectos como
redundância e recuperação, bem como especificar horários de operação e de
manutenção. Ele também deve incluir informações para contato para relatar
falhas de sistema e de rede;
• Definir uma tecnologia de informação e política de manutenção de rede que
descreva como, tanto o pessoal de manutenção interno como externo, devem
manipular e acessar a tecnologia. Um tópico importante a ser tratado aqui é
como a manutenção remota é permitida e como tal acesso é controlado. Outra
área para considerar é a terceirização e como ela é gerenciada;
• Definir um relatório de violações que indique quais os tipos de violações devem
ser relatados e a quem estes relatos devem ser feitos. Uma atmosfera de não
ameaça e a possibilidade de denúncias anônimas irá resultar em uma grande
probabilidade de uma violação ser relatada; e
• Oferecer aos usuários informações sobre como agir na ocorrência de qualquer
tipo de violação.
Pode haver requisitos regulatórios que afetem alguns aspectos de uma política de
segurança tal como a monitoração. Os criadores da política devem considerar a busca de
assistência legal na criação da mesma. No mínimo, a política deve ser revisada por um
conselho legalmente instituído para tal fim.
Uma vez estabelecida, a política deve ser claramente comunicada aos usuários,
pessoal e gerentes. Deve-se criar um documento que os usuários assinem, afirmando que
leram, entenderam e concordaram com a política estabelecida (vide Anexo II). Esta é uma
parte importante do processo. Finalmente sua política deve ser revisada regularmente para
verificar se está suportando com sucesso suas necessidades de segurança.
3.9.7. Flexibilidade
No intuito de tornar a política viável a longo prazo, é necessária bastante
flexibilidade baseada no conceito de segurança arquitetural. Uma política deve ser
34
largamente independente de hardware e software específicos. Os mecanismos para a
atualização da política devem estar claros. Isto inclui o processo e as pessoas envolvidas.
Também é importante reconhecer que há expectativas para cada regra. Sempre que
possível a política deve expressar quais expectativas foram determinadas para a sua
existência. Por exemplo, sob que condições um administrador de sistema tem direito a
pesquisar nos arquivos do usuário. Também pode haver casos em que múltiplos usuários
terão acesso à mesma userid. Por exemplo, em sistemas com um usuário root, múltiplos
administradores de sistema talvez conheçam a senha e utilizem a conta.
3.9.8. Classificação das Informações
Segundo Claudia Dias (Dias, 2000), diferentes tipos de informação devem ser
protegidos de diferentes maneiras. Por isso a classificação das informações é um dos
primeiros passos para o estabelecimento de uma política de segurança de informações.
Um vez classificada a informação, a política pode definir como tratá-la de acordo com sua
classe, escolhendo mecanismos de segurança mais adequados.
A classificação mais comum de informações é aquela que as divide em 04 níveis:
1) Públicas ou de uso irrestrito: as informações e os sistemas assim classificados
podem ser divulgados a qualquer pessoa sem que haja implicações para a instituição.
Exemplo: serviços de informação ao público em geral, informações divulgadas à
imprensa ou pela internet
2) Internas ou de uso interno: as informações e os sistemas assim classificados não
devem sair do âmbito da instituição. Porém, se isto ocorrer, as conseqüências não serão
críticas.
Exemplo: Serviços de informação interna ou documentos de trabalho corriqueiros
que só interessam aos funcionários.
3) Confidenciais: informações e sistemas tratados como confidenciais dentro da
instituição e protegidos contra o acesso externo. O acesso a estes sistemas e informações é
feito de acordo com sua estrita necessidade, isto é, os usuários só podem acessá-los se
estes forem fundamentais para o desempenho satisfatório de suas funções na instituição. O
acesso não autorizado a esses dados e sistemas pode comprometer o funcionamento da
instituição, causar danos financeiros ou perdas de fatias do mercado para o concorrente.
Exemplo: Dados pessoais de clientes e funcionários, senhas, informações sobre
vulnerabilidades de segurança dos sistemas institucionais, contratos , balanços entre outros.
35
4) Secretas: o acesso interno ou externo de pessoas não autorizadas a este tipo de
informação é extremamente crítico para a instituição. É imprescindível que o número de
pessoas autorizadas seja muito restrito e o controle sobre o uso dessas informações seja
total.
Exemplo: Informações dos contribuintes, declarações de imposto de renda.
3.9.9. Análise de Riscos
Análise de riscos é a análise das ameaças, impactos e vulnerabilidades das
informações e das instituições de processamento das mesmas e da probabilidade de sua
ocorrência. O gerenciamento de risco é o processo de identificação, controle e
minimização ou eliminação dos riscos de segurança que podem afetar os sistemas de
informação a um custo aceitável (ISO/IEC 17799:2000).
Muitas vezes o termo risco é utilizado como sinônimo de ameaça ou da
probabilidade de uma ameaça ocorrer. Na verdade, risco é uma combinação de
componentes, tais como ameaças, vulnerabilidades e impactos em um determinado
ambiente, de forma a proporcionar a adoção de medidas apropriadas tanto às necessidades
de negócio da instituição ao proteger seus recursos de informação, como aos usuários que
precisam utilizar esses recursos, levando em consideração justificativas de custos, nível de
proteção e facilidade de uso.
A análise de risco é o ponto chave da política de segurança englobando tanto a
análise de ameaças e vulnerabilidades quanto a análise de impactos, a qual identifica os
componentes críticos e o custo potencial aos usuários do sistema.
Para tomar as devidas precauções, é preciso inicialmente identificar as ameaças e os
impactos, determinar a probabilidade de uma ameaça se concretizar e entender os riscos
potenciais, classificando-os por nível de importância e severidade da perda, e os custos
envolvidos na sua prevenção ou recuperação. Se combater uma ameaça for mais caro do
que seu dano potencial, talvez não seja aconselhável tomar quaisquer medidas preventivas
neste sentido.
Os riscos podem apenas ser reduzidos, já que é impossível eliminar todos. A quebra
de segurança sempre poderá ocorrer.
Conhecer com antecedência as ameaças aos recursos informacionais e seus
impactos pode resultar em medidas efetivas para reduzir as ameaças, as vulnerabilidades e
conseqüentemente os impactos.
36
3.9.9.1. Riscos Externos
Relacionados a seguir estão alguns tipos de riscos externos aos quais
freqüentemente as organizações estão sujeitas:
Vírus, Worms e Trojans
Segundo o CSI/FBI Computer Crime and Security Survey, os vírus estão em
primeiro lugar entre as principais ameaças à segurança da informação no ano de 2001.
Os vírus podem ser inofensivos (apenas mostram uma mensagem ou tocam uma
música), ou nocivos apagando ou modificando arquivos do computador. Podem ser
inseridos por hackers que entram no sistema e plantam o vírus, através de e-mails ou
disquetes contaminados.
Os códigos de vírus procuram entre os arquivos dos usuários, programas
executáveis sobre os quais os usuários têm direito de escrita. Ele infecta o arquivo
colocando nele parte de um código. Quando um arquivo de programa está infectado com
vírus é executado e o vírus imediatamente assume o comando, encontrando e infectando
outros programas e arquivos.
A seguir estão algumas características de um vírus:
• Consegue se replicar;
• Precisa de um programa “hospedeiro” portador’;
• É ativado por uma ação externa; e
• Sua habilidade de replicação é limitada aos sistema virtual.
Na mesma categoria dos vírus, estão os warms, que são programas projetados para
replicação e possuem as seguintes características, algumas das quais os diferenciam dos
vírus.
• Eles se replicam, assim como os vírus;
• São entidades autônomas, não necessitam se atracar a um programa ou arquivo
“hospedeiro”, ao contrário dos vírus;
• Residem, circulam e se multiplicam em sistemas multi-tarefa;
• Para worms de rede, a replicação ocorre através dos links de comunicação.
37
O Trojan (Cavalos de Tróia) é um código escondido em um programa, tal como um
jogo ou uma tabela que tem a aparência de seguro, mas possui efeitos escondidos. Quando
o programa é rodado, parece funcionar como o usuário esperava, mas na verdade está
destruindo, danificando ou alterando informações por trás. É um programa em si mesmo e
não requer um “hospedeiro” para carregá-lo. Geralmente são espalhados por e-mails.
Intercessão
Eavesdropping e Packet Sniffing - São intercessões de pacotes no tráfego para leitura
por programas de usuários não legítimos. O sniffer pode ser colocado na estação de
trabalho conectada à rede, bem como em roteadores ou gateways. Este método é utilizado
para intercessão de logins e senhas de usuários, números de cartões de crédito e
direcionamento das trocas de e-mails estabelecendo as relações entre indivíduos e
organizações.
Snoofing e Downloading - São intercessões do mesmo tipo do sniffer sem
modificação do conteúdo dos pacotes embora a ação seja diferente, pois o atacante se
apossa de documentos que trafegam na rede, fazendo download para a sua própria
máquina, interceptando e-mails e outros tipos de informações.
Modificação e Fabricação
Tampering ou Data Diddling. Esta categoria trata da modificação não autorizada de
dados. Com um software instalado em um sistema o atacante modifica ou apaga arquivos.
Entre as vítimas estão bancos, autarquias fiscais, escolas, e outros tipos de bancos de
dados. Na Web há inúmeros exemplos de home pages invadidas para colocação de slogans
ou marcas de presença.
A utilização de cavalos de Tróia está dentro desta categoria para tomar controle
remoto dos sistemas vítimas. Entre os programas mais comuns estão o Back Orifice e o
NetBus, que são camuflados com esta finalidade
Spoofing - Esta técnica consiste em atuar em nome de usuário legítimo para
realizar tarefas de tampering ou snoofing. Uma das formas pode ser o envio de e-mail falso
em nome da vítima, invasão de outros computadores ou até um terceiro, ou ainda outros de
forma que oculte sua identidade. Esta forma de looping torna muito difícil a sua
identificação. A base desta atuação é tomar posse do logins e senhas das vítimas.
38
Interrupção
Jamming ou Flooding. São interrupções do funcionamento do sistema através da
saturação de dados, pode ser espaço de um disco ou envio de pacotes até a saturação do
tráfego da rede vítima impossibilitando-a de receber os pacotes legítimos.
O atacante satura o sistema com mensagens de que querem estabelecer conexão
através de vários computadores com a vítima e ao invés de indicar a direção do IP dos
emissores estas direções são falsas. O sistema responde as mensagens, mas como não
recebe as respostas acumula o buffer com informações em aberto, não dando lugar às
conexões legítimas. Outros ataques comuns são “ping da morte” e a saturação de e-mails.
Bombas Lógicas - O ataque consiste em programas sabotadores introduzidos nas
máquinas das vítimas com intuito de destruir as informações ou paralisá-las.
Engenharia Social
Este mecanismo de recolhimento de informações é uma das formas mais perigosas
e eficientes utilizada pelos hackers.
Um bom exemplo de ataque de engenharia social é o de ligar para um setor de
informática de uma corporação, dizendo ser um novo funcionário de um determinado setor
e dizer que precisa de um username e senha para acesso ao sistema. Muitas vezes o hacker,
consegue através deste telefonema, o username e a senha necessários para o início de seu
ataque.
Uma forma mais fácil ainda é de ligar para o setor de informática dizendo ser “o
fulano de tal” que esqueceu a senha, e gostaria que a senha fosse trocada. Claro que desta
forma, o hacker tem que conhecer o nome de um usuário do sistema que esteja há muito
tempo sem utilizá-lo.
Variando muito de organização para organização, a obtenção de informações
através de engenharia social ainda é utilizada com muito sucesso em diversas organizações
e seu sucesso depende exclusivamente do conhecimento do pessoal em assuntos de redes e
computadores. A melhor defesa contra este ataque é o treinamento dos funcionários e
usuários de redes e computadores.
39
3.9.2.2. Riscos Internos
Os riscos internos são decorrentes de duas fontes principais, desastres naturais e
pessoas. Não se podem prever ou evitar os desastres naturais tais como enchentes, raios, ou
incêndios, que podem causar sérios danos aos sistemas de computação. Contudo, é
necessário implementar defesas contra eles. A melhor ação a ser tomada é ter em vigor um
plano de recuperação de desastres.
Os riscos pessoais podem ser causados por empregados insatisfeitos ou apenas
descuidados.
Os empregados insatisfeitos podem tentar sabotar o sistema de informação, das
seguintes formas:
• Modificando ou apagando dados;
• Destruindo dados ou programas com bombas lógicas;
• Derrubando os sistemas;
• Destruindo os equipamentos ou instalações; e
• Inserindo dados incorretamente.
Os empregados descuidados geralmente não tem intenção de causar nenhum dano
ao sistema, mas podem apagar arquivos importantes, estragar um computador pelo mal
uso, acessar informações indevidas e entrar informações incorretas no sistema.
3.9.10. Análise de Ameaças
Antes de decidir como proteger um sistema é necessário saber contra o que ele será
protegido.
Segundo o 2001 CSI/FBI Computer Crime and Security Survey, as principais
ameaças à segurança da informação no ano de 2001 foram:
1o. lugar: Vírus de computador
2o. lugar: Uso interno indevido do acesso à rede
3o. lugar: Roubos de notebooks
4o. lugar: Acesso interno não autorizado
5o. lugar: Penetração externa no sistema.
40
Segundo Claudia Dias (Dias, 2000) a análise das ameaças e vulnerabilidades do
ambiente de informática deve levar em consideração todos os eventos adversos que podem
explorar as fragilidades de segurança desse ambiente e acarretar danos.
Alguns conceitos importantes para se realizar uma análise de ameaças são:
• Recurso: componente de um sistema computacional, podendo ser recurso
físico, software, hardware ou informação;
• Vulnerabilidade: fraqueza ou deficiência que pode ser explorada por uma
ameaça. Pode ser associada à probabilidade da ameaça ocorrer;
• Ataque: ameaça concretizada;
• Impacto: conseqüência de uma vulnerabilidade do sistema ter sido explorada
por uma ameaça. É o resultado da concretização de uma ameaça;
• Probabilidade: chance de uma ameaça atacar com sucesso o sistema
computacional;
• Risco: medida de exposição a qual o sistema computacional está sujeito.
Depende da probabilidade de uma ameaça atacar o sistema e do impacto
resultante deste ataque.
Ameaça é tudo aquilo que pode comprometer a segurança de um sistema, podendo
ser acidental (falha de hardware, erros de programação, desastres naturais, erros do
usuário, bugs de software) ou deliberada (roubos, espionagem, fraude, sabotagem,
invasão de hackers, entre outros).
Iindependentemente do tipo, as ameaças consideradas mais comuns em um
ambiente informatizado são:
• Vazamento de informações (voluntário ou involuntário) – informações
desprotegidas ou reveladas a pessoas não autorizados;
• Violação de integridade - comprometimento da consistência de dados;
• Indisponibilidade de serviços de informática - impedimento deliberado de
acesso aos recursos computacionais por usuários não autorizados; e
• Acesso e uso não autorizado - um recurso computacional é utilizado por pessoa
não autorizada ou de forma não autorizada.
41
3.9.11. Auditoria
A auditoria envolve o exame de recursos: lógicos, tecnológicos, sistemas de
aplicativos, físicos e humanos em uma entidade a fim de garantir na informação: a
eficiência, a efetividade, a confidencialidade, a integridade, a disponibilidade, a
confiabilidade e o cumprimento dos objetivos estabelecidos. Isto a faz a principal auxiliar
na administração de um sistema de dados, dando-lhe suporte na monitoração, no
planejamento e organização, na aquisição e implementação e na distribuição e suporte
(CobiT, 2000); pois a eficácia administrativa está no domínio destes conhecimentos
continuamente adquiridos.
No atual estágio do desenvolvimento da tecnologia de informação composta por
pessoas, dados, máquinas e ambiente que além de complexos, interagem entre si, o próprio
processo se transforma antes mesmo de se ter um conhecimento profundo de suas etapas,
aumentado assim sua vulnerabilidade. A prática da auditoria é o meio fundamental para
acompanhar este dinamismo e reduzir os riscos nas etapas atuais e futuras.
A metodologia de auditoria para que as Secretarias de Receita desenvolvam uma
Governança de TI, a fim de alcançar os objetivos de receber e distribuir pecúlio às outras
secretarias, será baseado na tecnologia de auditoria CobiT, como meio de desenvolver este
conceito.
A Governança de TI se alicerça em três pilastras: o domínio, o recurso e a
informação. O domínio é a metodologia empregada. O recurso são os instrumentos
disponíveis à governabilidade de TI. A informação é o conteúdo que estabelece os critérios
de qualidade para o negócio das Secretarias de Receita.
42
Figura 3 - Metodologia CobiT
Dimensionamento da Auditoria: x=Domínio; y=Informação; t= Objetivo do negócio; z=Recursos de Tecnologia da Informação; x* y* z= Governança de TI (figura baseada na metodologia CobiT de Auditoria)
3.9.12. Plano de Contingência
Contingência de segurança computacional é um evento com potencial para
interromper operações computacionais, e consequentemente as missões críticas e funções
dos negócios. Tais eventos podem ser uma queda de energia, falha de hardware, incêndio
ou tempestade. Se um evento for muito destrutivo, é geralmente chamado de desastre. De
forma geral, três categorias de desastres podem afetar as organizações:
• Desastres naturais (eventos);
• Desastres técnicos (panes); e
• Desastres relacionados a seres humanos (comportamento).
Para evitar possíveis contingências e desastres ou minimizar os danos que eles
causam, as organizações podem tomar medidas de precaução para controlar o evento.
Geralmente chamada de Plano de Contingência (também conhecido como plano de
recuperação de desastre, de continuidade do negócio, de continuidade das operações, ou de
43
retomada do negócio), esta atividade está intimamente ligada ao manejo de incidentes, que
primeiramente trata ameaças técnicas maliciosas tais como hackers e vírus.
O objetivo do Plano de Contingência é não permitir a interrupção das atividades
do negócio e proteger os processos críticos contra efeitos de grandes falhas ou desastres
(ISO/IEC 17799:2000).
Os planos de contingência devem ser desenvolvidos e implementados para garantir
que os processos do negócio possam ser recuperados no tempo devido. Tais planos devem
ser mantidos e testados de forma a se tornarem parte integrante de todos os outros
processos gerenciais (ISO/IEC 17799:2000).
Os seguintes passos devem ser seguidos no processo de elaboração de um plano de
contingência:
a) Identificar as funções críticas da organização;
b) Identificar os recursos que dão suporte às funções críticas;
c) Antecipar potenciais contingências ou desastres;
d) Selecionar as estratégias do plano de contingência;
e) Implementar as estratégias de contingência; e
f) Testar e revisar a estratégia.
Para a elaboração de um plano de contingência eficaz, é crucial que se observem os
seguintes elementos-chave:
a) Obter o apoio da alta diretoria;
b) Possuir um objetivo claro que defina exatamento o que o plano vai realizar;
c) Priorizar as funções críticas para manter a empresa em funcionamento;
d) Verificar quais recursos financeiros estão disponíveis para o realizar o plano
que for necessário;
e) Definir claramente as responsabilidades de todos os envolvidos estabelecendo
antecipadamente quem é o responsável por cada tarefa de recuperação e
exatamente o que essa responsabilidade significa;
f) Evitar um ponto único de falha para que o sucesso ou falha do plano inteiro não
deve ficar sob a responsabilidade de uma única pessoa. Deve haver uma cadeia
de comando, descrevendo quem assume o controle por alguém se um
funcionário morrer ou tornar-se inapto para desempenhar suas tarefas; e
g) Ter flexibilidade, ou seja, um bom plano deve ser atualizado anualmente ou
conforme a necessidade da empresa/organização.
44
De acordo com a ISO/IEC 17799:2000, o processo de planejamento da
continuidade do negócio deve considerar os seguintes itens:
a) Definição e reconhecimento de todas as responsabilidades e procedimentos de
emergência;
b) Implementação dos procedimentos de emergência que viabilizem a
recuperação e restauração nos prazos necessários. Especial atenção deve ser
dada à análise de dependência de recursos e serviços externos aos negócios e
aos contratos existentes;
c) Documentação dos processos e procedimentos definidos;
d) Treinamento adequado da equipe nos procedimentos e processos de
emergências definidos, incluindo a gerência de crise;
e) Teste de atualização dos planos.
De acordo com o NIST Handbook a estratégia de um plano de contingência
consiste de três partes: resposta de emergência, recuperação e retomada. A resposta de
emergência aborda as ações iniciais tomadas para proteger vidas e limitar danos.
Recuperação refere-se aos passos tomados para continuar o suporte às funções críticas.
Retomada é o retorno às operações normais.
A estratégia utilizada para possibilitar a capacidade de processamento está agrupada
nas seguintes categorias:
• Hot site (instalações quentes) – Um prédio equipado de antemão com
capacidade de processamento e outros serviços;
• Cold site (instalações frias) – Um prédio para abrigar processadores que podem
ser facilmente adaptados para uso;
• Site redundante – Um local equipado e configurado exatamente como o
primeiro;
• Acordo de reciprocidade – Um acordo que permite que duas organizações
apoiem uma a outra.
• Híbridas – Qualquer combinação acima, tal como usar um hot site como backup
caso uma instalação redundante seja destruída por uma outra contingência.
Seja qual for o tipo de instalação, quente, fria, ou híbrida a equipe de suporte
precisa estar apta a preencher as seguintes funções:
45
• Armazenar cópias do plano contra desastres da empresa;
• Permitir que sua empresa funcione tanto como uma unidade administrativa;
quanto como uma unidade operacional; e
• Armazenar backups de dados e a biblioteca de software.
3.10. FERRAMENTAS DE SEGURANÇA
Com base no levantamento dos riscos, ameaças e vulnerabilidades que podem
afetar a segurança das informações, apresentamos a seguir algumas das ferramentas de
segurança mais freqüentemente utilizadas.
3.10.1. Criptografia
A criptografia tem como objetivo, proteger a confidencialidade, autenticidade e
integridade das informações. Técnicas e sistemas criptográficos devem ser usados para a
proteção das informações que são consideradas de risco e para aquelas que os outros
controles não fornecem proteção adequada.
Baseado na análise de risco, o nível apropriado de proteção deve ser identificado
levando-se em conta o tipo e a qualidade do algoritmo criptográfico usado e o tamanho
das chaves a serem utilizadas (ISO/IEC 17799:2000).
A criptografia é tão antiga quanto a própria escrita. Os romanos utilizavam códigos
secretos para comunicar planos de batalha. Contudo, somente depois da Segunda Guerra
Mundial, com a invenção do computador, o uso da criptografia tomou maior impulso em
seu desenvolvimento. O trabalho criptográfico formou a base para a ciência da computação
moderna.
3.10.1.1. Algoritmos Criptográficos
Existem dois tipos básicos de algoritmos criptográficos que podem ser utilizados
tanto sozinhos como em combinação. Estes algoritmos, chave única e chave pública e
privada, são usados para diferentes aplicações e deve-se analisar qual é o melhor para cada
caso.
Para que uma mensagem seja cifrada utilizam-se uma ou mais chaves (seqüência de
caracteres) que serão embaralhadas com a mensagem original. Estas chaves devem ser
46
mantidas em segredo, pois somente com o conhecimento delas é que se poderá decifrar a
mensagem.
O primeiro tipo de algoritmo que surgiu foi o de chave única, também chamado de
algoritmo de chave simétrica. Neste, o sistema usa a mesma chave tanto para a cifragem
como para a decifragem dos dados, e esta deve ser mantida em segredo.
3.10.1.2. Criptografia Simétrica
A Criptografia Simétrica consiste em transformar, utilizando-se uma chave K e uma
função y=f(x), um texto legível (informação aberta) – x - em um texto ilegível (informação
criptografada) – y – O texto y é transmitido para o destino onde y é decriptografado pelo
algoritmo inverso f –1 (y) obtendo-se o texto legível – x – se e só se o destinatário conhece a
chave K, a qual deve ser utilizada no algoritmo inverso f –1 (y). Para quem desconhece a
chave K é computacionalmente difícil obter-se y a partir do conhecimento de x se o
algoritmo for bem projetado, isto é, se for seguro.
3.10.1.3. Algoritmos de Chave Simétrica
DES (Data Encryption Standard) - Uma cifra de bloco criada pela IBM e
endossada pelo governo dos Estados Unidos em 1977. O DES utiliza uma chave de 56 bits
e opera em blocos de 64 bits. Projetado para ser implementado em componentes de
hardware, ele é relativamente rápido e é usado com freqüência para criptografar grandes
volumes de dados de uma só vez. O DES é usado em muitas aplicações mais seguras da
Internet, incluindo a SSL (Secure Sockets Layer) e a maioria das alternativas mais seguras
do IP.
DES Triplo (Triple DES) - O DES triplo é uma evolução do DES, no qual um
bloco de dados é criptografado três vezes com diferentes chaves.
Vistos os anúncios da possibilidade do cálculo da chave secreta do DES por força
bruta estarem sendo cada vez mais viáveis economicamente em função inclusive do
tamanho desta chave (56 bits), a NIST (National Institute of Standards in Technology
antiga NBS - National Bureau of Standards) lançou em 1997 uma competição aberta para
o sucessor do DES, chamado AES – Advanced Encryption Standard. Nesta competição
foram apresentadas 18 propostas, sendo que das cinco finalistas foi escolhido, entre
duzentos, o algoritmo de criptografia Rijndael, produzido por dois Belgas.
47
Algumas das vantagens do AES são: poder usar chaves de 128, 192 e 256 bits ou
maiores e ser executado eficazmente em um grande número de ambientes, cartões
inteligentes, softwares de computador e browsers, enquanto o DES foi projetado
principalmente para hardware
Outro problema do DES foram as mudanças propostas pela NSA nas S-Boxes do
algoritmo original (Lucifer), visto que alguns observadores temiam que essa mudança
poderia introduzir uma armadilha e poderia permitir que um atacante decifrasse mensagens
criptografadas pelo DES sem testar todas possíveis chaves.
Os S-boxes são tabelas não-lineares que determinam como o algoritmo de
criptografia substitui bytes por outros.
RC2 e RC4 - Ron Rivest da RSA DSI (Data Security Inc.) projetou essas cifras
com tamanho de chave variável para proporcionar uma criptografia em alto volume que
fosse muito rápida. Pode ser usado como substituto do DES, pois ambos são cifras de
bloco. Em softwares, o RC2 é aproximadamente 2 vezes mais rápido do que o DES, ao
passo que o RC4 é 10 vezes mais rápido que o DES.
O IDEA (International Data Encryption Algorithm) foi criado em 1991, sendo
projetado para ser facilmente calculado em softwares. É bastante forte e resistente a várias
formas de criptoanálise. Opera com blocos de textos em claro no tamanho de 64 bits e
possui uma chave de 128 bits, sendo que o mesmo algoritmo é usado para cifrar e decifrar
os textos.
3.10.1.4. Criptografia Assimétrica
O problema da criptografia simétrica é que as partes na comunicação devem
conhecer a mesma chave, que deve ser divulgada entre as partes de forma sigilosa, pois se
um terceiro elemento não autorizado tiver acesso à chave poderá comprometer a segurança
atribuída pela criptografia.
Como solução para tal situação temos o algoritmo de chaves assimétricas. Esta
solução é composta basicamente de um algoritmo de criptografia e de decriptografia (o
qual pode ser ou não de conhecimento público, mas deve ser conhecido pelas partes de
uma comunicação) e um par de chaves (conhecidas como chave privada e chave pública) e
que tem, basicamente, as seguintes premissas:
48
• A informação criptografada por uma chave só pode ser decriptografada pela
outra;
• Uma chave não pode ser descoberta a partir da outra (mesmo conhecendo o
algoritmo de criptografia e de decriptografia e tendo a informação
criptografada); e
• A chave pública de uma entidade é amplamente divulgada sendo que a chave
privada só é de conhecimento da mesma.
Dessa forma a comunicação entre duas partes, como por exemplo A e B, é feita
como se segue:
• Tanto A quanto B possuem, cada um, um par de chaves (pública e privada);
• Se A deseja enviar a B, ele solicita a chave pública de B;
• De pose da chave pública de B, A criptografa a informação com essa chave e
envia a B; e
• A mensagem criptografada com a chave pública de B só pode ser
decriptografada pela chave privada de B.
Algoritmos assimétricos (ou de chave pública e privada) são muito complexos
sendo que as chaves utilizadas são números primos entre si e de valores muito grandes, o
que torna muito lenta a cifragem e decifragem de uma grande quantidade de dados.
Por isso, geralmente, algoritmos assimétricos são utilizados apenas para estabelecer
sessão e a troca, de forma confiável, entre as partes envolvidas na comunicação, de uma
chave simétrica.
Um dos parâmetros para se medir a resistência de um algoritmo é o tamanho de
suas chaves. Quanto maior o número de bits das chaves, maior o número de possíveis
combinações e, teoricamente, maior a resistência do algoritmo contra ataques.
3.10.1.5. Algoritmos de Chave Assimétrica
Dentre os diversos algoritmos de chave assimétrica destacam-se:
Diffie-Hellman – Protocolo para troca de chaves, criado antes do RSA, e
modificado posteriormente, visto que pode ser “quebrado” por um intruso que capta toda a
troca de informações.
49
RSA - É um algoritmo criado e patenteado pela RSA Data Security Inc., porém com
uso liberado para quaisquer aplicações. Baseado na dificuldade computacional de se fatorar
um número inteiro muito longo (por exemplo 512 bytes de tamanho) em dois números
primos.
A segurança do RSA está baseada no problema de fatorar números grandes.
Miller e Rabin – Outro algoritmo de criptografia assimétrica muito usado. Similar
ao RSA mas é um algoritmo probabilístico, no sentido de que se pode concluir falsamente
que o número inteiro é primo mas com baixa probabilidade.
3.10.1.6. Algoritmos para Geração de Assinatura Digital.
Consiste de algoritmos que utilizam chaves privada e pública para, a partir de um
texto legível de tamanho m, gerar uma informação criptografada de tamanho n onde n é
muito menor que m.
Tal função em um algoritmo assimétrico é conhecida como função de Hash ou de
Espalhamento.
Os algoritmos mais conhecidos são o MD5 (Message Digest 5), que é um
aprimoramento do MD4, e o RSA, também usado para gerar assinaturas digitais de 128
bits para mensagens de qualquer tamanho.
O RSA é um algoritmo que gera assinaturas digitais de 160 bits para mensagens de
qualquer tamanho. É considerado mais seguro que o MD5, porém tem uma performance
em média 50% inferior, mas é considerado um algoritmo bastante rápido além de seguro.
A segurança do RSA está baseada no problema de fatorar números grandes.
Um dos fatores que determinam a popularidade do RSA é o fato de ele também
poder ser usado para assinatura digital (ver 3.10.2 – PKI).
3.10.2. PKI (Public Key Infrastructure)
É o processo de certificação digital que possibilita a identificação inequívoca da
identidade, procedência e conteúdo das informações, baseado na troca de chaves
criptografadas.
Uma PKI é utilizada para prover a identificação de uma entidade eletrônica
(usuário, computador, etc.) na Internet.
50
A identificação digital de um usuário é chamada de Certificado Digital, o qual
possui o nome, chave pública (ver criptografia assimétrica) e outros dados de um usuário.
É usado para validar uma assinatura digital que pode ser anexada a um e-mail ou formatos
eletrônicos.
As chaves privadas são armazenadas em um hard disk ou em um Token. Neste caso
a chave somente pode ser utilizada quando o token for inserido no computador (um
exemplo é o smart card).
Uma PKI é composta dos seguintes componentes:
• CA - (Certificate Authorities – Autoridade Certificadora) : Responsável por
criar, distribuir e revogar certificados digitais.
• RA - (Registration Authorities - Autoridade Registradora): Registra novos
usuários.
Podemos citar ainda outros conceitos utilizados em PKI:
• Certificação: é o processo de associação de uma chave pública a um usuário.
• Validação: verificação se o certificado está ou não expirado e se as informações
nele são verdadeiras.
• Revogação: um certificado não pode ser apagado ou reutilizado. Quando o
mesmo não é mais válido é marcado pela CA como revogado.
Os usuários da PKI podem descobrir o status atual de um certificado digital
utilizando o processo Real-time Online Certificate Status Checking.
Figura 4 - Funcionamento do Processo Real-time Online Certificate Status Checking:
1 – Certificado Emitido
CA
www.sef.df.gov.br
Usuário
2 – Certificado Enviado
3 – Checando e Validando
51
Outro modo, menos confiável, de checar o status de um certificado requer que os
usuários da PKI façam um download de uma lista de certificados revogados (CRL) pela
CA.
O maior problema das CRLs é o fato de que muitos certificados são revogados por
dia. Uma empresa pode correr risco, pelo fato de possuir uma CRL desatualizada, de estar
confiando em um certificado que acabou de ser revogado.
3.10.2.1. Assinatura Digital
As assinaturas digitais fornecem os meios para proteção da autenticidade e
integridade de documentos eletrônicos (ISO/IEC 17799:2000).
Para criar uma assinatura digital para uma mensagem de e-mail, por exemplo, uma
cópia da mensagem é criptografada (algoritmo Hash) usando a chave privada (assinatura
digital), a qual é enviada, junto com a mensagem de e-mail e o certificado digital do
remetente para o destinatário, que cria a assinatura digital utilizando a chave pública do
remetente e compara com a assinatura recebida. A assinatura digital somente pode ser
decriptografada e verificada usando-se a chave pública embutida no certificado digital do
remetente, garantindo assim que uma mensagem não foi falsificada por terceiros.
3.10.3. Firewall
Firewall é um sistema baseado em software ou hardware capaz de controlar o
acesso entre duas redes ou sistemas, impedindo acessos indevidos e ataques.
O firewall de uma rede não é apenas um roteador ou servidor para defesa. É na
verdade, uma combinação de elementos, com o objetivo de oferecer segurança às
informações que trafegam na rede, seja ela uma intranet ou internet.
É um dos elementos utilizados para segmentar a rede e criar um perímetro de defesa
definido em uma política de segurança.
Um dos maiores benefícios do firewall é o de facilitar o trabalho do administrador
da rede que consolida a segurança no sistema de firewall evitando distribuir todo um
esquema de segurança por cada um dos servidores que integram a rede privativa.
O firewall oferece um ponto de segurança que pode ser monitorado e, caso apareça
alguma atividade suspeita, gera um alarme antes que ocorra efetivamente um ataque ou
suceda algum problema no trânsito dos dados.
52
A preocupação principal de um administrador de rede são os múltiplos acessos à
Internet que podem ser controlados através do firewall. Cada um destes pontos de acesso
significa um ponto potencial de ataque à rede interna, os quais devem ser monitorados
regularmente.
Um firewall não pode proteger a rede contra os seguintes ataques:
• Backdoors (portas dos fundos) - modem conectado à rede interna e à Internet
via telefônica, por exemplo;
• De engenharia social;
• Vírus passados internamente através de arquivos e softwares; e
• Possíveis ataques em transferência de dados. Isto ocorre quando aparentemente
dados inofensivos são enviados e copiados em um servidor interno e executados
despachando um ataque.
As premissas do sistema de firewall que descrevem a filosofia fundamental da
segurança da organização são as seguintes:
• Tudo que não é especificamente permitido, é proibido.
• Tudo que não é especificamente proibido é permitido.
Um firewall típico se compõe de uma ou mais combinações dos seguintes
obstáculos:
• Roteador filtra-pacotes;
• Gateways a nível de aplicação; e
• Gateways a nível de circuito.
O roteador toma decisões de recusar ou permitir a entrada de cada um dos pacotes
que são recebidos. O roteador examina cada datagrama para determinar se este corresponde
a um dos seus pacotes filtrados e se foi aprovado por suas regras de filtro. Quando se avalia
um roteador para ser usado para filtragem de pacotes, os seguintes critérios devem ser
observados: endereços de IP origem e destino, números de porta TCP origem e destino,
estado do bit ACK no pacote TCP, números de porta UDP origem e destino, e direção do
fluxo de pacotes.
O problema do filtro de pacotes IP é que não pode prover um controle eficiente
sobre o tráfego. Ele pode permitir ou negar um serviço em particular, mas não é capaz de
compreender o contexto todo deste serviço.
53
O gateway de aplicação pode ser configurado para suportar unicamente as
características específicas de uma aplicação que o administrador considere relevantes,
negando todas as outras.
O gateway de aplicação pode também exercer a função de um servidor proxy o qual
é utilizado para concentrar serviços de aplicação através de uma única máquina.
O Statefull Inspection é um firewall composto por um filtro de pacotes mais
inteligente. Permite uma verificação a nível de camada de aplicação sem requerer um proxy
para cada tipo de serviço segurado. Conhece os estados de cada comunicação que passa
pela máquina do firewall, incluindo pacote, conexão e informação de aplicação. Servidores
de segurança fazem a verificação do conteúdo de acordo com a definição do usuário.
O maior esforço atual em técnicas de firewall é encontrar uma combinação de um
par de roteadores de filtragem com um ou mais servidores proxy na rede entre dois
roteadores. Esta configuração permite ao roteador externo bloquear qualquer tentativa de
usar a camada IP subjacente para quebrar a segurança, enquanto permite ao servidor proxy
tratar potenciais furos de segurança nos protocolos das camadas superiores. A finalidade do
roteador interno é bloquear todo tráfego exceto para o servidor proxy.
Os firewalls podem ser uma grande ajuda quando se está implementando segurança
em um site e protegem contra uma variedade de ataques. Mas são apenas uma parte da
solução. Eles não podem proteger seu site contra todos os tipos de ataques.
3.10.4. Anti-Vírus
Anti-vírus é um software capaz de detectar e eliminar viroses de computador,
assegurando integridade e disponibilidade das informações.
3.10.4.1. Softwares de Prevenção
Os programas de prevenção permanecem residentes em memória durante todo o
período de uso do computador. Eles acompanham todos os processos do sistema, atentos
para sinais de contaminação ou reprodução do vírus. Esses programas filtram os acessos a
arquivos feitos por outros programas. Um dos maiores defeitos dos softwares de prevenção
é que a maioria deles não consegue evitar a contaminação do segmento de boot. A razão é
simples: a contaminação do segmento de boot acontece durante a inicialização da máquina,
quando o software antivírus nem foi carregado para a memória. Apesar disso, após a
54
inicialização do computador conseguem identificar a contaminação e indicam o
procedimento para a remoção do vírus.
3.10.4.2. Softwares de Detecção
Os programas de detecção baseiam-se no princípio de que uma contaminação pode
ser localizada e contida imediatamente após ter ocorrido. Os programas detectam o vírus
por meio das pistas deixadas por eles durante a invasão do sistema. Os programas de
detecção são mais eficazes que os de prevenção e detectam qualquer tipo de vírus. A
forma mais eficaz de proteção disponível atualmente é alcançada por produtos que usam a
técnica que cria uma imagem do disco. Esse tipo de programa de detecção cadastra todas as
informações críticas do sistema na hora da instalação inicial de cada pacote de software,
incluindo o sistema operacional e o segmento de boot. Depois disso, uma verificação
rotineira é executada para comparar as informações cadastradas com as atuais, isto é,
comparar a imagem do disco original contra a atual. Se traços de contaminação forem
detectados, a área do disco será identificada e o usuário, alertado. Os softwares antivírus
que usam essa técnica têm sido muito bem sucedidos na identificação de uma grande
variedade de vírus digitais.
3.10.4.3. Software de Identificação
Esse tipo de programa antivírus somente funciona nos casos em que o vírus que
contaminou o sistema é conhecido. O vírus será identificado pelo programa que pesquisa
no disco rígido a procura de características internas e específicas de cada tipo de vírus nele
cadastrado. Uma vez localizado o vírus, o programa efetua uma alteração no arquivo
contaminado, tentando restaurar seu formato original.
3.10.4.4. Requisitos Básicos de um Antivírus
A seguir estão alguns requisitos básicos que um software antivírus deve possuir:
• Capacidade de monitorar todo o tráfego de arquivos e informações e o sistema
computacional (programas/processos em execução, memória e interrupções do
computador);
55
• Capacidade de detectar vírus quando o arquivo estiver sendo executado,
copiado, movido, renomeado ou aberto, por outro programa;
• Tomar medidas de prevenção com as seguintes opções de configuração: limpar,
excluir, tornar inacessível o arquivo contaminado ou apenas avisar sobre
arquivo infectado;
• Detectar e tomar medidas de prevenção para todos os tipos de vírus (vírus de
inicialização, vírus de programa, vírus polimorfos, vírus de macros para
arquivos produzidos pelos produtos/softwares do MS-Office, “Cavalos de
Tróia”, controles Active X, applets Java, VB Script e outros códigos);
• Detectar e tomar medidas de prevenção contra vírus desconhecidos pela
ferramenta antivírus ofertada;
• Oferecer em tempo real para downloads da Internet (via HTTP, FTP, SMTP ou
POP3) e para arquivos e informações provenientes da rede de computadores a
qual o equipamento está conectada;
• Detectar e tomar medidas de prevenção em arquivos compactados, no mínimo,
para os formatos PKZIP, ZIP2EXE, ZIP, ARJ, RAR e CAB;
• Ser ativado/inicializado toda vez que o computador for ligado; e
• Opção inteligente para atualização via internet (HTTP e FTP), arquivo local de
rede e executável.
3.10.5. VPN (Virtual Private Network)
Sistema implementado por software ou hardware capaz de assegurar uma conexão
de dados segura em meios públicos (como a internet) através de mecanismos de
autenticação e criptografia.
Uma VPN garante a segurança (modificação e interceptação) de dados transmitidos
pela Internet e a redução de custos com comunicação corporativa. Links dedicados podem
ser substituídos pela Internet.
As LANs podem, através de links dedicados ou discados, conectar-se a algum
provedor de acesso local e interligar-se a outras LANs, possibilitando o fluxo de dados
através da Internet. Esta solução pode ser muito interessante sob o ponto de vista
econômico, sobretudo nos casos em que enlaces internacionais ou nacionais de longa
distância estão envolvidos.
56
O acesso remoto a redes corporativas utilizando a Internet pode ser viabilizado com
a tecnologia VPN através da ligação local a um provedor de acesso. A estação remota disca
para o provedor de acesso, conectando-se à Internet e o software de VPN cria uma rede
virtual privada entre o usuário remoto e o servidor de VPN corporativo através da Internet.
As VPNs possibilitam a conexão física entre redes locais, restringindo acessos
indesejados através da inserção de um servidor VPN entre elas. O servidor VPN não irá
atuar como um roteador entre a rede departamental e o resto da rede corporativa uma vez
que o roteador permitiria a conexão entre as duas redes autorizando o acesso de qualquer
usuário à rede departamental sensitiva.
Adicionalmente, toda comunicação ao longo da VPN pode ser criptografada
assegurando a confidencialidade das informações.
Uma VPN pode ser implementada de dois modos: tunelamento e por pacote, sendo
que o primeiro é o mais usado.
Para a implementação de uma VPN é necessário o uso de Gateway ou roteador
VPN (alguns roteadores de borda fazem este papel) que crie o túnel de comunicação
segura.
Para se implementar uma VPN entre duas redes (ou até mesmo um notebook ou um
computador de casa e uma rede LAN) interconectadas através de uma terceira rede (esta
pública como a internet ou até mesmo frame-relay, ATM ou X.25) deve-se utilizar em cada
uma um gateway VPN (que inclusive pode ser um software de comunicação ou até o
próprio sistema operacional que utiliza protocolo de comunicação que suporta VPN em um
notebook por exemplo).
A informação enviada entre as redes passa por um gateway VPN que forma o túnel,
encapsula e criptografa a informação a nível de rede (padrão atual é IPSEC). Depois, o
pacote criptografado é roteado e enviado via internet, por exemplo, como um datagrama IP
normal.
Na comunicação remota o protocolo de comunicação para transmissão segura é o
PPTP (Point-to-Point Tunneling Protocol), que é a extensão do PPP usado em conexões
dial-up tradicionais. Um cliente VPN é requerido no equipamento do usuário móvel
(alguns sistemas operacionais como o Windows 2000 suportam o protocolo PPTP).
57
3.10.5.1. IPSec
O problema das soluções de segurança, a nível de camada de aplicação, é que são
específicas para um ou outro serviço/aplicação.
Como resposta a isto, um subgrupo do IETF (Internet Engineering Task Force)
desenvolveu um padrão para comunicação TCP/IP de forma genérica. Esta solução é
chamada de IPSec (IP Security Suite).
Toda a comunicação LAN, WAN e Internet utiliza o controle de roteamento
baseado na camada de rede. O IPSec funciona como uma subcamada logo acima da
camada IP.
O padrão IPSec provê segurança a nível de autenticação, confiabilidade e
confidencialidade.
De forma geral, para garantir a segurança, o IPSec criptografa o pacote IP. Os
procedimentos utilizados são os seguintes:
ESP (Encapsulating Security Payload) – O ESP possibilita a construção de túneis
(tunelamento) criptografados, onde o header e o payload do datagrama IP são
encapsulados e criptografados (utilizando algoritmo simétrico) no novo payload do IPSec,
então ele adiciona um novo header contendo o IP destino do gateway VPN. Desta forma, o
IPSec oferece a vantagem de esconder da Internet os endereços IP originais, impedindo a
leitura por ataques de monitoração de tráfego. Como parte final da operação, o payload
agora é autenticado com algoritmos de hash (assinatura digital).
AH (Authentication Header) – Depois de criado o novo header, este deve ser
autenticado. A autenticação do AH difere do ESP porque a autenticação do AH não
protege as informações que estão no cabeçalho do pacote IPSec, mesmo porque alguns
campos são alterados à medida em que atravessam a rede em função do roteamento. A
autenticação deve suportar algoritmos de hash específicos e que estejam dentro do padrão
IPSec.
IKE (Internet Key Exchange) – Para as parte envolvidas em uma transmissão de
dados segura se comunicarem é preciso serem concluídas três etapas importantes:
• Negociação entre as partes sobre protocolos, algoritmos de criptografia e chaves
a serem utilizadas na sessão;
• Troca de chaves de um modo eficiente; e
• Manter estes requisitos durante a conversação.
58
O IKE funciona basicamente em duas fases: a primeira é o estabelecimento de uma
sessão segura (utilizando-se chaves assimétricas) e a segunda é a negociação da troca das
chaves.
3.10.6. IDS (Intrusion Detection System )
A detecção de intrusos é uma tecnologia de segurança capaz de identificar e isolar
intrusões contra um sistema de computação e iniciar procedimentos de alerta e contra-
ataque. Diferentes IDSs têm diferentes classificações de intrusão. Um sistema tentando
detectar ataques contra servidores Web pode considerar apenas pedidos maliciosos HTTP,
enquanto que um sistema que se proponha a monitorar protocolos dinâmicos de roteamento
pode considerar apenas RIP spoofing. Independente do tipo, os IDSs compartilham uma
definição geral de intrusão, que é o uso não autorizado ou inadequado de um sistema de
computação.
A detecção de intrusos é um componente importante de um sistema de segurança e
complementa outras tecnologias. Ao fornecer informações ao administrador do site, o IDS
permite não apenas a detecção de ataques explicitamente endereçados por outros
componentes de segurança (tais como firewalls), como também tentativas de notificação
de novos ataques não previstos por outros componentes,
Os IDSs também fornecem informação que potencialmente permitem às
organizações descobrirem as origens de um ataque. Desta forma, os IDSs tentam fazer com
que os “atacantes” se tornem responsáveis por suas ações, e até certo ponto, servem para
desestimular futuros ataques.
Devido a sua importância dentro de um sistema de segurança, é crucial que o IDS
funcione conforme a expectativa da organização que o está implementando. Para que o IDS
seja útil, o administrador do site precisa poder confiar na informação fornecida pelo
sistema. Sistemas com falhas não só fornecem menos informações, como também uma
perigosa falsa sensação de segurança.
Dadas as implicações de falhas em um componente do IDS, é correto presumir que
os IDSs em si são alvos óbvios para ataques. Um intruso mais esperto que perceba que um
IDS foi implementando em uma rede que ele está atacando irá muito provavelmente atacar
primeiro o IDS tentando desabilitá-lo ou forçando-o a dar informações falsas (distraindo o
pessoal de segurança do verdadeiro ataque).
59
Para que um componente de software possa resistir a ataques, ele precisa ser
projetado e implementado com um entendimento claro sobre os meios específicos pelos
quais ele pode ser atacado.
3.10.7. Backup
Sistema que possibilita a reprodução e a posterior restauração de informações a
partir de meios magnéticos, ópticos e outros.
Backup dos dados essenciais do negócio e de arquivos de programa devem ser
feitos regularmente. Recursos e instalações alternativos devem ser disponibilizados de
forma a garantir que todos os dados e sistemas aplicativos essenciais ao negócio possam
ser recuperados após um desastre ou problemas em mídias. Procedimentos alternativos
para sistemas independentes devem ser regularmente testados para a garantia de que eles
satisfaçam os requisitos dos planos de continuidade de negócios. Os seguintes controles
devem ser considerados:
1) Um nível mínimo de cópias de segurança, juntamente com o registro completo
e atualizado destas cópias e com a documentação dos procedimentos de
recuperação, devem ser mantidos em local remoto a uma distância suficiente
para livrá-los de qualquer dano que possa ocorrer na instalação principal;
2) Os backups devem ser objeto de proteção física e ambiental compatíveis com os
padrões utilizados no ambiente principal. Os controles adotados para as mídias
e para o ambiente principal devem ser estendidos para o ambiente alternativo;
3) As mídias utilizadas para backup devem ser periodicamente testadas, sempre
que possível, de modo a garantir a sua confiabilidade de uso quando for
necessário em caso de emergência; e
4) Os procedimentos de recuperação devem ser verificados e testados
periodicamente para garantia de sua efetividade e de que podem ser
completados dentro do prazo determinado nos procedimentos operacionais
para recuperação. (ISO/IEC 17799:2000).
Fazer backup dos dados e programas de uma rede é uma das ferramentas de
segurança mais fáceis e baratas de serem implementadas em uma organização, contudo
pode ser facilmente negligenciado quando tudo parece estar funcionando bem.
Infelizmente, várias empresas só descobrem a importância da implementação de um bom
60
plano de backup quando perdem seus dados por um acidente na sala do servidor, ou por um
descuido de algum usuário apagando todos os seus arquivos.
3.10.8. RADIUS (Remote Authentication Dial In User Service)
O RADIUS é um padrão utilizado para autenticação remota.
As funções primárias do servidor RADIUS são autenticação e autorização de
usuários remotos (dial-up) para conexão a uma rede.
Um servidor RAS (ou qualquer servidor NAS - Network Access Server) passa a ser
um cliente do servidor RADIUS (também conhecido como proxy RADIUS). A negociação
entre o usuário e o RADIUS se dá basicamente da seguinte forma:
Todo usuário, ao conectar-se a um servidor RAS, deve informar as suas credencias
(nome, senha, e outras quando necessário). O servidor RAS encaminha ao proxy RADIUS
um pedido de acesso contendo as credenciais do usuário (access-request), as quais são
analisadas pelo RADIUS.
O RADIUS valida o usuário e retorna ao RAS as permissões e configurações do
usuário (access-accept) ou rejeição de acesso (access-reject).
O RADIUS opera tanto com mecanismos de autenticação do Unix e Windows
quanto com protocolos de autenticação, como o PAP e o CHAP, sobre o protocolo PPP.
PAP (Protocolo de Autenticação de Senha) - o usuário envia a sua senha aberta na
rede e o servidor retorna as permissões do usuário.
Neste caso, a senha segue criptografada entre o RAS e o RADIUS por uma chave
conhecida por ambos os servidores.
CHAP (Challenge Handshake Authentication Protocol) – O mais utilizado em
autenticação RADIUS. Neste caso é enviado pela rede um desafio. Este desafio consiste
em criar um Message Digest, através do Algoritmo RSA – MD5 utilizando a senha do
usuário.
O servidor RAS envia o Message recebido ao servidor RADIUS que conhece a
senha do usuário e que a utiliza para criar um Message Digest e comparar com o recebido.
A segurança da confidencialidade da senha está no fato do RSA ser um algoritmo
de Hash (a mensagem original não pode ser obtida através do conhecimento da chave e da
mensagem criptografada).
61
3.10.9. Biometria
A biometria é o estudo das características mensuráveis do ser humano que
possibilitam o reconhecimento de um indivíduo. A impressão digital, íris, retina, geometria
da mão, voz, face e velocidade de digitação são características que permitem a
identificação de usuários. Esta abordagem confirma a unicidade e estabilidade destas
características, o que permite o reconhecimento ao longo da vida.
A identificação biométrica procura trabalhar como a mente humana. O
reconhecimento das pessoas é realizado por meio da comparação das características
biométricas, cujo índice de similaridade vai determinar o sucesso da identificação, ou seja,
se as características biométricas apresentadas são muito parecidas com as armazenadas,
neste caso o sistema confirma a identidade do usuário. Este mecanismo está sujeito à
ocorrência de três situações: identificação com sucesso, o falso-positivo e o falso-negativo.
Exemplificando, quando se atende o telefone há grandes chances de se identificar o
interlocutor pela voz e em algumas vezes errar no reconhecimento. Quando ocorre o
acerto, este advém do fato da voz do interlocutor possuir muitas características em comum
com a correspondente já memorizada, neste caso temos uma identificação com sucesso.
Quando ocorre uma troca na identificação do interlocutor estamos diante de um fato
denominado falso-positivo. Por fim, quando o interlocutor já é conhecido mas não é
prontamente identificado estamos diante de um fato denominado falso-negativo.
Na observação de uma carteira de identidade é possível identificar rapidamente seu
proprietário pela foto mas não pela impressão digital que requer um complexo processo de
análise comparativa que a mente humana não está acostumada a fazer. No entanto, um
processo automatizado de reconhecimento biométrico dos traços digitais pode ser
altamente confiável, rápido e economicamente viável.
Cada tecnologia de identificação possui seu próprio mecanismo de captura de
dados. Um scanner de impressão digital é um dispositivo de dimensões reduzidas com as
mesmas funcionalidades de scanner de mesa, porém, especializado na captura de digitais
humanas. O mesmo acontece com a captura da imagem do olho para o reconhecimento da
íris que é realizado por uma câmera de vídeo especialmente projetada para trabalhar com
maior sensibilidade capaz de registrar todos os detalhes de um olho.
Existem atualmente dois métodos de reconhecimento: reconhecimento 1:1 e
reconhecimento 1:N. O primeiro aplica-se às senhas, onde o usuário se identifica por meio
de um código alfanumérico e apresenta sua identificação biométrica, restando ao sistema
62
comparar as características desta com aquelas já armazenadas. O método de
reconhecimento 1:N, é pouco utilizado devido a sua alta complexidade pois o usuário
deverá ser identificado apenas por suas características biométricas (impressão digital, íris,
voz, etc,) a partir de inúmeras comparações que resultam na escolha de um conjunto já
armazenado e que mais se aproxima daquele capturado.
A identificação biométrica leva em conta características dos seres na presença de
vida. Desta forma, a extração de partes do corpo humano para forjar uma presença
inexistente não obterá êxito numa possível fraude, portanto esta tecnologia pode ser
aplicada para permitir ou negar acesso físico a ambientes protegidos além de controlar
acessos lógicos a sites de serviços eletrônicos.
3.10.10. Call Back
É o procedimento para identificar um terminal remoto. No procedimento call back,
o host desconecta a ligação logo após a chamada e a seguir liga para o número de telefone
autorizado do terminal remoto para restabelecer a conexão.
É um mecanismo utilizado pelo servidor RAS para garantir a autenticidade do
ponto remoto que deseja acessar a rede.
Exemplificando, este processo pode ocorrer da seguinte forma: o usuário através de
sua linha telefônica solicita conexão ao servidor RAS. Após a troca de informação de
identificação o equipamento do usuário derruba a chamada e aguarda a solicitação de
conexão do servidor RAS. O mesmo, com a identificação do ponto discado, efetua nova
chamada ao ponto remoto utilizando o número telefônico anteriormente informado como
sendo do usuário.
3.10.11. Token Card
Dentre um variado número de protocolos para verificação da autenticidade de
usuários encontramos um modelo baseado em Cartões de Identificação comumente
conhecidos por token card ou smart card. Tais mecanismos baseiam-se em dois métodos
diferentes:
• Desafio e Resposta; e
• Autenticação por sincronismo.
63
O esquema baseado em desafios e respostas pressupõe a pré liberação controlada de
um semi identificador do usuário que irá compor sua identificação completa no ato da
entrada no sistema. Este método, resumidamente, funciona da seguinte forma:
a) O usuário aciona o servidor de autenticação, e este emite um prompt para que
o mesmo efetue seu login;
b) O usuário informa seu ID pessoal para o servidor e este retorna-lhe um número
aleatório, denominado desafio, que aparece em sua tela; e
c) O usuário então insere este número em seu token card, o mesmo é cifrado
junto com a chave do usuário contida no cartão transformando-se numa
resposta que é enviada para o servidor, que o autentica ou não caso essa
resposta esteja de conformidade com informações de sua base de dados.
O esquema a seguir demonstra o funcionamento do mecanismo de desafio/resposta.
Figura 5 – Autenticação desafio/resposta com ficha
Na autenticação por sincronismo ocorrem os seguintes passos:
a) O usuário efetua seu login de acesso no servidor que emite um prompt para
receber um código de acesso;
b) O usuário informa um número de identificação pessoal (PIN) a seu token card e
obtém como resultado um número representando sua senha para ser usada uma
única vez no servidor; e
c) O token card transmite ao servidor a senha obtida e este a compara com outra
gerada em seu ambiente, caso as mesmas sejam equivalentes o acesso do
usuário à rede é permitido.
64
O esquema a seguir ilustra o mecanismo de autenticação com token card realizado
por sincronismo.
Figura 6 – Autenticação com Sincronismo
A utilização de um dos dois sistemas faz com que o usuário tenha que carregar um
dispositivo tal qual um cartão de crédito, para providenciar suas credenciais de
autenticação.
65
4. CONTEXTUALIZAÇÃO
As conseqüências da expansão das comunicações eletrônicas sobre os serviços
ofertados pelos Governos à sociedade são objeto de prognósticos que destacam a
velocidade e amplitude surpreendentes dos impactos esperados.
As ameaças à segurança das comunicações eletrônicas provocam uma perda
estimada de cerca de US$ 84,4 bilhões anuais decorrentes de ataques aos sistemas de
transações eletrônicas (dados do The Management Advice Group).
O surgimento dos hackers tem assustado, impondo o desafio da elaboração de
respostas com idêntica agilidade, criatividade e flexibilidade. A comunidade dos hackers
atualmente é estimada em cerca de 3.500 sites na Internet, 800 bulletinboards contendo o
que poderia ser qualificado como “receitas” de assalto aos sistemas, além de
aproximadamente 50 publicações especializadas. Segundo a Network Associates, são
criados na Internet cerca de 10 novos vírus por dia. Contudo, a questão da segurança não
pode se limitar ao problema dos ataques a sistemas, porque também inclui a ocorrência de
acidentes ou de falhas não intencionais.
A segurança aparece hoje como responsável por 81% das intenções de
investimento, segundo dados de pesquisas do Gartner Group. Não haveria como realmente
estimar os custos envolvidos na expansão da área de segurança em virtude de rápida
evolução tecnológica no setor.
Tratando das organizações governamentais brasileiras, especificamente daquelas
responsáveis pela administração tributária, constatamos junto às cartas consultas
encaminhadas ao Ministério da Fazenda desde 1997, por quase todas as unidades da
federação, com vistas a apreciação do Programa Nacional de Apoio à Administração
Fazendária dos Estados e Municípios – PNAFEM, a formação de uma clara agenda de
questões a serem enfrentadas pelo citado segmento do setor público, onde aparecem com
freqüência os seguintes temas:
• A busca de meios para suprir uma oferta continuada de serviços demandados
pela população, dentro de uma nova concepção que pode ser sintetizada na
simbologia “24x7”;
• A transparência ou amplas facilidades de acesso à informação pública pelo
cidadão;
• A busca da mais ampla capilaridade; e
66
• A busca de meios para a materialização do “governo dentro de casa”, por meio
do contato direto com o cidadão, o que deverá ensejar não somente a expansão
e redesenho da prestação de serviços mas também a criação de novos
mecanismos de interação entre governo e sociedade.
No âmbito de qualquer organização, a manutenção da segurança depende da
adequada formulação e implementação de políticas corporativas, a partir de um diagnóstico
preciso e da opção dentre um amplo leque de tecnologias, metodologias e instrumentos.
Os custos envolvidos são componentes cada vez mais indissociáveis no esquema de
modernização. Dessa forma, segurança não é simples proteção, porque precisa igualmente
contemplar a prevenção, a detecção e a reação a ataques ou a falhas. Há uma relação de
implicação evidente entre segurança e custos, na medida em que a decisão pela aquisição
de uma ferramenta para tal fim deve considerar os riscos e sua gradação.
Em síntese os desafios da segurança impõem às organizações, em especial:
• Conhecimento das ameaças que rondam seus negócios;
• A adoção de políticas de segurança;
• Desenvolvimento de uma cultura de segurança;
• A construção de sistemas sólidos de identificação e de autenticação; e
• A implementação de forma efetiva da política de segurança.
Para o Estado além da preocupação com a melhor forma de aplicação interna das
novas tecnologias em consonância com seus aspectos organizacionais e demandas da
sociedade, coloca-se a discussão de sua prévia e necessária intervenção regulatória,
compreendendo em particular os seguintes assuntos:
• assinatura eletrônica;
• cyber-crimes;
• moeda eletrônica;
• marcas e nomes de domínio na Internet, e
• direitos autorais sobre multimídias.
Conforme aponta a sétima pesquisa Módulo Security, 53% dos ataques contra
organizações brasileiras tem como autores funcionários insatisfeitos das organizações
atingidas. Aspecto importante é o indício de que os dados a respeito da criminalidade
eletrônica são subestimados, considerando os riscos de imagem para as instituições que
realizam transações com clientes em meio eletrônico, associados com a divulgação de
ocorrências dessa natureza.
67
O aperfeiçoamento da legislação brasileira já possibilita a criminalização de
condutas que anteriormente eram de difícil enquadramento legal, tais como o acesso
indevido e a violação de sistemas, a falsificação de documentos em meio eletrônico, a
obtenção de segredos, a cópia não autorizada de programas, a espionagem e a violação de
bancos de dados.
Além desses, crimes que já eram objeto de tipificação legal podem ser praticados
com o auxílio de equipamentos de computação, tais como o estelionato (por meio da
transferência eletrônica de fundos), a discriminação racial (objeto de legislação específica:
a Lei n.º 7.716/96 da Constituição Federal –CF), a pornografia infantil (objeto da Lei n.º
8.069/91 da CF) e a interceptação telemática, conhecida como “grampo” (Lei n.º 9.296/96
da CF).
Entretanto, o rol de práticas criminosas em meio eletrônico desafia os limites das
abordagens convencionais na sua investigação e demanda soluções criativas. Os cyber
crimes estão levando a uma revisão de conceitos na área jurídica em virtude de suas
características inovadoras. São crimes que extrapolam a territorialidade convencional,
porque têm lugar, por exemplo, no espaço virtual da Internet. Por outro lado, só podem ser
tipificados a partir de evidências materiais (o registro da informação) e não por meio de
testemunhos. O anonimato, a extrema dispersão territorial, a velocidade e facilidade de
movimentação, são características que dificultam a investigação convencional.
Tratando expressamente das Secretarias de Receita, constatamos que a maioria
delas apresentam situações similares quanto ao desenvolvimento de seus sistemas de
computação.
Limitadas pela legislação que lhes impõem inúmeras regras e contando com
orçamentos restritos destinados a novos investimentos, tais instituições se viram obrigadas
a desenvolver soluções caseiras na busca do atendimento das demandas da comunidade.
O aumento da demanda com o aparecimento constante de novos contribuintes,
acompanhado de exemplos significativos de excelentes serviços prestados pela rede
mundial, tem pressionado os gestores responsáveis pelas funções de Estado de
administração tributária a se desdobrarem em soluções imediatistas que por vezes não têm
observado os princípios básicos da segurança necessária.
Relacionamos a seguir uma série de problemas mais comuns na área das
tecnologias de informática aplicadas, verificados junto a um grande número de Secretarias
de Receita:
68
• Falta de um plano diretor de tecnologia visando maximizar os investimentos na
aquisição e manutenção de hardwares e softwares;
• Ferramentas tecnologicamente desatualizadas;
• Sistemas corporativos com baixa integração;
• Má alocação de equipamentos de informática;
• Falta de clareza de produtos contratados com terceiros;
• Grande dependência de serviços de terceiros; e
• Ausência de um sistema de segurança e controle de acessos.
4.1. OBJETIVO GERAL DAS ORGANIZAÇÕES DE ADMINISTRAÇÃO TRIBUTÁRIA
Como em qualquer organização, o Governo funciona baseado em uma divisão clara
das tarefas a serem desenvolvidas no plano de sustentação interna e, principalmente,
daquelas de natureza finalística onde os resultados são ofertados diretamente à
comunidade.
No elenco de agentes e atribuições governamentais verificamos um segmento
responsável pela administração tributária cuja missão principal é suprir as necessidades
financeiras para suporte das ações desenvolvidas pelo Estado. A captação dos citados
recursos origina-se de um conceito onde os bens comuns devem ser providos por toda a
sociedade mediante uma participação proporcional de cada um de seus membros conforme
suas disponibilidades e posses. Cabe às entidades de administração tributária a missão de
definir a capacidade contributiva de cada um de seus membros, propor a forma de
participação destes e implementar os mecanismos de captação dos citados recursos.
4.2. OBJETIVOS ESPECÍFICOS
A missão de captar recursos junto à sociedade resulta de uma variedade de sub
funções que precedem o ato de recolhimento e vão muito além deste. Estudos preliminares
devem apontar, além da capacidade, a disposição da sociedade em participar como co-
autora das ações do Governo. As principais atividades de uma instituição de administração
tributária estão resumidas a seguir:
• Elaboração de estudos demonstrativos da viabilidade econômico/tributária;
• Proposição dos modelos de tributação;
69
• Arrecadação de impostos e taxas;
• Realizar lançamentos;
• Administrar de declarações;
• Controlar pagamentos;
• Controlar repasses bancários;
• Fiscalização.
• Cobrar inadimplências;
• Gerenciar contencioso fiscal;
• Julgamentos da instância administrativa;
• Atender aos contribuintes.
Devemos ressaltar que nos últimos tempos dois fatores vêm causando uma
verdadeira revolução no âmbito da administração tributária agregando-lhes novas
atribuições internas, a saber:
• O vertiginoso desenvolvimento dos meios de comunicação disseminou
conceitos de cidadania participativa até então restritos a uma pequena parte da
sociedade. Este fato especializou as demandas dos cidadãos que ainda
revestidos de direitos passaram a cobrar com veemência as respectivas
contrapartidas, obrigando tais instituições a buscarem rapidamente qualidade
nas suas funções de atendimento aos contribuintes; e
• As novas ferramentas de processamento eletrônico de dados foram adotadas em
larga escala sem grandes preocupações com a segurança dos mesmos. O
aparecimento dos crimes cibernéticos mostrou grandes vulnerabilidades e o
aparecimento de novas atividades internas.
4.3. ORGANOGRAMA PADRÃO
Após um longo período de observação das estruturas organizacionais existentes nos
estados e municípios destinadas ao suporte das atividades tributárias, constatou-se a
predominância absoluta de uma estrutura clássica conforme apresentada a seguir, onde,
comumente, não aparece definida uma entidade cuja missão principal seja a formulação e
gestão de políticas destinadas proteger os ativos de tecnologia e informações existentes.
70
Figura 7 - Estrutura Básica das Secretarias de Receita
4.4. COMPETÊNCIAS GENÉRICAS
4.4.1. Coordenação de Administração
Compete à Coordenação de Administração, diretamente subordinada ao Secretário
de Receita, as seguintes atividades básicas:
• Coordenar e, por intermédio dos órgãos a ele subordinados, executar as
atividades de administração financeira, de material, de pessoal ativo, inativo e
pensionista, e de serviços gerais da Secretaria;
• Elaborar as normas internas relativas à administração geral, respeitada a
orientação definida pelos órgãos centrais;
• Elaborar a programação e supervisionar a execução dos trabalhos dos órgãos
que lhe são diretamente subordinados;
• Prestar apoio operacional a todos os órgãos subordinados à secretaria;
• Coordenar a gestão orçamentária da secretaria;
• Coordenar e controlar a execução dos trabalhos das gerências de recursos
humanos, de administração financeira e de material e de apoio logístico;
• Coordenar as atividades referentes às operações patrimoniais internas,
procedendo ao registro e ao controle dos bens móveis e imóveis;
Departamento de Atendimento aos contribuintes ATE
Coordenação de Informática - INF
Departamento de Tributação - TRI
Departamento de Fiscalização - FIS
Coordenação de Administração
Departamento de Arrecadação ARR
Junta de Recursos Fiscais - JRF
SECRETÁRIO DE RECEITA
71
• Propor normas e procedimentos para registro e controle dos bens patrimoniais
próprios;
• Elaborar a programação financeira mensal da secretaria; e
• Coordenar e controlar a execução financeira da secretaria.
4.4.2. Coordenação de Informática
Compete à Coordenação de Tecnologia e Informação as seguintes atividades
básicas:
• Planejar, coordenar, supervisionar e orientar as atividades de informatização da
Secretaria de Receita;
• Desenvolver e administrar os sistemas internos da Secretaria de Receita;
• Treinar usuários na utilização dos sistemas;
• Registrar e controlar as ocorrências de defeitos técnicos;
• Prestar assistência técnica preventiva aos equipamentos de informática;
• Realizar auditorias em softwares e hardwares; e
• Executar de forma sistêmica as rotinas estabelecidas para a proteção dos dados
(backups).
4.4.3. Departamento de Tributação
Compete ao Departamento de Tributação, órgão de direção executiva, diretamente
subordinado ao Secretário de Receita as seguintes atividades:
• Propor alterações na legislação tributária estadual;
• Prestar esclarecimentos sobre a aplicação da legislação tributária;
• Acompanhar junto à Procuradoria Geral do Estado as ações judiciais contra a
Secretaria de Receita;
• Analisar solicitações de benefícios fiscais;
• Analisar e relatar, em primeira instância, o contencioso administrativo fiscal; e
• Atender a diligências do Tribunal Administrativo de Recursos Fiscais.
72
4.4.4. Departamento de Arrecadação
Compete ao Departamento de Arrecadação, órgão de direção executiva, diretamente
subordinado ao Secretário de Receita as seguintes atividades:
• Realizar estudos com o objetivo de estabelecer as metas de arrecadação e
fornecer subsídios para a elaboração dos planos anual e plurianual;
• Controlar a arrecadação de tributos e a execução dos convênios celebrados com
os agentes arrecadadores;
• Processar e controlar os documentos de arrecadação e de acompanhamento da
receita;
• Acompanhar e controlar o parcelamento de débitos fiscais;
• Inscrever, notificar, controlar e baixar os débitos em dívida ativa;
• Administrar e manter os cadastros de contribuintes; e
• Acompanhar os registros de informações de cadastro de veículos automotores.
4.4.5. Departamento de Fiscalização
Compete ao Departamento de Fiscalização Tributária, órgão de direção executiva,
diretamente subordinado à Secretário de Receita, as seguintes atividades:
• Estabelecer o programa de ação fiscal e realizar o seu acompanhamento;
• Monitorar e auditar estabelecimentos industriais, comerciais e prestadores de
serviços;
• Realizar fiscalizações itinerantes; e
• Administrar os postos fiscais e depósitos de mercadorias apreendidas.
4.4.6. Departamento de Atendimento ao Contribuinte
Compete ao Departamento de Atendimento ao Contribuinte, órgão de direção
executiva, diretamente subordinado ao Secretário de Receita as seguintes atividades
básicas:
• Propor normas para sistematizar o atendimento aos contribuintes;
• Realizar o atendimento remoto ao contribuinte;
• Operar os sistemas de registro de consultas técnicas (call center); e
73
• Promover o atendimento direto aos contribuintes.
4.5. PERFIL DO USUÁRIO
As Secretarias de Receita aparecem em todos os estados como uma das unidades do
Governo que opera baseada num quadro de funcionários de carreira detentores das maiores
qualificações técnicas, sendo este composto por Auditores Fiscais e Técnicos Tributários.
Além dos servidores pertencentes aos quadros permanentes é comum serem
identificados alguns funcionários externos, prestadores de serviços, normalmente ligados
às atividades de processamento de dados, tanto no desenvolvimento de sistemas quanto na
produção dos mesmos.
4.6. INTERAÇÃO COM OUTRAS ORGANIZAÇÕES
Devido à natureza das atividades que exercem, as Secretarias de Receita necessitam
de uma constante interação com as seguintes entidades:
• Contribuintes Contabilistas Fornecedores diversos
• Procuradoria Bancos Ministério da Fazenda
• Poder judiciário Entidades de Classe Receita Federal.
• Imprensa Tribunais de Contas Banco Central
• Assembléias legislativas Ministério Público CVM
• Institutos de pesquisas Fiscos Estaduais
4.7. PERSPECTIVAS DE EVOLUÇÃO
As unidades de administração das Secretarias de Receita sofreram um grande
impacto decorrente da especialização das demandas por informações gerenciais resultantes
do tratamento de um volume cada vez maior de dados relativos a declarações e
recolhimentos de tributos.
Anteriormente à Constituição Federal de 1998, os governos salvavam-se dos
débitos orçamentários elevando a carga tributária por meio de um sem número de
manobras legais, tais como aumento de alíquotas e criação de novas taxas e contribuições
sem o devido estudo de viabilidade econômica. Aliados a estas facilidades, contavam ainda
com as manobras financeiras decorrentes da espiral inflacionária.
74
Até o início da década de 90 observou-se uma estrutura onde os contribuintes de
uma forma geral e a rede bancária enviavam enormes quantidades de papel às Secretarias
de Receita que se desdobravam num oneroso processo de captação gerando,
invariavelmente, outros relatórios pouco operacionais, conforme ilustrado a seguir, tendo
como principais ameaças:
• Invasão interna;
• Defeitos nos sistemas aplicativos;
• Falha em equipamentos; e
• Inexistência de cópias sistêmicas de segurança.
CONTRIBUINTES Figura 8 – Modelo observado no final da década de 1980 na maioria das Secretarias de Receita.
A simples geração de relatórios operacionais passou a não atender a especialização
ocorrida nas demandas ao enorme volume de dados que se apresentava para tratamento.
Devemos ressaltar que outros fatores contribuíram para uma mudança de forma de
trabalho, dentre eles o barateamento dos componentes de informática, tais como
processadores, e, principalmente, unidades de armazenamento.
A popularização de novos meios de armazenamento, como os discos magnéticos
portáteis e sistemas destinados à automação de pequenos e médios escritórios, facilitaram o
surgimento de uma nova fase na administração tributária onde a mesma eliminou sua
digitação interna e passou a captar seus dados declaratórios diretamente de dispositivos
BANCOS
RESUMO DE
DECLARAÇÕES
DOCUMENTOS DE
ARRECADAÇÃO
PAGAMENTOS DE IMPOSTOS
PROCESSAMENTO
RELATÓRIOSOPERACIONAIS
RELATÓRIOS
OPERACIONAIS
DE PACAPTAÇÃO EMISSÃO
SAÍDAS EM
VÍDEO
75
enviados pelos contribuintes. Além destes, os dados resultantes de pagamentos passaram a
ser recebidos diretamente em meio magnético da rede bancária. Neste modelo os
contribuintes, verdadeiros donos dos dados armazenados nas suas respectivas organizações
de administração tributária, ainda mantinham-se passivos no processo, apresentando suas
informações mas não tendo acesso a elas.
Esta conformação, mostrada na Figura 9, trouxe uma nova forma de ambiente com
um visível aumento no volume de dados processados e o aumento dos seguintes riscos:
• Invasões internas;
• Falhas nos equipamentos;
• Armazenamento inadequado;
• Incompatibilidades nas tecnologias de armazenamento;
• Inexistência de cópias sistêmicas de segurança;
• Defeitos nos sistemas aplicativos; e
• Vírus.
Figura 9 – Modelo observado na primeira metade da década de 1990
CONTRIBUINTES
BANCOS
DECLARAÇÕES
DOCUMENTOS DE ARRECADAÇÃO
PAGAMENTOS DE IMPOSTOS
PROCESSAMENTO
RELATÓRIOS
OPERACIONAIS
RELATÓRIOS
GERENCIAIS
CAPTAÇÃO E
EMISSÃO
SAÍDAS EM
VÍDEO
76
Com a especialização das redes e principalmente a disseminação e estabilidade da
Internet ocorreu uma nova mudança a partir da qual os agentes que interagem com as
organizações de administração tributária passaram a obter os serviços desejados
diretamente a partir dos cadastros básicos residentes naqueles órgãos e previamente
processados por eles.
Além dos riscos existentes nos modelos anteriores, esta modalidade, ilustrada a
seguir, agregou novos riscos considerados de difícil controle conforme a relação abaixo:
• Invasões externas;
• Vírus especialistas;
• Defeitos nos sistemas aplicativos;
• Falhas nos equipamentos;
• Armazenamento inadequado;
• Inexistência de cópias sistêmicas de segurança; e
• Defeitos nos sistemas aplicativos.
Figura 10 – Modelo implantado a partir da segunda metade da década de 1990 e observado até hoje num
grande número Secretarias de Receita
CONTRIBUINTES
BANCOS
DECLARAÇÕES E
NOTAS FISCAIS
DOCUMENTOS DE ARRECADAÇÃO
PROCESSAMENTO
RELATÓRIOS
GERENCIAIS
DEC E
N.F.
SAÍDAS EM
VÍDEO
INTERNET
PAG
CAPTAÇÃOE
PROCESSAMENTO
REDES PRIVADAS
77
Novos modelos de administração tributária pressupõem atendimentos
especializados e com a maior comodidade possível aos contribuintes. Além disso,
pressupõem extrema interligação entre todas as unidades da federação de modo que tenha
seus dados cadastrais residentes em um único local, ou seja, na sua unidade de origem e as
demais tenham acesso irrestrito a eles. O sistema deverá operar em modo distribuído.
Outro fator que exigirá uma revolução nos padrões atuais reside no fato de que
todas as operações comerciais que representem entradas ou saídas de mercadorias e
serviços realizadas por qualquer contribuinte deverão ser informadas à sua circunscrição
fiscal. Esta premissa é fundamental para que os novos sistemas de fiscalização sejam
eficazes. Nesta direção existem conjecturas no sentido de buscar meios técnicos para
operacionalizar um sistema onde os dados históricos fiquem armazenados nos sites dos
próprios contribuintes e estejam permanentemente disponíveis às Secretarias de Receita
conforme o modelo a seguir:
Figura 11 – Modelo tendência para implantação ainda na década de 2000.
BANCOS
DECLARAÇÕES E
NOTAS FISCAIS (SINTÉTICO)
DOCUMENTOS DE ARRECADAÇÃO
PROCESSAMENTO
SAÍDAS EM
VÍDEO
INTERNET
CONTRIBUINTES
DECLARAÇÕES E NOTAS FISCAIS
(ANALÍTICO)
78
A operacionalização com base no esquema demonstrado anteriormente é uma
realidade dependente exclusivamente do tempo. Internamente há um elenco de discussões
sobre as atualizações necessárias e suas formas de implementação. No campo externo
ocupado pela sociedade em geral, representada pelos contribuintes, ocorre uma visível
movimentação exigindo maior transparência e efetividade no trato dos recursos públicos.
As estruturas organizacionais tendem a se complementar com a especialização das
já existentes unidades operacionais de informática e o acréscimo de outra sub-unidade de
natureza colegiada responsável pela elaboração e manutenção de uma política de segurança
dos recursos e informações conforme mostra a figura a seguir:
Figura 12 – Modelo de organograma observado como tendência para as Secretarias de Receita a ser
implantado nos próximos anos.
4.8. MATRIZ DE USO DE DADOS
A seguir apresentamos o modelo de uma matriz de uso de dados utilizada pela
Secretaria de Receita de Brasília.
Coordenação de Informática - INF
Departamento de Tributação - TRI
Departamento de Fiscalização - FIS
Departamento de Atendimento aos
Contribuintes
Coordenação de Administração
Departamento de Arrecadação ARR
Junta de Recursos
Fiscais - JRF
Conselho de gestão da política de segurança
da informação
RECEITA TRIBUTÁRIA
79
USUÁRIOS INTERNOS
USUÁRIOS EXTERNOS
CADASTROS TRI ARR FIS ATE ADM INF JRF CTB OUTROS
Abrangência da coletoria C I,A,C C C C C C C C Acionista x capital C I,A,C C A,C C C C C C Aditamento de contrato C C I,A,C C C C C C C Aditamento do convênio C C I,A,C C C C C C C Agência bancária C I,A,C C C C C C Alíquotas I,A,C C C C C C C C C Atividade econômica C I,A,C C A,C C C C C C Atribuição de cargo C C C C I,A,C C C Atribuição de função C C C C I,A,C C C Auto de infração C C I,A,C C C C C C C Requisições I,A,C I,A,C I,A,C I,A,C I,A,C I,A,C I,A,C I,A,C I,A,C Autorização de impressão de documento Fiscal
C C I,A,C A,C C C C C C
Autorização de uso de documento fiscal C C I,A,C A,C C C C C C Autorização para uso de documento fiscal eletrônico
C C I,A,C A,C C C C C C
Categoria de estabelecimentos I,A,C C C A,C C C C C C Categoria de veículos I,A,C C C A,C C C C C C Classificação contábil da receita C I,A,C C C C C C C C Classificação tributária da receita C I,A,C C C C C C C C Classificação de produtos – NCM I,A,C C C C C C C C C Código fiscal de operações A,C C I,A,C C C C C Códigos de receita C I,A,C C C C C C C C Conhecimentos de transporte C C I,A,C A,C C C C C C Contratos C C C C I,A,C C C C C Datas de vencimentos A,C I,A,C A,C A,C C C C C C Denúncias C C I,A,C C C Documento de inscrição em dívida ativa C C I,A,C A,C C C C C C Documentos de arrecadação C I,A,C C A,C C C C C C Declaração mensal de serviços prestados A,C A,C I,A,C A,C C C C I,A,C C Declaração mensal de empresas de pequeno Porte
A,C A,C I,A,C A,C C C C I,A,C C
Declaração mensal de micro empresas A,C A,C I,A,C A,C C C C I,A,C C Equipamentos emissores de cupom fiscal C C I,A,C A,C C C C C C Escalas de plantão C C C C I,A,C C C Ficha cadastral de contribuinte A,C A,C I,A,C A,C C C C I,A,C C Grupo financeiro C I,A,C C C C C C Guia de informação mensal de ICMS C I,A,C C A,C C C C I,A,C C Guia de Informação sobre valor agregado C I,A,C C A,C C C C I,A,C C Guia nacional de informação de ICMS C I,A,C C A,C C C C C C Histórico de instituição C C I,A,C C C C C C Histórico de processos A,C A,C A,C A,C I,A,C A,C A,C C C Indicador de desempenho I,A,C C C C C C C Indicadores demográficos I,A,C C C C C C C C C Indicadores econômicos I,A,C C C C C C C C C Índices de depreciação I,A,C C C C C C C C C Índices de participação C C I,A,C A,C C C C C C Item de produto C A,C I,A,C A,C C C C C C Legislação e atos legais A,C A,C A,C I,A,C C C C C C Leilão C I,A,C C A,C C C C C C Log de auditoria C C C C C I,A,C C Logradouros C C I,A,C A,C C C C C C Marcas de veículos C C I,A,C A,C C C C C C Modelos de veículos C C I,A,C A,C C C C C C Moedas C I,A,C C A,C C C C Nota fiscal C C I,A,C A,C C C C C C
80
Notificações C C I,A,C C C C C C C Ordem de serviço I,A,C I,A,C I,A,C A,C C C C C C Pauta de valor de IPVA I,A,C A,C A,C C C C C C C Portarias de citação A,C A,C I,A,C C C C C C C Processos A,C A,C A,C A,C I,A,C C C C C Recibos I,A,C I,A,C I,A,C I,A,C I,A,C C C C C Regiões demográficas I,A,C C C A,C C C C C C Termo de fiscalização C C I,A,C C C C C Termo de responsabilidade I,A,C I,A,C I,A,C I,A,C I,A,C C C Tipo de documento C C C A,C I,A,C C C Tipo de documento fiscal C C C A,C I,A,C C C Tipo de ordem de serviço C C C A,C I,A,C C C Tipo de participação C C I,A,C A,C C C C C C Tipo de processo C C C A,C I,A,C C C C C Transferência de crédito fiscal I,A,C C C C C C C C C Transportadoras C C I,A,C A,C C C C C C Unidade de medida C C C A,C I,A,C C C C C Usuários de sistemas A,C A,C A,C A,C A,C I,A,C A,C Valor de produto por município I,A,C C C A,C C C C C C Vigências I,A,C C C A,C C C C C C
Tabela 1 - Matriz de Uso de dados
Legenda : TRI – Departamento de tributação ARR – Departamento de Arrecadação FIS – Departamento de Fiscalização ATE – Atendimento aos Contribuintes ADM – Coordenação de Administração INF – Coordenação de Informática JRF – Junta de Recursos Fiscais. CTB – Contribuintes OUTROS - Outras entidades I – Inclusão A – Alteração C – Consulta
Obs: A opção “E” para exclusão não foi utilizada pois em sistemas de
administração tributária não ocorre a remoção de registros, apenas sua desativação.
81
5. POLÍTICA DE SEGURANÇA
5.1. ANÁLISE DE RISCOS
Em ambientes das Secretarias de Receita onde são depositadas informações capazes
de espelhar toda a vida financeira das empresas da circunscrição, não importando seu porte
ou atividade econômica, é lícito prever que, com maior ou menor grau de probabilidade,
ocorrerão invasões dos mais variados tipos capazes de causar algum impacto.
De acordo com o Risk Management Guide do NIST (Junho/2001) podem-se
classificar as probabilidades de ocorrência de ameaças em 3 categorias:
Alta: a fonte da ameaça é altamente motivada e suficientemente capaz e as contra-
medidas para evitar que as vulnerabilidades se concretizem são ineficazes.
Média: a fonte da ameaça é motivada e suficientemente capaz mas as contra-
medidas já estão implementadas para impedir que as vulnerabilidades sejam concretizadas
com sucesso; ou a fonte da ameaça não é motivada para concretizar estas vulnerabilidades
ou é apenas parcialmente capaz de fazê-lo
Baixa: a fonte da ameaça não possui motivação ou capacidade ou então, os
controles para prevenir ou ao menos impedir que as vulnerabilidades se concretizem foram
implementados com sucesso.
Na tabela apresentada a seguir relacionamos as ameaças às quais as Secretarias de
Receita estão expostas, a probabilidade de ocorrências e os possíveis impactos.
82
Ameaça Probabilidade de
ocorrência Impactos
Destruição acidental Média • Sistemas vitais não disponíveis Configuração incorreta de sistemas Média • Sistemas vitais não disponíveis
• Fraude Fornecimento inconsciente de informações sigilosas
Média • Possibilidade de processo legal contra o órgão
• Perda de credibilidade Instalação de hardware não autorizado Alta • Fraude Instalação de software não autorizado Alta • Fraude Vírus Alta • Sistema vitais não disponíveis
• Destruição de informações Problemas nos sistemas operacionais Alta • Sistemas vitais não disponíveis Cavalos de Tróia Alta • Sistema vitais não disponíveis
• Destruição de informações • Divulgação de informações sigilosas • Perda de credibilidade
Invasores disfarçados Média • Destruição de informações • Divulgação de informações sigilosas • Perda de credibilidade
Desastres naturais Baixa • Sistemas vitais não disponíveis Conflitos (guerras) Baixa • Sistemas vitais não disponíveis Sabotagem Média • Sistemas vitais não disponíveis;
• Perda de credibilidade Roubo Média • Perda de credibilidade;
• Possibilidade de processo legal Grampos telefônicos Média • Divulgação de informações sigilosas;
• Perda de credibilidade Monitoramento não autorizado do tráfego na rede
Baixa • Divulgação de informações sigilosas; • Possibilidade de processo legal
Modificação criminosa dos dados armazenados
Média • Perda de credibilidade; • Perda de receita.
Acesso ao arquivo de senhas Média • Fraude; • Divulgação de informações sigilosas; • Possibilidade de processo legal.
Uso de senhas frágeis Alta • Fraude; • Divulgação de informações sigilosas; • Possibilidade de processo legal.
Acesso físico não autorizado Alta • Fraude; • Divulgação de informações sigilosas; • Possibilidade de processo legal.
Não cumprimento de normas Alta • Fraude; • Divulgação de informações sigilosas; • Possibilidade de processo legal; • Sistema vitais não disponíveis; e • Perda de arrecadação.
Repúdio Média • Perda de Credibilidade • Fraude
Backdoor Alta • Fraude • Interceptação de informação • Perda de credibilidade • Destruição de informação
Tabela 2 – Análise de Ameaças
83
Neste trabalho constatamos as principais vulnerabilidades com alta probabilidade
de ocorrência, sobre as quais discorremos a seguir:
• Divulgação de informações sigilosas ou com restrições de divulgação, que
ocorre quando o funcionário ou prestador de serviço das Secretarias de Receita,
que tem acesso às informações classificadas como sigilosas, divulga-as
indevidamente para outros não autorizados;
• Inserção de informação, programas danosos ou vírus de computador sem
controle de recebimento ou tratamento adequado para evitar danos, que ocorre
quando funcionários ou prestadores de serviço com acesso às informações das
Secretarias de Receita inserem, sem autorização da Gerência de Segurança,
arquivo ou programa que provoque danos na base de informação;
• Possibilidade de acesso/modificação da informação realizada por usuários não
autorizados;
• Possibilidade de modificação, divulgação ou destruição de informação por
aplicações em teste ou operadas por usuários sem conhecimento do uso correto
do programa; e
• Utilização de endereço eletrônico de qualquer funcionário para disponibilização
ou divulgação de informação sem o conhecimento do dono da conta.
5.1.1. Vulnerabilidades
As vulnerabilidades são os pontos fracos de uma instituição que permitem ataques e
são uma fonte de riscos. O levantamento das vulnerabilidades existentes é fundamental
para se mensurar de forma clara e enxuta quais ações, metodologias, práticas e ferramentas
devem-se aplicar para garantir a integridade, confidencialidade, autenticidade e
disponibilidade da informação.
5.1.1.1. Vulnerabilidades Externas
• Controle de acesso (visualização, adição, alteração ou exclusão da informação)
sem utilização de autenticação confiável.
• Falta de procedimentos de anuência hierárquica e documentação da
disponibilização de informações;
84
• Falta de uma política e regras claras quanto à disponibilização da informação
por outros meios (exemplo, informações por telefone);
• Falta de controle do volume de acessos ao site e informações disponibilizadas
para acesso externo;
• Existência de diretório de FTP anônimo;
• Utilização de TFTP (uma versão simplificada do FTP que não usa senha para
autenticação de usuários); e
• Falta de sistema de detecção de intrusos.
5.1.1.2. Vulnerabilidades Internas
• Falta de controle, por autenticação, das estações;
• Existência de contas padrão – muitos programas e pacotes de terceiros vêm com
contas padrão com senhas padrão. Contas como guest ou de Administrador;
• Uso de senhas fracas – podem ser de contas padrão com senhas padrão, contas
de convidados, contas compartilhadas, contas sem senha ou com senha
facilmente identificável. Utilização, nos sistemas com autenticação, de usuários
e senhas comuns (divulgação de senhas);
• Falta de política de troca e bloqueio de contas e senhas;
• Falta de controle de permissão de uso das estações (policies);
• Falta de gerenciamento e controle de privilégios de usuários com definição
clara dos perfis e permissões das contas de cada usuário;
• Não há uma revisão periódica dos critérios, permissões dos usuários;
• Não há definição de procedimentos e autoridades para conceber criação de
contas e permissões de concessões de privilégios;
• Falta de controle de log quanto a acessos de usuários incluindo data e hora.
• Existência de pontos de rede ociosos habilitados;
• Qualquer notebook, estação ou equipamento, com interface ethernet pode ser
conectado a um ponto da rede e funcionar (controle de acesso ao meio físico da
LAN);
• Usuários não esclarecidos sobre as conseqüências do uso incorreto de
informação da instituição;
85
• Qualquer pessoa que tenha acesso físico à estação pode utilizá-la e pode
também instalar ou desinstalar qualquer aplicativo (inclusive programas
danosos ou modems – portas dos fundos);
• Ferramenta antivírus sem procedimentos para atualização periódica e possível
de ser desativada por qualquer usuário;
• Terminais e Workstations sem controle de tempo de conexão;
• Falta de controle do acesso físico às estações; e
• Falta de gerenciamento de processamento de informação sobre responsabilidade
de terceirizados.
5.1.1.3. Vulnerabilidades Referentes a Correio Eletrônico
• Informações não públicas circulam dentro e fora da rede através de e-mail sem
controle/certificação do usuário remetente;
• Não há garantia da entrega da informação;
• Qualquer usuário com acesso à rede interna pode enviar e-mail informando o
endereço eletrônico de outro; e
• Arquivos anexados só são verificados contra vírus na estação.
5.1.1.4. Vulnerabilidades Referentes a Aplicações
• Em muitos casos apenas um usuário é responsável pela informação sem haver,
portanto, controle de log ou outro usuário para confirmar a operação
(permitindo o uso danoso da informação por funcionários insatisfeitos, por
exemplo);
• Não há controle de atualização e uso de versões anteriores de aplicações;
• Ambiente de produção, desenvolvimento e teste único;
• Falta de documentação dos procedimentos de produção;
• Código fonte de aplicações distribuídas sem controle; e
• Falta de regras de segurança para orientação dos desenvolvedores quanto à
segurança de acesso e divulgação de informação pelos programas.
86
5.1.1.5. Outras Vulnerabilidades
• Acessos e troca de informações via RAS sem criptografia (VPN) ou
autenticação segura (PKI por exemplo);
• Backups não testados ou sem controle;
• Falta de revisão do controle de falhas;
• Falta de monitoração de uso (garantir disponibilidade);
• Não há controle de software pirata ou não homologado;
• Falta de procedimentos para atualização de patches e SP (Service Pack);
• Facilidade para o roubo e furto de equipamentos e programas;
• Não é utilizada, com base na legislação vigente e qualquer obrigação contratual,
a segurança de dados e serviço, a inclusão de cláusula no contrato de
funcionários e prestadores de serviço que especifiquem sanções em caso de
tentativa de acesso não autorizado (ISO/IEC 17799:2000);
• Não é aplicada a regra: Tudo deve ser proibido a menos que expressamente
permitido (ISO/IEC 17799:2000); e
• Falta de ferramenta de inventário automatizado da rede (hardware e software
em servidores e estações).
5.2. NORMAS DE SEGURANÇA
1 - Toda e qualquer informação da Secretaria de Receita armazenada e
disponibilizada por meio de recursos de informática deve ser protegida contra acesso,
alteração, destruição, divulgação de cópias não autorizadas, quer seja acidental ou
intencional.
2 - A proteção da informação deve ser preventiva viabilizando o processo de
recuperação de dados.
3 - O critério de classificação das informações deverá ser designado de forma a
garantir que as mesmas sejam avaliadas em duas escalas:
• níveis de importância: crítica, essencial e não essencial; e
• níveis de sensibilidade: confidencial, uso interno e uso público.
4 – Todo acesso à informação deve ser registrado de forma a viabilizar auditoria
quando necessário.
87
5 - O direito de acesso à informação está ligado à posição ocupada pela pessoa
dentro das Secretarias de Receita ou fora dela, e não à própria pessoa.
6 - O acesso à rede das Secretarias de Receita através de equipamentos de usuários
remotos ou de equipamento para teste deverá ter aprovação da autoridade competente.
7 - Nos contratos que impliquem o manuseio de informações das Secretarias de
Receita por parte de terceiros, devem constar cláusulas que garantam a observância da
política de segurança da mesma.
8 - O cumprimento das normas estabelecidas pela Política de Segurança da
Informação é obrigatório a todos os usuários com direito de acesso à rede.
9 - Todos os empregados, prestadores de serviços e estagiários autorizados a usar
os recursos da rede devem ser treinados em segurança da informação através de
seminários, palestras, material explicativo, folders e outros.
10 - O Departamento Geral de Informática das Secretarias de Receita tem o dever
de monitorar as informações disponíveis em todos os servidores e estações, bem como
monitorar toda a informação que trafega na rede, acompanhando rotineiramente, acessos,
sanções, uso de recursos e inspecionando arquivos, conforme necessário.
11 - Um plano de contingência deverá ser elaborado e mantido a fim de possibilitar
a restauração imediata dos serviços em caso de sinistro.
12 – Estas normas segurança deverão ser documentadas e disponibilizadas a todas
as partes interessadas.
5.3. POLÍTICA DE SEGURANÇA APLICADA A PESSOAS EM CONFORMIDADE COM A
ISO/IEC 17799:2000
Objetivo: Reduzir os riscos de erro humano, roubo, fraude ou uso indevido de
instalações.
1. Funcionários e prestadores de serviços eventuais que acessam as instalações de
processamento da informação da Secretaria de Receita devem se comprometer, através
de um documento escrito, em preservar o sigilo das informações;
2. Prestadores de serviços eventuais que não tenham contrato assinado deverão assinar
documento garantindo a segurança das informações das bases de dados antes de terem
88
acesso as instalações nas quais ocorrem os processamentos visando garantir e proteger
a integridade das informações armazenadas;
3. Todo funcionário, colaborador, prestadores de serviços e fornecedores (serviços e
equipamentos) deverão ter seus dados de apresentação (identidade, CPF , CNPJ entre
outros) e qualificação técnica e profissional confirmados e verificados;
4. Todo funcionário, prestador de serviço ou colaborador será responsável pela segurança
das informações contidas na base de dados durante um período de tempo definido
mesmo após o termino do contrato de trabalho ou de prestação de serviços na
Secretaria de Receita;
5. Todos os usuários deverão ser treinados nos procedimentos de segurança e no uso
correto das instalações de processamento da informação de forma a garantir a
integridade das informações minimizando possíveis riscos de ataques e alterações em
sua base de dados;
6. A Gerência de Segurança da Secretaria de Receita supervisionará a atuação de
colaboradores novos e inexperientes com relação aos acessos a sistemas considerados
de maior importância;
7. O gerente de cada área deverá constantemente supervisionar a atuação de sua equipe de
trabalho certificando-se do uso e implementação das regras básicas de segurança da
informação;
8. Todos os usuários do sistema de informação devem estar conscientes dos
procedimentos para notificação dos incidentes como violação de segurança, ameaças,
falhas ou mal funcionamento que possam ter impactos na segurança dos ativos
organizacionais;
9. Todo usuário do sistema deverá notificar o mal funcionamento de software à Gerência
de Segurança, não devendo executar nenhum tipo de ação, como remoção e software
suspeito sem a devida autorização da mesma;
10. Todas as regras e responsabilidades de segurança da Secretaria de Receita devem ser
documentadas e divulgadas a todos que possuam acesso ao sistema em concordância
com a Política de Segurança da mesma;
11. Será proibida a instalação de quaisquer programas pelos usuários visando proteger a
base de dados contra vírus ou instalação de softwares piratas;
12. Será definido um processo disciplinar formal para tratar com os usuários que tenham
violado as políticas e procedimentos de segurança estabelecidas e implementadas pela
Gerência de Segurança;
89
13. Deverá existir um procedimento de orientação a todos os usuários do sistema de
informação da Secretaria de Receita quanto ao acesso de recursos e serviços oferecidos
na Internet quando os mesmos forem de procedência duvidosa ou desconhecida.
5.4. POLÍTICA DE SEGURANÇA LÓGICA
Objetivo: Reduzir os riscos relacionados às configurações lógicas dos sistemas e
acessos.
1. A política antivírus será feita de modo sistemático através de e-mails semanais em
forma de notícias, notas de esclarecimentos, ou palestras, visando manter a integridade
da base de informações da Secretaria de Receita ;
2. Qualquer notícia recebida sobre vírus através do correio eletrônico, que não for do
comitê antivírus, não poderá ser repassada adiante. Deverá ser remetida para o
Conselho de Segurança que analisará o conteúdo e remeterá notas esclarecedoras ao
interessado;
3. A atualização do antivírus será feita de forma automatizada em todos os computadores
da rede, além do sistema de defesa nos servidores, protegendo a base de dados de
ataques de novos vírus;
4. Será proibida a abertura de arquivos executáveis, isto é, com terminação .exe, .com,
.pif, . bat, e outros, recebidos por e-mail para impedir que estes arquivos transfiram
para a rede algum tipo de vírus que possa prejudicar o sistema de informação;
5. As senhas deverão conter no mínimo oito caracteres entre letras maiúsculas e
minúsculas, caracteres especiais e números inviabilizando o uso de nomes de familiares
ou datas que poderiam ser facilmente descobertas;
6. As senhas dos usuários do sistema de informações deverão ser trocadas a cada 30 dias
e serão canceladas, por falta de uso, em 10 dias.
7. A conta do usuário será bloqueada após três tentativas erradas de logon e somente será
desbloqueada mediante autorização do Gerente de Segurança.
8. As últimas 5 senhas deverão ser registradas na base de dados e não poderão ser
repetidas pelos usuários do sistema de informação;
90
9. As senhas não deverão ser compartilhadas ou anotadas visando proteger as informações
do acesso de pessoas não autorizadas;
10. O usuário será automaticamente desconectado se ficar sem usar o sistema por mais de
15 minutos (time-out) para evitar o uso do mesmo por outro usuário que poderá estar
mal intencionado quanto ao acesso e consulta das informações ;
11. Os microcomputadores em rede deverão possuir senha no setup e devem estar
configurados de forma a não permitir o boot por unidade de discos flexíveis ou Cdrom.
12. O suporte a equipamentos de informática só poderá ser prestado por técnicos do
Departamento Geral de Informática ou com o acompanhamento deste, após registro no
sistema de controles de help desk.
13. A utilização de sistemas ou de permissão de uso de microcomputadores deverá ser
solicitada formalmente ao Departamento Geral de Informática.
14. O compartilhamento de arquivos, diretórios e outros recursos só será efetuado por
técnicos do Departamento Geral de Informática e de forma a não comprometer os
requisitos mínimos de segurança;
15. Deverá ser instalado na rede um software para detecção de intrusos (IDS) para
identificação de qualquer tipo de intrusão que possa prejudicar o sistema de
informações da Secretaria de Receita;
16. Deverão ser estabelecidos procedimentos de rotina para execução das cópias de
arquivos e disponibilização dos recursos de reserva;
17. Deverá ser elaborado um plano de contingência para recuperação de informações da
base de dados da Secretaria de Receita em caso de ataques diversos, ou desastres;
18. Deverá ser garantida e protegida toda infra-estrutura das redes físicas da Secretaria de
Receita com intuito de proteger consequentemente as informações da rede lógica;
19. Os controles de falhas devem ser constantemente revisados e atualizados de modo a
garantir a não ocorrência de falhas por repetidas vezes;
20. Deverá ser implementada uma lista de procedimentos para o gerenciamento e controle
do uso de mídias removíveis como fitas, discos, cartuchos e formulários impressos
91
visando impedir a divulgação e exposição classificadas como sigilosas ou de acesso
restrito.
21. O acesso remoto deverá ser protegido por VPN e certificação digital (PKI).
22. Deverá existir um servidor RADIUS para autenticação de usuários visando oferecer
maior segurança nos acessos remotos.
23. As redes de computadores deverão ser protegidas por um firewall que seja um produto
bem conceituado no mercado, devidamente configurado e permanentemente atualizado,
interligado a um sistema de IDS para reforçar a segurança.
5.5. POLÍTICA DE SEGURANÇA FÍSICA E DO AMBIENTE EM CONFORMIDADE COM A
ISO/IEC 17799:2000
Objetivo: Prevenir o acesso não autorizado, dano e interferência às instalações
físicas da organização e à sua informação.
1. As Secretarias de Receita devem usar perímetros de segurança para proteger as áreas
que contemplam as instalações de processamento de informações criticas ou sensíveis;
2. O perímetro de segurança deve estar claramente definido e ser fisicamente consistente
inviabilizando invasões por algum tipo de brecha ou falha ;
3. As portas de incêndio no perímetro de segurança devem possuir sensores de alarmes e
mola para fechamento automático;
4. Deverá existir uma supervisão/vigilância constante aos visitantes das áreas de
segurança através de registro em livro específico no qual serão indicadas as horas de
entrada e saída e a identificação do local (departamento/gerência) para onde se dirigiu
o visitante em questão;
5. Apenas pessoal autorizado poderá ter acesso às instalações de processamento de
informações sensíveis, sigilosas ou críticas;
6. Deverão ser utilizados controles de autenticação para autorizar e validar qualquer
acesso;
7. Todos os funcionários ou prestadores de serviço deverão utilizar alguma forma visível
de identificação e informar à segurança sobre a presença de qualquer pessoa não
identificada ou de qualquer estranho não acompanhado;
92
8. Equipamentos conectados à rede local não poderão possuir placas ou hardware do tipo
fax modem uma vez que a mesma pode servir como porta de entrada para possíveis
ataques à base de informações da Secretaria de Receita;
9. Equipamentos como fotocopiadoras e máquinas de fax, devem ser instalados de forma
apropriada dentro de áreas de segurança para evitar acesso do público de modo a não
comprometer a segurança da informação;
10. As portas e janelas deverão ser mantidas fechadas quando não utilizadas, sendo
instaladas proteções externas principalmente quando essas portas e janelas se
localizarem em andar térreo;
11. As instalações de processamento da informação gerenciadas pela Secretaria de Receita
devem ficar fisicamente separadas daquelas gerenciadas por terceiros ou contratados
eventuais;
12. Os arquivos e as listas de telefones internas que identificam os locais de processamento
das informações sensíveis não devem ser acessados pelo público;
13. Materiais combustíveis ou perigosos devem ser guardados de forma segura a uma
distância apropriada de uma área de segurança;
14. Equipamentos de contingência e meios magnéticos de reserva devem ser guardados a
uma distância segura para evitar danos que podem se originar em um desastre da
instalação principal;
15. Todo trabalho desenvolvido em área de segurança deverá ser supervisionado por um
funcionário da Gerência de Segurança;
16. Qualquer equipamento de gravação, seja fotografia, vídeo, som ou outro tipo de
equipamento, só deve ser utilizado a partir de autorização da alta administração;
17. Somente pessoal autorizado previamente pelas áreas de segurança da rede e das
informações poderão ter acesso a área de manipulação e suporte (carga e descarga)
externa ao prédio da Secretaria de Receita ;
18. Todo o material de entrada deve ser inspecionado contra potenciais perigos antes de ser
transportado para a área na qual será utilizado, sendo o mesmo registrado conforme
orientação da Gerência de Segurança;
19. Os equipamentos devem ser protegidos contra falhas de energia e outras anomalias na
alimentação elétrica utilizando-se sempre UPS (no-breaks);
20. O sistema de energia elétrica deverá incluir além de alimentação múltipla, geradores e
no-breaks visando a continuidade da operabilidade de acesso às informações da base de
dados;
93
21. O uso de qualquer equipamento para o processamento das informações fora dos limites
da Secretaria de Receita deverá ser autorizado pela alta administração da mesma;
22. Os cabeamentos elétricos e de telecomunicação que transmitem dados ou suportam
serviços de informação devem ser protegidos contra interceptação ou dano;
23. As linhas elétricas e de telecomunicações dos recursos de processamento da
informação devem possuir aterramento, onde possível, ou serem submetidas a proteção
alternativa adequada;
24. O cabeamento da rede deverá ser protegido contra interceptações não autorizadas ou
danos, por exemplo pelo uso de conduítes ou evitando a sua instalação através de áreas
públicas;
25. Os cabos elétricos devem ficar separados dos cabos de comunicação para prevenir
interferências;
26. Todo equipamento deverá ter sua manutenção revista de tempos em tempos, segundo a
orientação do fabricante do mesmo, evitando que a ocorrência de falhas possa
prejudicar o acesso à base de informações;
27. Deve-se usar uma cobertura adequada de seguro para proteger os equipamentos
existentes fora das instalações da Secretaria de Receita;
28. Papéis e meios magnéticos de computadores devem ser guardados em gavetas
adequadas com fechaduras ou em outros itens de mobiliários seguros quando não
estiverem sendo utilizados, especialmente fora do horário normal de trabalho;
29. Computadores pessoais, terminais de computador e impressoras não devem ser
deixados ligados quando não assistidos e devem ser protegidos com senhas, chaves ou
outros controles quando não estiverem em uso;
30. Informações sensíveis e classificadas, quando impressas, devem ser retiradas da
impressora rapidamente;
31. Equipamentos, informações ou software não devem ser retirados da instituição sem
autorização;
32. A sala do CPD deverá permanecer trancada com acesso livre apenas ao pessoal
autorizado da Gerência de Segurança;
33. Os equipamentos servidores e dispositivos que caracterizam o CPD deverão estar em
uma sala devidamente climatizada com controle de acesso;
34. Todos os microcomputadores em rede deverão possuir chave de segurança para
travamento da CPU, não permitindo, portanto, o acesso por pessoa não autorizada ao
interior do equipamento.
94
35. As mídias de backup deverão ser acondicionadas em cofre com características especiais
para suportar incêndios e outros tipos de intempéries;
36. O CPD deverá possuir um sistema de detecção/alarme e combate automático para caso
de incêndio;
37. Todas as salas internas do CPD deverão possuir extintores para combate de incêndio
elétrico (CO2/Pó químico);
38. Todas as saídas de emergência deverão estar claramente identificadas e desimpedidas
visando facilitar a fuga, caso necessário;
39. O backup dos dados deverá ser feito diariamente de forma incremental e semanalmente
de forma completa; e
40. Deverá existir um sistema de iluminação alternativa para o CPD e áreas de fuga.
5.6. APLICABILIDADE
A Política de Segurança das Secretarias de Receita será aplicável a todo funcionário
ou prestador de serviço que tenha acesso às dependências da mesma.
5.7. RESPONSABILIDADE
Todo funcionário ou prestador de serviço das Secretarias de Receita será
responsável pelo cumprimento das orientações estabelecidas na Política de Segurança,
contudo, cabe aos gerentes de cada departamento o controle e o acompanhamento do
cumprimento das mesmas.
5.8. SANÇÕES
Aos usuários que, de forma intencional ou não, desrespeitarem as normas
estabelecidas pelo Conselho de Segurança das Secretarias de Receita serão aplicadas as
seguintes sanções:
• Advertência verbal;
• Advertência escrita;
• Suspensão do direito de uso de serviço da intranet;
95
• Suspensão do direito de uso de serviços oferecidos pela rede Secretarias de
Receita por tempo determinado; e
• Demissão.
Observação: A aplicação destas sanções não isenta o usuário da base de dados das
Secretarias de Receita de sofrer outras penalidades previstas em Regulamentos Internos da
Secretaria, ou mesmo de sofrer processos penais por crimes de peculato, de extravio,
sonegação e inutilização de livro ou documento, de condescendência criminosa, de
violação de sigilo funcional entre outros estabelecidos no código penal.
5.9. PLANO DE CONTINGÊNCIA
O Plano de Contingência da Secretaria de Receita será formado por dois
componentes distintos, que são o Plano de Ação para Emergências e o Plano de
Recuperação de Desastres. Ambos os planos ajudarão as Secretarias de Receita a proteger
sua capacidade de processar dados. O propósito do Plano de Ação para Emergências é
prevenir e/ou limitar os danos aos recursos de informação. O propósito do Plano de
Recuperação é restaurar de maneira segura as operações após a contenção dos danos.
5.9.1.1 Plano de Ação para Emergências
O plano de ação é composto do seguintes itens:
• A primeira seção é um inventário completo de todos os recursos de informação
e uma avaliação de sua criticidade;
• A segunda seção é a identificação de possíveis ameaças às operações do site das
Secretarias de Receita e as contramedidas existentes/propostas para cada
ameaça; e
• A terceira seção é o procedimento de resposta imediata documentando ações
remediais a serem tomadas após a identificação das ameaças.
O desenvolvimento e manutenção do plano de ação deve ser feito da seguinte
forma:
• O Gerente da Rede/Especialista em TI, os encarregados da segurança e outros
membros do staff devem realizar um inventário dos recursos e,
96
subseqüentemente, determinar a criticidade de cada recurso identificado usando
o formato fornecido mais adiante;
• O Gerente da Rede/Especialista em TI, os encarregados da segurança e outros
membros do staff devem em seguida identificar as possíveis ameaças a estes
recursos e as devidas contramedidas existentes ou propostas, usando o formato
fornecido neste documento;
• O Gerente da Rede/Especialista em TI, os encarregados da segurança e outros
membros do staff devem formular um Procedimento Imediato de Resposta
usando a informação fornecida neste documento;
• Sempre que houver uma compra significativa de novos recursos de informação,
o Plano de Ação deve ser atualizado para refletir tais mudanças; e
• O Gerente da Rede/Especialista em TI e o encarregado da segurança devem
rever anualmente o conteúdo deste plano e fazer as devidas mudanças sempre
que necessário.
5.9.2.2 Contagem dos Recursos e Avaliação de Criticidade
A contagem dos recursos e avaliação de criticidade identificam todos os recursos de
informação e depois documentam a criticidade dos mesmos. Os recursos identificados
devem incluir hardware e software, periféricos, armazenagem de mídia, máquinas de fax,
modems, sistemas de controle climático, documentação e pessoal. Recursos também
incluem serviços tais como telefonia, eletricidade e internet. A criticidade destes recursos
deve ser determinada em termos de quanto tempo as Secretarias podem funcionar sem eles.
Para fins de uniformidade uma escala de 0 a 5 deve ser usada e definida da seguinte
forma:
0 – a Secretaria pode funcionar indefinidamente sem este recurso
1 – a Secretaria pode funcionar até um mês sem este recurso
2 - a Secretaria pode funcionar até duas semanas sem este recurso
3 - a Secretaria pode funcionar até uma semana sem este recurso
4 - a Secretaria pode funcionar até um dia sem este recurso
5 - a Secretaria pode funcionar até quatro horas sem este recurso
97
O quadro é um exemplo de como pode ser feita a contagem e classificação de
recursos:
CRITI QUANT DESCRIÇÃO DO RECURSO
4 1 Pentium/800 server: 128MB RAM, 1.44MB FD, 14GB HD, Monitor
3 1 Pentium/800 server: 128MB RAM, 1.44MB FD, 9GB HD, Monitor
2 5 CD-ROM
4 3 10BASE-T Transceiver
4 5 HP Laserjet 4500
1 2 32 bit NIC card (extra)
4 10 MS Office 97
5 1 Serviço de telefonia
5 1 Eletricidade
4 2 Pessoal operacional
3 4 Extintores de incêndio (água)
Tabela 3 – Contagem de Recursos
5.9.2. Identificação de Ameaças e Contramedidas
Ameaça é qualquer circunstância ou evento com potencial para comprometer e/ou
interromper as operações diárias de uma instituição. Ameaças são vistas como sendo de
natureza física, ambiental, e relacionadas a suporte. Os sites da Secretaria de Receita
tornam-se vulneráveis quando contramedidas não forem implementadas para impedir ou
diminuir o impactos de todas as ameaças identificadas. Ameaças são concretizadas quando
uma ou mais vulnerabilidades são exploradas.
A seguir encontra-se uma lista abrangente de ameaças divididas em três categorias
distintas. Esta lista não tem a pretensão de ser exaustiva. Há várias outras possíveis
ameaças particulares a cada unidade das Secretarias de Receita. Esta lista tem como
objetivo servir de base para a identificação das ameaças existentes nas Secretaria de
Receita em geral.
98
AMBIENTAIS FÍSICAS RELATIVAS A SUPORTE
- Fogo
- Enchente
- Explosões
- Raios
- Condições climáticas adversas
- Fumaça
- Poeira
- Insetos
- Vapores químicos
- Roedores
- Interferência eletromagnética
- Descarga Eletrostática
- Ativação de sprinklers
- Vazamento de água
- Acesso não autorizado às
instalações
- Transporte inadequado de
equipamentos
- Montagem/Armazenamento
incorreto
- Derramamento/queda
- Riscos de acidentes de viagem
- Roubo
- Sabotagem
- Vandalismo
- Extorsão
- Terrorismo/ameaça de bomba
- Supressão Inadequada de
Incêndio
- Queda de energia
- Ruído elétrico/aterramento
inadequado
- Temperaturas instáveis
- Umidade excessiva
- Manutenção imprópria
- Indisponibilidade de pessoal
- Falha no sistema de telefonia
Tabela 4 – Identificação de Ameaças
Cada Secretaria de Receita deve escolher a lista de ameaças que diz respeito a
qualquer recurso de informação em sua localidade, independente das contramedidas. Após
a identificação de todas as possíveis ameaças, a Secretaria de Receita deve avaliá-las e
delinear todas as contramedidas existentes ou propostas para cada ameaça aos recursos. As
Secretarias de Receita devem fazer uma distinção entre as contramedidas existentes e as
propostas. Caso as contramedidas propostas não possam ser implementadas em tempo,
uma solução provisória deve ser identificada.
99
Mostramos a seguir o exemplo de uma relação das ameaças e suas contramedidas:
AMEAÇA
CONTRAMEDIDA
1. Fogo Ter um sistema de sprinklers espalhados por todo o prédio. Extintores de incêndio disponíveis em locais de fácil acesso em todo o prédio. **Propõe-se a instalação de equipamento de identificação e combate a incêndio na sala do servidor.** Solução provisória – instalação de extintores de dióxido de carbono na sala do servidor.
2. Explosão Ter um acordo com outra organização onde uma apóie a outra em caso de explosão.
3. Raio Pára-raios instalados no teto. **Propõe-se a instalação de UPS para os servidores.
4. Fumaça Detetores de fumaça em todo o prédio. 5. Poeira Fazer limpeza completa do prédio. Manutenção preventiva com limpeza
de todo o equipamento. Filtros de ar instalados na sala do servidor e trocados mensalmente.
6. Insetos Colocar telas em todas as portas e janelas. 7. Queda de energia elétrica
Possuir um gerador para suportar todo o prédio.
8. Aterramento inadequado
***Propõem-se que eletricistas e o pessoal de manutenção dos computadores revisem e consertem todo o aterramento.
9. Indisponibilidade de pessoal
Fazer uma lista com os números de telefone do pessoal de operações e suporte para os casos de emergência.
10. Acesso não autorizado
Manter trancadas as áreas de acesso. Ativar alarmes fora do horário de expediente.
11. Montagem/ Armazenamento Incorreto
Ter todos os equipamentos instalados corretamente para reduzir a possibilidade de pancada ou queda. A área de armazenagem deve ser fora da sala do computador com acesso e temperatura controlados.
14. Colisão Todos os equipamentos devem ser posicionados longe de áreas com muito movimento.
15. Roubo Colocação de trancas em todas as áreas de acesso. 16. Supressão Incorreta de Incêndio
Todos os extintores de incêndio com água devem ser removidos da sala do servidor.
Tabela 5 – Ameaças e Contramedidas
5.9.2 Procedimento de Resposta Imediata
O propósito do Procedimento de Resposta Imediata é limitar os danos no caso de
uma ameaça contra um recurso de informação se concretizar ou ser iminente. Este
procedimento deve documentar ações corretivas em ordem de execução e indivíduos e/ou
organizações especificas a serem contatadas.
100
No mínimo as seguintes informações devem ser incluídas no procedimento de
resposta imediata e verificadas a cada três meses:
1) Instruções detalhadas das ações corretivas para as ameaças existentes (tais como
fogo, vazamento de água, queda de energia, entre outros);
2) Os nomes, números de telefones de emergência do encarregado de ativar o
plano de contingência, do gerente da rede, do encarregado da segurança de
sistemas, do pessoal operacional, e do pessoal de manutenção dos sistemas; e
3) Número de telefone da polícia, bombeiros e hospitais locais.
5.9.3 Plano de Recuperação de Desastre
Este é um plano que facilita a segura restauração das operações do sistema após a
concretização de uma ameaça e a contenção dos danos. O propósito deste plano é reduzir o
impacto de um desastre através de uma rápida recuperação. A recuperação é efetuada por
meio de coordenação e efetiva utilização de todos os recursos de informação disponíveis.
Este plano prevê uma resposta regional ou global a desastres através de esforços
combinados entre as Secretarias de Receita. Esta resposta deve adotar o conceito de
compartilhamento e/ou redirecionamento de recursos sobressalentes de informação entre
as diversas unidades das Secretarias de Receita. Este conceito incentiva o apoio mútuo
entre as unidades sem incorrer em custos adicionas substanciais.
5.10. AUDITORIA
Auditar e ouvir são sinônimos, pois vêm do verbo latino auditare, portanto
auditoria é ouvir as informações sobre um processo, a fim de transformá-las em correções
ou melhorias deste processo.
Auditar um processo, é gerar conhecimento de suas várias etapas. A eficácia da
auditoria dependerá de sua continuidade e de seu dinamismo em acompanhar um processo
em seu desenvolvimento. A auditoria tem o papel de colher informações e transformá-las
em conhecimento. É a principal auxiliar na administração de um sistema de dados, pois a
eficácia administrativa está na aplicação dos conhecimentos continuamente adquiridos.
101
Figura 13 - Formação da Cultura de Segurança
Para um processo de auditoria em uma instituição pública, é necessário obter
informações sobre o sistema com usuários, dados, equipamentos e ambiente, ou melhor,
auditá-los, como a forma mais eficaz de conhecer o processo e os seus procedimentos,
aplicados à área de segurança de rede no ambiente de uma instituição tributária.
Para adequação da auditoria de sistemas de dados a uma política correta de
segurança, este trabalho tem como base as recomendações ISO/IEC 17799:2000 para
auditorias e apresenta em sua metodologia sugestões de diversos autores citados no
decorrer do desenvolvimento.
5.10.1. Recomendações ISO/IEC 17799:2000
A auditoria tem com objetivo: Maximizar a eficácia e minimizar interferência no
processo de auditoria de sistemas.
Devem existir controles para salvaguardar os sistemas operacionais e ferramentas
durante as auditorias de sistemas.
Proteção também é necessária para salvaguardar a integridade e prevenir o uso
impróprio das ferramentas de auditoria.
Estas três primeiras diretrizes são as máximas que devem reger toda ação de
aplicação de auditoria em qualquer tipo instituição, pois nos garante a aplicação limpa e
didática da ação auditora.
102
As auditorias requerem atividades, envolvendo verificações nos sistemas
operacionais que devem ser cuidadosamente planejadas e acordadas para minimizar
riscos de interrupção dos processos do negócio.
Requisitos de auditorias devem ser acordados com a administração apropriada.
Escopo da verificação deve ser acordado e controlado.
A verificação deve ser limitada para acesso ao software e aos dados somente
paraleitura. Outros acessos diferentes de apenas leitura devem somente ser permitidos a
cópias isoladas de artigos do sistema, que devem ser apagadas quando a auditoria for
finalizada.
Os recursos de tecnologia para execução da verificação devem ser identificados
explicitamente e tornados disponíveis.
Requisitos adicionais ou especiais devem ser identificados e acordados.
As normas ISO/IEC 17799:2000 citadas anteriormente harmonizam a ação auditora
ao ambiente operacional auditado, ampliando a troca de informação e conhecimento sobre
o modus operare do processo, facilitando os ajustes e correções de falhas, dada apropriada
cumplicidade adquirida no processo auditado.
Todo o acesso deve ser monitorado e registrado de modo a produzir uma trilha de
referência.
Todos os procedimentos, requerimentos e responsabilidades devem ser
documentados (ISO/IEC 17799:2000).
Estas últimas normas a partir de seus registros e documentos darão o subsídio para
debates e discussões que irão aprimorar as diretrizes e normas da política de segurança no
decorrer do tempo, respondendo dinamicamente às ameaças e riscos que futuramente
poderão surgir.
5.10.2. Tipos de Auditoria Propostos
Aplicação de Auditoria Interna e Externa tem sido empregada com bastante êxito
em várias empresas privadas ou públicas. As auditorias internas são mantidas com recursos
e funcionários da própria empresa, em sua maioria da área de informática. Auditorias
externas são formadas por firmas especializadas em auditoria de sistemas, que
disponibilizam os seus serviços a empresas contratantes.
A melhor maneira de se colherem informações de um sistema é com as pessoas que
estão vivenciando o processo atual do sistema de dados e também com aquelas que têm
103
muita experiência neste tipo de processo e que vivam profissionalmente de organismos
especializados em auditorias que capturam estes tipos de informação nas diversas empresas
auditadas e se atualizam constantemente com as inovações do mercado.
As auditorias internas têm algumas vantagens importantes: não são tão perceptíveis
aos funcionários quanto as auditorias externas; têm como atuar periodicamente realizando
revisões globais; são mais econômicas pois seus recursos são menos onerosos; atuam
muito rapidamente nos casos de emergência; são fortes fontes de consulta atualizada,
principalmente nos sistemas muito especializados, ponto de apoio e base para as auditorias
externas; são as guardiãs dos vários planos de segurança estabelecidos pela organização.
As equipes auditoras internas são compostas por funcionários, na sua maioria do
setor de informática, mas comumente podem ter um ou outro funcionário ligado às áreas
em questão, principalmente em se tratando de áreas de maior risco.
Nas auditorias externas a equipe é formada por funcionários com dedicação
exclusiva, que trabalham em firmas de auditoria, com especialização em sistemas. Podem
somar conhecimento adquirido por experiências em outras empresas e através de altos
graus de especialização e de renovação constante do conhecimento, uma vez que se
dedicam com exclusividade a este ramo de negócio. Comumente se espera uma maior
objetividade por partes destas empresas.
O emprego das duas auditorias, interna e externa, é chamado de auditoria articulada,
devido à superposição de responsabilidades e uso comum de recursos. Esta constitui a
auditoria de melhor proveito para colher informações e adquirir conhecimentos sobre
sistema de informação de dados.
As auditorias interna e externa devem estar ligadas hierarquicamente ao Comitê de
Segurança, o qual poderá convocá-las ou dissolvê-las. Seus relatórios e documentos são de
uso exclusivo deste comitê.
5.10.3. Quando Devem ser Feitas as Auditorias
A auditoria advém da necessidade de que um sistema de dados seja seguro agora e
continue sendo seguro no futuro, como condição sine qua non à continuidade do negócio,
por isso a necessidade de correção freqüente e continuada de seu sistema de segurança.
É evidente que não poderá haver regra de periodicidade muito rígida para que
sejam feitas estas auditorias. Isto dependerá de muitos fatores, tais como grau de
conscientização e aprendizado de usuários e administradores e da conceituação da política
104
de segurança empregada, dos sistemas lógicos, físicos e ambientas das unidades de
informação.
Serão usadas algumas recomendações de Wietse Venema & Dan Farmer (1996)
para distribuir as Auditorias em relação ao tempo: • Antes do funcionamento da rede;
• Agendadas de manutenção; e
• Auditoria Emergencial.
Na auditoria antes do funcionamento deve-se fazer uma análise do grau de
conscientização e vulnerabilidade, ameaças, e riscos internos e externos, já adequando
politicamente e fisicamente a rede para a redução dos riscos de quebra de segurança.
As auditorias agendadas devem ser continuadas de acordo com as necessidades e
padrões de segurança assegurados a uma redução de riscos de incidentes de segurança na
rede.
O estado crítico, a complexidade e o corpo administrativo devem ser considerados
para a decisão de periodicidade para auditorias agendadas.
• Estações de trabalhos: entre 12 a 24 meses;
• Redes grandes: 24 meses; e as pequenas: 12 meses; e • Firewall: a cada 6 meses ou menos.
As auditorias emergenciais devem ocorrer logo após o incidente de segurança,
devendo-se fazer primeiro uma análise dos estragos, através da verificação de integridade
do sistema antes do acidente. Alguns programas de integridade podem ajudar na
identificação de mudanças ocorridas.
5.10.4. Como Auditar
A preparação da auditoria passa pela criação de um ambiente propício à sua
implementação, no qual devemos desenvolver o comprometimento da alta gerência à sua
implantação como premissa para êxito do empreendimento. Também nas gerências
imediatas e subalternas deve haver comprometimento como reforço adicional.
O comprometimento é expresso em documento onde constam as principais diretrizes
da política de segurança, como seu objetivo em contexto aos objetivos estratégicos e dos
negócios da Secretaria de Receita como um todo.
105
O engajamento dos funcionários é premissa complementar de uma boa auditoria.
Deve ser feito através de conferências explicativas, estudo dirigido, debates ou outras
formas didáticas a fim de proporcionar o desenvolvimento de uma cultura da necessidade
de auditoria permanente e atuante como fonte de alimentação da política de segurança.
A equipe de auditoria, em decorrência dos serviços que está prestando, passa a
maior parte do tempo falando com pessoas sobre procedimentos, rotinas e sistemas,
discutindo os achados, resumindo as observações e recomendações. É essencial o
desenvolvimento da habilidade em entrevistas. Na apresentação o entrevistador deve
atenuar a natural ansiedade do auditado. Durante a entrevista deve incentivar a
oportunidade ao entrevistado de dar sugestões a problemas específicos. Na despedida deve
lembrar que não estão encerrados os contatos, pois haverá novos encontros em outras
ocasiões, já que auditorias são instrumentos contínuos de melhoria do sistema e
aperfeiçoamento da política de segurança.
As modalidades de entrevistas podem ser: contato pelo correio, contato telefônico e
contato direto.
A remessa de carta via correio não pode ser considerada uma entrevista, mas é um
contato onde não é necessária a presença do entrevistado. Comumente é usada quando o
universo é muito grande e disperso geograficamente, pois há uma redução considerável de
custo nestes casos, mas o número de respostas é muito baixo dificultando a análise dos
resultados obtidos.
O contato telefônico atinge um grande número de pessoas em um tempo de trabalho
curto, pois o tempo deve variar entre 30 a 15 minutos sendo o ideal apenas 15 minutos,
mas perde a observação do entrevistador das reações não verbais do entrevistado e também
o calor humano que é muito importante para estabelecimento de um ambiente de
cooperação mútua entre auditor e auditado.
Nas entrevistas de contato direto pode-se estabelecer de maneira mais fácil um
contado amistoso com o auditado, onde se desenvolve um ambiente propício à confiança e
cooperação, que proporcionará as trocas de informação sobre os procedimentos, rotinas e
sistemas, em cada uma das etapas do processo em abordagem. A habilidade do
entrevistador é de suma importância para este clima.
A cada término de entrevista devem-se recapitular perguntas respondidas e as
informações obtidas que serão devidamente registradas e mostradas ao entrevistado como
sua contribuição à auditoria.
106
5.10.5. Metodologia
Nesta última década várias metodologias de auditoria foram criadas dada a
necessidade de desenvolvimento da política segurança em TI. Pelo menos cinco
documentos foram publicados por instituições diferentes com o intuito de definir acessos,
relatos e melhorias no controle interno em TI, como o do Information Systems Audit and
Control Foundation, o Control Objectives for Information and related Technology (CobiT
1996, 1998, 3ª edição em julho de 2000), o do Institute of Internal Auditors Research
Foundation, o Systems Auditability and Control (SAC 1991, revisada em 1994), o do
Committee of Sponsoring Organizations of the Treadway Commission, Internal Control-
Integrated Framework (COSO 1992), o do American Institute of Certified Public
Accountant, o Consideration of the Internal Control Structure in a Financial Statement
Audit (SAS 55,1988), e a sua emenda (SAS 55/78, 1995), mostraremos o quadro
comparativo de suas diferenças no Anexo I.
A metodologia empregada pela auditoria CobiT incorpora várias fontes
conceituais de outras metodologias como a SAC e a COSO, que por sua vez absorveram os
conceitos de controle interno do SAS 55/78. A definição conceitual CobiT adapta o
controle do COSO: As políticas, procedimentos, práticas e estruturas organizacionais são
orientadas para prover uma razoável garantia, de modo que o objetivo dos negócios seja
alcançado, e que eventos não desejados sejam evitados ou detectados e corrigidos.
A metodologia CobiT é orientada em dois pontos de apoio: Objetivos ou Metas do
Negócio e a Governança em TI. No primeiro ponto estão as metas das Secretarias de
Receita que são a sua arrecadação e a distribuição do erário público nas diversas
secretarias. O segundo ponto, a Governança de TI: Uma estrutura de relações e processos
para dirigir e controlar a empresa a fim de alcançar as metas do negócio, adicionando
valor enquanto balanceia risco verso retorno em TI e seus processos (CobiT,2000).
Governança de TI é da responsabilidade da alta direção e da administração
executiva. É uma parte integrante de governo da empresa. É composta pela liderança da
estrutura organizacional e o processo que garante que a TI da organização se apóie e se
expanda às estratégias e aos objetivos da organização.
Os objetivos de controle se relacionam de maneira clara e distinta com os objetivos
do negócio, que definidos com uma orientação aos processos, determina um início de
reengenharia nos negócios se necessário.
107
A metodologia CobiT identifica uma ferramenta que chama de Marco Diferencial
de quatro domínios que está dentro da Governança de TI que são:
• Planejamento e organização;
• Aquisição e implementação;
• Suporte e distribuição; e
• Monitoração.
A metodologia CobiT identifica os processos de TI a cada domínio, os chamados de
objetivos de controles de alto nível, um total de 34 objetivos, que cobrem toda a estrutura
no aspecto de informação e seu suporte tecnológico. Ainda foi desenvolvido um
instrumento guia de auditoria para cada um dos 34 objetivos de controles, assegurando um
exame detalhado dos processos de TI. Os objetivos detalhados, num total de 318,
proporcionam à administração da empresa um panorama de real cumprimento das normas e
regras ou recomendações e aprendizados para desenvolvimento de uma cultura forte em TI.
108
Figura 14 – Estrutura da Metodologia COBIT
Fonte: Implementation Tool Set CobiT, 3rd Edition Boston July 2000, CobiT Steering Committee and the IT governance Institute
109
6. CONCLUSÃO
Com base no que foi apresentado e desenvolvido neste trabalho constatamos que a
implementação de uma política de segurança de informação nas organizações como as
Secretarias de Receita tornou-se fundamental.
A preocupação com a integridade, confidencialidade e autenticidade das
informações exige das organizações uma meticulosa análise de vulnerabilidades e riscos
que ameaçam suas bases de dados.
É importante ressaltar que tivemos algumas limitações para a realização deste
trabalho, pois muitos detalhes técnicos, características próprias e situações encontradas
durante o processo de levantamento de informações não puderam ser divulgados para
garantir e resguardar o funcionamento e segurança das próprias Secretarias de Receita.
Mecanismos e ferramentas de defesa tais como os apresentados neste trabalho
foram apresentados com o intuito de garantir a proteção das informações consideradas
sigilosas ou de acesso restrito.
Neste trabalho, procurou-se sugerir às Secretarias de Receitas recursos de proteção
das informações, procedimentos de usuários, métodos de controle através de auditorias e
um plano de contingência que viabilizasse a continuidade dos negócios em caso de
desastres ou qualquer tipo de infortúnio, baseando-nos no levantamento dos riscos,
ameaças e vulnerabilidades a que este tipo de organização esta sujeita.
Nossa base de estudo para coleta de dados foi a Secretaria de Receita de Brasília-
DF. Assim, faz-se necessário que, para cada Secretaria, distribuída por todo território
nacional, seja implementada uma política de segurança adaptada à sua realidade.
Enfatizamos a necessidade de criação e implementação de planos de ação
emergenciais e recuperação de informação em caso de desastres reforçando ainda, a
importância de que todo este processo seja constantemente auditado.
Constatamos que a prática constante de auditorias internas e externas é o modo
mais eficaz de ouvir e responder ao dinamismo de um processo de TI. Para apresentação
deste tema, tomamos como base o sistema CobiT, elaborado e inspirado na norma ISO/IEC
17799:2000. O CobiT é bastante novo e pouco conhecido, não sendo encontrado muito
material a seu respeito.
A ISO/IEC 17799:2000 serviu como principal fonte de referência e base para o
trabalho no que se refere aos conceitos envolvidos na implementação de uma Política de
110
Segurança de informação, análises de riscos e vulnerabilidades de uma base de dados e
principalmente na parte de controles de segurança física e pessoal.
Apesar de ter sido primordial para a realização deste trabalho, a norma ISO/IEC
17799:2000 é uma fonte de informações recente, não tendo sido ainda bastante divulgada
para as organizações. Existem poucos trabalhos para a consulta no aspecto da segurança de
informação, o que de certa forma limitou nosso âmbito de pesquisa.
Com relação a parte de segurança lógica, a norma ISO/IEC 17799:2000 apresenta o
tema de forma distribuída em sua maior parte, abordando separadamente os aspectos de
segurança de senhas e processos criptográficos. Não há um detalhamento dos
procedimentos de segurança referentes à parte de software e acesso lógico à rede.
Em virtude desta distribuição, a proposição de uma política de segurança para as
Secretarias de Receita, não poderia ser exclusivamente baseada na ISO/IEC 17799:2000.
Os controles referentes às partes de segurança física e aplicada a pessoas foram, em
sua maioria, retirados da ISO/IEC 17799:2000. Cerca de 30% dos mesmos foram
adaptados. Com relação aos controles lógicos, 80% dos mesmos foram modificados e
adaptados ao contexto do trabalho.
Apesar da necessidade de complementações, a ISO/IEC 17799:2000 é, atualmente,
a mais completa base de orientação para formação e consolidação de um programa de
Política de Segurança.
Diversas outras fontes bibliográficas contribuíram para a consolidação do trabalho.
A apresentação das ferramentas de segurança como métodos de criptografia, uso de
firewall, anti-vírus, softwares especializados, juntamente com o estabelecimento de
controles baseados na norma ISO/IEC 17799:2000, a responsabilização dos usuários do
sistema possibilitaram que o objetivo principal do trabalho fosse alcançado, ou seja, a
sugestão de uma política de segurança eficaz para as Secretarias de Receita .
Acreditamos que o uso contínuo de auditorias bem estruturadas e com
metodologias adequadamente empregadas, englobando os três elementos chaves da
segurança: pessoas, dados e ambiente físico, proporcione a criação de um ambiente de
informações resguardadas e protegidas.
Esperamos, enfim, que este trabalho, pioneiro na área de segurança de informações
para instituições governamentais que tratem de tributação e arrecadação, sirva de base e
fonte de consulta para outros.
111
REFERÊNCIAS BIBLIOGRÁFICAS
A Comparison of Internal Controls: CobiT®, SAC, COSO and SAS 55/78; By: Janet L.
Colbert, Ph.D., CPA; e Paul L. Bowen, Ph.D., CPA, 2001. Disponível em:
http://www.isaca.org/bkr_cbt3.htm. Acesso em abril de 2001.
An Introduction to Computer Security: The NIST Handbook. Special Publication 800-12.
National Institute of Standards and Technology, U.S. Department of Commerce.
Disponível em http://www.nist.gov. Acesso em março de 2001.
Arquitetura de Segurança, Desenvolvido pela HP para o Tribunal Superior Eleitoral.
Board Briefing on It Governance. IT Governance Institute, Information Systems Audit and
Control Association (ISACA), Information Systems Audit and Control Foundation,
(ISACF),2001. Disponível em http://www.isaca.org e http://www.Itgovernace.org
Acesso em abril de 2001.
BRASIL. Constituição Federal. Lei n.º 7.716 de 1996 sobre discriminação racial; Lei No.
8.069 de 1991 sobre pornografia infantil; e Lei No. 9.296 de 96 sobre interceptação
telemática (grampo).
Canadian Trusted Computer Product Evaluation Criteria – (CTCPEC) vol1.vol 2
Disponível em ftp.cse.dnd.ca. Acesso em março de 2001.
Computer Crime and Security Survey, CSI/FBI , 2001.
Common Criteria Overview. Disponível em: http://www.radium.nscs.mil/tpep/library/
ccitse/cc_over.html. Acesso em junho de 2001.
Cooperation on Security of Information Systems Joint Task 01. Foundations for the
Harmonization of Information Technology Security Standards; Revised Draft, Version b; Abril 1993.
Department of Defense Trusted Computer System Evaluation Criteria, Orange Book: 26
December 1985 Disponível em http://www.radium.ncsc.mil/tpep/library/rainbow/ 5200.28-STD.html. Acesso em Março de 2001.
112
DIAS, Claudia. Segurança e Auditoria da Tecnologia da Informação. 1ª Edição. Rio:
Axcel Book, 2000.
Federal Criteria of Information Technology Security. Vol. 1 e Vol 2 . Disponível em
http://www.undergroundnews.com/kbase/underground/hacking/fcsvol1.htm /http://www.undergroundnews.com/kbase/underground/hacking/fcsvol2.htm.Acesso em abril de 2001.
GUTTMAN, Barbara; BAGWILL, Robert. Internet Security Policy: A Technical Guide
NIST Special Publication 800-XX.. July, 1997. Disponível em http://csrc.nist.gov/isptg.
Acesso em maio de 2001.
HELD, Gilbert. Comunicação de Dados. 6ª Ed. Rio de Janeiro: Editora Campus, 1999.
Implementation Tool Set CobiT. 3rd Edition Boston July 2000, CobiT Steering Committee
and the IT Governance Institute. http://www.isaca.org e http://www.Itgovernace.org.
Acesso em maio de 2001.
Information Security management - Part 1: Code of Practice for Information Security
Management; BS 7799-1:1999.
Information Security Risk Assessment. United States General Accounting Office
Disponível em http://www.gao.gov. Acesso em abril de 2001.
Information Technology Security Evaluation Criteria-ITSEC, Department of Trade and
Industry. Disponível em http://www.itsec.gov.uk. Acesso em maio de 2001.
ISO/IEC 17799:2000. First edition 10/12/2000. Disponível em http://www.iso.ch. Acesso
em março de 2001.
OPPENHEIMER, Priscila. Projetos de Redes Top-Down. 1a. Ed. Rio: Campus, 1999.
PFLEEGER, Charles. Security in Computing. Ed.2. NJ: Pearson, 1996.
Rede Tchê: Segurança de Dados. Universidade Federal do Rio Grande do Sul. Disponível
em http://www.cert-rs.tche.br/servicos/infosec.html. Acesso em abril de 2001.
113
RFC 2196 – Site Security Handbook, 1997. Disponível em http://www.-rn.informatik.uni-
bremen.de/home/ftp/doc/rfc/cfc2196.txt. Acesso em março de 2001.
Risk Management Guide. NIST Special Publication 800-30. First Public Draft June 2001.
Disponível em http://www.nist.gov. Acesso em julho de 2001.
ROBERTI, MICHAEL. Building an Enterprise Security Architecture. Sans Institute.
Abril, 2001. www.sans.org. Acesso em junho de 2001.
Seguridad Informática. Tema: Hackers. Disponível em http://www.monografia.com em
Maio de 2001.
Técnicas de Entrevistas para Auditorias. Brasil – DF TCU 1998. Disponível em
http://www.tcu.gov.br. Acesso em maio de 2001.
TERADA, Routo. Segurança de Dados: Criptografia em Redes de Computador. 1ª Ed.
São Paulo: Editora Edgard Blücher, 2000.
VENEMA, Wietse & FARMER, Dan. Security Auditing & Risk Analysis. April
30th,1996. Santa Clara (CA). Disponível em http://www.porcupine.org/auditing. Acesso
em april de 2001.
Xcert PKI Guide 2000. Disponível em www.xcert.com. Acesso em março de 2001.
ZACKER, Craig et DOYLE, Paul. Redes de Computadores: Configurações,
Manutenção e Expansão. 1ª Edição em Português. São Paulo: Makron Books, 2000.
114
ANEXO I
Comparação de Conceitos de Controle em Auditoria1 Instituições COBIT (1996) SAC(1991) COSO(1992) SAS 55(1988)
/78(1995) Audiência primária
Administração, usuários e auditores de sistema informação
Auditores internos Administração Auditores externos
Controle Interno visto como
Conjunto dos processos, inclusive Políticas, Procedimentos, Práticas, e as Estruturas de Organização
Conjunto de Processos, Subsistema e pessoas
Processo Processo
Objetivos da Organizacional em Controle Internos
Operações Efetivas & Eficiente, Confidencialidade, Integridade e Disponibilidade da Informação. Relato financeiro confiável, e Obediência às leis & regulamentos
Operações Efetivas & Eficiente, Confidencialidade, Integridade e Disponibilidade da Informação. Relato financeiro confiável, e Obediência às leis & regulamentos
Operações Efetivas & Eficiente, Confidencialidade, Integridade e Disponibilidade da Informação. Relato financeiro confiável, e Obediência às leis & regulamentos
Operações Efetivas & Eficiente, Confidencialidade, Integridade e Disponibilidade da Informação. Relato financeiro confiável, e Obediência às leis & regulamentos
Componentes ou Domínios
Domínios: Planejamento e Organização, Aquisição e Implementação, Suporte e Distribuição, e Monitoramento
Componentes: Ambiente de Controle, Sistemas Manuais & Automatizados, Procedimentos de Controle
Componentes: Ambiente de Controle, Avaliação de Risco Atividades de Controle, Informação & Comunicação, e Monitoramento
Componentes: Ambiente de Controle, Avaliação de Risco Atividades de Controle, Informação & Comunicação, e Monitoramento
Focos Tecnologia da Informação
Tecnologia da Informação
Sobre toda a Entidade
Balanço Financeiro
Efetividade de Controle Interna
Por um período tempo
Por um período tempo
Por um tempo pontual
Por um período tempo
Responsabilidade para Sistema de CI
Administração Administração Administração Administração
Formato 187 páginas em quatro documentos
1193 páginas em 12 módulos
353 páginas em quatro volumes
63 páginas em dois documentos
1 A Comparison Internal Controls: CobitT®, SAC, COSO and SAS 55/78; By: Janet L. Colbert, Ph.D., CPA, CIA;and Paul L. Bowen, Ph.D., CPA, year 2001(http://www.isaca.org/bkr_cbt3.htm)
115
ANEXO II
R E Q U E R I M E N T O
Pelo presente requerimento, eu, (fulano de tal), solicito acesso aos Sistemas da Secretaria da Receita, declarando que utilizarei o mesmo somente no estrito cumprimento de minhas atividades profissionais estando de pleno acordo com as seguintes determinações: 1) Devo cumprir fielmente as normas, políticas, procedimentos e diretrizes da Secretaria de
Receita destinadas à proteção de seus sistemas automatizados contra mal uso, abuso, perda ou acesso não autorizado. Compreendo que qualquer violação destes regulamentos podem resultar em ação administrativa, civil ou processo criminal, ou em demissão;
2) Devo proteger incondicionalmente o sigilo de minha senha. em caso de suspeita de comprometimento de seu segredo devo reportar o fato a meu supervisor ao administrador da rede;
3) Não devo compartilhar meu identificador de acesso (id) e senha com nenhum outro indivíduo;
4) Nunca devo transcrever minha senha em dispositivos ou locais que possam ser facilmente encontrados por outrem;
5) Devo criar e usar senhas com no mínimo 08 caracteres compostas de letras maiúsculas, minúsculas, caracteres especiais e números, devendo ainda, trocá-la no intervalo de tempo determinado pelo sistema;
6) Devo desconectar-me do sistema (logoff) sempre que necessitar de um afastamento de minha estação de trabalho por um tempo superior a 10 minutos;
7) Independente do motivo, devo notificar imediatamente ao administrador da rede quando não necessitar mais de acesso aos recursos do sistema;
8) Devo acessar somente os aplicativos aos quais tenho permissão autorizada pelo gerente da rede e utilizar os computadores da Secretaria de Receita somente para fins lícitos;
9) Estou proibido de usar a informação obtida através do acesso aos sistemas de computação da Secretaria para realização de ganho pessoal, lucro financeiro, ou publicação sem aprovação formal de meu superior;
10) Estou proibido utilizar os computadores da Secretaria para atividades ofensivas a meus colegas de trabalho ou ao público em geral, tais atividades incluem, mas não se limitam a: discursos sobre ódio, artigos que ridicularizem outras pessoas com base em raça, credo, religião, cor, sexo, deficiência física ou mental, nacionalidade, ou orientação sexual;
11) Estou proibido de acessar, criar, visualizar, guardar, copiar, ou transmitir por meio da rede da Secretaria de Receita, materiais contendo pornografia, apologia ao uso de drogas e armas, divulgação de jogos ilegais, atividades terroristas ou qualquer outra de natureza ilegal ou proibida.
_________________________ ________________________ __________________ NOME ASSINATURA DATA
116
ANEXO III
ISO/IEC 17799:2000. First edition 10/12/2000. Paragrafo 6. e 7
