DOU - 13/10/2021

RESOLUÇÃO CFC Nº 1.635, DE 7 DE OUTUBRO DE 2021

Institui a Política de Segurança da Informação para Aquisição, Desenvolvimento e Manutenção de Sistemas da Informação.

O PRESIDENTE DO CONSELHO FEDERAL DE CONTABILIDADE no uso de suas atribuições legais e regimentais,

Considerando o Decreto nº 9.637, de 26 de dezembro de 2018, que institui a Política Nacional de Segurança da Informação;

Considerando o Decreto nº 10.222, de 5 de fevereiro de 2020, que aprova a Estratégia Nacional de Segurança Cibernética;

Considerando as normas técnicas ABNT NBR ISO/IEC 27001:2013 Tecnologia da informação - Técnicas de segurança - Sistemas de gestão da segurança da informação - Requisitos, ABNT NBR ISO/IEC 27002:2013 - Tecnologia da Informação - Técnicas de Segurança - Código de prática para controles de Segurança da Informação e ABNT NBR ISO/IEC 27003:2020 - Tecnologia da Informação - Técnicas de Segurança - Sistemas de Gestão da Segurança da Informação - Orientações;

Considerando que o Plano Diretor de Tecnologia da Informação (PDTI) 2020-2021 do Conselho Federal de Contabilidade estabelece o objetivo estratégico de "Garantir que o acesso, o tratamento e o armazenamento de informações do Conselho Federal de Contabilidade ocorram em conformidade com políticas e normas que assegurem a confidencialidade e a integridade das informações";

Considerando a Resolução CFC nº 1.627, de 19 de agosto de 2021, que dispõe sobre a Política de Segurança da Informação do CFC;

Considerando a necessidade de estabelecer princípios e diretrizes de segurança da informação para a validação dos sistemas desenvolvidos, mantidos, adquiridos ou em produção, resolve:

CAPÍTULO I

DA INSTITUIÇÃO, OBJETIVO E APLICAÇÃO

Art. 1º Fica instituída a Política de Segurança da Informação para Aquisição, Desenvolvimento e Manutenção de Sistemas de Informação no âmbito do Conselho Federal de Contabilidade.

Art. 2º Esta política de segurança norteia o processo de aquisição, desenvolvimento e manutenção de sistemas de informação para assegurar a disponibilidade, continuidade, confidencialidade e integridade dos serviços prestados por estes sistemas, visando reduzir os riscos institucionais.

Art. 3º A política deve ser observada na contratação ou implementação de soluções de TI que envolvam o desenvolvimento, a manutenção ou a aquisição de sistemas, independentemente de quem os tenha desenvolvido ou adaptado e são aplicáveis, no que couber, àqueles disponíveis no mercado para aquisição e aos sistemas em produção pelo CFC.

Art. 4º Esta norma se aplica a todos os conselheiros, empregados, assessores, estagiários e aprendizes do CFC ou indivíduos que, direta ou indiretamente, utilizam ou suportam os sistemas, infraestrutura ou informações do CFC e, especialmente, destina-se aos responsáveis da área de TI envolvidos pelo processo de aquisição, desenvolvimento e manutenção dos sistemas de informação.

Art. 5º Esta norma não substitui o documento de metodologia de desenvolvimento de sistemas adotado pela CGTI, mas o complementa quanto aos aspectos de segurança da informação.

Art. 6º A elaboração e atualização deste documento é de responsabilidade do Comitê de Segurança da Informação.

CAPÍTULO II

DOS TERMOS E DEFINIÇÕES

Art. 7º Para os efeitos desta política, são estabelecidos os seguintes conceitos e definições:

I - Ambiente de desenvolvimento: espaço com acesso controlado contendo os itens de configuração em desenvolvimento, operação, processamento, geração e armazenamento de dados, onde os usuários desenvolvedores farão as publicações e testes no decorrer do processo de construção dos softwares;

II - Ambiente de homologação: espaço com acesso controlado contendo os itens de configuração em homologação, operação, processamento, geração e armazenamento de dados, onde os usuários e gestores donos do produto farão as homologações e aceites antes da publicação dos softwares em produção;

III - Ambiente de produção: espaço com acesso controlado contendo os itens de configuração em produção, operação, processamento, geração e armazenamento de dados, onde os usuários finais acessarão o software.

IV - Ambiente de versão: sistemas de controle de fontes que possibilitam rastrear e gerenciar as alterações em códigos e em documentação de software. Espaço com acesso controlado, contendo os códigos fontes e as documentações dos artefatos de softwares entegues ao CFC ou desenvolvidos pelas equipes internas;

V - Ameaça: qualquer circunstância ou evento com o potencial de causar impacto negativo sobre a confidencialidade, integridade, autenticidade e disponibilidade da informação.

