Guia de documentação interna sobre segurança da informação. O que, como e porque

Em um de nossos artigos anteriores, abordamos a questão de formar um conjunto de documentos para examinadores sobre a proteção de dados pessoais. Nós fornecemos um link para nossos modelos de documentos , mas focamos no tópico da documentação de segurança da informação muito superficialmente.

Neste artigo, gostaria de divulgar este tópico com mais detalhes, tanto no contexto de dados pessoais em particular quanto na proteção de informações em geral. Quais documentos devem estar com o operador, que são opcionais. De onde vem a demanda por esse ou aquele documento. O que escrever em documentos e o que não vale a pena. Sob o corte muitas letras sobre este assunto.

Algumas palavras em defesa da segurança "papel"

Como o artigo se concentrará na chamada segurança "papel", gostaria de descrever imediatamente nossa posição nesta parte da segurança da informação.

Para muitos técnicos que trabalham com "mãos", essa segurança "papel" geralmente causa rejeição e negligência acentuadas. No entanto, por incrível que pareça, quando esse técnico coloca à sua disposição uma nova peça de hardware ou software (e às vezes ambos em um único produto), ele quer primeiro se familiarizar com a documentação desse milagre da tecnologia.

A justificativa mais comum para essa posição de desdém é que todos esses documentos são feitos apenas para exibição, a fim de cumprir os requisitos da lei, isso é uma perda de tempo, os documentos devem ser suportados, mas ninguém fará isso, etc., etc.

Infelizmente, esta posição não é infundada. Ao longo dos anos, tanto entre os guardas de segurança locais quanto entre licenciados, integradores e outras partes interessadas, a triste prática da mesma atitude em relação aos documentos de segurança da informação se desenvolveu. Como resultado, um círculo vicioso foi traçado - os documentos são inúteis porque são negligenciados e, por sua vez, são negligenciados porque são inúteis.

Isso é parcialmente agravado pelo fato de que frequentemente os documentos de segurança da informação são escritos por pessoas que estão longe da tecnologia da informação. Afinal, como posso escrever uma seção sobre a proteção de ferramentas de virtualização sem entender como essa virtualização funciona?

Para reverter essa situação, é necessário criar documentos bons, informativos e úteis. Ao mesmo tempo, esses documentos devem cumprir a legislação aplicável de proteção de informações. Vamos ver o que pode ser feito com tudo isso.

Alguns esclarecimentos

Para começar, a fim de eliminar perguntas e conjecturas desnecessárias, consideramos necessário esclarecer alguns pontos.

1. No artigo, consideraremos apenas documentos organizacionais e administrativos internos (doravante referidos como "ARD") para proteção de informações. Design, certificação e outros documentos não serão considerados.
2. Também não consideraremos o modelo de ameaça, embora seu modelo esteja aqui . O desenvolvimento de um modelo de ameaça é outra história. Escreva nos comentários - você precisa de um manual sobre o desenvolvimento de um modelo de ameaça no Habré?
3. O artigo contará com nosso conjunto de modelos. Não é algum tipo de padrão ou conjunto geralmente aceito. Esse conjunto reflete nossa abordagem puramente para o desenvolvimento da ARD. Como a legislação geralmente não prescreve nada específico a esse respeito, você pode ter sua própria opinião sobre a integridade e o conteúdo dos documentos, e isso é normal!
4. Pode haver erros e erros de digitação nos modelos. Nós mesmos constantemente os aprimoramos e refinamos.
5. No contexto do cumprimento dos requisitos, os sujeitos de dados pessoais (152- e estatutos) e sistemas de informação do estado (ordem 17 do FSTEC) serão afetados principalmente. Além disso, há outra história com organizações financeiras (requisitos do Banco Central da Federação Russa) e vários padrões (ISO 2700x e outros) - não os consideraremos aqui.

Conclusão dos documentos

Se você confia na legislação para proteger as informações, há pouco a dizer onde exatamente quais documentos devemos desenvolver, portanto, temos que confiar em várias dicas indiretas.

Por exemplo, fornecemos a parte 2 do artigo 19 da lei nº 152-FZ "Sobre dados pessoais". O texto simples será o texto da lei, em itálico - as notas do autor.

2. A segurança dos dados pessoais é alcançada, em especial:

1) a determinação de ameaças à segurança de dados pessoais durante o processamento em sistemas de informação de dados pessoais; (precisa de um modelo de ameaça)

2) a aplicação de medidas organizacionais e técnicas para garantir a segurança dos dados pessoais durante o processamento nos sistemas de informações de dados pessoais necessários para atender aos requisitos de proteção de dados pessoais, cuja implementação garante os níveis de segurança de dados pessoais estabelecidos pelo governo da Federação Russa; (as medidas organizacionais são, em grande parte, nossos documentos, além disso, elas nos enviam para ler mais estatutos)

