Certificação de sistemas de informação sob o princípio de segmentos padrão. Mitos e Realidade

Bom dia, Habr! Hoje, gostaríamos de considerar vários mitos relacionados à certificação de objetos de informatização (OI) para requisitos de segurança da informação sobre o princípio de segmentos padrão. E também vamos descobrir como fazer essa certificação corretamente.

É preciso dizer que há muitos mitos circulando sobre isso e, muitas vezes, eles se contradizem. Por exemplo, existe uma opinião de que, de acordo com o princípio de segmentos padrão, você pode certificar todos os ISPDs em um país (embora a certificação não seja obrigatória para ISPDs), mas, por outro lado, existe uma opinião de que você precisa certificar os sistemas de informação apenas da maneira antiga e todos esses seus "segmentos típicos" astuto.

1. Introdução

A certificação do objeto de informatização é talvez um dos estágios mais regulamentados e conservadores na construção de um sistema de proteção de informações.

O conservadorismo reside no fato de que a certificação está sujeita a um sistema específico com uma lista específica de meios técnicos, que são reescritos ordenadamente no passaporte técnico para o objeto de informatização e no certificado de conformidade. Substituir, por exemplo, um computador queimado de um sistema de informações certificado pode implicar pelo menos uma longa correspondência com a organização que conduziu a certificação e, no mínimo, testes adicionais de certificação (ou seja, custos).

Esse não era um grande problema, enquanto a certificação dos requisitos de segurança da informação era um computador independente que processa as informações protegidas ou pequenas redes locais dedicadas.

Mas o progresso não pára. Agora, para sistemas de informação estaduais, o 17º decreto do FSTEC determina sua certificação obrigatória antes do comissionamento. E os sistemas de informação estaduais hoje não são um computador estático ou um pequeno lokalka, mas grandes sistemas de mudança dinâmica, geralmente de escala regional ou mesmo federal.

Então, o que fazer neste caso? O atestado é necessário, mas é impossível certificar um sistema estático, pois quase todos os dias são adicionados novos elementos e removidos os antigos. "Segmentos típicos" vêm em socorro.

Este conceito foi introduzido pela 17ª ordem do FSTEC e pela norma GOST RO 0043-003-2012 “Proteção de informações. Certificação de objetos de informatização. Disposições Gerais ”em 2013. Infelizmente, GOST está marcado como "aglomerado", diferente da ordem do FSTEC, portanto o padrão não pode ser citado aqui. Mas nada será perdido com isso, uma vez que a ordem do FSTEC na ordem para a extensão do certificado de conformidade a segmentos típicos é descrita com muito mais detalhes (seção 17.3), e alguns parágrafos curtos são dedicados a isso na norma.

Mitos sobre Certificação de Segmento de Tipo

Existem muitos mitos em torno de segmentos típicos. Aqui vamos analisar aqueles que nós mesmos encontramos. Se você tem exemplos de mitos ou perguntas semelhantes (você não tem certeza se é um mito ou não), seja bem-vindo ao comentar.

Mito número 1. Um certificado no princípio de segmentos padrão pode certificar todos os sistemas de informação na Federação Russa

Teoricamente, isso não é diretamente proibido por documentos regulamentares, mas na prática isso não será possível. Uma das cláusulas 17 da ordem FSTEC nos segmentos de modelo afirma que a execução da documentação organizacional e administrativa para proteção de informações deve ser garantida nos segmentos padrão. Portanto, o grande problema é o desenvolvimento dessa documentação, que levará em consideração diferentes processos tecnológicos de processamento de informações, diferentes informações protegidas, diferentes requisitos de reguladores, etc. Como resultado, a documentação desenvolvida para um sistema não será relevante para outro.

Mito número 2. "Segmentos típicos" são fornecidos apenas para sistemas de informações estaduais

Isto não é verdade. Em primeiro lugar, a décima sétima ordem do FSTEC permite que suas disposições sejam aplicadas no desenvolvimento de sistemas de proteção de informações em quaisquer outros sistemas de informação. Em segundo lugar, o GOST RO 0043-003-2012 usa o conceito mais amplo de "objetos de informatização" em vez de "sistemas de informação de estado".

