Política de Segurança da Informação

1. Introdução e Objetivo

A SecureSt8 é uma startup de cibersegurança: nosso produto é, literalmente, a confiança de que sabemos proteger dados e sistemas. Isso significa que a segurança da informação não pode ser tratada como um documento formal guardado numa gaveta — ela precisa ser aplicado no nosso dia a dia, na forma como configuramos um servidor, no modo quando desenvolvemos uma nova aplicação, como respondemos a um e-mail suspeito ou como usamos uma ferramenta de IA para acelerar uma tarefa.

Esta Política estabelece as regras, papéis e controles mínimos de segurança da informação que se aplicam a todos que atuam em nome da SecureSt8. Ela foi construída sobre o NIST Cybersecurity Framework (CSF), a referência internacional mais usada para organizar programas de segurança, e considera as leis brasileiras aplicáveis ao nosso negócio, para que estejamos preparados tanto para operar com clientes exigentes quanto para sermos auditados por eles.

Por que isso importa para você, na prática:

• Nossos clientes vão nos auditar com o mesmo rigor (ou mais) que aplicamos a eles.
• Um incidente de segurança na SecureSt8 não é só um problema técnico — é a nossa credibilidade em jogo.
• Cada colaborador e terceiro é uma linha de defesa: a maioria dos incidentes começa em um erro humano evitável, não em uma falha sofisticada.

2. Papéis e Responsabilidades

• Liderança / Sócios: aprovam esta Política, garantem recursos para segurança e respondem por decisões estratégicas de risco.
• Responsável por Segurança da Informação (função exercida pela liderança técnica e atualmente dos próprios sócios-fundadores, podendo ser formalizada como CISO conforme crescimento da empresa): coordena a implementação dos controles, gestão de vulnerabilidades, resposta a incidentes e relacionamento com auditorias de clientes.
• Todos os colaboradores e terceiros: são responsáveis por seguir esta Política, proteger as credenciais e dispositivos sob sua responsabilidade e reportar imediatamente qualquer suspeita de incidente.
• Responsáveis técnicos por sistemas e produtos: garantem que os ambientes sob sua responsabilidade (nuvem, código, pipelines) sigam os controles definidos nos Capítulos 6 a 10.

3. Framework Adotado e Referencial Normativo

Organizamos nossos controles de segurança em torno das seis funções do NIST CSF 2.0. Isso facilita tanto a gestão interna quanto a comunicação com clientes e auditores que já conhecem o framework de referência.

Além do NIST CSF, observamos o seguinte marco legal e normativo, essencial por operarmos no Brasil e tratarmos dados de clientes:

4. Classificação da Informação

Todo dado ou documento que criamos, recebemos ou processamos deve ser tratado de acordo com um dos quatro níveis abaixo estabelecidos como critérios de classsificação de dados na nossa empresa. Na dúvida, trate a informação como Confidencial até confirmar o nível correto com seu gestor ou responsável pelo dado.

• Dados de clientes (achados de testes de segurança, credenciais, dados pessoais de usuários finais, arquitetura de sistemas) são, por padrão, Confidenciais ou Restritos — nunca Públicos ou Internos.
• Documentos devem indicar sua classificação no cabeçalho ou nome do arquivo sempre que possível (ex.: “CONFIDENCIAL — Relatório Pentest Cliente X”).

5. Governança de Riscos e Ativos (Identificar)

5.1 Inventário de ativos

• Mantemos um inventário atualizado de ativos críticos: contas de nuvem, repositórios de código, ferramentas SaaS, dispositivos corporativos e bases de dados de clientes.
• Todo novo sistema, ferramenta ou serviço que armazene ou processe dados de clientes deve ser registrado nesse inventário antes de entrar em uso.

5.2 Avaliação de riscos

• Realizamos internamente a avaliação de risco a cada novo projeto ou cliente, considerando o tipo de dado tratado, criticidade do ambiente e exigências contratuais específicas e aplicando todos os controles de segurança necessários e de acordo as definições com o cliente.
• Riscos identificados são registrados, priorizados e tratados (mitigados, aceitos formalmente pela liderança, transferidos ou evitados) — nunca simplesmente ignorados.