3) usando os procedimentos para avaliar a conformidade das instalações de proteção de informações aprovadas da maneira prescrita;

4) avaliação da eficácia das medidas adotadas para garantir a segurança dos dados pessoais antes do comissionamento do sistema de informações de dados pessoais;

5) levar em consideração os portadores de máquinas de dados pessoais; (obviamente, você precisa de algum tipo de diário contábil e desenvolveu regras para contabilizar a mídia da máquina)

6) a descoberta de acesso não autorizado a dados pessoais e a adoção de medidas; (é necessário desenvolver algumas regras para detectar incidentes e eliminar suas consequências, pode ser necessário nomear uma equipe de resposta a incidentes)

7) restauração de dados pessoais modificados ou destruídos devido ao acesso não autorizado a eles; (são necessárias regras de backup e restauração)

8) o estabelecimento de regras para o acesso aos dados pessoais processados ​​no sistema de informações de dados pessoais, bem como o registro e registro de todas as ações realizadas com dados pessoais no sistema de informações de dados pessoais; (o desenvolvimento de um sistema de acesso a dados pode ser feito com base em funções no sistema, apenas o próprio software deve ser capaz de manter registros de quem costumava acessar quais dados)

9) controle sobre as medidas tomadas para garantir a segurança dos dados pessoais e o nível de segurança dos sistemas de informação de dados pessoais. (precisamos de um determinado plano para monitoramento periódico, além de, provavelmente, um diário no qual os resultados desse monitoramento serão registrados)

Com este exemplo, queríamos mostrar a diferença: como a lei é escrita e o que de fato exige de nós. Aqui não vemos o requisito direto "o operador deve desenvolver um modelo de ameaça", mas essa necessidade ainda segue o texto do 152-FZ, pois o cumprimento de qualquer requisito está documentado.

Mais especificamente, o FSTEC nos fala sobre a integridade e o conteúdo da ARD. Em 2014, esse regulador emitiu um documento metodológico, Medidas de Segurança da Informação nos Sistemas de Informação do Estado. Um documento sem sarcasmo é excelente, se você não entendeu algo na ordem de implementação das medidas das 17ª, 21ª ou outras ordens do FSTEC (sim, embora o documento seja destinado ao GIS, mas as medidas geralmente coincidem com o FSTEC), consulte este o documento pode ficar muito mais claro.

Portanto, neste documento, o FSTEC descreve mais extensivamente medidas para garantir a segurança das informações e, muitas vezes, você pode encontrar esse texto:

As regras e procedimentos para identificação e autenticação de usuários são regulamentados nos documentos organizacionais e administrativos para proteção de informações. (IAF.1)

As regras e procedimentos para gerenciar contas de usuário são regulamentados nos documentos organizacionais e administrativos do operador para proteger as informações. (UPD.1)

As regras e procedimentos para gerenciar fluxos de informações são regulamentados nos documentos organizacionais e administrativos do operador para a proteção das informações. (UPD.3)

Bem, algo já, mas essas regras e procedimentos são uma carruagem inteira.

Como resultado, tive que me amordaçar com um prato que escrevia todos os requisitos de todos os documentos e fazia anotações e anotações sobre cumprimento, não cumprimento.



A idéia principal desta seção é que há uma montanha de requisitos na legislação sobre proteção de informações; a implementação de muitos deles precisa ser documentada. A criação de um documento separado para cada requisito ou a mesclagem de tudo em uma grande "Política de SI" depende de todos. Todas as coisas adicionais que precisamos registrar nos documentos, não de acordo com os requisitos, mas com base na necessidade prática, são adicionadas sem problemas.

A propósito, observe que na tabela e nos próprios documentos algumas seções ou parágrafos são rotulados como “K1” ou “K2 +”. Isso significa que uma seção ou parágrafo é necessária apenas para sistemas de informação da classe 2 e acima ou para a primeira (classe máxima). Tudo o que não está marcado é executado em todos os sistemas de informações estaduais e ISPD.

Também é óbvio que, por exemplo, algumas seções ou mesmo documentos inteiros podem ser eliminados se as características estruturais e funcionais do sistema de informações ou outras condições iniciais exigirem. Por exemplo, removemos o fornecimento de vigilância por vídeo, se não estiver. Ou removemos todas as seções relacionadas à proteção das ferramentas de virtualização, se não forem aplicadas.

Nossos modelos estão divididos em 4 pastas:

Geral - documentos que precisam ser desenvolvidos para todos os sistemas (conforme aplicável), seja ISPDn, GIS, sistema de controle de processo automatizado ou objeto KII.

Somente GIS - documentos para sistemas de informação estaduais ou municipais, existem apenas documentos únicos necessários para GIS e MIS.