Mito número 3. Se eles nos derem um certificado que pode ser estendido para segmentos padrão, podemos aplicá-lo a qualquer coisa

Não é assim, no spoiler o texto completo do parágrafo 17.3 da ordem FSTEC nº 17 para segmentos típicos, consideraremos os casos em que o certificado emitido não pode ser distribuído. Aqui temos que ficar com mais detalhes.


Além disso, pegaremos exemplos específicos de erros e citaremos apenas as citações apropriadas desse ato normativo como justificativa para que isso não possa ser feito.

Exemplo No. 1

Somente a parte do servidor é certificada, mas quero estender o certificado para estações de trabalho (AWS). Isso pode ser feito?



Não! A certificação do sistema de informação é permitida com base nos resultados dos testes de certificação de um conjunto selecionado de segmentos do sistema de informação que implementam toda a tecnologia de processamento de informações .

A transferência de informações por canais de comunicação também é uma tecnologia de processamento. Além disso, neste exemplo, nenhuma estação de trabalho é certificada; portanto, não podemos estender o certificado para outra estação de trabalho padrão.

Exemplo No. 2

Aqui, levamos em conta o erro anterior e incluímos canais de transmissão de dados e uma estação de trabalho típica no certificado. De repente, tivemos a necessidade de organizar um laptop para um grande chefe com uma conexão a um sistema certificado (através de canais seguros, é claro). Podemos estender o certificado de conformidade com este laptop?

Não! Um segmento é considerado apropriado para o segmento do sistema de informação em relação ao qual foram realizados testes de certificação se as mesmas classes de segurança e ameaças à segurança da informação foram estabelecidas para os segmentos indicados ...

Aqui, por meios técnicos móveis, novas ameaças à segurança das informações aparecem que não são relevantes para estações de trabalho estacionárias e provavelmente não são consideradas no modelo de ameaça para um sistema certificado.

Exemplo No. 3

Bem, levamos em conta esse batente e adicionamos ameaças ao modelo de crescimento, ameaças a dispositivos móveis. Agora posso estender o certificado para o laptop de um grande chefe?



Não! Um segmento é considerado relevante para o segmento do sistema de informação para o qual foram realizados testes de certificação ...

Apesar de a ferramenta móvel ter sido descrita na documentação de design do sistema de proteção de informações e o modelo de ameaças levar em conta as ameaças associadas aos meios técnicos móveis, não foram realizados testes de certificação para essa ferramenta.

Exemplo No. 4

Quão complicado é! Mas esta situação: existe uma instituição médica, existem dois sistemas de informação - com funcionários e um sistema de informação médica (MIS) com pacientes. Podemos salvar, certificar o sistema de informações com os funcionários e estender esse certificado aos IIAs?



Não! Um segmento é considerado apropriado para o segmento do sistema de informação em relação ao qual foram realizados testes de certificação se as mesmas classes de segurança foram estabelecidas para os segmentos indicados ... soluções de design idênticas para o sistema de informação .



Embora pareça que tudo é complicado aqui, na verdade, você só precisa pensar nas opções possíveis para segmentos típicos na preparação da construção de um sistema de proteção. Mas, de fato, se você levar tudo em consideração (e não houver muitos requisitos), não haverá problemas com a distribuição do certificado.

Mito número 4. Segmentos típicos devem ser descritos na documentação de design do sistema de proteção, começando com o modelo de ameaça

Não existe esse requisito. Embora isso não seja diretamente proibido, essa abordagem pode levar a alguns problemas no futuro. O que a 17ª ordem FSTEC nos diz sobre isso:

As características da certificação de um sistema de informação com base nos resultados dos testes de certificação de um conjunto selecionado de seus segmentos, bem como as condições e procedimentos para distribuir um certificado de conformidade a outros segmentos de um sistema de informação, são definidos no programa e nos métodos de testes de certificação, conclusão e certificado de conformidade.