VI - Análise de Risco: uso sistemático de informações de identificação de fontes para estimar o risco.

VII - Análise dinâmica: tipo de teste que verifica o comportamento externo do software em busca de anomalias ou vulnerabilidades. A análise dinâmica ocorre por meio de interações com o software em execução. Um exemplo é o chamado teste de penetração.

VIII - Análise estática: tipo de teste de software que verifica sua lógica interna em busca de falhas ou vulnerabilidades. A análise estática ocorre por meio da verificação do código-fonte ou dos binários.

IX - Ativos de informação: ativos de informação qualquer dispositivo de software ou hardware que agrega valor ao negócio e compõe a infraestrutura de rede de dados do CFC, assim como também os locais onde se encontram estes dispositivos, gestão do pessoal que a eles possuem acesso, além dos processos envolvidos na gestão e operacionalização dos ativos de informação.

X - Avaliação de conformidade em segurança da informação: exame sistemático do grau de atendimento dos requisitos relativos à segurança da informação com as legislações específicas.

XI - Avaliação de riscos: processo para comparar o risco estimado com critérios predefinidos para determinar a importância do risco.

XII - Base de dados: conjunto de dados interrelacionados, organizados de forma a permitir a recuperação da informação. Tem como objetivo fornecer a informação atualizada, precisa e confiável.

XIII - Confidencialidade: propriedade de que a informação não esteja disponível ou revelada a indivíduos, entidades ou processos não autorizados.

XIV - Controles de segurança: medidas adotadas para evitar ou diminuir a probabilidade de exploração de uma vulnerabilidade. Exemplos de controles de segurança são: a criptografia, as funções de hash, a validação de entrada, o balanceamento de carga, as trilhas de auditoria, o controle de acesso, a expiração de sessão, os backups e etc.

XV - Criptografia: arte e ciência de esconder o significado de uma informação de receptores não desejados.

XVI - Criticidade: é o nível de dependência da instituição em relação ao ativo, caso ela precise dele durante uma crise. A criticidade está diretamente relacionada ao tempo máximo aceitável da paralisação de um serviço ou processo associado às atividades finalísticas do CFC e pontua o quanto essa paralisação será crítica para a instituição..

XVII - Disponibilidade: propriedade de que a informação esteja acessível e utilizável sob demanda por um usuário autorizado.

XVIII - Integridade: propriedade de que a informação não foi modificada ou destruída, de maneira não autorizada ou acidental, por indivíduos, entidades ou processos.

XIX - Modelo positivo de segurança: modelo no qual se define o que é permitido explicitamente, rejeitando o restante.

XX - Recuperação segura em caso de falha: modelo no qual a falha no processamento de um controle de segurança resulte no mesmo caminho que seria executado no caso de uma vedação emitida por tal controle.

XXI - Requisitos de segurança: conjunto de necessidades de segurança que o sistema deve atender, sendo tais necessidades influenciadas fortemente pela política de segurança do CFC, compreendendo aspectos funcionais, não funcionais e legais. Os aspectos funcionais descrevem comportamentos que viabilizam a criação ou a manutenção da segurança e, geralmente, podem ser testados diretamente. Na maioria dos casos, remetem a mecanismos de segurança como, por exemplo, controle de acesso baseado em papéis de usuários como administradores ou usuários comuns; autenticação com o uso de credenciais como usuário e senha ou certificados digitais. Os aspectos não funcionais descrevem procedimentos necessários para que o sistema permaneça executando as funções adequadamente mesmo quando sob uso indevido. São exemplos de requisitos não funcionais, dentre outros, a validação das entradas de dados e o registro de logs de auditoria com informações suficientes para análise forense.

XXII - Riscos de segurança da informação: possibilidade potencial de uma ameça comprometer a informação ou o sistema de informação pela exploração da vulnerabilidade.

XXIII - Segurança da informação: ações que objetivam viabilizar e assegurar a disponibilidade, a integridade, a confidencialidade e a autenticidade das informações.

XXIV - Sistema de informação: aplicação da tecnologia da informação que dá apoio às atividades de determinada área de conhecimento, visando otimizar as operações, o gerenciamento e a decisão, trabalhando os dados e transformando-os em informação.

XXV - Trilhas de auditoria: são rotinas específicas programadas nos sistemas para fornecerem informações de interesse da auditoria. São entendidas como o conjunto cronológico de registros - logs - que proporcionam evidências do funcionamento do sistema.

Esses registros podem ser utilizados para reconstruir, revisar e examinar transações desde a entrada de dados até a saída dos resultados finais, bem como para avaliar e rastrear o uso do sistema, detectando e identificando usuários não autorizados.

XXVI - Vulnerabilidade: fragilidade de um ativo ou grupo de ativos de informação que pode ser explorada negativamente por uma ou mais ameaças.

