DOE 23/04/2024 - Diário Oficial do Estado do Ceará

44
DIÁRIO OFICIAL DO ESTADO | SÉRIE 3 | ANO XVI Nº075 | FORTALEZA, 23 DE ABRIL DE 2024
comunicações de incidentes, bem como as partes interessadas.
6.2.Tratamento de incidentes
6.2.1.O processo de tratamento a incidentes deverá conter, pelo menos, as seguintes fases: Preparação; Análise de Eventos, Detecção e Registro de
incidentes; Contenção, Erradicação e Recuperação; e Atividades Pós Incidente.
6.2.2. Fase de Preparação:
6.2.2.1.A fase de Preparação tem como objetivo preparar as equipes para atuar na resposta a incidentes, na tentativa de limitar a ocorrência de
incidentes, selecionando e implementando controles com base em avaliações de risco;
6.2.2.2.Deverá ser estabelecida ferramenta para registro de incidentes, que permita registro e rastreamento de problemas recorrentes.
6.2.3.Fase de Análise de Eventos, Detecção e Registro de incidentes:
6.2.3.1.A fase de Análise de Eventos, Detecção e Registro de incidentes tem como objetivo analisar os eventos a fim de enquadrá-los como incidentes
de segurança da informação, posteriormente realizar o registro do incidente, e realizar o escalonamento ao nível adequado.
6.2.3.2.Sempre que possível, os incidentes deverão ser analisados e detectados por meios de monitoramento automatizado, com auxílio de softwares.
6.2.3.3.A partir do momento em que há suspeita de um incidente, a equipe responsável deve registrar todas as ações relativas ao evento, iniciando
a elaboração do relatório de tratamento do incidente.
6.2.3.4.Assim que incidente for recebido pela equipe responsável, o mesmo deve ser submetido às etapas de classificação e priorização, verificação
de autorização de atuação, análise e coleta de evidências, e convocação de membros e áreas envolvidas.
6.2.3.5.A classificação e priorização do tratamento de incidentes deverá ser feita para a correta alocação de recursos em áreas e sistemas, e será
previamente mensurada por meio de variáveis de impacto, que, por sua vez, conterão diferentes definições de níveis de impacto.
6.2.4.Fase de Contenção, Erradicação e Recuperação:
6.2.4.1.Busca implementar ações para contenção, erradicação e recuperação do incidente; identifica as origens de ataques e coletadas as evidências;
6.2.4.2.As estratégias de contenção deverão ser documentadas e conter justificativas dos critérios utilizados para as escolhas priorizadas.
6.2.4.3.É recomendável identificar a origem de ataques durante o tratamento de incidentes, dando preferência e enfoque na contenção, na erradicação
e na recuperação.
6.2.4.4.É necessário documentação e preservação de todas as informações de coleta, bem como manuseio das evidências, garantindo níveis de
segurança adequados.
6.2.4.5.A erradicação e a recuperação devem ser utilizadas como abordagens de remediação do incidente, para que os ativos sejam restaurados para
seu estado normal, e os administradores dos ativos devam confirmar se os mesmos estão operando de maneira adequada.
6.2.4.6.No caso de incidentes de grande impacto, e que necessitem de recuperação a longo prazo, recomenda-se priorizar o aumento dos níveis gerais
de segurança e correções de recursos de alto valor agregado para a organização nos primeiros dias, a fim de evitar novos incidentes.
6.2.5.Atividades pós-incidente: realizar atividades que busquem a melhoria dos processos de tratamento a incidentes, visando a elevação do nível
de segurança, por meio do mapeamento de vulnerabilidades exploradas e aplicação das devidas correções em todos os seus sistemas.
6.2.5.1.As equipes responsáveis terão a competência de aplicar os controles que julgarem adequados de forma a limitar a frequência de ocorrência,
danos e custos decorrentes de eventuais incidentes, e para servir como fator de análise crítica da gestão de incidentes.
6.2.5.2.As informações provenientes das análises sobre os incidentes de segurança devem ser encaminhadas para consideração no planejamento
das atividades de Segurança da Informação.
6.2.5.3.Em caso de ocorrência de incidentes graves, o CSIPD, ou seu representante deverá monitorar as atividades pós-incidentes.
7.EXCEÇÕES
7.1.Os casos omissos, excepcionais e eventuais dúvidas quanto à aplicação da PSI serão resolvidos pelo Comitê de Segurança da Informação e
Privacidade de Dados (CSIPD).
8.PENALIDADES
8.1.O não cumprimento da Norma de Gestão de Incidentes de Segurança da Informação por parte dos colaboradores estará sujeito às penalidades
previstas nas esferas administrativa, civil e penal.
9.ELUCIDÁRIO
9.1.Área de TI: Coordenação de Tecnologia da Informação e Comunicação.
9.2.Colaboradores: servidores, consultores externos, estagiários, prestadores de serviços ou a quem quer que venha a ter acesso a dados ou infor-
mações da Sefaz.
9.3.CSIPD: Comitê de Segurança da Informação e Privacidade de Dados.
9.4.Correio eletrônico corporativo ou e-mail corporativo: serviço de tecnologia da informação, disponibilizado pela Sefaz, que permite o envio e
recebimento de mensagens eletrônicas.
9.5.Informação: Qualquer conjunto de dados que resulte em algum significado compreensível. A informação pode possuir algum valor para o sistema
CrediSIS, seus clientes, parceiros e colaboradores, bem como pode ser de propriedade da empresa ou estar sob sua custódia.
9.6.Solução do incidente: situação em que os serviços voltaram a operar normalmente e que a solução apresentada foi considerada satisfatória,
mesmo que como solução de contorno.
9.7.Fechamento do incidente: ocorre em duas situações, encerramento do incidente com a produção de todos os artefatos e relatórios pertinentes,
ou automaticamente pelo sistema, após um prazo pré-estabelecido.
9.8.Medida de solução: controle e/ou ação tomada para sanar vulnerabilidades e problemas que sejam a causa-raiz de um ou mais incidentes de
segurança da informação.
9.9.Recurso: Qualquer ativo, tangível ou intangível, que possua valor para a empresa. Podem ser considerados recursos: pessoas, ambientes físicos,
tecnologias, serviços contratados, em nuvem, sistemas e processos;
9.10.Medida de contenção: controle e/ou ação tomada para evitar que danos causados por um determinado incidente continuem aumentando com
o passar do tempo. Além disso, tais medidas visam o restabelecimento do sistema/serviço afetado, mesmo eu não seja em sua capacidade total.
ANEXO VI A QUE SE REFERE A PORTARIA N°098/2024 - NORMA DE GESTÃO DE INCIDENTE DE SEGURANÇA DA INFORMAÇÃO
1.APRESENTAÇÃO
Esta norma estabelece orientações para o desenvolvimento seguro no âmbito da Secretaria da Fazenda, com o objetivo de assegurar os requisitos de
autenticidade, confidencialidade, integridade e disponibilidade nos sistemas de informação desenvolvidos na Instituição ou por fábricas de software
contratadas.
O desenvolvimento seguro consiste em boas práticas aplicáveis ao processo de desenvolvimento de software, desde a especificação dos requisitos até
a implantação em produção. Como resultado, tem-se um produto com menos vulnerabilidades (em quantidade e severidade), mais robusto e confiável.
2.AUTENTICAÇÃO E AUTORIZAÇÃO
2.1.Todos os casos de uso na especificação do sistema devem ser avaliados do ponto de vista da segurança, tratando-se a autenticação e a autorização
como regra, e o uso anônimo como exceção.
2.2.A autenticação de usuários e sistemas deve ser baseada em um dos seguintes mecanismos:
2.2.1.Ferramenta de single sign-on (SSO) da Sefaz.
2.2.2.Certificação digital.
2.2.3.Serviço de login único governamental.
2.3.Não se deve realizar autenticação com base em endereços de rede, como endereço MAC e endereço IP.
2.4.Os controles de autorização devem ser realizados através de grupos e perfis em ferramenta de controle de acesso.
2.5.A realização de uma ação crítica deve requerer um nível adicional de autenticação, como uma nova autenticação ou o uso de autenticação de
dois fatores. As ações são definidas como críticas no documento de requisitos.
2.6.Sessões stateful devem ser invalidadas no servidor depois de logout do usuário ou de um tempo pré-definido (timeout).
2.7.Para as integrações entre serviços críticos, é recomendado o uso de autenticação mútua com certificado digital.
2.7.1.Classificam-se como críticos os serviços compreendidos na definição do item 3.3 da Norma de Uso de Recursos de Informática.
3.CRIPTOGRAFIA
3.1.Não se deve incluir senhas, tokens, chaves criptográficas, nomes de servidores, endereços IP e outros dados sensíveis diretamente em código-fonte.
3.1.1.Tais dados só podem ser armazenados depois de transformados em um formato irreversível, através de uma função hash.
3.1.2.Deve-se usar uma função de derivação de chave para dificultar o ataque bruto a um hash. Exemplo: PBKDF2.
3.2.Chaves criptográficas devem ser geradas aleatoriamente, através de um mecanismo CSPRNG imprevisível.
3.2.1.Caso se use uma senha como chave criptográfica, ela deve ser combinada com um salt aleatório.
3.3.Não se deve utilizar algoritmos criptográficos sabidamente inseguros. Exemplos: MD5, SHA1, DES e RC4.