Este artigo esclarece de forma sucinta a norma ISO/IEC TR 13335 parte 3 - Techniques for the management of it security. Publicada em 1998, descreve técnicas de gestão de segurança para a área de tecnologia da informação. Pode ser utilizada para trabalhar em conjunto com a BS 7799-2, que sugere quais os processos devem ser implantados para conduzir a gestão de segurança, enquanto que a ISO 13335-3 descreve as técnicas. Verifica-se que a parte 3 desta ISO em praticamente todas as cláusulas trata da gestão de risco com técnicas de análise de risco.
A norma consiste em 5 partes, sob o título geral de tecnologia da informação: diretrizes para gerenciamento da segurança em TI.
Parte1: conceitos e modelos para segurança em TI.
Parte2: gerenciamento e planejamento da segurança TI
Parte3: técnicas para o gerenciamento de segurança em TI
Parte4: seleção de proteção
Parte5: proteção para conexões externas.
A norma provê diretrizes no gerenciamento da segurança em TI. A norma deve ser adequada para as necessidades específicas de cada organização. Ela está dividida em 12 cláusulas e foi baseada nas diretrizes gerais das normas ISO/IEC TR 13335-1 e ISO/IEC TR 13335-2.
1. Técnicas para o gerenciamento da segurança em TI
Inclui a análise dos requisitos de segurança, o estabelecimento de um plano para satisfazer esses requisitos, a implementação do plano, bem como a manutenção e administração da segurança implementada.
É extremamente importante, em um gerenciamento de segurança, o processo de avaliação dos riscos, identificando como podem ser reduzidos e qual nível é aceitável.
2. Objetivos, estratégia e políticas da segurança em TI
Depois de estabelecidos os objetivos da segurança em TI e a estratégia de segurança, deve ser desenvolvida uma política de segurança corporativa. Além de baseada na análise de risco, essa política deve considerar os aspectos organizacionais, inclusive os objetivos corporativos e a cultura da empresa. É muito importante que a política de segurança esteja alinhada com a política corporativa.
2.1. Objetivos e estratégia da segurança em TI
Conhecer quanto o negócio depende de TI, a troca de informações e quanto a acuracidade, integridade, disponibilidade, confidencialidade são essenciais para a tomada de decisão, é fundamental que seja considerado qual o nível de risco que é aceitável para a organização. A correta definição desses parâmetros e o seu entendimento pela direção da empresa, influenciam fortemente no sucesso do gerenciamento da segurança.
O conhecimento de quanto a TI é importante para a organização é o ponto de partida para a definição dos objetivos e estratégias de segurança.
2.2. Política de segurança de TI corporativa
Uma política de segurança corporativa de TI deve ser produzida baseada de acordo com a estratégia e objetivos de segurança de TI.
É necessário estabelecer e manter uma política corporativa de segurança consistente com o negócio, segurança, políticas de TI, legislação e regulamentação.
Atividades relevantes de segurança descritas na política de segurança corporativa podem ser baseada nas estratégias e objetivos organizacionais, nos resultados das análises de risco, revisões, acompanhamento de resultados e nos relatórios de incidentes relevantes.
Essa política deve ser escrita de forma que seja compreendida por todos os níveis da organização. É importante que os funcionários assinem um documento formalizando o conhecimento da política de segurança e de suas responsabilidades. É fundamental um programa de divulgação e conscientização dessa política de segurança para todos os níveis da organização.
3. Ações de estratégia de análise de risco corporativa
A organização, antes de realizar uma análise de risco, deve ter definida a sua estratégia de análise, ou seja, metodologia, técnicas, ferramentas etc. Esta estratégia deve estar documentada na política de segurança corporativa de TI. Esses critérios abrangem, entre outros, o nível de risco aceitável, transferência do risco etc. A organização deve aprovar esses critérios.
Abaixo são apresentados quatro tipos de análise de risco. O que diferem elas, é o nível de detalhes.
Método Básico;
Método Informal;
Análise de risco detalhada;
Método combinado;
3.1 Método Básico
A organização pode aplicar os critérios de análise de risco, selecionando as correções padrão.
3.1.1. Vantagens
Mínimo de recursos é necessário para selecionar as correções, envolvendo tempo de esforço de TI;
Muitas correções básicas, são similares as adotadas para muitos sistemas que estão rodando nas organizações;
3.1.2. Desvantagens
Se o critério da base de risco dor definido como alto, pode ser um nível excessivo para alguns sistemas;
Se o nível definido como muito baixo alguns sistemas ficarão expostos;
Há dificuldade na gestão das mudanças relevantes de segurança. Se um sistema for atualizado, pode ser difícil avaliar se as correções básicas ainda são suficientes;
Se os sistemas de TI têm um nível baixo de requisitos de segurança, então essa é a melhor estratégia de custo benefício. Muitas organizações implementam o mínimo de correções necessárias para proteger dados sensíveis para atender as regulamentações.
3.2. Método Informal
É uma análise informal não estruturada em métodos, mas explora o conhecimento e experiência das pessoas.
3.2.1. Vantagem
Normalmente essa abordagem não requer muitos recursos e tempo. Não necessita uma habilidade adicional para conduzir este tipo de análise;
3.2.2. Desvantagens
Sem um processo formal os detalhes importantes são perdidos em uma próxima análise;
A justificativa para implementação de correções sem uma avaliação de risco se torna difícil;
Indivíduos que tem um mínimo de experiência em análise de risco, podem ter dificuldade em fazer esta tarefa;
Alguns métodos avaliações no passado estavam direcionados para vulnerabilidades como correções de segurança, aonde eram implementadas baseadas somente nas vulnerabilidades identificadas, sem considerar todo o ambiente;
Pode ser um problema se a pessoa que fez a análise de risco, deixar a organização;
As desvantagens acima mostram que essa opção não é um método efetivo de análise de risco para muitas organizações.
3.3. Análise de risco detalhada
É a terceira opção, onde é conduzida uma análise de risco detalhada para todos os sistemas de TI na organização. Esse processo envolve em detalhes a identificação e avaliação dos ativos, determinação das ameaças e vulnerabilidades. Os resultados da análise são usados para estimar os riscos, além de identificar justificar correções de segurança.
3.3.1. Vantagens
É provável que as correções apropriadas sejam identificadas para todos os sistemas;
Os resultados podem ser usados no gerenciamento das mudanças de segurança;
3.3.2. Desvantagens
Esse método requer uma considerável quantia de tempo, esforço e experiência para obter resultados. Há possibilidade de que as necessidades de segurança de um sistema crítico podem ser atendidas muito tarde. Todos os sistemas devem ser analisados no mesmo nível de detalhes, necessitando uma soma de tempo para completar esta análise.
3.4. Método combinado
A quarta opção conduz uma análise inicial de alto nível para todos os sistemas de TI, concentrando os valores do negócio que tais sistemas possuem, bem como os riscos a que estes sistemas estão expostos.
3.4.1. Vantagens
A incorporação desse método é rápida e simples, mostrando ganhos no programa de análise de risco;
É possível rapidamente construir uma estratégia para um programa de segurança organizacional;
Os recursos e investimentos podem ser aplicados aonde houver maior benefício, e sistemas que tenham maior necessidade de proteção devem ser priorizados;
3.4.2. Desvantagens
Como uma análise de risco inicial está em um alto nível e potencialmente menos exata, alguns sistemas podem não ser identificados nos detalhes da análise de risco.
Entretanto estes sistemas poderão ser convertidos de acordo com a segurança.
4. Identificação dos ativos
Um ativo não se limita a software e hardware. É tudo aquilo que tem valor para a organização. Os valores destes ativos devem ser providos pelos seus proprietários e usuários destes ativos.
Alguns tipos de ativos: dados, hardware, software, equipamentos de comunicação, dispositivos, documentos, pessoas, entre outros.
5. Avaliação de ameaças
Os ativos estão expostos a vários tipos de ameaças. Essas ameaças quando exploram as vulnerabilidades causam incidentes de segurança e considerável impacto, dependendo do valor do ativo para a organização.
As ameaças podem ter origem natural ou humana, tais como: erros ou omissão, fraudes ou roubo, sabotagem, vírus, incêndio, acidentes naturais, entre outros.
6. Avaliação de vulnerabilidades
Esta avaliação inclui a identificação de fraquezas no ambiente físico, organizacional, procedimentos, gerenciamento, softwares, hardwares, etc., que podem ser exploradas por uma ameaça, causando uma perda de confidencialidade, integridade ou disponibilidade.
O resultado da avaliação é a relação dos ativos e as vulnerabilidades, classificadas, por exemplo, como baixa, média e alta.
7. Avaliação de riscos
O objetivo é identificar através de uma avaliação, os riscos que os ativos estão expostos e identificar e selecionar uma correção de segurança justificada e apropriada. Com um conjunto de fatores como valor do ativo, vulnerabilidades e ameaças relacionadas, pode se obter o valor do risco.
Porém existem diferentes tipos de metodologias de análise, baseada em determinação de valores dos ativos, vulnerabilidades e ameaças, inclusive com softwares para automatizar esta análise.
8. Política de segurança do sistema de TI
A política de segurança de um sistema de TI deve conter detalhes de proteções requeridas e descrever porque são necessários. O plano de segurança de TI para o sistema procede em como implementá-los. A política de segurança de um sistema de TI deve ser compatível com a política de segurança de TI incorporada, e todo o conflito deve ser evitado, deve ser baseada nas análises estratégicas de riscos usadas.
9. Plano de segurança de TI
O plano de segurança de TI é um documento de coordenação definindo as ações a serem tomadas para implementar as proteções requeridas para um sistema de TI.
10. Implementação do plano de segurança de TI
A correta implementação de segurança das proteções depende de um plano de segurança bem estruturado e documentado, consciência de segurança e treinamento associado com cada sistema de TI deve ter um lugar em paralelo.
11. Implementação das proteções
Para a implementação das proteções, todos os passos necessários descritos no plano segurança de TI devem ser realizados. Para assegurar a continuidade e consistência, a documentação das proteções é uma parte importante da documentação de segurança de TI. Os procedimentos detalhados dos testes de segurança devem ser escritos, e um relatório de teste padrão deve ser usado.
12. Consciência de segurança
O objetivo do programa da consciência da segurança é acrescentar um nível de consciência dentro da organização no ponto onde a segurança se torna a segunda natureza e o processo se torna uma rotina que todos os empregados podem seguir facilmente.
O desenvolvimento do programa da consciência da segurança começa com uma revisão das estratégias de segurança, objetivos e políticas. A equipe de revisão deve determinar a avaria dos requisitos de acordo com a política de segurança de TI incorporada, tendo como instrumentos de acompanhamento o programa e monitoramento dos programas de consciência de segurança.
13. Treinamento da segurança
O treinamento específico de segurança é requerido para pessoas com tarefas e responsabilidades relatadas para segurança de TI. O grau de profundidade do treinamento da segurança deve ser determinado conforme a importância total de segurança de TI para a organização, e deve variar de acordo com os requisitos de segurança dos papéis executados. Um programa de treinamento de TI deve ser desenvolvido para cobrir toda necessidade da segurança relevante para a organização.
14. Aprovação dos sistemas de TI
Organizações devem assegurar que a aprovação ocorre para todos ou sistemas de TI selecionados que se encontram com os requisitos de política de segurança de sistemas de TI e plano de segurança de TI. Esse processo de aprovação deve ser baseado em técnicas como verificação de segurança, teste de segurança, e/ou avaliação de sistema. Essa aprovação deve ser válida para um ambiente operacional definido, e para o período de tempo indicado no plano ou política de segurança do sistema de TI. Qualquer mudança significante para segurança de proteções implementada, ou mudanças de procedimentos relevantes de segurança operacional, podem requerer uma nova aprovação. Critérios para estimular uma nova aprovação devem ser incluídos na política de segurança do sistema de TI.
15. Verificação da conformidade da segurança
A verificação da conformidade da segurança é a revisão e analise da implementação das proteções. É usado para verificar se os sistemas de TI ou serviços para os requisitos de segurança, documentados na política de segurança de sistema de TI e plano de segurança de TI.
16. Mudança de gerência
O ambiente de TI está em constantes mudanças, tais mudanças são conseqüências de novos produtos, atualizações de softwares, novos usuários, interconexões adicionais na rede, etc.
Quando uma mudança no sistema de TI ocorre, é importante determinar quais os impactos que ela irá gerar no ambiente, algumas mudanças são mais significativas que outras, porém todas devem ser analisadas com os riscos e custos medidos. As mudanças menores podem ser feitas informalmente, porém os resultados e as decisões de gerenciamento devem ser documentadas.
17. Monitoramento
Verifica se o sistema, seus usuários e o ambiente em si mantêm o nível de segurança dentro do plano de segurança de TI. Um plano de procedimentos para o dia a dia deve ser elaborado e usado como um guia para as operações e deve ser mantido atualizado. Monitoramento é importante para detectar mudanças de segurança relevantes. Recursos devem ser monitorados para detectar mudanças em seus valores. Razões para essas mudanças são: objetos do negócio e da organização, as aplicações rodando no sistema de TI, as informações processadas no sistema de TI e os equipamentos de TI.
18. Manipulação de incidentes
É muito importante criar um Esquema de Análise de Incidentes (IAS) para identificar riscos e medir sua severidade. Para ser bem sucedido, um IAS deve ser construído com os requisitos dos usuários.
Os resultados obtidos com o desenvolvimento de um IAS são: propiciar analise de riscos e revisões de gerenciamento de riscos, prevenção de incidentes, levantamento do nível de conscientização sobre segurança de TI e proporciona informações de alerta, bem como equipes responsáveis por emergências.
Os aspectos chave de um IAS são: estabelecimento de planos pré determinados para manipulação de incidentes quando eles ocorrem e treinamento de pessoal para investigação de incidentes, bem como equipes de resposta a emergências.
Anexos
19. Anexo B - Validade dos recursos
A validade dos recursos em uma organização é um passo essencial em todas as análises de risco. Para executar a validade dos recursos em uma organização, primeiro devem-se identificar os recursos. O dono do recurso que deve ser responsável por determinar o seu valor.
O próximo passo é fazer uma escala de importância e atribuir níveis de acordo com a importância de cada recurso. Essa escala pode ser quantitativa ou qualitativa, a decisão de qual escala utilizar é um problema em muitas organizações.
O critério básico para atribuição de valores para cada recurso deve ser escrito em termos não ambíguos. Possíveis critérios para determinar o valor do recurso podem ser, seu custo de compra, custo de substituição, ou custo de recriação, ou pode ser um valor abstrato como, por exemplo a reputação da companhia.
Outra base para validação dos recursos é o custo devido a perda de confidencialidade, integridade ou disponibilidade como resultado de um incidente.
Muitos recursos podem ter vários valores atribuídos durante a validação. Esses recursos podem ser pelo trabalho gasto para desenvolvê-los bem como o valor que tem se cair nas mãos de um concorrente como por exemplo, um plano de negócios de uma organização. O processo de validação deve levar em consideração todos esses aspectos.
Finalmente, todas as validações de recursos devem ser reduzidas para bases comuns. Seguindo alguns critérios que deve levar em consideração danos resultantes da perda de confidencialidade, integridade ou indisponibilidade como: violação de legislação ou regulamentações, redução da performance dos negócios, ruptura de informações pessoais, riscos de segurança pessoal, ruptura de confidencialidade comercial, ruptura de ordem publica, perdas financeiras, rompimento das atividades de negócio e riscos na segurança do ambiente. Estes são alguns exemplos de critérios que devem ser considerados na validação dos recursos, cada organização, deve adequar seus critérios com a sua realidade.
Depois de estabelecer os critérios, a organização deve colocá-los em uma escala. O primeiro passo é decidir o número de níveis a ser usado. Não existe uma regra para o número de níveis, cada organização deve escolher de acordo com suas características. Normalmente o número de níveis fica entre 3 (ex. baixo, médio e alto) e 10.
Os níveis de valores podem ser atribuídos de acordo com critérios selecionados por exemplo, possível perda financeira, pode ser medida em valores, mas considerando a segurança pessoal, um medida financeira não será apropriada. Os níveis variam de acordo com a realidade de cada organização, pois um valor que pode ser insignificante para uma grande organização pode ser desastroso para uma pequena organização.
20. Anexo D - Exemplos de vulnerabilidades
A seguir estão listadas as principais vulnerabilidades em várias áreas de segurança:
20.1. Ambiente e Infra-estrutura
Falta de segurança no prédio, portas e janelas; falta de controle de acesso; energia instável.
20.2. Hardware
Susceptibilidade a poeira, umidade, sujeira; susceptibilidade a variações de temperatura; manutenção insuficiente; sensibilidade à radiação eletromagnética.
20.3. Software
Especificação incorreta e/ou confusa para os desenvolvedores; testes insuficientes; interface complicada; senhas de acesso não protegidas; download e uso sem controle; falta de documentação; falta de backup.
20.4. Comunicações
Linhas desprotegidas; falta de identificação e autenticação do receptor e transmissor; falta de comprovação de que uma mensagem foi enviada; transmissão de senhas de acesso de forma clara.
20.5. Documentos
Estocagem desprotegida; processo de cópia sem controle.
20.6. Funcionários
Trabalho de terceiros ou limpeza sem supervisão; insuficiente treinamento de segurança; uso incorreto de hardwares e softwares; falta de mecanismos de monitoramento; falta de uma política de uso de ferramentas de comunicação; procedimentos de seleção incorretos.
21. Anexo E - Método de análise de tipo de riscos
A análise de riscos tem os seguintes estágios:
Identificação dos bens e seus valores;
Avaliação das ameaças;
Avaliação das vulnerabilidades;
Avaliação das medidas de segurança existentes ou planejadas;
Avaliação dos riscos.
A avaliação dos riscos, é uma combinação dos impactos causados por incidentes e o nível das ameaças e vulnerabilidades levantadas. Os riscos são em função dos:
valores dos bens;
as ameaças;
a facilidade de exploração das vulnerabilidades pelas ameaças;
as medidas de segurança, que podem reduzir as vulnerabilidades.
O objetivo da análise de risco é identificar os riscos aos quais os sistemas estão expostos, a fim de selecionar as mais apropriadas medidas de segurança. Para avaliar os riscos diversos aspectos devem ser considerados, incluindo o impacto e a freqüência com que eles ocorrem.
O impacto pode ser avaliado de modo quantitativo ou qualitativo, ou até mesmo de uma combinação de ambos. Para avaliar a freqüência com que o risco ocorre, deve ser estabelecido um período de tempo durante o qual os bens necessitam estar protegidos. A probabilidade de uma ameaça ocorrer é afetada pelos seguintes itens:
A atratividade do bem;
A facilidade de conversão do bem em recompensa;
As capacidades técnicas do agente ameaçador;
A freqüência da ameaça;
A susceptibilidade da vulnerabilidade às ameaças.
Muitos métodos fazem uso de tabelas e combinam medidas subjetivas e empíricas. Atualmente não existe um método correto ou errado, as empresas devem utilizar o método que seja mais cômodo e que garantem mais resultados perante às suas necessidades. Um exemplo de técnicas com tabelas está apresentado na tabela1.
Nos métodos de análise de risco deste tipo, os bens são avaliados em valores reais ou estimados em termos de custos de substituição e/ou reconstrução. Estes custos são então convertidos para uma escala qualitativa. Softwares são avaliados da mesma maneira que bens físicos, tendo inclusive seus valores intrínsecos avaliados, como confidencialidade ou integridade do código-fonte.
As avaliações dos dados são obtidas entrevistando-se o pessoal que pode falar com autoridade sobre os dados em questão, determinando-se assim os valores e a sensibilidade dos dados. A avaliação é feita levando-se em consideração algumas regras como, por exemplo: segurança das pessoas, informação das pessoas, obrigações legais, leis, interesses comerciais e econômicos, política de negócios e operações, entre outros.
Estas regras facilitam a identificação dos valores em uma escala numérica (de 1 a 4), como mostrado na figura. O próximo passo é então a avaliação das ameaças e das vulnerabilidades, em ALTA, MÉDIA, BAIXA, que é geralmente feita através de questionários feitos aos funcionários técnicos, pessoal, inspeções nos locais e revisões de documentação. Feito isso, pode-se medir o risco aplicando a tabela mostrada acima.
Para cada bem, as vulnerabilidades relevantes e suas correspondentes ameaças são consideradas. Se existe uma vulnerabilidade sem ameaça, ou ameaça sem vulnerabilidade, então não há risco algum.
O tamanho da tabela, em termos de números de severidade de ameaças, vulnerabilidades ou valor dos bens, pode ser ajustado para atender às necessidades da empresa.
Creditos: http://www.vivaolinux.com.br/artigo/Resumo-da-Norma-ISO-IEC-133353?pagina=1
Nenhum comentário:
Postar um comentário