XXVII - ACL: Lista de Controle de Acesso, é uma técnica de controle de acesso que permite definir para cada usuário, uma lista de recursos que o mesmo tem acesso.

CAPÍTULO III

DAS DIRETRIZES E PROCEDIMENTOS

Art. 8º Para o desenvolvimento, a manutenção, a aquisição ou o funcionamento de sistemas de informação no Conselho Federal de Contabilidade, independentemente das metodologias ou das tecnologias utilizadas, devem-se observar as seguintes diretrizes e procedimentos.

I - Toda aquisição, desenvolvimento e manutenção de sistemas de informação deve ser submetido a um processo de gestão de configuração e mudança de forma a garantir o controle efetivo de modificações realizadas em ambientes diversos, com o objetivo de registrar, avaliar e autorizar qualquer modificação em sistemas de informação.

II - Identificar, definir, validar e documentar, na fase inicial de qualquer demanda, os requisitos de segurança e a disponibilidade a que os sistemas deverão atender.

III - Usar modelo positivo de segurança definido no contexto da aplicação e dos ativos envolvidos, baseado na classificação da informação e conhecimentos dos processos institucionais.

IV - Implementar controle de acesso baseado em papéis ou perfis de usuários, ou controle via Lista de Controle de Acesso (ACL), preferencialmente por meio de componentes isolados.

V - Implementar controles de segurança necessários para proteger os ativos e informações digitais, de acordo com a sua criticidade.

VI - Sempre que possível, usar controles de segurança como componentes, de forma que sejam catalogados e reutilizados em outros sistemas. É recomendado que esses componentes sejam baseados nos controles definidos nas NBR ISO/IEC 27001 e 27002.

VII - Implementar os controles de segurança em múltiplas camadas da arquitetura do sistema, de acordo com a criticidade das informações tratadas.

VIII - Implementar a obrigatoriedade de realização de testes unitários para minimizar os erros e, possivelmente a automatização de entrega de publicação de sistemas desenvolvidos.

IX - O backup relacionado aos sistemas de informações, bem como sua frequência e retenção, deve ser definido, conforme o nível de confiabilidade em que foram classificados na Política de Backup.

X - Desenvolver ou adquirir sistemas de forma que suas mensagens de erro não revelem detalhes de sua estrutura interna ou a configuração do ambiente.

XI - Verificar o atendimento dos requisitos de segurança do software, por meio de análise estática e/ou análise dinâmica, preferencialmente na fase de construção.

XII - Identificar e corrigir as vulnerabilidades encontradas anteriormente à entrada de qualquer sistema em produção, segundo o critério de prioridade e de aceitação do risco.

XIII - Investigar e tratar de forma contínua as vulnerabilidade técnicas dos sistemas de informações em uso.

XIV - A base de dados do ambiente de testes deve ser especificamente para testes, assim como o ambiente de homologação deve ser utilizado especificamente para homologação do sistema e/ou requisitos com o usuário requisitante/final.

XV - Remover arquivos desnecessários para o funcionamento do sistema e contas criadas para testes, quando da passagem para o ambiente de produção.

XVI - Evitar a implementação de parâmetros de configuração dentro do códigofonte.

XVII - Usar arquivos externos de configuração, adequadamente protegidos contra acesso e alteração indevidos.

XVIII - Utilizar o princípio do mínimo privilégio, que consiste na estratégia de segurança baseada na ideia de conceder autorizações apenas quando realmente for necessária para o desempenho de uma atividade específica, observada a legislação pertinente.

XIX - Recuperar de modo seguro em caso de falha.

XX - Registrar em logs todos os eventos relevantes para a instituição e para a segurança da informação, com o armazenamento de informações suficientes para investigação e análise forense. a. Os logs que permitam a construção de uma trilha de auditoria deverão ser protegidos de forma consistente com o contexto da aplicação e dos processos institucionais envolvidos.

XXI - Utilizar controles de segurança da informação específicos para os sistemas, independentemente de quaisquer proteções utilizadas na infraestrutura subjacente.

XXII - As bases e massas de dados utilizadas para teste e validação de sistemas devem ser anonimizadas caso contenham dados classificados como sigilosos, conforme a legislação.

XXIII - Não permitir acesso ao ambiente de produção por pessoal estranho às Unidades Organizacionais envolvidas na manutenção de infraestrutura, salvo em situações devidamente justificadas e documentadas e com acompanhamento contínuo e presencial.

XXIV - Observar que, em caso de contratação de serviço para desenvolvimento ou manutenção de software, o código-fonte deve ser custodiado de modo seguro pela empresa contratada e o CFC.

XXV - Para que um sistema de informação seja utilizado no CFC, quando não produzido pelo próprio Conselho, os requisitos e contratos de licenciamento devem ser controlados, indicando o proprietário da aplicação e a forma adequada de uso, em concordância com a lei de direitos autorais, bem como o tempo de vigência do contrato.