PD - documentos sobre proteção de dados pessoais e nos termos da legislação sobre proteção de dados pessoais. Se, por exemplo, tivermos um GIS no qual os dados pessoais são processados, devemos criar documentos de todas as pastas.

CIPF - documentos relacionados ao uso de ferramentas criptográficas, são necessários para a implementação de documentos regulamentares do FSB, são desenvolvidos para todos os sistemas que utilizam meios criptográficos certificados de proteção de informações.

Vamos considerar com mais detalhes os documentos, de onde eles vieram e quais requisitos eles cumprem.

Geral

01 Ordem de nomeação de pessoas responsáveis ​​e instruções para essas pessoas

Este pedido indica: a pessoa responsável pela organização do processamento de dados pessoais e o administrador de segurança.

A necessidade de nomear o primeiro é estipulada no artigo 18.1 da lei federal:

1. O operador deve tomar medidas ... Essas medidas podem incluir, mas não estão limitadas a:

1) a nomeação pelo operador, que é uma pessoa jurídica, da pessoa responsável pela organização do tratamento de dados pessoais;

Administrador de segurança - a necessidade desse amigo se deve, por exemplo, à cláusula 9 da ordem no 17 do FSTEC:

Para garantir a proteção das informações contidas no sistema de informações, o operador nomeia a unidade estrutural ou funcionário (funcionário) responsável pela proteção das informações.

Essas pessoas diferem em que o "responsável" está mais na parte do papel e o "administrador" na parte técnica.

Para que o responsável e o administrador entendam suas tarefas e autoridades, eles têm direito a instruções.

02 Pedido para a designação de uma equipe de resposta a incidentes de segurança da informação (GRIIB) e instruções de resposta

A abreviação do SRIMS, embora um pouco ridícula, mas bastante oficial, foi introduzida pela GOST R ISO / IEC TO 18044-2007 “Tecnologia da Informação. Métodos e ferramentas de segurança. Gerenciamento de incidentes de segurança da informação. ”

A necessidade de documentos é exigida por vários documentos regulatórios. Por exemplo, o mesmo artigo 19 da Lei de Dados Pessoais. Mais detalhadamente, porém, a resposta a incidentes é divulgada nas ordens do FSTEC.

Pedido nº 17 da FSTEC:

18.2 Durante a identificação e resposta a incidentes:

• identificação de pessoas responsáveis ​​por identificar incidentes e responder a eles;
• detecção e identificação de incidentes, incluindo negação de serviço, falhas (reinicializações) na operação de hardware, software e ferramentas de proteção de informações, violações das regras de controle de acesso, ações ilegais para coletar informações, introdução de programas maliciosos de computador (vírus) e outros eventos, levando a incidentes;
• informar oportunamente as pessoas responsáveis ​​por identificar incidentes e responder a eles sobre a ocorrência de incidentes no sistema de informações por usuários e administradores;
• análise de incidentes, incluindo a determinação das fontes e causas dos incidentes, bem como a avaliação de suas conseqüências;
• planejar e tomar medidas para eliminar incidentes, incluindo a restauração do sistema de informações e seus segmentos em caso de negação de serviço ou após falhas, eliminando as conseqüências da violação das regras de controle de acesso, ações ilegais para coletar informações, introdução de programas maliciosos de computador (vírus) e outros eventos levando a incidentes;
• Planejar e tomar medidas para evitar a recorrência de incidentes.

Os mesmos documentos encerram várias medidas organizacionais, por exemplo, RSB.1 “Determinação de eventos de segurança a serem registrados e seus períodos de armazenamento” e SSB.2 “Determinação da composição e conteúdo das informações sobre eventos de segurança a serem registrados”. Tudo isso pode ser indicado nas instruções de resposta a incidentes para não produzir documentos separados.

03 Manual do Usuário

A principal justificativa legal para a necessidade de uma instrução desse tipo são todos os locais da legislação em que diz respeito à instrução dos usuários sobre questões de segurança da informação. Por exemplo, a Parte 1 do Artigo 18.1 da Lei de Dados Pessoais:

6) familiarização dos funcionários do operador que processam diretamente dados pessoais com as disposições da legislação da Federação Russa sobre dados pessoais, incluindo requisitos para a proteção de dados pessoais, documentos que definem a política do operador em relação ao processamento de dados pessoais, atos locais no processamento de dados pessoais e (ou) treinamento desses funcionários.

Uma necessidade indireta desse documento é o registro legal da responsabilidade do usuário por possíveis incidentes de segurança da informação. Como mostra a prática , nos casos em que essas instruções não existem e (ou) o usuário não está familiarizado com ela, um usuário que viola os requisitos de SI provavelmente não será responsabilizado.

