ISO / IEC 27001: 2013 – Tecnologia da informação – Técnicas de segurança – Sistemas de gestão de segurança da informação – Requisitos (segunda edição)

< Padrão anterior ^ Subir um nível ^ Próximo padrão >

Introdução

ISO / IEC 27001 especifica formalmente um Sistema de Gestão de Segurança da Informação, um acordo de governança que compreende um conjunto estruturado de atividades para gerenciar os riscos da informação (chamados de riscos de segurança da informação no padrão) .

O SGSI é uma estrutura abrangente por meio da qual a gestão identifica, avalia e trata (aborda) os riscos de informação da organização. O ISMS garante que os arranjos de segurança sejam ajustados para acompanhar as mudanças nas ameaças à segurança, vulnerabilidades e impactos nos negócios – um aspecto importante em um campo tão dinâmico e uma vantagem fundamental da abordagem flexível orientada a riscos do ISO27k em comparação com, digamos, PCI-DSS.

O padrão cobre todos os tipos de organizações (por exemplo, empresas comerciais, agências governamentais, sem fins lucrativos) de todos os tamanhos (de microempresas a grandes multinacionais) em todos os setores (por exemplo, varejo, banco, defesa, saúde , educação e governo). Este é claramente um resumo muito amplo.

A ISO / IEC 27001 não exige formalmente controles de segurança da informação específicos, uma vez que os controles exigidos variam acentuadamente em uma ampla gama de organizações que adotam o padrão. Os controles de segurança da informação da ISO / IEC 27002 estão resumidos no anexo A da ISO / IEC 27001, como um menu. As organizações que adotam a ISO / IEC 27001 são livres para escolher quaisquer controles específicos de segurança da informação que sejam aplicáveis aos seus riscos de informações particulares, baseando-se naqueles listados no menu e potencialmente complementando-os com outras opções à la carte (às vezes conhecidas como conjuntos de controle estendidos). Tal como acontece com a ISO / IEC 27002, a chave para selecionar os controles aplicáveis é realizar uma avaliação abrangente dos riscos de informação da organização, que é uma parte vital do SGSI.

Além disso, a gerência pode optar por evitar, compartilhar ou aceitar os riscos de informação em vez de mitigá-los por meio de controles – uma decisão de tratamento de risco dentro do processo de gerenciamento de risco.

História

ISO / IEC 27001 é derivado do BS 7799 Parte 2, publicado pela primeira vez como tal pelo British Standards Institute em 1999.

BS 7799 Parte 2 foi revisado em 2002, incorporando explicitamente o estilo Deming Ciclo Plan-Do-Check-Act.

BS 7799 parte 2 foi adotada como a primeira edição da ISO / IEC 27001 em 2005 com várias alterações para refletir seus novos custodiantes .

A segunda edição da ISO / IEC 27001 foi publicada em 2013, tendo sido amplamente revisada para se alinhar com os outros padrões de sistemas de gestão ISO. PDCA não é mais explícito, mas o conceito de refinamento contínuo e melhoria sistemática permanece, com certeza.

Estrutura do padrão

ISO / IEC 27001: 2013 tem as seguintes seções:

0 Introdução – o padrão descreve um processo para gerenciar sistematicamente riscos de informação.

1 Escopo – especifica requisitos genéricos de SGSI adequados para organizações de qualquer tipo, tamanho ou natureza.

2 Referências normativas – apenas a ISO / IEC 27000 é considerada absolutamente essencial para usuários de 27001: os padrões ISO27k restantes são opcionais.

3 Termos e definições – ver ISO / IEC 27000.

4 Contexto da organização – compreensão do contexto organizacional, das necessidades e expectativas das partes interessadas e definição do escopo do SGSI. A Seção 4.4 afirma claramente que “A organização deve estabelecer, implementar, manter e melhorar continuamente” o SGSI.

5 Liderança – a alta administração deve demonstrar liderança e compromisso com o SGSI, ordenar a política e atribuir a segurança da informação funções, responsabilidades e autoridades.

6 Planejamento – descreve o processo para identificar, analisar e planejar o tratamento dos riscos da informação e esclarecer os objetivos da segurança da informação.

7 Suporte – adequado, recursos competentes devem ser atribuídos, conscientização, documentação preparada e controlada.

8 Operação – um pouco mais de detalhes sobre como avaliar e tratar os riscos da informação, gerenciar mudanças e documentar coisas (em parte para que possam ser auditadas por os auditores de certificação).