5.3 Gestão de risco de terceiros

• Fornecedores e ferramentas de terceiros que acessam dados de clientes passam por avaliação prévia de segurança, proporcional ao risco (ex.: onde os dados são armazenados, se há certificações de segurança, histórico de incidentes).
• Contratos com fornecedores críticos devem prever cláusulas de segurança, confidencialidade e direito de auditoria, quando aplicável.

6. Controle de Acesso (Proteger)

Controle de acesso é o controle mais explorado em incidentes reais — a maioria dos ataques bem-sucedidos começa com uma credencial fraca, reaproveitada ou obtida por engenharia social. Por isso, este é um dos capítulos mais rígidos desta Política.

6.1 Princípios gerais

• Menor privilégio: cada pessoa recebe apenas os acessos estritamente necessários à sua função, nunca por padrão “para garantir”.
• Segregação de funções: sempre que possível, quem solicita um acesso não é quem o aprova.
• Acesso nominal: é proibido compartilhar contas, senhas ou credenciais entre pessoas, inclusive entre colegas da mesma equipe.

6.2 Autenticação

• Autenticação multifator (MFA) é obrigatória em: e-mail corporativo, provedores de nuvem, repositórios de código, ferramentas de gestão de senhas e qualquer sistema que acesse dados de clientes.
• Senhas devem ter no mínimo 8 caracteres (ou usar frases-senha), ser únicas por sistema e armazenadas apenas em gerenciador de senhas corporativo aprovado — nunca em planilhas, blocos de notas ou papel.
• Credenciais de acesso a ambientes de clientes seguem, adicionalmente, qualquer exigência específica definida em contrato (ex.: cofres de senha do próprio cliente).

6.3 Ciclo de vida de acesso (admissão, mudança e desligamento)

• Admissão: acessos são concedidos somente após assinatura do NDA e conclusão do treinamento inicial de segurança na SecureSt8 (Capítulo 14).
• Mudança de função: acessos que não são mais necessários devem ser revogados no mesmo dia da mudança.
• Desligamento: todos os acessos (contas, VPN, repositórios, ambientes de clientes) devem ser revogados em até 24 horas do encerramento do vínculo, sob responsabilidade do gestor direto.
• Revisão periódica: acessos a sistemas críticos e ambientes de clientes são revisados a cada 90 dias para eliminar acessos órfãos ou excessivos.

6.4 Acesso privilegiado e remoto

• Contas administrativas (“root”, “admin”) são de uso exclusivo para tarefas que exigem privilégio elevado, nunca para uso diário — utiliza-se conta comum para atividades do dia a dia.
• Ações privilegiadas em ambientes de clientes são registradas em log e, quando exigido contratualmente, comunicadas previamente ao cliente e com controles sob custódia da senha.
• Acesso remoto a ambientes internos ou de clientes deve ocorrer apenas por conexões seguras (VPN corporativa ou equivalente aprovado), nunca por redes Wi-Fi públicas sem proteção adicional.

6.5 Acesso físico

• Dispositivos corporativos (notebooks, celulares) da SecureSt8 devem permanecer sob custódia do colaborador, com tela bloqueada automaticamente após período de inatividade e com cuidado sobre o uso seguro do dispositivo em ambientes externos.
• Impressão, fotografia ou anotação manual de dados Confidenciais ou Restritos de clientes é proibida fora de ambientes controlados.

7. Proteção de Dados e Criptografia (Proteger)

• Dados Confidenciais e Restritos devem ser criptografados em trânsito (TLS 1.2 ou superior) e em repouso (criptografia de disco e de banco de dados).
• Backups de dados de clientes seguem o mesmo nível de proteção dos dados originais, incluindo criptografia e controle de acesso restrito.
• Dados de clientes não são copiados para dispositivos pessoais, contas de nuvem pessoais ou pendrives sem autorização expressa da liderança de segurança e consentimento prévio do cliente.
• Ao final de um projeto ou quando não houver mais base legal/contratual para retenção, os dados são eliminados de forma segura e irreversível.

