DOE 23/04/2024 - Diario Oficial do Estado do Ceara - Caderno 1
Baixar página em PDF · Criar alerta deste tema
O visualizador interativo precisa de JavaScript — baixe a página original em PDF.
TEXTO OFICIAL · ÍNTEGRA
DIÁRIO OFICIAL DO ESTADO | SÉRIE 3 | ANO XVI Nº075 | FORTALEZA, 23 DE ABRIL DE 2024
44
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; 6242A éi d ã dã dd ifii d iéi ilid lh iid |
| ....s estratgas e contenço evero ser ocumentaas e conter justcatvas os crtros utzaos para as escoas prorzaas. 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 |
| 81O não cumrimento da Norma de Gestão de Incidentes de Seurana da Informaão or arte dos colaboradores estará sujeito às enalidades |
| .. p gç ç p p p 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.