PORTARIA Nº 225, DE 31 DE JULHO DE 2023.

O DIRETOR-GERAL DA SECRETARIA DO TRIBUNAL REGIONAL ELEITORAL DO ESTADO DE SÃO PAULO, no uso de suas atribuições legais e regulamentares, conforme delegação de competência estabelecida no artigo 2º, inciso I, da Portaria TRE-SP nº 1/2022;

CONSIDERANDO a necessidade de definir processos de Desenvolvimento Seguro de Software no âmbito do Tribunal Regional Eleitoral de São Paulo;

CONSIDERANDO a necessidade de apoiar os processos de continuidade de serviços de TI, em caso de eventos de causas naturais, acidentais, tecnológicas ou humanas;

CONSIDERANDO a necessidade de apoiar a gestão do processo de tratamento e resposta a incidentes em redes computacionais no Tribunal Regional Eleitoral de São Paulo;

CONSIDERANDO a Resolução CNJ nº 396/2021,, que institui a Estratégia Nacional de Segurança Cibernética do Poder Judiciário (ENSEC-PJ);

CONSIDERANDO a Resolução TSE nº 23.644/2021, que institui a Política de Segurança da Informação (PSI) no âmbito da Justiça Eleitoral;

CONSIDERANDO a Portaria DG/TSE nº 444/2021, que dispõe sobre a instituição da norma de termos e definições relativa à Política de Segurança da Informação do Tribunal Superior Eleitoral;

CONSIDERANDO a Resolução TRE-SP nº 580/2022, que institui a Política de Segurança da Informação (PSI) no âmbito da Justiça Eleitoral de São Paulo;

CONSIDERANDO as boas práticas em segurança da informação e privacidade previstas nas normas ABNT NBR ISO/IEC 27001 e ABNT NBR ISO/IEC 27002, complementadas pela norma ABNT NBR ISO/IEC 27701;

CONSIDERANDO as boas práticas na gestão da continuidade de negócios previstas nas normas ABNT NBR ISO/IEC 22301 e 22313;

CONSIDERANDO as boas práticas em segurança da informação previstas no modelo CIS Controls;

CONSIDERANDO a necessidade de implementar controles para o tratamento de dados pessoais, de acordo com a Lei nº 13.709/2018 (LGPD);

CONSIDERANDO que a segurança da informação e a proteção de dados pessoais são condições essenciais para a prestação dos serviços jurisdicionais e administrativos do Tribunal Regional Eleitoral de São Paulo;

RESOLVE:

CAPÍTULO I

DISPOSIÇÕES PRELIMINARES

Art. 1º  Fica instituída a Portaria para o Desenvolvimento Seguro de Software, com o intuito de estabelecer padrões de segurança no desenvolvimento de software, em consonância com a Política de Segurança da Informação (PSI) do Tribunal Regional Eleitoral de São Paulo.

Art. 2º  Para os efeitos da Política de Segurança da Informação do Tribunal Regional Eleitoral de São Paulo, aplicam-se os termos e definições conceituados na Portaria DG/TSE nº 444/2021.

CAPÍTULO II

DAS DEFINIÇÕES

Art. 3º  Para os efeitos da Política de Segurança da Informação do TRE-SP e das normas a ela subordinadas, aplicam-se os termos e definições conceituados na Portaria DG/TSE nº 444, de 8 de julho de 2021.

CAPÍTULO III

DO DESENVOLVIMENTO

Art. 4º  O processo para desenvolvimento seguro de software deverá considerar, obrigatoriamente, a Portaria que institui o gerenciamento de vulnerabilidades no âmbito do TRE-SP.

Art. 5º  O modelo de desenvolvimento seguro adotado no TRE-SP deverá considerar, ao menos:

I - o princípio de privilégio mínimo, com a finalidade de atribuir acesso mínimo à usuária e ao usuário para a realização das atividades.

II - o princípio da mediação completa, no qual todas as requisições devem ser verificadas, analisadas e autorizadas entre objetos e dependências do software.

Art. 6º  Deverá ser implementado modelo de gerenciamento de ameaças que contemple o registro e acompanhamento de problemas de segurança, seus efeitos e impactos, devendo ser priorizados de acordo com a severidade de sua classificação.

§ 1º O registro de problemas deverá contemplar pelo menos as seguintes categorias:

I - Falsificação (Spoofing): capacidade de se passar por outra pessoa, processo ou sistema.

II - Adulteração (Tampering): capacidade de alterar a informação sem autorização.

III - Repúdio (Repudiation): capacidade de evitar responsabilidade por uma ação.

IV - Divulgação de Informação (Information Disclosure): obter acesso à informação sem autorização.

V - Negação de Serviço (Denial of Service): causar interferência ou mau funcionamento de um sistema ou serviço.

VI - Elevação de privilégio (Elevation of privilege): obter controle não autorizado sobre um sistema ou processo.

§ 2º A classificação da severidade se dará da seguinte forma:

I - Alta: para incidentes que exijam resposta imediata em razão de indisponibilidade de algum serviço.

II - Média: para incidentes que tenham o potencial que configura a hipótese prevista no inciso I.

III - Baixo: para incidentes de baixo impacto ou poder destrutivo.

Art. 7º  Para garantir segurança no processo de desenvolvimento deve-se, dentro das possibilidades, seguir as seguintes diretrizes:

I - possibilitar treinamento contínuo dos desenvolvedores;

II - usar bibliotecas seguras;

III - utilizar ferramentas de análise de código para verificação de padrões de configuração segura e convenções;

IV - utilizar ferramentas de teste dinâmico de código visando encontrar vulnerabilidades e

V - realizar teste de invasão manual a nível de código.

CAPÍTULO IV

DO INVENTÁRIO DE SOFTWARES

Art. 8º  Os softwares desenvolvidos internamente e por terceiros, incluindo os seus componentes, deverão ter gestores definidos quando da sua utilização.

Art. 9º  Os gestores dos softwares serão responsáveis por:

I - garantir que sejam mantidos atualizados;

II - atualizar inventários mensalmente;

III - avaliar os riscos de segurança e propor ações de combate e

IV - realizar as atualizações críticas de alto risco de forma automática ou em até 14 dias.

CAPÍTULO V

DO USO DE COMPONENTES

Art. 10.  O uso de componentes de software somente será permitido:

I - se forem adquiridos de fontes confiáveis;

II - se os componentes forem utilizados em sua versão mais atual ou, na impossibilidade, em versão anterior com suporte válido;

III - se os componentes estejam em desenvolvimento e manutenção ativa e

IV - se os componentes possuam histórico divulgado de correção de bugs e vulnerabilidades.

Art. 11.  Antes da utilização, a segurança dos componentes deverá ser verificada pela análise de fragilidades com consulta a bancos de dados de vulnerabilidades disponíveis como o CVE -Common Vulnerabilities and Exposures, e NIST -National Vulnerability Database (NVD).

Art. 12.  Para análise de riscos de componentes de terceiros deve-se rigorosamente considerar:

I - selecionar produtos que estejam estabelecidos no mercado e que possuam segurança comprovada;

II - manter inventário automático ou individualizado atualizado;

III - avaliar o risco de cada componente;

IV - mitigar ou aceitar os riscos avaliados e

V - monitorar os riscos.

CAPÍTULO VI

DA INFRAESTRUTURA

Art. 13.  O processo de desenvolvimento seguro de software deverá possuir elementos de sua infraestrutura padronizados seguindo rigoroso Modelo Seguro de Configuração para componentes de infraestrutura de aplicações que estabeleçam a funcionalidade mínima e que possuam imagens padrão que passaram por processo de hardening.

Art. 14.  Os ambientes de Sistemas de Produção e Não Produção deverão ser especificados e mantidos separados.

Art. 15.  O repositório de informações e códigos-fonte deverá ser segregado e possuir políticas rígidas de acesso com rastreamento de ações realizadas.

CAPÍTULO VII

DA CAPACITAÇÃO DE DESENVOLVEDORES

Art. 16.  A Coordenadoria de Desenvolvimento de Sistemas deverá manter um programa estabelecido de capacitação para desenvolvimento seguro que contemple princípios gerais de segurança, práticas padrão de segurança de aplicações e proteção de dados pessoais.

§ 1º O programa deverá ser realizado semestralmente para promover a segurança dentro da equipe e construir uma cultura de segurança entre os desenvolvedores.

§ 2º O resultado da análise de código fonte deve ser inserido no processo de liberação/mudança.