Quanto ao documento em si, aqui decidimos não carregar usuários com bobagens desnecessárias, para tornar o documento não muito difícil de perceber e útil, não apenas em relação à segurança da informação na empresa, mas também em questões de segurança da vida pessoal. Por exemplo, eles descreveram métodos de engenharia social com exemplos.

05 Política de Segurança da Informação

Provavelmente um dos documentos mais volumosos de todo o conjunto. Lembre-se acima, escrevemos sobre o documento “Medidas para proteger informações no SIG” e sobre o grande número de “regras e procedimentos” que precisam ser escritos na ARD? Na verdade, a “Política de IB” é, de fato, uma coleção de todas essas regras e procedimentos.

Aqui, talvez, valha a pena parar na palavra "Política". Muitas vezes nos dizem que nossa “política” é muito direcionada, mas na verdade um documento com esse nome deve ser mais abstrato e de alto nível. Pode ser assim, mas aqui como pessoal de segurança, em primeiro lugar, com o conhecimento técnico, a palavra "Política" está associada, por exemplo, às políticas de grupo do domínio, que por sua vez estão associadas a regras e configurações específicas.

De fato, como esse documento será chamado não é importante. Se você não gostar da palavra "Política", poderá renomeá-la para "Regras e procedimentos para segurança da informação". Este não é o ponto. O principal é que essas mesmas regras e procedimentos já devem ser definidos de forma clara e específica neste documento.

Vamos parar aqui com mais detalhes.

Se você abrir um documento e começar a trabalhar com ele, notará que em alguns lugares não há espaços em branco específicos no texto, mas há um "Descrever" seco. Isso ocorre porque algumas coisas não podem ser descritas para que o texto seja adequado para pelo menos metade dos sistemas de informação específicos ao mesmo tempo. Para cada caso, é melhor descrever essas seções separadamente. É por isso que ainda somos céticos em relação a vários preenchimentos automáticos de documentos.

No texto principal, tudo deve ficar claro como um todo. Gostaria de me concentrar um pouco nas aplicações.

Solicitação de alterações nas listas de usuários

Parece para muitos que esse procedimento para rastrear usuários e suas credenciais em um sistema altamente burocrático; no entanto, frequentemente encontramos situações em que essa abordagem ajudou a avançar na investigação de incidentes de segurança da informação. Por exemplo, era necessário estabelecer quais poderes foram concedidos ao usuário inicialmente. Quando os aplicativos do aplicativo para a política de SI foram levantados, verificou-se que uma conta tinha um aumento não autorizado de autoridade.

De qualquer forma, cabe a cada operador decidir se executa ou não esse procedimento de registro do usuário. Aqui, provavelmente vale a pena mencionar imediatamente que o que é feito explicitamente exatamente como descrito em nosso modelo de política de SI não é exigido por nenhum ato legislativo. O modelo de documento é provavelmente a opção mais grave e deprimente. E então todo mundo decide por si mesmo - onde afrouxar as porcas e onde apertar ainda mais.

Regulamento relativo à delimitação dos direitos de acesso e à lista de pessoas

A diferenciação dos direitos de acesso do usuário é uma medida óbvia para qualquer administrador de sistema. : .2 « (, , ), (, , ) », .4 « () , , » .

, .

. , , . . – , « » , « » , « » .



.3 « (, , , ) , , ».

, , , « ». , « » - . , .



.3 « () () ». , , .

, - . - - .

. , , .



. « 2 : , , ». , , , « , » .

10 .

( ), . , 2 19 « »:

, :

7) , ;

:

.4

. , , , .

, :

.3 , ,

06

: .2 « , , , , ».

, , , . ., . , , . , , «», , .

07 ...

2 – . 2 , .

: « , , , , ?». , – . , , , - . .

– , . , 1 18.1 « »:

1. … , , :

4) () , , , ;

08-14 ...

08-10 . :

• , , . .;
• (, , , . .);
• (, HDD, ).

. . , . , - . , , , 09 10 .

, . . .

, . . , , . .

01

, . , 17- « , ». , , , « ».

, .

02-03

. , , .

, , .

– , , .

04

17- , ( ) .

01

, , . , , . , . , - .

02

3 « » . , , , . . , .

, , , ( , ). .

03

, . , . , , , (, ). , .

04

! : « ?».

2 18.1 « »:

, , . , - , - , , , - .

, , . , , , .

05-06

, . : , , . , .

07

- , , , .

. . — , – . , , , , .

, . :

1. , ( — ), (), , , , , , .

2. , .

, . « » :

4) — ;

. , – , ( – ).

08

, , , , . , , . . .

09

. . , , . .

10

, . , 4 9 « ».

11

, , . - . , . , — , , .

12

, ( , ).

13

. – . , .

, . , , . ( 2001 ), - , , . , .

Conclusão

, . , , , . - , . , , , , « ».