9 Avaliação de desempenho – monitorar, medir, analisar e avaliar / auditar / revisar os controles, processos e sistema de gestão de segurança da informação, melhorando sistematicamente as coisas quando necessário.

10 Improv emento – abordar as conclusões de auditorias e análises (por exemplo não conformidades e ações corretivas), faça refinamentos contínuos no SGSI.

Anexo A Objetivos e controles de controle de referência – pouco mais na verdade do que uma lista de títulos das seções de controle na ISO / IEC 27002. O anexo é normativo, implicando que organizações certificadas devem usá-lo , mas o órgão principal diz que eles são livres para desviá-lo ou complementá-lo para lidar com seus riscos de informação específicos. O Anexo A sozinho é difícil de interpretar. Consulte a ISO / IEC 27002 para obter mais detalhes úteis sobre os controles, incluindo orientações de implementação.

Bibliografia – indica aos leitores cinco padrões relacionados, além da parte 1 das diretivas ISO / IEC, para obter mais informações. Além disso, a ISO / IEC 27000 é identificada no corpo da norma como uma norma normativa (ou seja, essencial) e há várias referências à ISO 31000 sobre gerenciamento de risco.

Requisitos obrigatórios para certificação

ISO / IEC 27001 é uma especificação formalizada para um ISMS com dois propósitos distintos:

1. Ela apresenta o projeto para um ISMS, descrevendo as partes importantes em um nível bastante alto nível;
2. Ele pode (opcionalmente) ser usado como base para a avaliação de conformidade formal por auditores de certificação credenciados para certificar uma organização em conformidade.

A seguinte documentação obrigatória é explicitamente necessário para a certificação:

1. escopo do SGSI (conforme a cláusula 4.3)
2. Política de segurança da informação (cláusula 5.2)
3. Processo de avaliação de risco da informação ( cláusula 6.1.2)
4. Processo de tratamento de risco da informação (cláusula 6.1.3)
5. Objetivos de segurança da informação (cláusula 6.2)
6. Evidência da competência do pessoas que trabalham na segurança da informação (cláusula 7.2)
7. Outros documentos relacionados ao SGSI considerados necessários pela organização (cláusula 7.5.1b)
8. Planejamento operacional e documentos de controle (cláusula 8.1)
9. Os resultados das avaliações de risco (cláusula 8.2)
10. As decisões sobre o tratamento de risco (cláusula 8.3)
11. Evidências do monitoramento e medição da segurança da informação (cláusula 9.1 )
12. O programa de auditoria interna do SGSI e os resultados das auditorias realizadas (cláusula 9.2)
13. Provas de análises críticas da alta direção do SGSI (cláusula 9.3)
14. Provas de não-conformidades identificadas e ações corretivas decorrentes (cláusula 10.1)
15. Vários outros: o Anexo A menciona, mas não especifica completamente a documentação adicional, incluindo as regras para o uso aceitável de ativos, política de controle de acesso, procedimentos operacionais, confidencialidade ou não – acordos de divulgação, princípios de engenharia de sistema seguro, política de segurança da informação para relacionamentos com fornecedores, informar procedimentos de resposta a incidentes de segurança da ação, leis, regulamentos e obrigações contratuais relevantes, além dos procedimentos de conformidade e procedimentos de continuidade de segurança da informação associados. No entanto, apesar do Anexo A ser normativo, as organizações não são formalmente obrigadas a adotar e cumprir o Anexo A: elas podem usar outras estruturas e abordagens para tratar seus riscos de informação.

Os auditores de certificação quase certamente irão verifique se esses quinze tipos de documentação estão (a) presentes e (b) adequados para a finalidade.

O padrão não especifica precisamente qual forma a documentação deve assumir, mas a seção 7.5.2 fala sobre aspectos como títulos, autores, formatos, mídia, revisão e aprovação, enquanto 7.5.3 diz respeito ao controle de documentos , o que implica uma abordagem bastante formal no estilo ISO 9000. A documentação eletrônica (como páginas da intranet) é tão boa quanto os documentos em papel, na verdade melhores no sentido de que são mais fáceis de controlar e atualizar.

Escopo do SGSI e Declaração de Aplicabilidade (SoA)

Considerando que o padrão se destina a conduzir a implementação de um SGSI em toda a empresa, garantindo que todas as partes da organização se beneficiem ao abordar seus riscos de informação de maneira apropriada e gerenciada sistematicamente , as organizações podem definir o escopo de seu SGSI da forma mais ampla ou restrita que desejarem – na verdade, definir o escopo é uma decisão crucial para a alta administração (cláusula 4.3). Um escopo de ISMS documentado é um dos requisitos obrigatórios para certificação.