§ 3º Este controle deve fazer parte do processo de liberação.

CAPÍTULO VIII

DA PROTEÇÃO DE DADOS PESSOAIS

Art. 17.  Os softwares ou componentes que façam tratamento de dados pessoais deverão seguir os requisitos da Lei nº 13.709/2018, Lei Geral de Proteção de Dados, e atender a pelo menos os seguintes princípios:

I – finalidade: realização do tratamento para propósitos legítimos, específicos, explícitos e informados ao titular, sem possibilidade de tratamento posterior de forma incompatível com essas finalidades;

II - adequação: compatibilidade do tratamento com as finalidades informadas ao titular, de acordo com o contexto do tratamento;

III - necessidade: limitação do tratamento ao mínimo necessário para a realização de suas finalidades, com abrangência dos dados pertinentes, proporcionais e não excessivos em relação às finalidades do tratamento de dados;

IV - livre acesso: garantia, aos titulares, de consulta facilitada e gratuita sobre a forma e a duração do tratamento, bem como sobre a integralidade de seus dados pessoais;

V - qualidade dos dados: garantia, aos titulares, de exatidão, clareza, relevância e atualização dos dados, de acordo com a necessidade e para o cumprimento da finalidade de seu tratamento;

VI - transparência: garantia, aos titulares, de informações claras, precisas e facilmente acessíveis sobre a realização do tratamento e os respectivos agentes de tratamento, observados os segredos comercial e industrial;

VII - segurança: utilização de medidas técnicas e administrativas aptas a proteger os dados pessoais de acessos não autorizados e de situações acidentais ou ilícitas de destruição, perda, alteração, comunicação ou difusão;

VIII - prevenção: adoção de medidas para prevenir a ocorrência de danos em virtude do tratamento de dados pessoais;

IX - não discriminação: impossibilidade de realização do tratamento para fins discriminatórios ilícitos ou abusivos e

X - responsabilização e prestação de contas: demonstração, pelo agente, da adoção de medidas eficazes e capazes de comprovar a observância e o cumprimento das normas de proteção de dados pessoais e, inclusive, da eficácia dessas medidas.

Art. 18.  O processo de desenvolvimento seguro de software deverá estar alinhado com os padrões da indústria:

I - Privacy By Design: assegura que a proteção de dados pessoais deverá ser estabelecida desde a concepção do software ou componente compreendendo todo o ciclo de vida, onde a equipe deverá realizar uma abordagem proativa na proteção de dados pessoais.

II - Privacy By Default: o software deverá resguardar a exposição de dados pessoais salvaguardando a privacidade, sendo o mais restritivo possível tanto na exposição/visualização de dados pessoais quanto na coleta.

Art. 19.  As vulnerabilidades que afetem dados pessoais terão prioridade sobre as demais, para as suas correções.

Art. 20.  Os componentes de terceiros que manuseiam dados pessoais devem passar por análise adicional, sendo inventariados e validados em sua conformidade com a proteção de dados pessoais, além de passar por testes de invasão específicos.

CAPÍTULO IX

DISPOSIÇÕES FINAIS

Art. 21.  Os casos omissos e eventuais dúvidas quanto à aplicação desta Portaria serão dirimidos pela Comissão de Segurança da Informação do Tribunal Regional Eleitoral de São Paulo.

Art. 22.  A STI elaborará, em até 120 dias, os procedimentos operacionais para aplicação desta Portaria que levem em conta as boas práticas de cibersegurança e os recursos tecnológicos disponíveis.

Art. 23.  Esta Portaria deverá ser revisada a cada 12 meses pela Gestora ou pelo Gestor de Segurança da Informação e encaminhada para nova apreciação da Comissão de Segurança da Informação (CSI)

Art. 24.  O descumprimento não fundamentado desta Portaria deve ser comunicado e registrado como incidente de segurança da informação pela Gestora ou pelo Gestor de Segurança da Informação e será objeto de apuração pela unidade competente do Tribunal com consequente aplicação das penalidades cabíveis a cada caso.

Art. 25.  Esta Portaria entra em vigor na data de sua publicação e sua implementação iniciará imediatamente e deverá estar totalmente implantada no prazo de 12 (doze) meses a contar desta data.

CLAUCIO CRISTIANO ABREU CORRÊA

DIRETOR-GERAL