Política de Resposta a Incidentes

1. Introdução

Este documento descreve a Política de Resposta a Incidentes do aplicativo DeskCamera. O DeskCamera é um aplicativo local de transmissão de tela desenvolvido para funcionar dentro da rede local do cliente. Ele não oferece serviços em nuvem, não armazena nem processa dados do usuário e não transmite nenhum conteúdo ao vivo para os servidores do DeskCamera.

2. Objetivo

Garantir que o DeskCamera tenha uma abordagem estruturada para identificar, gerenciar e resolver incidentes de segurança que possam afetar o desenvolvimento do software, a distribuição ou a infraestrutura de suporte.

3. Escopo

Abrange incidentes de segurança relacionados ao código-fonte do DeskCamera, pipeline de compilação, dependências de terceiros, sistemas de distribuição e ferramentas internas de desenvolvimento.

4. Tipos de Incidentes Abrangidos

  • Acesso não autorizado a repositórios de código
  • Comprometimento de certificados de assinatura ou do ambiente de compilação
  • Vulnerabilidades na cadeia de suprimentos (bibliotecas de terceiros)
  • Configurações incorretas que afetam a integridade dos instaladores distribuídos
  • Vulnerabilidades em ferramentas utilizadas durante o ciclo de vida de desenvolvimento de software (SDLC)

5. Papéis e Responsabilidades

  • CTO – Supervisiona o gerenciamento de incidentes e aprova ações críticas
  • Equipe de Desenvolvimento – Avalia detalhes técnicos, corrige o código e restaura os sistemas
  • Líder de Segurança – Coordena investigações, mantém registros e assegura a comunicação

6. Processo de Tratamento de Incidentes

6.1. Identificação

  • Monitoramento automatizado de CVEs (Common Vulnerabilities and Exposures) por meio de fontes de segurança
  • Revisões manuais de código e detecção de anomalias durante operações rotineiras

6.2. Avaliação

  • Classificação com base na gravidade (Crítico, Alto, Médio, Baixo)
  • Verificação se algum software distribuído foi afetado

6.3. Contenção e Mitigação

  • Revogação imediata de credenciais comprometidas
  • Isolamento dos ambientes ou pipelines afetados
  • Remoção ou correção de bibliotecas de terceiros afetadas

6.4. Recuperação

  • Restauração do ambiente limpo a partir de backups
  • Reassinatura dos builds com chaves limpas e verificadas
  • Reteste e revalidação da integridade dos instaladores liberados

7. Comunicação

  • Interna: Todos os incidentes são registrados e comunicados à gestão
  • Externa: Os clientes são informados em até 24 horas apenas se a integridade dos builds distribuídos ou dos mecanismos de atualização for comprometida

8. Revisão Pós-Incidente

  • Análise da causa raiz dentro de 5 dias úteis
  • Atualização dos procedimentos de segurança, se necessário
  • Relatório do incidente armazenado internamente e utilizado em treinamentos anuais de segurança

9. Revisão e Testes

  • Esta política é revisada anualmente pelo CTO
  • Testes internos simulados de resposta a incidentes são realizados periodicamente