Ou seja, temos o direito de mencionar segmentos típicos apenas na fase de certificação. Nesse caso, seus segmentos serão típicos por padrão, se as condições da seção 17.3 da ordem FSTEC nº 17 forem atendidas. Mas encontramos casos em que segmentos típicos já foram tentados para descrever no estágio de modelagem de ameaças, quase indicando o número de série do equipamento desses segmentos. O problema dessa abordagem é que, se ocorrer uma substituição de hardware ou algo mudar nas tecnologias de processamento (por exemplo, um ambiente de virtualização aparecer), os segmentos nos quais o certificado já está distribuído podem se tornar, digamos, ilegítimos típicos. E, nesse caso, pode ser necessário realizar não "testes adicionais de certificação", mas realizar todo o conjunto de testes de acordo com o novo.

Em geral, nosso conselho é não mencionar segmentos típicos na documentação do projeto. De fato, de acordo com a legislação atual, qualquer segmento que atenda às condições estabelecidas será típico.

IMPORTANTE! Se você é um operador de um sistema de informações e planeja certificar um sistema de informações com a capacidade de estender o certificado para segmentos padrão, não deixe de discutir com seu organismo de certificação para que essa possibilidade seja refletida nos documentos de certificação, conforme exigido pela 17ª ordem do FSTEC!

Mito número 5. O FSTEC não entende "segmentos típicos" e, se formos certificados assim, seremos punidos

Esse mito parece muito estranho, dado que segmentos típicos são descritos em mais detalhes na documentação regulatória do FSTEC. Essa idéia é ouvida com mais frequência pelos guardas de segurança da chamada "velha escola".

Em geral, exceto por "isso não é verdade", não temos nada a dizer aqui. Pelo contrário, o regulador está promovendo esse sistema de certificação de sistemas de informação de todas as maneiras possíveis e, recentemente, chegamos a uma afirmação do FSTEC de que um enorme sistema de informações em nível regional não era certificado pelo princípio de segmentos padrão. Lá eu tive que explicar que, nesse caso específico, não era o ideal.

Mito número 6. Os segmentos típicos funcionam apenas quando a parte e os segmentos certificados são de propriedade de uma organização

Isto não é verdade. Isso não está explicitamente declarado na legislação, mas tudo o que não é proibido é permitido. Mas, é claro, existem certas diferenças quando os segmentos de peça e modelo certificados são de propriedade de uma organização e quando os segmentos de modelo pertencem a entidades legais de terceiros, existem.

Nos casos em que tudo pertence a uma organização, essa organização pode executar de maneira independente medidas para proteger as informações em um segmento padrão, nomear uma comissão e estender o certificado para um segmento padrão.

Nos casos em que existe um operador central do sistema de informação estadual (por exemplo, um Centro regional de Tecnologia da Informação) e segmentos de outras entidades legais (como um sistema regional de gerenciamento de documentos das instituições estatais), tudo fica um pouco mais complicado. A dificuldade reside no fato de que, de acordo com a lei, o operador desses SIG é responsável pela proteção das informações nos sistemas de informações estaduais. Portanto, para que o próximo teste não aqueça o operador pelo fato de que em algum ponto da escola a 400 km do centro regional, não são tomadas medidas de proteção de informações, ele precisa documentar esse processo pelo menos na fase de conexão de um segmento típico. Antes de tudo, são criadas as regras de conexão com o sistema de informações, nas quais o operador descreve clara e claramente os requisitos de proteção de informações que devem ser atendidos no segmento conectado. Isso geralmente inclui a nomeação dos responsáveis, a aprovação de documentos internos para proteção de informações (especialmente operadores confusos podem até desenvolver e fornecer um conjunto padrão), a compra, instalação e configuração das ferramentas necessárias de proteção de informações, análise de vulnerabilidades, etc. Além disso, a organização que deseja se conectar realiza todos os requisitos e da maneira especificada nos regulamentos confirmam isso.

Por outro lado, todas as dificuldades descritas são um plano de ação aproximado que já inventamos em conjunto com um desses operadores. Se o operador de um GIS distribuído não tiver medo de assumir a responsabilidade de não provar o fato de cumprir os requisitos para proteger as informações no segmento remoto, pelo menos no estágio de conexão, ele poderá seguir um caminho simplificado (como "simplificado" esse operador também deve decidir).