Embora a Declaração de Aplicabilidade não seja explicitamente definida, é um requisito obrigatório da seção 6.1.3. SoA refere-se à saída das avaliações de risco da informação e, em particular, às decisões sobre o tratamento desses riscos. O SoA pode, por exemplo, assumir a forma de uma matriz identificando vários tipos de riscos de informação em um eixo e opções de tratamento de risco no outro, mostrando como os riscos devem ser tratados no corpo, e talvez quem é responsável por eles. Geralmente faz referência aos controles relevantes da ISO / IEC 27002, mas a organização pode usar uma estrutura completamente diferente, como NIST SP800-53, o padrão ISF, BMIS e / ou COBIT ou uma abordagem personalizada.Os objetivos e controles de segurança da informação da ISO / IEC 27002 são fornecidos como uma lista de verificação no Anexo A para evitar negligenciar os controles necessários: eles não são obrigatórios.

O escopo do ISMS e SoA são cruciais se um terceiro pretende anexar qualquer confiança ao certificado de conformidade ISO / IEC 27001 de uma organização. Se o escopo ISO / IEC 27001 de uma organização incluir apenas “Acme Ltd. Departamento X”, por exemplo, o certificado associado não diz absolutamente nada sobre o estado da segurança da informação em “Acme Ltd. Departamento Y” ou mesmo “Acme Ltd.” como um todo. Da mesma forma, se por algum motivo a administração decidir aceitar riscos de malware sem implementar controles antivírus convencionais, os auditores de certificação podem contestar tal afirmação ousada, mas, desde que as análises e decisões associadas sejam corretas, isso por si só não seria justificativa para recusar-se a certificar a organização, uma vez que os controles antivírus não são obrigatórios.

Métricas

Em vigor (sem realmente usar o termo “métricas”) , a edição de 2013 da norma exige o uso de métricas sobre o desempenho e a eficácia do SGSI e dos controles de segurança da informação da organização. A seção 9, “Avaliação de desempenho”, exige que a organização determine e implemente métricas de segurança adequadas … mas fornece apenas requisitos de alto nível.

Ofertas ISO / IEC 27004 conselhos sobre o que e como medir para satisfazer o requisito e avaliar o desempenho do SGSI – uma abordagem eminentemente sensata, não muito diferente da descrita em Métricas de segurança PRAGMATIC.

Certificação

A conformidade certificada com a ISO / IEC 27001 por um organismo de certificação acreditado e respeitado é totalmente opcional, mas está sendo cada vez mais exigida de fornecedores e parceiros de negócios por organizações que estão (com razão!) preocupadas com a segurança de suas informações e sobre os riscos de informação em toda a cadeia de abastecimento / rede de abastecimento.

A certificação traz uma série de benefícios acima e além da mera conformidade, da mesma forma que um O certificado da série ISO 9000 diz mais que n apenas “Somos uma organização de qualidade”. A avaliação independente necessariamente traz algum rigor e formalidade ao processo de implementação (implicando em melhorias para a segurança da informação e todos os benefícios que traz através da redução de risco) e, invariavelmente, requer a aprovação da alta administração (o que é uma vantagem em termos de consciência de segurança, pelo menos!).

O certificado tem potencial de marketing e valor de marca, demonstrando que a organização leva a sério a gestão da segurança da informação. No entanto, conforme observado acima, o valor de garantia do certificado é altamente dependente do escopo do ISMS e SoA – em outras palavras, não coloque muita fé no certificado de conformidade ISO / IEC 27001 de uma organização se você for altamente dependente de suas informações segurança. Da mesma forma que a conformidade com PCI-DSS certificada não significa “Garantimos a segurança dos dados do cartão de crédito e outras informações pessoais”, a conformidade com a ISO / IEC 27001 certificada é um sinal positivo, mas não uma garantia férrea sobre a segurança das informações de uma organização . Diz “Temos um ISMS compatível em vigor”, não “Estamos seguros”, uma distinção sutil, mas importante.

Status do padrão

ISO / IEC 27001 foi o primeiro publicado em 2005.

O padrão foi completamente reescrito e publicado em 2013. Isso foi muito mais do que apenas ajustar o conteúdo da edição de 2005, uma vez que a ISO insistiu em mudanças substanciais para alinhar este padrão com outros padrões de sistemas de gerenciamento.

A ISO / IEC 27002 foi extensivamente revisada e reeditada ao mesmo tempo, portanto, o Anexo A da ISO / IEC 27001 também foi completamente atualizado: consulte a página ISO / IEC 27002 para mais informações.