8. Uso Seguro de Inteligência Artificial

Como empresa de segurança que também usa IA generativa para ganhar produtividade, nós na SecureSt8, precisamos ser um exemplo de uso responsável para nossos clientes e sempre respeitando o conceito de security by design — o que entra em uma ferramenta de IA pode, sem os devidos cuidados, sair (ou ser usado para treinar modelos de terceiros) fora do nosso controle.

8.1 Regras gerais

• É proibido inserir dados Confidenciais ou Restritos de clientes (código-fonte de clientes, credenciais, achados de testes, dados pessoais) em ferramentas de IA generativa públicas ou não previamente aprovadas.
• Somente ferramentas de IA avaliadas e aprovadas pela liderança da SecureSt8 — com garantias contratuais de que os dados não são usados para treinamento de modelos de terceiros — podem ser usadas em tarefas que envolvam informações de clientes e sempre em alinhamento com as políticas e recomendações que possam ser definidas pelos nossos clientes.
• Ferramentas de IA de uso pessoal (contas gratuitas, não corporativas) nunca devem ser usadas para tarefas de trabalho envolvendo dados de clientes ou da SecureSt8.

8.2 Uso de IA em desenvolvimento e testes de segurança

• Saídas de ferramentas de IA usadas em código, relatórios ou análises de segurança devem sempre ser revisadas por um humano antes de serem entregues a um cliente — IA é um acelerador, não um substituto do julgamento técnico.
• Prompts e resultados gerados a partir de dados de clientes seguem a mesma classificação de sigilo dos dados originais (Capítulo 4).

8.3 Uso de IA em produtos da SecureSt8

• Funcionalidades de IA incorporadas aos produtos da SecureSt8 (ex.: nas soluções de exposure management e agentic security) devem ser documentadas quanto a quais dados processam, onde e por quanto tempo, para permitir avaliação de risco e resposta a perguntas de auditoria de clientes.
• Novos usos de IA que envolvam dados de clientes exigem avaliação prévia de risco e privacidade antes da entrada em produção.

9. Gestão de Vulnerabilidades (Detectar / Proteger)

9.1 Identificação de vulnerabilidades

• Realizamos varreduras de vulnerabilidade recorrentes em nossa própria infraestrutura, aplicações e endpoints, além de avaliar testes de segurança (pentests) periódicos programados, internos ou por terceiros independentes.
• Dependências de software (bibliotecas, pacotes) são monitoradas quanto a vulnerabilidades conhecidas (CVEs) de forma contínua.

9.2 Priorização e prazos de correção

Vulnerabilidades identificadas — em nossos próprios sistemas ou nos ambientes de clientes sob nossa responsabilidade — são classificadas por severidade, com os seguintes prazos-alvo de correção (SLA):

9.3 Gestão de patches

• Sistemas operacionais, aplicações e dependências críticas recebem atualizações de segurança dentro dos prazos definidos na tabela acima, priorizando ambientes expostos à internet.
• Mudanças emergenciais de segurança podem ser aplicadas fora da janela normal de mudanças, mediante aprovação simplificada da liderança técnica.

9.4 Divulgação responsável

• Vulnerabilidades identificadas em sistemas de clientes durante nossos serviços são reportadas exclusivamente ao cliente, de forma confidencial, nunca divulgadas publicamente sem autorização expressa e seguem o fluxo estabelecido contratualmente com o cliente.

10. Monitoramento e Detecção (Detectar)

• Mantemos registros (logs) de eventos de segurança relevantes — acessos, autenticações, alterações em sistemas críticos — por prazo mínimo compatível com obrigações legais e contratuais.
• Alertas de segurança (tentativas de acesso indevido, comportamento anômalo, uso incomum de credenciais) são monitorados e triados pela liderança de segurança na SecureSt8.
• Logs relacionados a ambientes de clientes seguem, adicionalmente, qualquer exigência específica definida em contrato quanto a retenção e acesso.

11. Resposta a Incidentes (Responder)