XXVI - Definir as regras para transferência do conhecimento sobre o software desenvolvido de modo a permitir a sua manutenção, de forma independente, por parte dos demais Conselhos.

XXVII - Estabelecer acordos de licenciamento, propriedade dos códigos e direitos de propriedade intelectual condizentes com o interesse do CFC, de forma a adquirir a titularidade do software ou para apenas exercer o direito de uso.

XXVIII - Instaurar meios que visem o controle da qualidade e precisão do trabalho efetuado de forma a garantir que os requisitos de segurança sejam atendidos.

XXIX - Sistemas que possuam a necessidade de controle de acesso ou lidem com dados sigilosos devem utilizar criptografia para a transmissão de dados e armazenamento em bancos de dados.

XXX - Definir a execução de testes pela contratada e homologação pelo CFC, antes da instalação do software obtido no ambiente de produção:

a) Realizar a análise estática e a análise dinâmica do software desenvolvido por terceiros.

XXXI - Definir regras, estabelecer responsabilidades e procedimentos operacionais quanto à liberação de acesso aos recursos tecnológicos e ao ambiente físico ou lógico do CFC.

XXXII - O suporte dos sistemas somente deve ser realizado após abertura de chamado pelo usuário.

XXXIII - Na fase do ciclo de vida do sistema, em que são levantados os requisitos, as necessidades, o estabelecimento de relação com as atividades institucionais ou o levantamento de custos, devem ser desenvolvidas as seguintes ações de segurança:

a) Avaliar, preliminarmente, os impactos e categorização do sistema conforme a tabela do inciso XXXV;

b) Definir os requisitos de segurança.

XXXIV - Na fase do ciclo de vida do sistema, em que são especificados e analisados os requisitos, o custo/benefício ou elaborado o plano de gerenciamento de riscos, devem ser desenvolvidas as seguintes ações de segurança:

a) Análisar os riscos;

b) Definir os controles de segurança da informação que serão implementados.

XXXV - Na fase do ciclo de vida, em que o sistema é construído, devem ser desenvolvidas as seguintes ações de segurança:

a) Desenvolver e testar os controles de segurança da informação;

b) Implementar controles de versão para garantir a gestão dos código-fonte;

c) Realizar procedimentos de verificação de funcionamento na infraestrutura de desenvolvimento após atualizações ou substituições de sistemas.

XXXVI - Na fase do ciclo de vida, em que o sistema é implantado, deve ser desenvolvida a seguinte ação de segurança:

a) Monitorar e avaliar a segurança da informação, podendo utilizar a norma ISO/ IEC 15408-3:2008 como referência.

XXXVII - Na fase de manutenção do sistema, deve ser desenvolvida a seguinte ação de segurança:

a) Gerenciar e revalidar os controles de segurança da informação.

XXXVIII -A avaliação de impacto potencial pode ser realizada com base na tabela do FIPS 199 (NIST):

Vide Tabela
*** Necessitando da(s) Tabela(s), solicite-o(s) à Editora Magister. ***

CAPÍTULO IV

DAS RESPONSABILIDADES

Art. 9º Os envolvidos no processo de desenvolvimento, manutenção e aquisição de sistemas no CFC devem receber treinamento em segurança de software.

Parágrafo único: Todos os usuários, ao utilizar um novo sistema ou nova versão, devem ser treinados e capacitados para a sua efetiva utilização.

Art. 10. O cumprimento desta política deve ser observado quando da elaboração dos processos de contratações de desenvolvimento, manutenção ou aquisição de sistemas, devendo a obrigação estar inserida nos respectivos Estudos Técnicos Preliminares, Termos de Referência ou Projetos Básicos e contratos.

Art. 11. A Coordenadoria de Gestão de TI (CGTI) deve supervisionar o processo desde o seu planejamento de aquisição, desenvolvimento, manutenção ou implementação, no caso de desenvolvimento de sistemas/softwares por terceiros.

Art. 12. A CGTI ou a Comitê de Tecnologia da Informação do CFC pode estabelecer outros procedimentos com o objetivo de complementar o definido nesta política.

Art. 13. Os usuários da rede interna do CFC devem reportar à CGTI as ocorrências de incidentes que afetem os ativos de informação ou descumprimento dessa norma tão logo tomem ciência do ocorrido, preferencialmente por meio de chamado no sistema helpdesk.

Art. 14. Na ocorrência de quebra de segurança por meio de recursos computacionais, a CGTI deve ser imediatamente informada para adotar as providências necessárias, limitando o acesso às informações e/ou recursos computacionais do CFC, se necessário.

Art. 15. Esta Resolução entra em vigor em 1º/11/2021.

ZULMIR IVÂNIO BREDA

Presidente do Conselho