Infelizmente, alguns operadores fazem isso porque acreditam sinceramente no mito a seguir.

Mito número 7. A autoridade de certificação é responsável por estender o certificado a segmentos que não atendem aos requisitos.

É muito importante para nós, como organismo de certificação, entender os limites de nossa responsabilidade. Como a lei não responde claramente à pergunta “quem é responsável por estender o certificado a segmentos não conformes”, escrevemos uma carta ao FSTEC.

O FSTEC respondeu que o organismo de certificação é responsável apenas pela qualidade dos próprios testes de certificação. O operador da organização do sistema de informação é responsável pela distribuição correta do certificado para segmentos típicos.

Mito número 8. Segmentos típicos não nos dão nada. De qualquer forma, você precisa atrair um licenciado e pagar-lhe dinheiro

Isto não é verdade. Pelo menos nos casos em que a equipe do operador do sistema de informação tenha especialistas capazes de realizar todas as atividades descritas acima.

Por outro lado, geralmente encontramos o fato de nos pedirem ajuda para conectar segmentos padrão. De qualquer forma, nesses segmentos, pelo menos, você precisa elaborar documentação interna, instalar e configurar corretamente as ferramentas de segurança da informação. Além disso, muitos operadores de sistemas de informação confiam mais nas conclusões sobre a conformidade de um segmento típico escrito por uma organização terceirizada do que no relatório do solicitante de conexão ao sistema.

Porém, mesmo nesse caso, segmentos típicos permitem que o operador economize dinheiro, pois pelo menos não há necessidade de desenvolver um modelo de ameaça separado e documentar a documentação do sistema de proteção de informações para elementos acopláveis. Também não há necessidade de realizar testes de certificação em larga escala.

Mito número 9. Em segmentos típicos, apenas os mesmos meios técnicos devem ser utilizados (por exemplo, computadores com a mesma placa-mãe, o mesmo processador, a mesma RAM, até o tipo, fabricante e modelo)

Esta questão também não está claramente descrita na legislação. Em um nível intuitivo, fica claro que a total conformidade do ferro do segmento certificado e conectado não é necessária, caso contrário, tudo isso é inútil. E quando precisamos esclarecer uma pergunta semelhante, o que fazemos? É isso mesmo - estamos escrevendo uma carta para o regulador. A FSTEC respondeu que as soluções técnicas idênticas (um fabricante, um modelo etc.) não devem ser usadas em segmentos típicos.

Para que um segmento seja considerado adequado para o certificado, é necessário que a mesma classe de segurança seja estabelecida para ele, as mesmas ameaças à segurança da informação sejam identificadas e as mesmas soluções de design sejam implementadas para o próprio sistema e para o sistema de proteção de informações. Como realmente escrito na 17ª ordem.

Mito número 10. Para cada segmento de tipo acoplável, você precisa criar seu próprio modelo de ameaça.

Não. No segmento típico, as mesmas ameaças devem ser relevantes como na parte certificada do sistema de informação. Consequentemente, o modelo de ameaça é um para todo o sistema. Se ocorrerem mudanças tecnológicas significativas no sistema de informação certificado que possam levar ao surgimento de novas ameaças à segurança da informação, é necessário revisar o modelo geral de ameaças e, se necessário, realizar testes de certificação adicionais do sistema como um todo.

Mito número 11. Os dados dos segmentos padrão anexados não precisam ser refletidos no passaporte técnico do sistema de informação

Sobre esta questão, também pedimos ao FSTEC. A resposta é que os dados dos novos segmentos devem ser inseridos no passaporte técnico. Mas a decisão de inserir novos dados na planilha de dados geral do sistema ou criar um documento separado para o segmento depende do operador.Em nossa opinião, é mais conveniente fazer um passaporte técnico separado para um segmento típico.

Só isso. Se você ainda tiver dúvidas sobre o tópico, faça o comentário. Esperamos que nossa publicação seja útil e facilite a vida dos operadores de sistemas de informações certificados.