Uma corrigenda técnica de 2014 esclareceu que a informação é, afinal, um trunfo. Caramba.

Uma segunda corrigenda técnica endum em 2015 esclareceu que as organizações são formalmente obrigadas a identificar o status de implementação de seus controles de segurança da informação no SoA.

Uma terceira corrigenda técnica proposta superou o tubarão: SC 27 resistiu ao impulso de continuar aprimorando o publicado padrão desnecessariamente com alterações que deveriam ter sido propostas quando estava em rascunho e podem não ter sido aceitas de qualquer maneira. Apesar de não ter sido abordada, a preocupação é válida: a norma de fato confunde risco de informação com riscos relativos ao sistema de gestão. Deveria ter abordado o último, mas em vez disso assumiu o primeiro.

Um Período de Estudo analisou o valor e a finalidade do Anexo A em relação ao SoA, concluindo que o Anexo A é um link útil para a ISO / IEC 27002, mas a redação do corpo principal deve deixar claro que o Anexo A é totalmente opcional: as organizações podem adotar qualquer conjunto de controles (ou mesmo outros tratamentos de risco) que considerem adequado para tratar seus riscos de informação, desde que o processo de seleção, implementação, gerenciamento, monitoramento e manutenção dos tratamentos de risco atenda aos requisitos do corpo principal – em outras palavras, todo o processo se enquadra no SGSI.

A próxima versão da ISO / IEC 27001 incorporará necessariamente mudanças significativas refletindo a próxima atualização da ISO / IEC 27002 (o que significa reescrever o Anexo A, novamente) mais algumas alterações na redação do corpo principal como resultado de revisões contínuas do Anexo SL …

Comentários pessoais

Anexo SL (anteriormente conhecido como “Guia de Rascunho 83”, às vezes “Anexo L” ) o apêndice 2 especifica o texto padrão e a estrutura comum a todas as normas de sistemas de gestão ISO e ISO / IEC cobrindo garantia de qualidade, proteção ambiental etc. A ideia é que os gerentes familiarizados com qualquer um dos sistemas de gestão entendam os princípios básicos que sustentam todos os outros. Conceitos como certificação, política, não conformidade, controle de documentos, auditorias internas e análises críticas de gestão são comuns a todos os padrões de sistemas de gestão e, de fato, os processos podem, em grande medida, ser padronizados dentro da organização.

Na próxima atualização deste ano, o Anexo SL apêndice 2 provavelmente (se aprovado):

• Definir risco como “efeito de incerteza” (descartar “de objetivos” da definição usada na versão atual da ISO / IEC 27000) com 4 notas (eliminando as 2 das 6 notas finais na definição atual). Se essa simplificação ajuda, prejudica ou não tem efeito sobre a ISO27k, resta saber.
• Substitua “resultados” por “resultados” – uma mudança feita principalmente para facilitar a tradução.
• Inclua “Planejamento de mudanças”, ou seja, quaisquer mudanças no sistema de gestão devem ser realizadas em uma forma planejada .
• Substitua “terceirizado” por “fornecido externamente” para abranger terceirização, contratação e compra convencional.
• Especifique separadamente os requisitos gerais para auditorias internas (9.2.1) e para o programa de auditoria interna (9.2.2).
• Especificar separadamente os requisitos gerais para as análises críticas pela gerência (9.3.1) e para suas entradas (9.3.2) e saídas (9.3.3).
• Enfatize novamente a necessidade de melhoria proativa do sistema de gestão, além de respostas reativas às deficiências.
• Obrigue várias outras alterações de redação a todos os padrões de sistemas de gestão ISO, incluindo (presumivelmente) o próximo lançamento da ISO / IEC 27001.

A confusão do SC 27 sobre o significado pretendido de “ativo de informação” permanece: a decisão de abandonar a definição nição de “ativo de informação” da ISO / IEC 27000 em vez de verdadeiramente inferior, esta questão pode ter sido um erro tático. Reverter para o termo “ativo”, definido amplamente como algo de valor, leva a problemas em toda a ISO27k se o termo for substituído por sua definição literal e explícita. Um tijolo é um ativo, enquanto um smartphone com tijolo é um passivo. “Valor” é um conceito nebuloso. É justo perguntar “Tem valor para quem?” também, uma vez que a organização atua como custodiante de algumas informações pertencentes a terceiros, incluindo informações pessoais e proprietárias que requerem proteção adequada. Isso deveria ser coberto pelo SGSI ou não? Esta é uma situação confusa, pouco clara e, em última análise, insatisfatória para um padrão internacional.