Um incidente de segurança é qualquer evento que comprometa a confidencialidade, integridade ou disponibilidade de dados ou sistemas — nossos ou de clientes. Todo colaborador e terceiro deve reportar suspeitas imediatamente à liderança de segurança, mesmo que não tenha certeza se configura um incidente.

11.1 Fases da resposta

11.2 Comunicação e obrigações legais

• Incidentes que envolvam dados pessoais são avaliados quanto ao risco aos titulares; quando o risco for relevante, a SecureSt8 comunica a Autoridade Nacional de Proteção de Dados (ANPD) e os titulares afetados em prazo razoável, conforme a LGPD.
• Clientes impactados por um incidente relacionado à prestação do nosso serviço são informados de forma transparente e no prazo (assim como fluxo de comunicação) definido em contrato (na ausência de prazo contratual, o mais breve possível).
• Toda comunicação externa sobre um incidente é feita apenas pela liderança da SecureSt8 — colaboradores não devem se manifestar sobre incidentes em nome da empresa.
• O canal interno de reporte de possíveis eventos que possam estar relacionados com incidentes na SecureSt8 é via canal csirt@securest8.com que será tratado internamente pela liderança para análise e tratamento adequado junto aos times responsáveis.

11.3 Reporte de boa-fé

• Quem reportar um incidente ou um erro próprio de boa-fé não sofre retaliação. Ocultar deliberadamente um incidente é falta grave, sujeita às medidas previstas no Código de Ética e Conduta da SecureSt8.

12. Continuidade e Recuperação (Recuperar)

• Sistemas e dados críticos (próprios e de clientes sob nossa custódia) possuem rotina de backup, com testes periódicos de restauração para garantir que os backups realmente funcionam.
• Backups são armazenados de forma segregada do ambiente de produção e protegidos com os mesmos controles de criptografia e acesso do Capítulo 7.
• Após qualquer incidente relevante, documentamos lições aprendidas e ajustamos controles, ferramentas ou treinamentos para reduzir a chance de recorrência.

13. Segurança em Desenvolvimento

• A SecureSt8 estabelece como prática básica entre seus colaboradores o conceito-base de security by design (segurança por padrão) na codificação e produtização das suas soluções onde queremos que nossos colaboradores partam deste princípio no desenho e entrega de soluções aos nossos clientes.
• Código-fonte é versionado em repositórios privados, com controle de acesso e revisão obrigatória (“code review”) antes de qualquer alteração ir para produção.
• Segredos (chaves de API, senhas, tokens) nunca são gravados diretamente no código-fonte; utilizam-se cofres de segredos ou variáveis de ambiente protegidas.
• Ambientes de desenvolvimento, teste e produção são segregados; dados reais de clientes não são usados em ambientes de teste sem anonimização ou autorização expressa.

14. Conscientização e Treinamento

• Todo colaborador e terceiro com acesso a sistemas ou dados passa por treinamento inicial de segurança da informação antes de receber suas credenciais internas.
• Reforços periódicos abordam temas como phishing, engenharia social e uso seguro de IA em eventos internos da SecureSt8.
• Simulações de phishing e outras práticas de conscientização podem ser realizadas para medir e melhorar a maturidade do time.

15. Conformidade, Auditoria e Penalidades

• Esta Política é parte das condições contratuais de colaboradores e terceiros da SecureSt8; seu descumprimento está sujeito às consequências previstas no Código de Ética, Conduta e Compliance da SecureSt8.
• A SecureSt8 se submete a auditorias de segurança solicitadas por clientes, dentro do escopo definido em contrato, e mantém evidências de conformidade com os controles descritos neste documento (registros, políticas assinadas, relatórios de vulnerabilidade, entre outros).
• Exceções a qualquer controle desta Política exigem aprovação formal e documentada da liderança de segurança, com prazo definido e plano de mitigação do risco assumido.

16. Governança e Atualização desta Política

• Esta Política é revisada, no mínimo, anualmente, ou sempre que houver mudança relevante na legislação, no framework adotado ou no perfil de risco da SecureSt8.
• Alterações são comunicadas a todos os colaboradores e terceiros vinculados, com nova ciência formal quando o conteúdo dos controles mudar de forma significativa.