Página traduzida e verificada automaticamente. Prevalece a versão em inglês. Algumas partes ainda estão em inglês enquanto a tradução é verificada. Ver em inglês · Informar um erro de tradução
O vocabulário, em linguagem simples
Cada termo traz o que ele é e por que um profissional deve se importar com ele. A segunda linha é a parte que o torna utilizável. Gratuito em todos os níveis, porque o vocabulário é a primeira barreira de entrada neste trabalho e a coisa errada a cobrar.
A B C D E F G H I J K L M N O P Q R S T V W Z
A
- Eficácia da certificação de acessos
-
A certificação de acessos é o processo periódico de revisar as contas ativas e suas permissões e tomar decisões deliberadas sobre se cada conta deve manter o acesso atual: confirmar que o acesso ainda é adequado, reduzir o escopo onde ele se tornou desproporcional e revogar o acesso que não é mais necessário.
a eficácia da certificação de acessos é importante para TPRM porque as certificações de acesso são frequentemente citadas como o principal controle de governança da gestão de acessos de fornecedores, como evidência de que os acessos são revisados periodicamente e confirmados como adequados.
- Eficácia da certificação de acessos: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias: taxa de revogação na certificação mais recente, não apenas a taxa de conclusão; confirmação de que a plataforma de certificação impede aprovações em massa; descrição do monitoramento da qualidade da certificação, adequação do tempo de revisão e distribuição das decisões.
- Configurações incorretas de políticas de acesso
-
Configurações incorretas de políticas de acesso são parâmetros de controle de acesso que não refletem corretamente o modelo de acesso pretendido para um sistema, recurso ou conjunto de dados no momento atual.
as configurações incorretas de políticas de acesso são relevantes para TPRM porque fornecedores que guardam dados de clientes podem ter políticas de acesso a armazenamento, bancos de dados e aplicações que foram configuradas corretamente para a sensibilidade original desses dados, mas não foram atualizadas à medida que os dados evoluíram.
- Configurações incorretas de políticas de acesso: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias verbais: ferramenta de CSPM e achados da varredura mais recente; processo que vincula a reclassificação de dados à revisão de políticas; documentação da frequência de revisão das políticas de acesso.
- Revisões de acesso
-
Uma revisão de acessos é uma verificação periódica de que as pessoas com acesso a um sistema ainda precisam dele, feita por alguém competente para julgar, sobre uma população que se pode demonstrar completa, com as revogações acompanhadas até a conclusão. É o controle que mais falha em trabalhos de asseguração, e falha de um modo incomum: a revisão acontece e mesmo assim não é aprovada.
toda estrutura a exige, todo auditor a amostra, e as quatro formas como ela falha são sempre as mesmas. A população era a exportação de um único sistema e deixou de fora os grupos, as contas de serviço e o caminho de suporte do fornecedor. O revisor aprovou quarenta nomes de direitos de acesso que não conseguia ler. Nada foi revogado, o que, após vários ciclos, significa que ninguém se envolveu. E as decisões foram registradas, mas as remoções nunca foram verificadas.
- Responsabilização
-
O Artigo 5(2) do GDPR exige que o controlador seja responsável pelo cumprimento dos princípios de proteção de dados e capaz de demonstrá-lo. A responsabilização não é mais um princípio entre os sete; é a obrigação de comprovar os outros seis. Documentação, registros, avaliações e políticas são a forma como essa comprovação é construída.
é por isso que a documentação é uma obrigação, e não uma boa prática. Uma organização que trata dados de forma lícita, mas não consegue demonstrar seu raciocínio, descumpriu o princípio da responsabilização e prestação de contas, mesmo que todos os outros princípios tenham sido atendidos. O bom comportamento não documentado é mal avaliado em uma investigação, porque o investigador não consegue distingui-lo da sorte.
- Decisões de adequação
-
Uma decisão de adequação é uma constatação da Comissão Europeia de que um país terceiro oferece um nível de proteção de dados essencialmente equivalente ao da UE, permitindo que dados pessoais sejam transferidos para lá sem nenhum mecanismo adicional de transferência. O Reino Unido, o Japão, a Suíça, o Canadá para organizações comerciais e os Estados Unidos no âmbito do Data Privacy Framework estão entre os abrangidos.
a adequação é conveniente e condicional. O Safe Harbour foi invalidado em 2015. O Privacy Shield foi invalidado em 2020. A cada vez, as transferências que se apoiavam na decisão perderam seu mecanismo da noite para o dia, e as organizações correram atrás de cláusulas contratuais padrão. O Data Privacy Framework já foi contestado, e a decisão do Reino Unido tem uma cláusula de caducidade que exige renovação.
- Ataques adversariais à IA
-
Os ataques adversariais são relevantes para TPRM porque os modelos de IA que os fornecedores implantam para decisões relevantes, como autenticação de documentos, verificação de identidade, detecção de fraudes e controle de qualidade, podem ter vulnerabilidades adversariais que as métricas padrão de acurácia em benchmarks não revelam.
os ataques adversariais são importantes para TPRM porque os modelos de IA que os fornecedores implantam para decisões relevantes (autenticação de documentos, verificação de identidade, detecção de fraudes, controle de qualidade) podem ter vulnerabilidades adversariais que as métricas padrão de precisão em benchmarks não revelam.
- Ataques adversariais à IA: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias verbais: tipos de ataque testados, como caixa-branca, caixa-preta e transferência; um fornecedor que confirma a acurácia em benchmarks de 97% deve ser questionado sobre a robustez adversarial. A acurácia em benchmarks descreve o desempenho em dados de teste padrão. A robustez adversarial descreve o desempenho em entradas projetadas especificamente para explorar o modelo. Ambas medem desempenho. Medem coisas diferentes.
- Exposição de chaves API de IA
-
A exposição de chaves API de IA é o risco de segurança criado quando credenciais que autenticam o acesso a APIs de modelos de IA, como chaves emitidas por portais de desenvolvedores de fornecedores de IA, endpoints de inferência e infraestrutura de disponibilização de modelos, são geradas, gerenciadas, armazenadas e usadas fora do programa de gestão de credenciais estabelecido pela empresa.
a exposição de chaves de API de IA importa para TPRM porque as relações da empresa com fornecedores de IA, cada vez mais numerosas à medida que a IA é incorporada às funções de negócio, geram uma população crescente de credenciais que autenticam o acesso a capacidades sensíveis de IA e podem expor o modelo do fornecedor aos padrões de consulta e aos dados da empresa.
- Exposição de chaves API de IA: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias verbais: inventário de chaves API ativas da organização; escopo de permissões de cada chave emitida; capacidade de alertar sobre uso anômalo de chaves.
- Expansão da superfície de ataque de IA
-
A expansão da superfície de ataque de IA é o crescimento da exposição agregada de dados e da vulnerabilidade de sistemas de uma empresa que ocorre à medida que vários fornecedores e ferramentas de IA são adotados ao longo do tempo, cada um avaliado individualmente como risco aceitável, mas que, em conjunto, criam uma superfície de risco maior do que a soma das avaliações individuais.
a expansão da superfície de ataque de IA é relevante para TPRM porque a empresa que avalia fornecedores de IA isoladamente pode deixar de ver o risco agregado criado por vários fornecedores de IA que, em conjunto, acessam diferentes elementos do mesmo universo de dados.
- Expansão da superfície de ataque de IA: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias: documentação do escopo de acesso individual a dados; consciência do contexto de exposição agregada; um fornecedor que confirma o escopo adequado de acesso a dados deve ser questionado sobre sua consciência da exposição agregada. O escopo individual é adequado para o acesso individual. A exposição agregada exige a visão combinada que as avaliações individuais não produzem.
- Viés de IA em decisões de risco
-
O viés de IA em decisões de risco é a distorção sistemática de avaliações de risco geradas por IA causada por vieses codificados nos dados de treinamento, em escolhas de desenho do modelo ou em ciclos de retroalimentação criados quando as saídas da IA influenciam dados de treinamento futuros.
o viés de IA em decisões de risco é relevante para TPRM porque a pontuação de risco de fornecedores baseada em IA conduz cada vez mais decisões relevantes sobre as relações com fornecedores, como a profundidade da diligência prévia, os termos contratuais, a intensidade do monitoramento e a classificação dos fornecedores em níveis.
- Viés da IA em decisões de risco: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias verbais: análise da intensidade das avaliações nos dados de treinamento; avaliação de impacto desproporcional entre grupos de fornecedores; um fornecedor que confirma a objetividade da IA deve ser questionado sobre a precisão entre grupos com características diferentes. A objetividade confirma consistência. A precisão entre grupos confirma que essa consistência reflete risco real, e não padrões históricos de avaliação.
- Aplicação da conformidade em IA
-
A aplicação da conformidade em IA é a capacidade operacional de garantir que as políticas de governança de IA, como requisitos de revisão, padrões de implantação e obrigações de monitoramento, sejam de fato aplicadas a todos os sistemas de IA que se enquadram no escopo da política, e não apenas aos sistemas apresentados para revisão pelos canais esperados.
a aplicação da conformidade em IA é relevante para TPRM porque fornecedores que alegam uma governança de IA abrangente devem ser avaliados pela cobertura da aplicação, ou seja, que fração de suas implantações de IA é de fato revisada pelo processo de governança, e não apenas pelo processo de governança em si.
- Aplicação da conformidade em IA: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias: inventário de IA com sistemas revisados vs. total de sistemas descobertos; integração da revisão de IA às compras de SaaS; um fornecedor que confirma ter um processo de governança de IA deve ser questionado sobre a cobertura de sua aplicação. O processo confirma o mecanismo de governança. A taxa de cobertura confirma quanto do parque de IA o mecanismo realmente alcança.
- Lacuna entre conformidade e segurança em IA
-
A lacuna entre conformidade e segurança em IA é a distinção entre a conformidade de um sistema de IA com regulamentações gerais de proteção de dados e de segurança, como GDPR para o manuseio de dados, SOC 2 para controles de segurança e ISO 27001 para a gestão da segurança da informação, e sua conformidade com os requisitos específicos que se aplicam a sistemas de IA que tomam decisões relevant
a lacuna entre conformidade e segurança em IA é relevante para TPRM porque a empresa que implanta o sistema de IA de um fornecedor em um caso de uso regulado herda as obrigações de conformidade desse caso de uso, independentemente de a documentação de conformidade do fornecedor cobrir essas obrigações.
- Lacuna entre conformidade e segurança em IA: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias verbais: exemplo de explicação individual nos termos do artigo 22; avaliação de alto risco segundo a Lei de IA da UE; um fornecedor que confirma conformidade com o GDPR deve ser solicitado a apresentar o exemplo de explicação do Artigo 22. A conformidade com o GDPR cobre o manuseio de dados. A conformidade com o Artigo 22 cobre a tomada de decisões automatizadas. O mesmo regulamento, obrigações diferentes.
- Continuidade e planejamento de saída em IA
-
O planejamento de continuidade e saída em IA é o conjunto de práticas que garantem que uma empresa consiga manter a continuidade dos negócios quando um modelo de IA de um fornecedor é descontinuado, um fornecedor sai do mercado ou uma relação comercial precisa ser encerrada, incluindo especificamente a preservação dos dados de treinamento, a documentação da calibração do modelo e da engenharia de vari
a continuidade e o planejamento de saída em IA são importantes para TPRM porque a dependência operacional de modelos de IA cria um risco de continuidade de negócios que não é tratado pelo planejamento de continuidade de negócios padrão.
- Continuidade e planejamento de saída em IA: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias verbais: compromisso de assistência na transição, incluindo dados de treinamento e engenharia de variáveis; portabilidade dos dados em formato reutilizável; um fornecedor que confirma um bom desempenho do modelo de IA deve ser questionado sobre o aviso de descontinuação e a assistência na transição. O desempenho confirma o valor da dependência. O aviso de descontinuação e a assistência na transição determinam o custo de desfazê-la sob pressão de tempo.
- Problemas de linhagem de dados em IA
-
A linhagem de dados de IA no contexto de operações de segurança descreve o caminho completo que sinais, alertas e inteligência de segurança percorrem desde sua geração pelos sistemas de detecção com IA até os processos de fluxo de trabalho, priorização, escalonamento e resposta que determinam como e quando as pessoas agem com base neles.
a linhagem de dados de IA nas operações de segurança é relevante para TPRM porque o resultado de segurança da implantação de monitoramento de segurança com IA de um fornecedor depende do caminho completo da detecção à resposta, e não apenas da capacidade de detecção da IA.
- Problemas de linhagem de dados em IA: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias verbais: tempo esperado entre a detecção e a investigação para alertas críticos fora do horário comercial; tempo médio de investigação como métrica acompanhada; processo de escalonamento fora do horário comercial para alertas críticos de IA.
- Riscos de retenção de dados em IA
-
Os riscos de retenção de dados de IA são os riscos de segurança, de conformidade e jurídicos decorrentes da retenção de dados que os usuários inserem em sistemas de IA, especificamente o risco de que informações sensíveis, regulamentadas ou protegidas por lei, carregadas em um assistente de IA, enviadas como consulta de IA ou tratadas por um pipeline de IA, sejam retidas nos sistemas do fornecedor de IA ou
os riscos de retenção de dados em IA são importantes para TPRM porque a adoção informal e rápida de ferramentas de IA em ambientes corporativos cria um risco sistemático de retenção para categorias de dados sensíveis (MNPI, dados pessoais, informações protegidas por sigilo profissional, dados de saúde regulados) que funcionários individuais enviam a assistentes de IA sem conhecimento específico d
- Riscos de retenção de dados de IA: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias: período de retenção do fornecedor para o nível atual; divulgação do período de retenção do provedor de LLM; compromisso de DPA com retenção zero ou configurável.
- Desafios de explicabilidade da IA
-
Os desafios de explicabilidade de IA importam para TPRM porque os requisitos legais e regulatórios de explicação de IA são significativamente mais exigentes do que o que as ferramentas atuais de explicabilidade fornecem automaticamente.
Os desafios de explicabilidade de IA importam para TPRM porque os requisitos legais e regulatórios de explicação de IA são significativamente mais exigentes do que o que as ferramentas atuais de explicabilidade fornecem automaticamente.
- Desafios de explicabilidade de IA: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias verbais: exemplo completo de explicação em linguagem simples para uma pessoa afetada; documentação da legitimidade das variáveis de maior contribuição; avaliação de conformidade com o padrão regulatório de explicação.
- Governança de IA
-
A governança de IA é o conjunto de decisões, responsáveis e registros que determinam quais sistemas de IA uma organização usa, o que cada um decide e sobre quem, quem o aprovou e que supervisão existe. Ela é distinta da segurança de IA no sentido de safety, que trata do comportamento dos próprios modelos, e da segurança de modelos, que trata dos ataques contra eles. A governança diz respeito ao uso que a organização faz.
pergunte a uma organização quantos sistemas de IA ela usa e a resposta estará errada em uma ordem de grandeza. Ela conta os dois modelos que a equipe de dados construiu e deixa de fora a funcionalidade do fornecedor que pontua chamados de suporte, a ferramenta de recrutamento que classifica candidatos e o assistente embutido em um produto que ninguém considerou como adoção de IA. A governança começa por saber o que está em uso, e a maioria dos programas começa por outro lugar.
- Estruturas de governança de IA
-
As lacunas no framework de governança de IA são as diferenças entre os processos documentados de governança de IA e sua implementação operacional: as reuniões de comitê que não ocorrem na frequência declarada, as revisões de modelo feitas na implantação inicial e ignoradas nas atualizações seguintes, e os programas de monitoramento que são descri
as lacunas nas estruturas de governança de IA são relevantes para TPRM porque a documentação de governança confirma a intenção do fornecedor.
- Frameworks de governança de IA: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias verbais: atas das três últimas reuniões do Comitê de Ética em IA; registros de revisão dos modelos nas atualizações mais recentes; confirmação de que a validação dos modelos se aplica às atualizações.
- Lacunas de governança de IA
-
As lacunas de governança de IA são as deficiências no framework de governança de IA de uma organização (políticas, processos, comitês de revisão e frameworks de conformidade) que resultam em sistemas de IA implantados ou mantidos em operação sem supervisão, transparência ou conformidade adequadas com os requisitos regulatórios aplicáveis.
as lacunas na governança de IA são relevantes para TPRM porque as obrigações de conformidade regulatória da empresa se aplicam aos sistemas de IA de fornecedores que executam funções reguladas nos fluxos de trabalho da empresa, independentemente de esses sistemas terem sido adquiridos em vez de desenvolvidos internamente.
- Lacunas na governança de IA: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias verbais: avaliação de alto risco segundo a Lei de IA da UE para os sistemas aplicáveis; um fornecedor que confirma maturidade em governança de IA deve ser questionado sobre o alinhamento regulatório atual. A maturidade da governança descreve o framework. A atualidade regulatória descreve se o framework reflete os regulamentos atualmente aplicáveis.
- Risco de alucinação de IA em decisões
-
No contexto de decisões relevantes tomadas por IA, o risco de alucinação vai além da confabulação de LLM e abrange a categoria mais ampla de decisões confiantes da IA baseadas em padrões que não refletem um raciocínio sólido, juridicamente defensável ou eticamente adequado.
o risco de alucinação de IA em decisões é relevante para TPRM porque a empresa que implanta a IA de decisões relevantes de um fornecedor herda a lógica de decisão do modelo, bem como as consequências jurídicas, regulatórias e reputacionais caso essa lógica seja considerada discriminatória, arbitrária ou juridicamente indefensável.
- Risco de alucinação de IA em decisões: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias: um fornecedor que confirma a explicabilidade deve ser questionado sobre o exemplo de explicação em linguagem simples e sobre a avaliação de discriminação por indicadores indiretos. A explicabilidade técnica identifica o que o modelo usou. A explicabilidade significativa conecta o que ele usou ao motivo pelo qual isso é uma razão legítima.
- Avaliações de impacto de IA
-
Uma avaliação de impacto de IA estabelece, para um sistema relevante, o que ele decide e sobre quem, o que pode dar errado para uma pessoa, e não para a empresa, como ele é classificado segundo a legislação aplicável e que supervisão e monitoramento existirão antes de ele entrar em operação. Seu resultado são decisões, não um documento, e ela está estreitamente relacionada ao relatório de impacto à proteção de dados, que frequentemente acompanha.
as avaliações chegam em dois formatos pouco úteis. Um questionário de segurança com a palavra IA acrescentada, que pergunta sobre criptografia sem dizer nada sobre contra quem o sistema decide. Ou um documento filosófico sobre equidade que não muda nada. A avaliação útil fica entre os dois e faz as duas perguntas que moldam tudo: o que o sistema decide, e sobre quem.
- Lacunas na resposta a incidentes de IA
-
As lacunas de resposta a incidentes de IA são as deficiências no programa de resposta a incidentes de uma organização que deixam os incidentes de decisões de modelos de IA (decisões prejudiciais da IA, falhas de modelos de IA, manipulação de sistemas de IA e violações da governança de IA) sem procedimentos de investigação definidos, requisitos de preservação de evidências, caminhos de escalonamento ou remediaç
as lacunas de resposta a incidentes de IA são importantes para TPRM porque produtos de IA de fornecedores que tomam decisões relevantes (crédito, seguros, emprego, decisões clínicas) acabarão produzindo decisões contestadas, investigadas ou levadas a litígio.
- Lacunas na resposta a incidentes de IA: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias verbais: playbook de incidentes de IA ou equivalente; caminho de escalonamento para especialistas externos em IA; um fornecedor que confirma uma capacidade abrangente de IR deve ser solicitado a apresentar seu playbook de incidentes de IA. A IR tradicional cobre incidentes de cibersegurança. A resposta a incidentes de IA cobre incidentes nas decisões dos modelos. Ambas são necessárias para implantações corporativas de IA.
- Vazamento de dados na inferência de IA
-
O vazamento de dados na inferência de IA é a exposição de dados presentes no ambiente de inferência de um modelo de IA (a janela de contexto, o prompt de sistema com geração aumentada por recuperação, as fontes de dados conectadas carregadas como contexto e os estados intermediários de processamento do modelo) à extração por meio de entradas do usuário, manipulação de prompts ou técnicas de canal lateral
o vazamento de dados na inferência de IA é importante para TPRM porque a configuração de retenção zero, embora necessária, não é suficiente para proteger os dados sensíveis que passam pelo ambiente de inferência de IA.
- Vazamento de dados na inferência de IA: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias verbais: descrição do conteúdo da janela de contexto, ou seja, o que é carregado no início da sessão; resultados de testes de injeção de prompt durante a sessão para extração de contexto; resultados de testes de confidencialidade do prompt de sistema.
- Registro de eventos e rastreabilidade de IA
-
O registro em log e a rastreabilidade de IA são a captura abrangente das informações necessárias para reconstruir a decisão de um sistema de IA a qualquer momento depois de tomada, especificamente a versão do modelo que tomou a decisão, os dados de entrada apresentados ao modelo no momento da decisão, as saídas intermediárias do modelo e a decis
o registro de eventos e a rastreabilidade de IA são relevantes para TPRM porque exames regulatórios, litígios e recursos contra decisões individuais exigem a capacidade de reconstruir decisões específicas de IA a partir de registros históricos.
- Registro e rastreabilidade em IA: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias verbais: demonstração da trilha de auditoria de decisões históricas; confirmação do registro das variáveis de entrada em cada momento; prazo de retenção dos logs de decisões.
- Uso indevido de IA por fornecedores
-
O uso indevido de IA por fornecedores abrange as formas pelas quais sistemas de IA implantados por fornecedores produzem resultados prejudiciais, injustos ou operacionalmente incorretos por causa de vieses nos dados de treinamento, escolhas de desenho do modelo e contextos de implantação que levam a IA a prejudicar sistematicamente segmentos específicos de clientes.
o uso indevido de IA por fornecedores é importante para TPRM porque os clientes da empresa interagem com os sistemas do fornecedor baseados em IA, e os resultados que esses sistemas produzem (priorização do suporte, classificação de serviços, roteamento de respostas) afetam os clientes da empresa, e não apenas os do fornecedor.
- Uso indevido de IA por fornecedores: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias verbais: resultados de auditoria de equidade por segmento de clientes; um fornecedor que confirma um bom desempenho da IA deve ser questionado sobre métricas específicas por segmento. O desempenho médio confirma que o sistema funciona para a média. As métricas por segmento revelam se ele funciona de forma consistente para todos.
- Cenários de uso indevido de IA
-
Os cenários de uso indevido de IA no contexto corporativo são situações em que ferramentas de IA aprovadas e implantadas para fins comerciais legítimos são usadas, ou agem por conta própria de forma autônoma, de maneiras que criam riscos jurídicos, éticos ou reputacionais não avaliados durante o processo de aprovação.
os cenários de uso indevido de IA são relevantes para TPRM porque ferramentas de IA de fornecedores aprovadas para funções legítimas podem ter capacidades, como coleta autônoma de dados, tomada de decisões automatizada e tratamento em escala, que criam riscos jurídicos e éticos não visíveis na avaliação de segurança, que se concentrou em como a ferramenta lida com os dados fornecidos pelo usuário.
- Cenários de uso indevido de IA: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias verbais: divulgação da capacidade de coleta autônoma de dados; base jurídica no GDPR para o tratamento de dados externos; orientações aos usuários sobre os requisitos de transparência.
- Risco da cadeia de suprimentos de modelos de IA
-
O risco da cadeia de suprimentos de modelos de IA é a categoria de riscos decorrentes da procedência, da composição e da integridade dos componentes que integram um modelo de IA, especificamente os dados de treinamento, a arquitetura do modelo de base, o processo de ajuste fino e a infraestrutura usada para desenvolver e implantar o modelo.
o risco da cadeia de suprimentos de modelos de IA importa para TPRM porque os produtos de IA que os fornecedores estão integrando aos fluxos de trabalho corporativos não são software tradicional: carregam informações sobre os dados com que foram treinados, podem se comportar de maneiras inesperadas quando entradas acionam vieses ou backdoors embutidos, e seu perfil de risco depende de u
- Risco da cadeia de suprimentos de modelos de IA: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias verbais: confirmação da opção de exclusão do uso em dados de treinamento e dos respectivos controles; a um fornecedor de IA que apresenta um relatório SOC 2 também devem ser pedidas as fichas de modelo, a procedência dos dados de treinamento e a avaliação de ataques de inferência. O SOC 2 cobre o invólucro operacional. A documentação do modelo cobre o risco da cadeia de suprimentos dentro dele.
- Controle de versões de modelos de IA
-
O risco de controle de versões de modelos de IA abrange os riscos de segurança e operacionais decorrentes da gestão das versões de modelos de IA em produção, especificamente os riscos criados quando atualizações de modelos de base, correções de segurança e revisões de modelos são adiadas, aplicadas de forma inconsistente ou não acompanhadas com o mesmo rigor do softwar
o controle de versões de modelos de IA é relevante para TPRM porque os produtos de IA que os fornecedores implantam em ambientes corporativos são construídos sobre cadeias de dependências, como modelos de base, infraestrutura de disponibilização e frameworks de ML, que exigem correções de segurança contínuas.
- Controle de versões de modelos de IA: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias: versão do modelo de base atualmente implantada vs. a mais recente disponível; atualização das correções de segurança, ou seja, correções pendentes e sua classificação de segurança; processo de validação acelerada para correções de segurança.
- Riscos operacionais de IA
-
Os riscos operacionais de IA são os riscos que surgem da implantação de sistemas de IA em contextos operacionais reais, em que as características de desempenho do modelo (precisão, modos de falha, níveis de confiança e vieses sistemáticos) interagem com as premissas dos processos de negócio, os níveis de supervisão humana e as consequências subsequentes de maneiras que criam op
os riscos operacionais de IA são relevantes para TPRM porque os processos de negócio que dependem de produtos de IA de fornecedores costumam ser desenhados com base em métricas agregadas de acurácia, e não em padrões sistemáticos de erro.
- Riscos operacionais de IA: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias verbais: relatórios de acurácia segmentados por tipo ou complexidade de caso; validação das premissas do processo de negócio em relação ao padrão de erros; cobertura do escopo de revisão humana nos segmentos com mais falhas.
- Vazamento de dados nas saídas de IA
-
O vazamento de dados nas saídas de IA, no contexto de produtos corporativos de IA, abrange duas dimensões de risco distintas. A primeira é o sentido tradicional de vazamento de dados: dados sensíveis do contexto da IA, do corpus de treinamento ou da base de conhecimento conectada aparecem em saídas acessíveis a partes não autorizadas.
o vazamento de dados nas saídas de IA é importante para TPRM porque os produtos de IA que os fornecedores implantam para profissionais do conhecimento nas empresas (assistentes de pesquisa, redatores de documentos, ferramentas de comunicação com clientes, aceleradores de análise) criam um risco sistemático de confabulação nos resultados que esses profissionais produzem.
- Vazamento de dados nas saídas de IA: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias verbais: avaliação da taxa de confabulação no domínio relevante; um fornecedor que confirma a qualidade da assistência de pesquisa com IA deve ser questionado sobre a avaliação da taxa de confabulação e a atribuição de fontes. A qualidade das saídas confirma que o processo de geração funciona. A avaliação da taxa de confabulação confirma com que frequência o que ele gera é preciso.
- Vulnerabilidades de plugins de IA
-
As vulnerabilidades de plugins de IA, no contexto de ferramentas de segurança baseadas em IA, são os pontos cegos estruturais e as limitações operacionais dos sistemas de detecção baseados em aprendizado de máquina; não são falhas na implementação da tecnologia, mas restrições inerentes ao funcionamento do aprendizado de máquina supervisionado, que criam lacunas sistemáticas entre as taxas de detecção public
as vulnerabilidades de plugins de segurança de IA são relevantes para TPRM porque o monitoramento de segurança baseado em IA é cada vez mais posicionado como a principal camada de detecção, substituindo ou reduzindo significativamente a revisão por analistas humanos.
- Vulnerabilidades de plugins de IA: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias verbais: escopo de cobertura de técnicas no conjunto de dados de teste; confirmação de cobertura de LOTL e de evasão adversarial; taxa de falsos positivos em produção em empresas comparáveis.
- Confiabilidade da pontuação de riscos de IA
-
A confiabilidade da pontuação de risco por IA é o grau em que uma pontuação de risco gerada por IA prevê com precisão o risco que afirma medir, e a disponibilidade dos metadados, dos dados de calibração e da quantificação de incerteza que permitem aos profissionais de risco avaliar se a pontuação merece confiança para a decisão específica que ela está sendo usada para s
a confiabilidade da pontuação de riscos de IA importa para TPRM porque pontuações de risco tratadas como confiáveis quando não são calibradas, quantificadas quanto à confiança nem acompanhadas em tendência produzem alocação de recursos sistematicamente incorreta: atenção demais a fornecedores com pontuação alta que não são realmente de alto risco, e de menos a fornecedores com pontuação baixa que são rea
- Confiabilidade da pontuação de risco por IA: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias verbais: dados de calibração por faixa de pontuação; intervalo de confiança ou quantificação da incerteza; tendência histórica da pontuação, com no mínimo seis meses.
- Monitoramento de segurança com IA
-
Um monitoramento de segurança de IA abrangente exige não apenas que o programa de monitoramento informe o que detecta, mas que preste contas com honestidade do que não detecta, de onde sua confiança na detecção é menor e de quais atividades de analistas humanos são necessárias para compensar as limitações da IA.
o monitoramento abrangente da segurança de IA importa para TPRM porque a garantia de segurança que os relatórios de monitoramento oferecem depende de esses relatórios representarem com precisão tanto as capacidades quanto as limitações do programa.
- Monitoramento de segurança por IA: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias verbais: divulgação das lacunas de cobertura nos relatórios de monitoramento; divulgação da variação de confiança por categoria de alerta; a um fornecedor que entrega relatórios semanais de monitoramento por IA deve ser pedido que acrescente uma seção de limitações. As métricas de desempenho descrevem o que está funcionando. A divulgação das limitações descreve o que as métricas de desempenho não mostram. Ambas são necessárias para um relatório honesto de monitoramento de segurança.
- Lacunas nos testes de segurança de IA
-
Lacunas nos testes de segurança de IA são as omissões no programa de testes de segurança de um fornecedor que deixam o próprio modelo de IA (em contraste com a infraestrutura, a aplicação e os controles operacionais ao seu redor) sem testes contra as categorias específicas de ataque às quais os sistemas de IA são vulneráveis.
as lacunas nos testes de segurança de IA são relevantes para TPRM porque as evidências de garantia de segurança que os fornecedores apresentam para produtos de IA frequentemente cobrem de forma abrangente as dimensões tradicionais de segurança, deixando as dimensões de segurança específicas de IA completamente sem avaliação.
- Lacunas nos testes de segurança de IA: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias verbais: evidências de testes de segurança específicos de IA, como entradas adversariais e injeção de prompt; resultados de exercícios de red team de IA; um fornecedor que apresenta evidências de SOC 2, testes de intrusão e SDLC deve ser solicitado a apresentar evidências de testes específicos de IA como uma categoria separada. As evidências tradicionais cobrem o invólucro. Os testes de IA cobrem o modelo. Ambos são necessários.
- Dependências da cadeia de suprimentos de IA
-
As dependências da cadeia de suprimentos de IA são as bibliotecas de código aberto, os componentes de modelos pré-treinados, os utilitários de processamento de dados e os pacotes de frameworks de ML que compõem a pilha de software sobre a qual um sistema de IA é construído, e por meio dos quais ataques à cadeia de suprimentos podem comprometer o sistema de IA sem atacar o próprio modelo.
As dependências da cadeia de suprimentos de IA são relevantes para TPRM porque a segurança do sistema de IA do fornecedor é limitada pela segurança de cada componente da sua pilha de dependências, e não apenas pela arquitetura do modelo e pelo processo de treinamento.
- Dependências da cadeia de suprimentos de IA: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias verbais: SBOM do pipeline de IA com todas as dependências de ML; cobertura da ferramenta de SCA para todas as dependências de IA; formato de serialização do modelo e confirmação de carregamento seguro.
- Lacunas na detecção de ameaças de IA
-
As lacunas na detecção de ameaças de IA são as categorias de técnicas, padrões de ataque e comportamentos de agentes de ameaça que uma plataforma de monitoramento de segurança baseada em IA não detecta, seja porque a cobertura de detecção dessas categorias nunca foi configurada, seja porque os dados de treinamento da IA não incluíam exemplos representativos dessas técnicas, seja
as lacunas na detecção de ameaças de IA importam para TPRM porque painéis de detecção totalmente verdes são frequentemente apresentados como evidência de cobertura abrangente, e aceitos como tal pelas equipes de TPRM que revisam a postura de segurança dos fornecedores.
- Lacunas na detecção de ameaças de IA: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias verbais: prazo entre a inteligência e a configuração para alertas recentes; mapa de cobertura ATT&CK atualizado no último trimestre; confirmação de detecção ativa para técnicas específicas apontadas pelo ISAC.
- Avaliação de fornecedores de IA
-
Avaliar um fornecedor cujo produto inclui IA acrescenta perguntas que a revisão de segurança padrão não faz. O que o sistema decide, e sobre quem. Com quais dados ele foi treinado, em um nível de descrição com o qual o fornecedor se comprometa. Que informações de desempenho ele publica, e para quais populações. Que supervisão o produto permite, e a quais registros você pode ter acesso. Respostas que você não consegue obter são achados.
quase toda IA chega dentro de produtos de fornecedores, então a maioria das organizações está avaliando o modelo de outra pessoa com visibilidade limitada. O questionário padrão estabelece se o fornecedor criptografa dados e revisa acessos. Não estabelece se a classificação feita pela ferramenta de recrutamento foi alguma vez medida em candidatos com mais de cinquenta anos, e essa é a pergunta que o regulador fará a você, não ao fornecedor.
- Riscos de dependência de fornecedores de IA
-
Os riscos de dependência de fornecedores de IA surgem quando a dependência operacional de uma empresa em relação ao modelo de IA de um fornecedor específico se torna tão profunda que os custos de troca, em tempo, esforço de recalibração, redesenho de fluxos de trabalho e interrupção operacional, se tornam proibitivos.
a dependência de fornecedores de IA é relevante para TPRM porque dependências profundas de IA criam um risco de concentração que pode não ser visível até que uma interrupção force uma migração.
- Riscos de dependência de fornecedores de IA: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias verbais: prazo contratual de aviso de descontinuação de API; um fornecedor que confirma um bom desempenho da IA deve ser questionado sobre seu prazo de aviso de descontinuação e o apoio à migração. O desempenho confirma o valor da dependência. O apoio à migração e o prazo de aviso determinam o custo de desfazê-la.
- Riscos de segurança da revisão de código assistida por IA
-
a segurança da geração de código por IA é importante para TPRM porque a adoção de assistentes de programação com IA nos fluxos de desenvolvimento dos fornecedores pode estar introduzindo padrões de vulnerabilidade que as ferramentas de segurança existentes não estão configuradas da melhor forma para detectar.
a segurança da geração de código por IA é importante para TPRM porque a adoção de assistentes de programação com IA nos fluxos de desenvolvimento dos fornecedores pode estar introduzindo padrões de vulnerabilidade que as ferramentas de segurança existentes não estão configuradas da melhor forma para detectar.
- Riscos de segurança da revisão de código assistida por IA: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias verbais: divulgação da adoção de assistentes de programação com IA e da respectiva governança; avaliação da cobertura de SAST para padrões gerados por IA; monitoramento da variação na taxa de achados desde a adoção.
- Riscos da automação baseada em IA
-
Os riscos da automação orientada por IA são as consequências operacionais, jurídicas e reputacionais que surgem quando fluxos autônomos de IA executam decisões e ações em escala sem integração adequada com todo o contexto operacional, sem supervisão humana apropriada dos casos-limite e sem restrições que limitem a ação autônoma a s
Os riscos da automação baseada em IA importam para TPRM porque fornecedores que usam automação com IA em fluxos de trabalho que afetam a empresa (gestão de contratos, comunicações com clientes, faturamento, relatórios de conformidade) podem produzir erros operacionais em massa que afetam os clientes, os parceiros e as relações regulatórias da empresa.
- Riscos da automação baseada em IA: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias verbais: revisão prévia à execução para comunicações em massa; um fornecedor que confirma o desempenho da automação com IA deve ser questionado sobre a completude da integração de dados e a revisão prévia à execução. As métricas de desempenho refletem o que a automação faz corretamente dentro do seu escopo. A completude da integração e as etapas de revisão limitam o que ela faz incorretamente em escala.
- Fadiga de alertas entre ecossistemas
-
A fadiga de alertas é a degradação da qualidade da análise que resulta de volumes elevados de alertas que superam a capacidade analítica disponível por alerta.
a fadiga de alertas é importante para TPRM porque a qualidade do SOC do fornecedor é a proteção do cliente contra ameaças aos seus dados, e a qualidade do SOC em condições de alto volume de alertas é significativamente menor do que a qualidade do SOC com um volume de alertas controlado.
- Fadiga de alertas entre ecossistemas: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias verbais: volume de alertas por analista por turno; taxa de falsos positivos por categoria de alerta; implantação de automação SOAR e impacto no volume de alertas.
- Lacunas na priorização de alertas
-
As lacunas na priorização de alertas são os desalinhamentos entre as severidades estáticas atribuídas aos alertas e o contexto dinâmico de risco que torna técnicas específicas mais ou menos perigosas conforme o cenário atual de ameaças. Os níveis de severidade dos alertas são atribuídos quando as regras são escritas, com base no perfil geral de risco da técnica naquele momento.
as lacunas na priorização de alertas são importantes para TPRM porque a velocidade de resposta do SOC a um alerta específico é determinada pelo seu nível de severidade, e um nível de severidade que não reflete o contexto atual de ameaças produz velocidades de resposta calibradas para um cenário de ameaças que já não existe.
- Lacunas na priorização de alertas: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias verbais: confirmação do fluxo entre a inteligência de ameaças e a priorização; atualização recente de severidade motivada pela inteligência de ameaças; um fornecedor que confirma SLAs de alerta definidos deve ser questionado se as atribuições de severidade que encaminham os alertas para esses SLAs são atualizadas com base na inteligência de ameaças atual. Os SLAs medem o cumprimento. As atribuições de severidade determinam se o cumprimento está calibrado para a ameaça atual.
- Testes de viés algorítmico
-
Os testes de viés medem se as saídas de um sistema diferem entre grupos de pessoas de maneiras relevantes, por exemplo, se as taxas de erro, as taxas de aprovação ou as pontuações variam conforme uma característica protegida ou um indicador indireto dela. Ninguém precisa ter a intenção de criar a diferença para que ela exista. Um modelo treinado com decisões históricas aprende os padrões dessas decisões, inclusive aqueles que ninguém defenderia.
é a medição que a maioria das avaliações alega fazer e poucas realizam. O desempenho medido no agregado pode ser excelente enquanto o desempenho para um grupo é ruim, e os números agregados escondem exatamente a constatação que um regulador ou um reclamante apresentará. As obrigações da Lei de IA da UE para sistemas de alto risco e a função Medir do framework NIST pressupõem que você consiga produzir os números por grupo.
- Técnicas de anonimização
-
As técnicas de anonimização incluem a agregação, que informa totais em vez de indivíduos; a generalização, que substitui valores precisos por faixas; a supressão, que remove valores raros; a adição de ruído, que perturba os valores; e a privacidade diferencial, que limita o que qualquer consulta pode revelar sobre qualquer indivíduo. Cada uma reduz o risco de reidentificação de forma diferente e com um custo diferente em utilidade.
o teste jurídico é se a reidentificação é razoavelmente provável por qualquer meio, inclusive pela combinação com outros conjuntos de dados. Um conjunto de dados que parece anônimo isoladamente pode ser reidentificado ao ser cruzado com um cadastro eleitoral, um perfil em rede social ou uma violação anterior. Os dados auxiliares são o que torna a reidentificação possível, e eles não estão sob o controle do controlador.
- Biblioteca de respostas
-
O conjunto de respostas aprovadas para perguntas de segurança recorrentes dos compradores, cada uma com suas evidências, responsável e data de revisão.
As perguntas dos compradores se repetem muito. No terceiro questionário, a maioria já tem uma resposta aprovada, e o trabalho passa de redigir para revisar.
Ensinado em TPR-260 · Veja também: Central de confiança, Atestação
- Fragilidades de autenticação de API
-
A autenticação de API é o conjunto de mecanismos pelos quais uma API verifica se a parte solicitante é quem afirma ser e se está autorizada a fazer a solicitação que está fazendo.
A autenticação de API é o controle que estabelece a fronteira de confiança entre a sua organização e a plataforma do fornecedor.
- Fragilidades de autenticação de API: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias verbais: documentação do prazo de expiração e do processo de rotação de tokens, com um prazo e um processo, não uma declaração de política; documentação dos escopos OAuth específicos da integração, os escopos efetivamente usados, não os disponíveis; confirmação de que o escopo do teste de intrusão de API inclui explicitamente a avaliação do mecanismo de autenticação.
- Uso indevido de identidades de API
-
Identidades de API são as credenciais (chaves de API, segredos de cliente, tokens OAuth e tokens de autenticação semelhantes legíveis por máquina) usadas por aplicações, integrações e processos automatizados para se autenticar em APIs e plataformas.
o uso indevido de identidades de API é relevante para TPRM porque as chaves de API são o principal mecanismo pelo qual aplicações de fornecedores e parceiros de integração acessam as plataformas dos clientes, e a gestão do ciclo de vida dessas chaves determina se o acesso que elas concedem permanece dentro do escopo pretendido ou se sobrevive a ele e o ultrapassa.
- Uso indevido de identidades de API: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias verbais: inventário de chaves API com datas de último uso e aplicações associadas; confirmação de varredura de repositórios com os resultados da última varredura; descrição do monitoramento de uso, ou seja, como o uso inesperado de chaves é detectado.
- Testes de segurança de API em CI/CD
-
os testes de segurança de API são relevantes para TPRM porque as APIs que os fornecedores corporativos expõem para integrações, como APIs REST, endpoints GraphQL e receptores de webhooks, são pontos de acesso aos dados e às funcionalidades do fornecedor que exigem testes de segurança específicos de API para serem avaliados de forma eficaz.
os testes de segurança de API são relevantes para TPRM porque as APIs que os fornecedores corporativos expõem para integrações, como APIs REST, endpoints GraphQL e receptores de webhooks, são pontos de acesso aos dados e às funcionalidades do fornecedor que exigem testes de segurança específicos de API para serem avaliados de forma eficaz.
- Testes de segurança de API em CI/CD: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias verbais: ferramenta e cobertura de testes de segurança específicos de API; casos de teste de BOLA e abordagem de testes com múltiplos usuários; documentação de cobertura do OWASP API Top 10.
- Exposição de IA baseada em API
-
A exposição de IA baseada em API é o risco de dados e de segurança criado quando o produto de IA de um fornecedor usa um LLM API de terceiros, como o GPT-4 da OpenAI, o Claude da Anthropic, o Gemini do Google ou o Azure OpenAI, como mecanismo de inferência subjacente, fazendo com que os dados corporativos enviados ao produto do fornecedor circulem pela infr do provedor terceiro de LLM
a exposição de IA baseada em API é relevante para TPRM porque a rápida adoção de produtos de fornecedores baseados em LLM criou uma nova classe de risco de quartas partes que a maioria dos programas de TPRM ainda não tratou de forma sistemática.
- Exposição de IA baseada em API: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias verbais: divulgação do backend de LLM, com provedor e nível de serviço; cobertura de DPA sobre o tratamento de dados pelo provedor de LLM; confirmação de assinatura do plano corporativo com termos reforçados.
- Registro em log e rastreabilidade de aplicativos
-
O registro de eventos de aplicações em um contexto de segurança é a captura sistemática de eventos relevantes para a segurança: eventos que permitem detectar ataques em andamento, investigar incidentes após o fato e demonstrar o cumprimento das obrigações de controle de acesso e de manuseio de dados.
o registro de eventos de aplicações em ambientes de fornecedores é relevante para TPRM por dois motivos distintos, frequentemente confundidos, mas com implicações de governança diferentes.
- Registro de eventos e rastreabilidade de aplicações: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias verbais: resposta afirmativa à pergunta do cenário de sessenta dias, com confirmação específica do registro de acessos a dados e da capacidade de atribuição de identidade; documentação da política de retenção de logs que mostre o período de retenção e o requisito ao qual ele está calibrado; confirmação do registro de eventos de acesso a dados na camada de aplicação, com atribuição da identidade do usuário.
- Segurança de registros de artefatos
-
A segurança de registros de artefatos é relevante para TPRM porque os artefatos de software que sua empresa recebe dos fornecedores são distribuídos por meio de registros cuja postura de segurança determina se o artefato que você baixa é o artefato que o fornecedor publicou.
a segurança de registros de artefatos é relevante para TPRM porque os artefatos de software que sua empresa recebe dos fornecedores são distribuídos por meio de registros cuja postura de segurança determina se o artefato que você baixa é o artefato que o fornecedor publicou.
- Segurança de registros de artefatos: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias verbais: registros de revisão de acesso ao registro de artefatos e lista atual de contas; integração do ciclo de vida de identidades ao acesso ao registro; um fornecedor que confirma a assinatura de artefatos deve ser questionado sobre a imutabilidade e os controles de acesso do registro. A assinatura confirma o artefato no momento da publicação. A imutabilidade garante que o artefato baixado é o artefato publicado. Os controles de acesso determinam quem pode substituir um artefato mutável.
- Asseguração versus certificação
-
Um SOC 2 é uma asseguração: uma firma de CPA emite uma opinião sobre a afirmação da administração a respeito de seus controles, segundo uma norma de asseguração. A ISO 27001 é uma certificação: um organismo de certificação acreditado certifica que um sistema de gestão está em conformidade com uma norma publicada, após uma auditoria contra os requisitos dessa norma. Os termos descrevem mecanismos diferentes, resultados diferentes e reguladores diferentes.
os compradores pedem uma certificação e recebem um atestado, ou o inverso, e nenhuma das partes percebe até que uma cláusula contratual seja posta à prova. Um SOC 2 não pode ser renovado como um certificado; um certificado ISO não contém controles testados como um relatório.
- Asseguração versus validação
-
Asseguração é a confiança profissional, expressa por um terceiro independente, de que um sistema de controles está operando de acordo com critérios definidos, com base em evidências coletadas por meio de métodos estruturados de avaliação.
a diferença entre asseguração e validação é importante para TPRM porque os riscos específicos que os relacionamentos com clientes criam (os dados particulares que expõem, os padrões de acesso particulares que permitem, os cenários de ataque mais relevantes) frequentemente não estão dentro dos critérios dos frameworks de conformidade que fornecem a principal asse
- Asseguração versus validação: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias verbais: confirmação de se o cenário específico foi testado nas avaliações existentes; consentimento para testes de validação direcionados nos cenários não validados; resultados de testes anteriores, se o cenário tiver sido avaliado.
- Tempo de permanência de ataques via fornecedores
-
O tempo de permanência de ataques via fornecedores é importante para TPRM porque a exposição dos dados do cliente não começa quando o atacante entra no ambiente do cliente, mas quando o atacante obtém acesso a qualquer ambiente no caminho da cadeia de suprimentos até os dados do cliente.
o tempo de permanência de ataques por meio de fornecedores é relevante para TPRM porque a exposição dos dados do cliente começa não quando o atacante entra no ambiente do cliente, mas quando ele obtém acesso a qualquer ambiente no caminho da cadeia de suprimentos até os dados do cliente.
- Tempo de permanência de ataques via fornecedores: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias verbais: MTTD empírico com base em incidentes reais; origem da detecção, comparando SOC interno e notificação externa; maior tempo de permanência em incidentes recentes.
- Asseguração
-
Uma declaração que uma organização faz sobre si mesma, às vezes assinada por um diretor, em contraste com uma certificação emitida por um organismo externo.
Sua credibilidade depende inteiramente da disciplina por trás dela, e uma alegação que não pode ser sustentada falha de três formas: com compradores, seguradoras e reguladores.
Ensinado em TRS-210 · Veja também: Central de confiança, Biblioteca de respostas
- Asseguração e certificação
-
Uma certificação é emitida por um organismo externo acreditado com base em um esquema definido, como a ISO 27001, após uma auditoria, e pode ser verificada junto ao emissor. Uma atestação é uma declaração sobre si mesmo, às vezes assinada por um diretor e às vezes acompanhada de um exame independente, como em um relatório SOC 2, em que um auditor atesta a descrição feita pela administração. As palavras são usadas de forma intercambiável em conversas comerciais e significam coisas diferentes em uma disputa.
os compradores perguntam se você é certificado, e a resposta honesta para muitos programas sólidos é que eles possuem um relatório de asseguração, não um certificado. Seguradoras, reguladores e áreas de compras corporativas percebem essa distinção. Afirmar ter certificação quando se possui uma asseguração é uma declaração falsa, e um comprador competente a identifica na primeira conversa.
- Qualidade das evidências de auditoria
-
A qualidade das evidências de auditoria é o grau em que as evidências apresentadas para um controle de segurança demonstram de fato o que se afirma que demonstram: que o controle está implementado, operando de forma eficaz e aplicado a todos os sistemas e usuários relevantes, e não apenas que uma configuração existe em uma captura feita em um determinado momento.
a qualidade das evidências é relevante para TPRM porque a garantia oferecida por uma avaliação concluída é tão forte quanto as evidências que a sustentam.
- Qualidade das evidências de auditoria: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias verbais: confirmação de cobertura, com todas as funções confirmadas ou uma captura de tela abrangente da política; confirmação de atualidade, demonstrando que a evidência representa o estado atual; preferência por resultados de conformidade automatizados em vez de capturas de tela manuais.
- Limitações de escopo das auditorias
-
As limitações de escopo de uma auditoria são os limites do que ela examinou, testou e sobre o que concluiu e, por implicação, do que a auditoria não examinou, não testou ou sobre o que não chegou a conclusões.
as limitações de escopo das auditorias são relevantes para TPRM porque relatórios SOC 2, certificados ISO 27001 e outros relatórios de auditoria de terceiros são a principal evidência da eficácia dos controles em avaliações de fornecedores, e todos eles têm limitações de escopo que afetam o que as conclusões do relatório sustentam validamente.
- Limitações do escopo da auditoria: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias: divulgação de problemas conhecidos de qualidade de controles durante o período auditado; descrição de mudanças significativas após o período; seção de exceções e resposta da administração no relatório mais recente.
- Independência do auditor
-
O auditor de serviços deve ser independente dos controles que examina. As normas de asseguração proíbem o auditor de projetar, implementar ou operar os controles, porque um auditor que construiu o controle não pode opinar com credibilidade sobre seu funcionamento. A independência é uma condição prévia para que a opinião tenha algum valor.
isso explica por que seu auditor não vai redigir suas políticas, não vai dizer exatamente qual controle implementar e vai responder a uma pergunta sobre remediação com uma descrição do critério, e não com uma solução. Uma firma que oferece tanto consultoria de preparação quanto a auditoria deve manter as duas atividades em equipes separadas, e muitas se recusam a fazer as duas para o mesmo cliente.
- Decisões automatizadas
-
O Artigo 22 do GDPR dá às pessoas o direito de não ficarem sujeitas a uma decisão tomada exclusivamente com base em tratamento automatizado, incluindo a definição de perfis, que produza efeitos jurídicos ou efeitos igualmente significativos sobre elas. Quando tais decisões são permitidas, por contrato, por lei ou por consentimento explícito, a pessoa tem direito à intervenção humana, a manifestar seu ponto de vista e a contestar a decisão.
decisões de crédito, triagens de contratação, precificação de seguros e bloqueios por fraude envolvem cada vez mais modelos, e o ser humano no circuito costuma ser apenas nominal. Um revisor que aprova tudo o que o modelo recomenda, a um ritmo de centenas por dia, não está intervindo. A decisão é, em substância, exclusivamente automatizada, diga o que disser o diagrama do processo.
B
- Testes de backup
-
Um backup é uma cópia. Uma restauração é a prova de que a cópia pode se tornar um sistema funcional dentro do prazo que você prometeu. Testar backups significa realizar a restauração, conforme um cronograma, para um destino definido, verificar o resultado e registrar o que aconteceu. A maioria das organizações executa backups. Muito menos organizações já restauraram um em condições minimamente parecidas com as de uma falha real.
os backups são o controle sobre o qual toda estrutura pergunta e toda seguradora pergunta, e a garantia que a maioria das organizações oferece é que a rotina de backup foi concluída. Uma rotina concluída prova que a cópia foi gravada. Não prova nada sobre se a cópia é legível, completa, atual ou restaurável dentro do objetivo, e o ransomware transformou a diferença entre um backup e uma restauração na diferença entre uma interrupção e o fechamento da empresa.
- Proteção de branches e contornos da revisão de código
-
Os desvios da proteção de ramificações importam para TPRM porque representam a distância entre os controles da cadeia de suprimentos de software que um fornecedor documentou e os controles efetivamente aplicados na prática.
os contornos da proteção de branches são relevantes para TPRM porque representam a distância entre os controles da cadeia de suprimentos de software que um fornecedor documentou e os controles efetivamente aplicados na prática.
- Contornos da proteção de branches e da revisão de código: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias verbais: configuração de proteção de branches, incluindo a cobertura de administradores; lista de acessos administrativos aos repositórios e data da última revisão; monitoramento dos logs de auditoria para commits diretos em branches protegidas.
- Desafios na atribuição de violações
-
A atribuição de violações é o processo de determinar quem conduziu um ataque específico: o agente de ameaça, sua motivação, sua afiliação organizacional e suas próximas ações prováveis.
os desafios na atribuição de violações são importantes para TPRM porque a resposta do cliente a uma violação em um fornecedor não deve ficar parada à espera de uma atribuição definitiva por parte da investigação forense do fornecedor.
- Desafios de atribuição de violações: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias verbais: fatos técnicos confirmados, separados da atribuição, como cronologia de acesso, sistemas e tipos de dados; TTPs observadas na investigação, independentemente da atribuição; avaliação preliminar de escopo independente da atribuição.
- Notificação de violações
-
O GDPR exige que o controlador notifique a autoridade de controle sobre uma violação de dados pessoais em até 72 horas após tomar conhecimento dela, a menos que seja improvável que a violação resulte em risco para as pessoas. Quando o risco for elevado, as pessoas afetadas também devem ser informadas sem demora injustificada. Os operadores devem notificar seus controladores sem demora injustificada.
a ciência vem antes da confirmação. As equipes esperam ter um quadro completo antes de notificar e perdem o prazo, quando o regulamento permite expressamente a notificação em fases: uma notificação inicial com o que se sabe, seguida de informações complementares à medida que a investigação avança. As 72 horas valem para o primeiro contato, não para o relatório final.
- Lacunas nas simulações de violação
-
As lacunas de simulação de violação são as diferenças entre o que um exercício de simulação de violação testa e o que um incidente de segurança real exige, especificamente a diferença entre uma simulação roteirizada e cooperativa, em que a equipe de IR é informada de cada etapa, e uma violação real, em que a detecção é ambígua, o escopo é incerto, o atacante está ativo e se ad
as lacunas nas simulações de violação são relevantes para TPRM porque o relatório de simulação que confirma a capacidade de IR segundo critérios definidos pode estar testando um conjunto de capacidades diferente daquele que uma violação real exige.
- Lacunas na simulação de violações: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias: metodologia de simulação, roteirizada vs. com foco em detecção; histórico de exercícios de equipe roxa ou com fogo real; MTTD e MTTC obtidos em exercícios adversariais.
- Carta-ponte carta de lacuna
-
Uma declaração de uma organização prestadora de serviços que cobre o período entre o fim do seu relatório de asseguração mais recente e a data de hoje.
É uma declaração da administração, não a opinião de um auditor: nenhum controle foi testado nesse período. Uma carta-ponte que ultrapassa cerca de seis meses geralmente indica que o próximo relatório está atrasado.
Ensinado em TPR-210 · Veja também: Tipo I e Tipo II, Organização subcontratada
- Cartas-ponte
-
Uma carta-ponte, às vezes chamada de carta de lacuna, cobre o tempo entre o fim do período de observação de um relatório e a data em que um cliente o está lendo. Ela declara que não ocorreram mudanças relevantes no ambiente de controle desde o fim do período. É redigida e assinada pela administração do fornecedor.
os relatórios são sempre históricos. Se o período terminou em setembro e agora é fevereiro, cinco meses estão descobertos, e a carta-ponte é a forma usual de tratar essa lacuna sem esperar o próximo relatório.
- Falhas de controle de acesso em aplicações de fornecedores
-
A falha de controle de acesso é a incapacidade de uma aplicação de aplicar corretamente as regras que determinam quais usuários autenticados podem acessar quais recursos, executar quais ações e ver quais dados.
o controle de acesso falho em uma aplicação de fornecedor é especialmente perigoso da perspectiva de risco de terceiros, porque pode expor os dados da sua organização a outros clientes da mesma plataforma, e expor você aos dados de outros clientes de formas que geram responsabilidade regulatória independentemente da intenção.
- Controle de acesso falho em aplicativos de fornecedores: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias: documentação do escopo do teste de intrusão que inclua explicitamente testes de IDOR e cenários de escalonamento de privilégios; confirmação de testes de isolamento entre locatários para aplicações multilocatário, com evidência da metodologia; confirmação da aplicação da autorização no lado do servidor, não controle de acesso na camada de UI, e sim no lado do servidor.
- Validação da integridade do build
-
A validação da integridade da compilação é o conjunto de controles que verificam a confiabilidade do processo de produção de artefatos: a cadeia de evidências, do código-fonte revisado ao binário implantado, que demonstra que cada etapa da compilação foi executada como esperado, por sistemas autorizados, com as entradas pretendidas e sem modificação não autorizada
a integridade do build é o controle que trata da lacuna que a assinatura de código deixa aberta: a lacuna entre “o artefato foi assinado com a chave do fornecedor” e “o artefato é uma representação fiel do código-fonte revisado”. Para profissionais de TPRM, é nessa lacuna que operam os ataques à cadeia de suprimentos de maior impacto.
- Validação da integridade do build: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias verbais: atestados de procedência SLSA ou referências a logs de transparência para as versões recentes; confirmação dos arquivos de lock de dependências com política de verificação de digest; descrição do isolamento do ambiente de build, com ambientes efêmeros ou equivalentes.
- Integridade do pipeline de build
-
A integridade do pipeline de build é relevante para TPRM porque o fornecedor de software cujo pipeline é comprometido produz software comprometido, independentemente da robustez dos seus controles de segurança em produção.
a integridade do pipeline de compilação importa para TPRM porque o fornecedor de software cujo pipeline é comprometido produz software comprometido, independentemente de quão fortes sejam seus controles de segurança de produção.
- Integridade do pipeline de build: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias verbais: inventário de integrações de terceiros em CI/CD com o escopo das credenciais; geração e nível de procedência SLSA; um fornecedor que confirma a segurança do ambiente de produção deve ser questionado sobre a segurança do pipeline de build. Os controles do ambiente de produção protegem o que está em execução. Os controles do pipeline de build protegem a forma como foi construído. O ataque à SolarWinds contornou os primeiros comprometendo os segundos.
- Acordo de associado comercial BAA
-
O contrato que a HIPAA exige entre uma entidade abrangida e qualquer pessoa que trate informações de saúde protegidas em seu nome, estendendo-se aos subcontratados.
Assiná-lo traz obrigações legais diretas, incluindo a comunicação de incidentes dentro de um prazo e a devolução ou destruição dos dados ao final, que uma certificação de segurança não abrange.
Ensinado em PRV-203 · Veja também: Termos do operador, Informações de saúde protegidas
- Análise de impacto nos negócios
-
Uma análise de impacto nos negócios determina, para cada serviço ou processo, o que acontece ao longo do tempo se ele ficar indisponível: quais clientes são afetados, que receita deixa de entrar, que obrigações são descumpridas e em que ponto o dano se torna inaceitável. Seus resultados são os objetivos de recuperação por serviço e uma ordem de prioridade do que restaurar primeiro quando tudo falha ao mesmo tempo.
objetivos de recuperação copiados de um modelo não protegem nada, e planos de continuidade que tratam todos os serviços como igualmente urgentes restauram a wiki enquanto os pagamentos estão fora do ar. A BIA é a etapa que produz os números dos quais todo o resto da continuidade depende, e é a etapa mais frequentemente substituída por uma planilha de palpites.
C
- CAIQ
-
O Consensus Assessments Initiative Questionnaire é o conjunto padrão de perguntas da Cloud Security Alliance, mapeado para a sua Cloud Controls Matrix. Foi concebido para provedores de serviços em nuvem, e muitos publicam um questionário preenchido em um registro público, o que significa que boa parte dos seus fornecedores de nuvem já o respondeu antes de você perguntar.
é o conjunto padrão com maior probabilidade de já existir para um fornecedor de SaaS ou de infraestrutura, por isso é a primeira coisa a procurar antes de redigir um questionário próprio. Ele também aparece quando um comprador pede um a você, e nesse momento ter um CAIQ atualizado e preenchido na sua central de confiança elimina uma categoria de solicitações.
- Declarações de escopo da certificação
-
Uma declaração de escopo da certificação é a frase no certificado, ou na descrição do sistema do relatório, que diz o que foi de fato examinado: quais produtos, quais ambientes, quais locais, quais entidades. Tudo o que a certificação afirma se aplica dentro dessa frase e nada fora dela. Um comprador que lê certificados lê a declaração de escopo antes do logotipo.
o SOC 2 Tipo II sem ressalvas de um fornecedor cobria sua plataforma principal. O comprador usava um produto mais novo do mesmo fornecedor, lançado após o período de observação e não mencionado na descrição do sistema. O relatório era preciso, sem ressalvas e irrelevante para a compra, e ninguém percebeu porque a verificação consistia em confirmar que existia um relatório.
- Gestão de mudanças sob CC8
-
O CC8 exige que as mudanças em infraestrutura, dados, software e procedimentos sejam autorizadas, projetadas, desenvolvidas, testadas, aprovadas e implementadas de forma controlada. É o critério que pergunta se as coisas chegam à produção de forma deliberada.
o caminho normal de mudanças costuma ser bem controlado, porque é projetado, documentado e usado todos os dias. O caminho emergencial é onde ele falha. Algo está fora do ar, uma correção é necessária agora, a aprovação usual é pulada, e uma semana depois ninguém encontra o registro. Os auditores sabem disso e selecionam deliberadamente mudanças emergenciais para amostragem.
- Convite para Charter Practitioner
-
Olá,
- Dados de crianças
-
O GDPR fixa em dezesseis anos a idade a partir da qual uma criança pode dar consentimento a serviços da sociedade da informação, permitindo que os Estados-membros a reduzam para treze, e a maioria a fixou em algum ponto intermediário. O tratamento de dados de uma criança com base no consentimento abaixo dessa idade exige autorização dos pais ou responsáveis. Códigos como o Age Appropriate Design Code do Reino Unido impõem obrigações de design a serviços com probabilidade de serem acessados por crianças, independentemente do público pretendido.
serviços não direcionados a crianças ainda assim as atraem, e “não é o nosso público” não é uma avaliação. O teste é se é provável que crianças acessem o serviço, e uma plataforma de uso geral sem verificação de idade provavelmente será acessada por crianças. As obrigações decorrem dessa probabilidade.
- Revisões de acesso e desprovisionamento de CI/CD
-
As revisões de acesso de CI/CD são importantes para TPRM porque contas órfãs de CI/CD são caminhos de acesso ao ambiente do pipeline que existem sem justificativa de negócio ativa. A conta de um ex-funcionário é uma credencial que pode ter sido comprometida por phishing ou roubo de credenciais sem que nenhum funcionário ativo perceba a atividade suspeita.
As revisões de acesso de CI/CD são importantes para TPRM porque contas órfãs de CI/CD são caminhos de acesso ao ambiente do pipeline que existem sem justificativa de negócio ativa.
- Revisões de acesso e desprovisionamento CI/CD: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias verbais: integração do ciclo de vida de identidades ao desligamento de funcionários; processo de desprovisionamento de contas de serviço e de contas de fornecedores; inventário de acessos CI/CD com justificativa e responsável.
- Registro de auditoria e observabilidade de CI/CD
-
o registro de auditoria de CI/CD é importante para TPRM porque a capacidade do fornecedor de investigar um comprometimento da cadeia de suprimentos ou um incidente de segurança em seu pipeline depende da qualidade e da retenção da sua trilha de auditoria de CI/CD.
o registro de auditoria de CI/CD é importante para TPRM porque a capacidade do fornecedor de investigar um comprometimento da cadeia de suprimentos ou um incidente de segurança em seu pipeline depende da qualidade e da retenção da sua trilha de auditoria de CI/CD.
- Registro de auditoria e observabilidade CI/CD: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias verbais: prazo de retenção dos logs de auditoria do CI/CD; armazenamento externo imutável para os logs de auditoria; completude dos eventos, com o contexto capturado junto aos eventos de implantação.
- Falhas na gestão de credenciais CI/CD
-
a gestão de credenciais de CI/CD é relevante para TPRM porque determina o raio de impacto, no pior cenário, do comprometimento de um pipeline. O fornecedor cujo pipeline usa uma única conta de serviço com credenciais de implantação em produção tem, a partir de qualquer comprometimento do pipeline, um raio de impacto equivalente a acesso total à produção.
a gestão de credenciais de CI/CD importa para TPRM porque determina o raio de impacto, no pior cenário, de um comprometimento do pipeline.
- Falhas na gestão de credenciais CI/CD: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias verbais: confirmação ou roteiro de implementação do Workload Identity; isolamento das credenciais de produção apenas para as etapas de implantação; auditoria das contas de serviço quanto ao escopo das credenciais.
- Segurança da plataforma de CI/CD: riscos do GitHub Actions e do GitLab CI
-
Ação da comunidade: aprovado na v2.1. Atualizado para a v2.2: nova funcionalidade.
a segurança da plataforma de CI/CD é relevante para TPRM porque as actions e os componentes executados nos pipelines de CI/CD dos fornecedores são código de terceiros executado com as credenciais do pipeline: o mesmo modelo de ameaça das dependências de aplicações, aplicado à infraestrutura de build em vez de à própria aplicação.
- Segurança da plataforma de CI/CD: riscos do GitHub Actions e do GitLab CI: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias verbais: implementação da fixação por SHA nos arquivos de workflow; lista de actions aprovadas ou restrições de publicadores; um fornecedor que confirma a segurança do CI/CD deve ser questionado sobre a fixação de actions e a governança de aprovação. A fixação de dependências da aplicação controla qual código roda na aplicação. A fixação de actions controla qual código roda no pipeline que gera a aplicação.
- Segurança de CI/CD para setores regulados
-
A segurança de CI/CD em setores regulados é relevante para TPRM porque as certificações de conformidade em setores regulados podem não refletir a conformidade do pipeline de CI/CD se o escopo da certificação não incluiu uma avaliação rigorosa dos requisitos específicos de CI/CD.
a segurança de CI/CD em setores regulados é relevante para TPRM porque as certificações de conformidade em setores regulados podem não refletir a conformidade do pipeline de CI/CD se o escopo da certificação não incluiu uma avaliação rigorosa dos requisitos específicos de CI/CD.
- Segurança de CI/CD para setores regulados: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias verbais: mapeamento do pipeline de CI/CD para os requisitos regulatórios; resultados da avaliação de lacunas e status da remediação; evidências de conformidade dos controles específicos de CI/CD.
- Arquitetura de segurança de rede em nuvem
-
A arquitetura de segurança de rede em nuvem é importante para TPRM porque a migração para a nuvem frequentemente transfere as cargas de trabalho das aplicações para a infraestrutura em nuvem sem transferir a disciplina de segurança de rede que regia o ambiente local.
a arquitetura de segurança de rede em nuvem é relevante para TPRM porque a migração para a nuvem frequentemente transfere cargas de trabalho de aplicações para a infraestrutura em nuvem sem transferir a disciplina de segurança de rede que regia o ambiente local.
- Arquitetura de segurança de rede em nuvem: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias verbais: resultados de auditoria de grupos de segurança com 0.0.0.0/0; um fornecedor que confirma segurança em nuvem deve ser questionado sobre a configuração dos grupos de segurança. Os grupos de segurança em nuvem são o principal controle de segurança de rede em ambientes de nuvem. 0.0.0.0/0 em portas de gerenciamento expõe as instâncias a toda a internet, independentemente dos controles de segurança na camada de aplicação.
- Segurança em nuvem
-
A segurança em nuvem, no contexto de risco de terceiros, não diz respeito principalmente à infraestrutura do provedor de nuvem; essa parte está em grande medida resolvida. O risco real está em como sua organização configurou o ambiente de nuvem e em como os fornecedores têm permissão para operar dentro dele.
quando um fornecedor opera dentro do seu ambiente de nuvem, o modelo tradicional de risco de terceiros (avaliar controles, receber asseguração, arquivar o relatório) deixa de funcionar quase por completo.
- Segurança em nuvem: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias verbais: um conjunto de permissões documentado e defensável para a função de nuvem do fornecedor, e não uma captura de tela de AdministratorAccess; evidências de CSPM ou ferramenta equivalente aplicada aos ambientes que ele gerencia; um processo definido para notificar os clientes sobre mudanças de configuração feitas em seu ambiente.
- Falhas de isolamento de cargas de trabalho em nuvem
-
O isolamento de cargas de trabalho na nuvem é o conjunto de mecanismos técnicos que impedem que uma carga de trabalho (uma aplicação, um processo, um contêiner, uma máquina virtual) acesse a memória, o armazenamento, o tráfego de rede ou o contexto de execução de outra carga de trabalho executada na mesma infraestrutura subjacente.
o isolamento de cargas de trabalho é a garantia técnica que sustenta os ambientes multitenant dos fornecedores.
- Falhas de isolamento de cargas de trabalho em nuvem: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias verbais: confirmação de que contêineres privilegiados são proibidos ou rigorosamente controlados nos ambientes de produção; um SLA de correção definido para vulnerabilidades críticas no runtime de contêineres, idealmente de 24 a 72 horas para CVEs críticas; documentação do escopo dos testes de intrusão que confirme a inclusão de cenários de isolamento de cargas de trabalho.
- A assinatura de código e seus limites
-
Os limites da assinatura de código são relevantes para TPRM porque empresas que exigem assinatura de código como controle de segurança da cadeia de suprimentos podem ter uma falsa sensação de garantia sobre a autenticidade de softwares assinados.
os limites da assinatura de código são relevantes para TPRM porque empresas que exigem assinatura de código como controle de segurança da cadeia de suprimentos podem ter uma falsa sensação de garantia sobre a autenticidade de softwares assinados.
- A assinatura de código e seus limites: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias verbais: confirmação de HSM ou de proteção equivalente das chaves; um fornecedor que confirma a assinatura de código deve ser questionado sobre a proteção das chaves e os logs de transparência. A verificação da assinatura confirma que a chave assinou o artefato. A proteção das chaves impede o comprometimento. Os logs de transparência detectam o comprometimento. Os três são necessários para uma garantia significativa da assinatura de código.
- Práticas de assinatura de código
-
A assinatura de código é citada com frequência em avaliações de segurança de fornecedores como evidência da integridade dos artefatos e da segurança da distribuição. Para profissionais de TPRM, os ataques à 3CX e à SolarWinds demonstram que um artefato assinado com a chave legítima de um fornecedor ainda pode ser malicioso se o ambiente de build que o produziu tiver sido comprometido.
a assinatura de código é frequentemente citada nas avaliações de segurança de fornecedores como evidência da integridade dos artefatos e da segurança da distribuição.
- Práticas de assinatura de código: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias verbais: confirmação do armazenamento das chaves de assinatura, baseado em HSM ou em armazenamento equivalente resistente a adulteração; controles de acesso ao pipeline automatizado de assinatura, com a chave de assinatura inacessível a desenvolvedores individuais; atestados de procedência SLSA ou documentação equivalente da procedência dos builds.
- Frameworks comuns de controles
-
Uma estrutura comum de controles é um único conjunto de controles que descreve o que sua organização realmente faz, com um identificador estável para cada um, mapeado para fora, para cada estrutura em relação à qual você é avaliado. Em vez de um conjunto de controles SOC 2, um conjunto de controles ISO e um conjunto de controles HITRUST mantidos por três equipes, um único conjunto de trinta a oitenta controles atende aos três, e cada evidência é produzida uma única vez.
a segunda estrutura é onde o custo do programa dobra, e não deveria. A maior parte do que SOC 2, ISO 27001, NIST CSF e HITRUST exigem é a mesma prática subjacente expressa de formas diferentes: acesso concedido de forma deliberada e revisado, mudanças aprovadas, incidentes tratados, fornecedores avaliados. As diferenças estão na ênfase e nas expectativas de evidência, não no que você faz na segunda-feira.
- Controles compensatórios
-
Um controle compensatório é uma medida alternativa adotada quando um controle exigido não pode ser implementado conforme especificado, por uma restrição real e documentada. Ele precisa atender à intenção do requisito original e oferecer rigor comparável, e a justificativa precisa ser registrada por escrito de forma que um avaliador possa testá-la. É mais trabalho do que a conformidade, não menos.
todo framework tem requisitos que algumas organizações não conseguem cumprir literalmente. Um sistema legado que não suporta autenticação multifator, um fornecedor que não pode assinar determinada cláusula, um processo que o texto de um regulador pressupõe e que o seu negócio não tem. O controle compensatório é o caminho legítimo para contornar cada um deles, e também é o caminho mais usado de forma abusiva para pular algo inconveniente.
- Controles complementares nos contratos
-
Os CUECs descrevem o que um cliente deve fazer para que os controles do fornecedor sejam eficazes. Cada vez mais, os contratos com fornecedores fazem referência direta aos CUECs, tornando sua implementação pelo cliente uma obrigação contratual, e não uma recomendação em um anexo.
se uma violação tiver origem em um controle que o relatório do fornecedor listou como responsabilidade do cliente, o fornecedor apontará para essa lista e para o contrato que a incorpora. A seção CUEC se tornou discretamente o documento que decide quem teve culpa.
- Controles complementares da organização subcontratada
-
Os controles complementares da organização subprestadora de serviços, CSOCs, são os controles que a empresa auditada presume que sua organização subprestadora executa. Segurança física do data center. Isolamento entre tenants no hipervisor. Descarte seguro de hardware. Eles são declarados no relatório e não são testados por ninguém nele.
Os CUECs empurram a responsabilidade para você, o cliente. Os CSOCs a empurram para o provedor que está por trás do fornecedor. Juntas, as duas listas descrevem tudo o que a opinião do relatório não cobre, e ler ambas é a única forma de entender sobre o que a opinião de fato é uma opinião.
- Controle complementar da entidade usuária CUEC
-
Um controle que a organização prestadora de serviços presume que seu cliente opera, listado no relatório de asseguração e no qual se apoia a opinião do auditor.
É uma obrigação que recai sobre você. Uma opinião sem ressalvas significa que o serviço é seguro se você fizer a sua parte, e o relatório diz qual é a sua parte.
Ensinado em TPR-215 · Veja também: Organização subprestadora de serviços, Tipo I e Tipo II
- Controles complementares da entidade usuária (CUECs)
-
Os controles de um fornecedor só funcionam se você fizer a sua parte, e os CUECs são a sua parte, descrita pelo fornecedor. São os controles que o fornecedor presume que você opera para que o ambiente dele seja seguro: exigir MFA dos usuários que você cria, revisar os acessos que você concedeu, definir o valor de retenção, manter suas próprias chaves API fora do controle de código-fonte. Eles ficam em uma seção do relatório SOC 2 que a maioria dos leitores pula.
um relatório SOC 2 é uma evidência sobre o fornecedor. A lista de CUEC é a única parte dele que diz respeito a você, e o auditor não testou nada dela, porque foi contratado pelo fornecedor e não tem visibilidade do seu lado. Cada CUEC é um controle pelo qual o fornecedor recusou a responsabilidade, por escrito, e a devolveu a você.
- Lacunas na automação da conformidade
-
As plataformas de automação de conformidade (Drata, Vanta, Secureframe e ferramentas semelhantes) automatizam a coleta de evidências de conformidade, o monitoramento da eficácia dos controles e a avaliação da prontidão para certificações de segurança.
as lacunas na automação da conformidade são relevantes para TPRM porque o monitoramento automatizado da conformidade é cada vez mais citado pelos fornecedores como evidência da eficácia contínua dos controles.
- Lacunas na automação da conformidade: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias: inventário do escopo de integração da plataforma de conformidade; confirmação da situação de integração das inclusões recentes; confirmação do alinhamento do escopo da descrição do sistema SOC 2.
- Lacuna entre conformidade e segurança
-
Conformidade é o estado de adequação a um conjunto definido de requisitos (uma norma, um regulamento, um framework) para um escopo definido em um determinado momento. Segurança é a resistência contínua a ameaças reais em toda a superfície de ataque.
a distinção entre conformidade e segurança é relevante para TPRM porque as certificações de conformidade são as evidências de terceiros mais usadas em avaliações de segurança de fornecedores, e elas têm sistematicamente as limitações descritas.
- Lacuna entre conformidade e segurança: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias verbais: inventário de sistemas adjacentes fora do escopo com conectividade ao ambiente no escopo; log de mudanças posteriores à avaliação com análise de impacto na conformidade; identificação de lacunas de escopo e avaliação compensatória.
- Conformidade como código em CI/CD
-
A conformidade como código é importante para TPRM porque as certificações de conformidade pontuais (relatórios PCI DSS QSA, relatórios de auditores SOC 2, certificações ISO 27001) descrevem com precisão o estado de conformidade no momento da auditoria, mas não conseguem confirmar o estado atual se tiver passado um tempo significativo.
a conformidade como código é relevante para TPRM porque as certificações de conformidade pontuais, como relatórios PCI DSS QSA, relatórios de auditor SOC 2 e certificações ISO 27001, descrevem com precisão o estado de conformidade no momento da auditoria, mas não conseguem confirmar o estado atual de conformidade se tiver decorrido um tempo significativo.
- Conformidade como código em CI/CD: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias verbais: implementação de conformidade como código e cobertura de estruturas; detecção e alerta de desvios de conformidade; um fornecedor que confirma uma certificação de conformidade deve ser questionado sobre o monitoramento contínuo desde a certificação. A certificação confirma a conformidade no momento da auditoria. O monitoramento contínuo de conformidade confirma que o estado de conformidade foi mantido. Ambos são necessários para uma garantia de conformidade atual.
- Risco de concentração
-
Exposição criada quando muitos dos seus serviços dependem do mesmo provedor, região, empresa ou infraestrutura de pagamentos.
Alguma concentração é racional; a obrigação é conhecê-la e planejar-se para ela. Nove fornecedores independentes em uma mesma região de nuvem falham juntos.
Ensinado em TPR-250 · Veja também: Quarta parte
- Acesso condicional: a lacuna entre a política e a aplicação efetiva
-
As lacunas de acesso condicional são relevantes para TPRM porque o contorno por autenticação legada enfraquece a exigência de MFA, que é a principal defesa contra o roubo de credenciais.
as lacunas no acesso condicional importam para TPRM porque o contorno por autenticação legada enfraquece o requisito de MFA, que é a principal defesa contra o roubo de credenciais.
- Lacunas no acesso condicional
-
O acesso condicional é um modelo de política de segurança em que as decisões de acesso são tomadas com base em vários sinais contextuais, e não apenas no êxito da autenticação.
as lacunas de acesso condicional são relevantes para TPRM porque determinam se os controles de acesso que regem como os empregados do fornecedor e seus próprios usuários internos acessam dados sensíveis são realmente sensíveis ao risco ou apenas superficialmente conformes.
- Lacunas no acesso condicional: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias verbais: documentação do requisito de conformidade dos dispositivos, com inscrição no MDM obrigatória para acessos sensíveis; inventário dos sinais de acesso condicional, com todas as condições avaliadas nas políticas de acesso; política de acesso a partir de dispositivos pessoais, com proibição explícita para acesso à produção.
- Consentimento
-
O consentimento segundo o GDPR deve ser livre, específico, informado e inequívoco, manifestado por uma ação afirmativa clara, e tão fácil de revogar quanto foi de dar. O controlador deve ser capaz de demonstrar que ele foi obtido. O consentimento agrupado com os termos de serviço, obtido por meio de caixas pré-marcadas ou imposto como condição para um serviço que não precisa dele não é válido.
o consentimento é a base mais exigente, e aquela cujos modos de falha são mais visíveis. Um regulador pode olhar um formulário de cadastro e ver se a caixa vinha pré-marcada. Um único consentimento que cobre várias finalidades distintas não atende ao requisito de especificidade. Um consentimento que não pode ser revogado sem ligar para uma central de atendimento não atende ao requisito de revogação.
- Plataforma de gestão de consentimento CMP
-
O componente que retém as tags de publicidade e de análise até que o visitante faça sua escolha e, então, libera apenas as categorias aceitas.
As falhas quase nunca estão no texto do banner. Estão nas tags disparadas antes da escolha, o que transforma o banner em teatro.
Ensinado em PRV-230 · Veja também: Global Privacy Control, Transparency and Consent Framework (estrutura de transparência e consentimento)
- Registros de consentimento
-
Um controlador que se baseia no consentimento deve ser capaz de demonstrar que o titular dos dados consentiu. Isso significa um registro de quem consentiu, quando, com o que especificamente, por qual mecanismo e qual texto lhe foi exibido naquele momento. O registro deve sobreviver a mudanças no texto, porque o consentimento obtido sob uma versão não cobre finalidades acrescentadas em uma versão posterior.
o texto muda. Os avisos de privacidade são revisados, finalidades são acrescentadas, e um consentimento obtido em 2021 para e-mails de marketing passa a ser usado como base para uma criação de perfis que nem existia na época. Um registro que capta apenas o fato do consentimento não consegue mostrar o que ele abrangia, e um regulador o tratará como se não abrangesse nada além do que pode ser comprovado.
- Cadeia de suprimentos de imagens de contêiner
-
O risco da cadeia de suprimentos de imagens de contêiner é relevante para TPRM porque o software entregue em contêineres inclui toda a pilha de software do fornecedor, incluindo bibliotecas do sistema e componentes do sistema operacional, e não apenas o código da aplicação.
o risco da cadeia de suprimentos de imagens de contêiner é relevante para TPRM porque o software entregue em contêineres inclui toda a pilha de software do fornecedor, incluindo bibliotecas do sistema e componentes do sistema operacional, e não apenas o código da aplicação.
- Cadeia de suprimentos de imagens de contêiner: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias: resultados da varredura de todas as camadas da imagem do contêiner; periodicidade e processo de reconstrução da imagem base; SBOM do contêiner incluindo bibliotecas do sistema.
- Segurança de registros de contêineres em CI/CD
-
A segurança de registros de contêineres é importante para TPRM porque as imagens de contêiner que as empresas implantam a partir de registros de fornecedores são o mecanismo de entrega da cadeia de suprimentos de software para aplicações em contêineres.
a segurança de registros de contêineres é relevante para TPRM porque as imagens de contêiner que as empresas implantam a partir de registros de fornecedores são o mecanismo de entrega da cadeia de suprimentos de software para aplicações em contêineres.
- Segurança de registros de contêineres em CI/CD: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias: autenticidade do namespace do registro (privado ou verificado); um fornecedor que distribui imagens de contêiner deve ser questionado sobre assinatura de imagens e verificação de namespace. A assinatura de imagens fornece a garantia de autenticidade. A verificação de assinaturas no pipeline do consumidor a impõe. Ambas são necessárias para fechar o vetor de typosquatting e de comprometimento da distribuição.
- Segurança de contêineres em CI/CD
-
A segurança de contêineres em CI/CD é importante para TPRM porque o software entregue em contêineres inclui toda a pilha de software (imagem base, dependências e aplicação), e a gestão de vulnerabilidades deve se estender a todas as camadas.
a segurança de contêineres em CI/CD é importante para TPRM porque o software entregue em contêineres inclui toda a pilha de software (imagem base, dependências e aplicação), e a gestão de vulnerabilidades deve se estender a todas as camadas.
- Segurança de contêineres em CI/CD: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias verbais: ferramenta de varredura de contêineres e confirmação de cobertura de todas as camadas; um fornecedor que confirma a varredura de contêineres deve ser questionado sobre a cobertura de camadas. A varredura da camada de aplicação cobre as dependências adicionadas pelo fornecedor. A varredura de todas as camadas cobre o ambiente de execução. Ambas são necessárias para uma gestão completa de vulnerabilidades de contêineres.
- A realidade da conformidade contínua
-
A conformidade contínua é uma filosofia de desenho de programas que substitui as avaliações de conformidade pontuais e periódicas por verificações automatizadas e permanentes que monitoram a eficácia dos controles entre os ciclos formais de avaliação. O termo contínua implica monitoramento constante: um programa que detectaria imediatamente qualquer falha de controle.
a realidade da conformidade contínua é importante para TPRM porque o termo conformidade contínua, nas descrições de segurança dos fornecedores, cria a impressão de um monitoramento em tempo real que a implementação operacional nem sempre sustenta.
- A realidade da conformidade contínua: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias: frequência de verificação dos controles críticos; configuração do roteamento de alertas, fila de incidentes vs. fila de conformidade; tempo de resposta pretendido e real para falhas críticas de conformidade.
- Lacunas no monitoramento contínuo
-
O monitoramento contínuo em TPRM é a coleta e a avaliação permanentes de sinais sobre a postura de segurança dos fornecedores entre os ciclos formais de avaliação, usando dados de classificações externas de segurança, feeds de inteligência de ameaças, divulgações públicas de vulnerabilidades, inteligência corporativa e monitoramento de ações regulatórias para detectar mudanças relevantes no r
as lacunas no monitoramento contínuo importam para TPRM porque os examinadores regulatórios em serviços financeiros, saúde e infraestrutura crítica esperam cada vez mais o monitoramento contínuo como componente dos programas de risco de terceiros, não como substituto das avaliações periódicas, mas como complemento que detecta mudanças relevantes entre avaliações for
- Lacunas no monitoramento contínuo: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias verbais: documentação do processo de notificação de mudanças relevantes; política de notificação de mudanças na liderança-chave de segurança; notificação de incidentes de segurança abaixo do limite contratual formal.
- Plataformas de monitoramento contínuo
-
As plataformas de automação da conformidade se conectam aos seus sistemas de nuvem, identidade, chamados e código, verificam continuamente as configurações em relação aos requisitos dos controles e coletam evidências automaticamente à medida que os controles são executados. Elas revelam lacunas entre as auditorias e eliminam grande parte do trabalho manual de coleta de evidências.
elas realmente reduzem o custo de um SOC 2 e tornam o desvio dos controles visível em poucos dias, em vez de na próxima auditoria. Para uma equipe pequena, podem ser a diferença entre uma auditoria administrável e uma que não é.
- Monitoramento contínuo versus avaliação pontual
-
O monitoramento contínuo é importante porque os eventos de risco que mais justificam uma resposta de TPRM, como violações em fornecedores, mudanças de infraestrutura e rotatividade da liderança, costumam ocorrer entre as avaliações, e não no momento conveniente do ciclo anual de revisão.
o monitoramento contínuo é importante porque os eventos de risco que mais exigem resposta de TPRM (violações em fornecedores, mudanças de infraestrutura, troca de liderança) costumam ocorrer entre as avaliações, e não no momento conveniente do ciclo de revisão anual.
- Monitoramento contínuo versus avaliação pontual: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias: obrigação contratual de autocomunicação com gatilhos específicos; prazo de notificação para os diferentes tipos de mudança; exemplos recentes de notificação proativa aos clientes.
- Monitoramento contínuo de fornecedores
-
Monitoramento contínuo significa decidir quais eventos alteram o risco de um fornecedor, acompanhar esses eventos e fazer com que cada um acione uma ação definida, com um responsável e um prazo. Não é um produto. Vale a pena acompanhar quatro coisas: informações sobre violações de dados envolvendo seus fornecedores, o vencimento dos artefatos em que você se baseia, mudanças no fornecedor, como novos suboperadores ou mudança de controle societário, e mudanças no seu próprio uso desses fornecedores.
os fornecedores mudam, e as mudanças não são anuais. Um fornecedor sofre uma violação em março, seu relatório expira em junho, ele adiciona um suboperador em agosto e é adquirido em outubro. Nada disso aparece em uma classificação registrada em janeiro, e é a classificação que o registro mostra. O quarto gatilho, a expansão do seu próprio uso, é o que os programas mais deixam passar, porque acontece do seu lado e nada chega para anunciá-lo.
- Aplicação dos requisitos contratuais de segurança
-
A aplicação dos requisitos contratuais de segurança é importante porque o valor de redução de risco desses requisitos depende inteiramente de eles serem implementados.
a aplicação dos requisitos contratuais de segurança é importante porque o valor de redução de risco dos requisitos contratuais de segurança depende inteiramente de eles serem implementados.
- Aplicação dos requisitos contratuais de segurança: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias verbais: confirmação de conformidade com cada requisito, acompanhada de evidências; evidências técnicas para os requisitos de criptografia e controle de acesso; documentação do processo de notificação de incidentes que demonstre o cumprimento do prazo de 72 horas.
- Controles contratuais versus controles reais
-
Os requisitos contratuais de segurança definem a postura de segurança que um fornecedor deve manter como condição do relacionamento comercial. Eles estabelecem obrigações, definem padrões e criam meios de recurso jurídico se os padrões não forem cumpridos.
a distinção entre controles contratuais e controles reais é relevante para TPRM porque as estruturas regulatórias esperam cada vez mais que as organizações não apenas tenham requisitos de segurança nos contratos com fornecedores, mas consigam demonstrar que esses requisitos estão sendo cumpridos.
- Controles contratuais versus controles reais: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias: evidências de configuração técnica para requisitos contratuais específicos; divulgação de exceções, ou seja, lacunas conhecidas em relação aos requisitos contratuais; avaliação de caminhos legados em relação aos requisitos contratuais.
- Duplicação de controles
-
A duplicação de controles é a manutenção de várias instâncias da mesma função de controle de segurança em uma organização: ferramentas separadas, processos separados ou programas separados que executam funções de segurança equivalentes com escopo sobreposto ou idêntico.
a duplicação de controles é relevante para TPRM porque fornecedores que mantêm controles duplicados podem ter uma postura de conformidade que parece abrangente, com várias ferramentas, vários programas e defesa em profundidade, enquanto a cobertura real é menos completa do que parece e o custo operacional é significativamente maior do que o de um programa racionaliz
- Duplicação de controles: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias verbais: registros de identificação e racionalização de duplicações.
- Equívocos sobre herança de controles
-
A herança de controles é a prática de confiar em uma certificação, auditoria ou avaliação de terceiros como evidência de que determinados controles existem, em vez de avaliar esses controles diretamente.
os equívocos sobre herança de controles são relevantes para TPRM porque criam um tipo específico de falsa garantia: a confiança que vem de uma certificação genuína e bem-conceituada que, na verdade, não cobre os ativos relevantes para o risco do cliente.
- Equívocos sobre herança de controles: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias verbais: declaração de escopo da certificação ou descrição do sistema que confirme a cobertura do serviço relevante; lista dos sistemas explicitamente excluídos da descrição de sistema do SOC 2; declaração de aplicabilidade da ISO 27001, se solicitada.
- Inconsistências no mapeamento de controles
-
O mapeamento de controles é a prática de documentar as relações entre os controles de segurança implementados e os requisitos de vários frameworks de conformidade, normas regulatórias e requisitos de clientes.
as inconsistências no mapeamento de controles são relevantes para TPRM porque os documentos de mapeamento são frequentemente apresentados como evidência de conformidade em avaliações de fornecedores, mostrando que os controles do fornecedor atendem aos requisitos relevantes para o cliente.
- Inconsistências no mapeamento de controles: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias verbais: descrição do conteúdo do controle que trate especificamente do texto do requisito; documentação do programa de treinamento ou do procedimento que mostre conteúdo específico do requisito; identificação de lacunas, caso o requisito seja atendido apenas parcialmente.
- Objetivo de controle e atividade de controle
-
Um objetivo de controle é o resultado de que você precisa. Uma atividade de controle é o que alguém de fato faz para alcançá-lo. “O acesso aos sistemas de produção é adequado” é um objetivo. “Os gestores revisam a cada trimestre uma lista, gerada pelo sistema, dos acessos de produção da sua equipe e registram a aprovação ou a remoção de cada item” é uma atividade. Os auditores testam atividades.
as matrizes de controles frequentemente listam objetivos e os chamam de controles. Quando o auditor pede evidências, não há nada a apresentar, porque um objetivo não deixa rastro. Ele só pode ser discutido. O trabalho fica parado enquanto a atividade é definida retroativamente.
- Responsável pelo controle
-
A pessoa nomeada responsável pelo funcionamento de um controle e pelas evidências que ele produz.
Um controle sem responsável é um controle cuja falha ninguém percebe. A atribuição de responsabilidade é o que transforma a descrição de um controle em algo testável.
Ensinado em AUD-201 · Veja também: Evidência, Aceitação de riscos
- Responsável pelo controle e responsável pela evidência
-
O responsável pelo controle é a pessoa que responde pelo funcionamento do controle conforme projetado. O responsável pela evidência é a pessoa encarregada de produzir o artefato que comprova que ele funcionou. Muitas vezes são pessoas diferentes, e o controle pode funcionar perfeitamente sem que a evidência jamais seja registrada, porque ninguém era responsável por registrá-la.
as auditorias falham na passagem entre os dois. O gestor que revisa os acessos faz a revisão; o analista que deveria exportar o registro está de licença; o auditor pede a evidência; não há nenhuma. O controle funcionou e a auditoria registra uma exceção.
- Profundidade dos testes de controles
-
A profundidade dos testes de controles é o grau em que os testes de segurança exercitam os controles, sistemas e caminhos de ataque mais relevantes para o modelo de ameaças real, e não os controles, sistemas e caminhos de ataque mais fáceis de testar dentro de um orçamento e prazo definidos.
a profundidade dos testes de controles é importante para TPRM porque os relatórios de testes de intrusão estão entre os itens de evidência mais solicitados e de maior peso nas avaliações de segurança de fornecedores.
- Profundidade dos testes de controles: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias verbais: documentação do escopo do teste de intrusão, incluindo os sistemas dentro e fora do escopo; confirmação de que os ambientes de API autenticados estão no escopo; descrição da metodologia de teste, com os componentes automatizados e manuais.
- Teste de controles versus desenho de controles
-
Um controle pode falhar de duas formas distintas. Uma falha de desenho significa que o controle, mesmo executado com perfeição, não alcançaria seu objetivo: a revisão acontece, mas a população revisada está incompleta, ou a etapa de aprovação existe, mas fica depois da implantação. Uma falha de operação significa que o controle está bem desenhado e não foi executado como previsto: a revisão foi pulada no segundo mês, a aprovação foi dada depois do fato.
os auditores relatam as duas separadamente, e a remediação é totalmente diferente. Uma falha de desenho exige que o controle seja redesenhado. Uma falha de operação exige que as pessoas e a cadência sejam corrigidas. Tratar uma como a outra desperdiça a remediação: retreinar os revisores não corrige uma população que deixou de fora as contas de serviço, e redesenhar a revisão não corrige um revisor que estava de licença sem ninguém para cobri-lo.
- Lacuna entre o controle e a implementação
-
A lacuna entre o controle e a implementação é a diferença entre o que um controle de segurança foi concebido para fazer, conforme especificado na política, na documentação do programa e nos procedimentos, e o que ele de fato faz na prática, conforme refletido nos registros de execução, nos dados de achados e nas métricas operacionais.
as lacunas na implementação de controles são importantes para TPRM porque a redução de risco proporcionada por um controle de segurança depende inteiramente do estado operacional do controle, e não do seu estado na política.
- Lacuna entre o controle e a implementação: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias verbais: data do teste de intrusão mais recente e quantidade atual de achados em aberto, com a idade do achado mais antigo; taxa de cumprimento do SLA de remediação, ou seja, o percentual em conformidade, não a política de SLA; data da reunião mais recente do comitê de segurança.
- Falhas de resposta coordenada
-
As falhas de resposta coordenada são as rupturas na resposta conjunta a incidentes que ocorrem quando os planos de IR do fornecedor e do cliente contêm objetivos conflitantes, procedimentos incompatíveis ou prazos incompatíveis que não podem ser conciliados sem negociação durante um incidente ativo. Os planos individuais podem ser excelentes em desenho e execução.
as falhas de resposta coordenada são relevantes para TPRM porque o resultado do cliente em um incidente compartilhado depende da qualidade da resposta coordenada, e uma resposta coordenada com conflitos de planos resolvidos em tempo real durante um incidente ativo é um resultado significativamente pior do que uma resposta coordenada com conflitos identificados e res
- Falhas de resposta coordenada: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias verbais: conflito reconhecido com o SLA de restauração do cliente; solução previamente negociada para o conflito; exercício de mesa conjunto que inclua o cenário de conflito.
- Mapeamento de COSO
-
Os Trust Services Criteria se baseiam no Internal Control Integrated Framework do COSO, especificamente em seus dezessete princípios, ampliados com critérios suplementares para o contexto dos serviços de confiança. Os critérios comuns CC1 a CC5 correspondem diretamente aos cinco componentes do COSO: ambiente de controle, avaliação de riscos, atividades de controle, informação e comunicação, e monitoramento.
isso explica a presença de critérios sobre supervisão do conselho, estrutura organizacional, competência e responsabilização naquilo que a maioria das pessoas espera que seja um relatório de segurança. Eles vêm do COSO e estão ali porque um ambiente de controle sem governança por trás não se sustenta.
- Critérios versus controles em questionários
-
Um questionário de segurança pergunta sobre controles específicos: você criptografa em repouso, você rotaciona chaves trimestralmente, você revisa acessos mensalmente. Um SOC 2 se reporta a critérios, com controles escolhidos pelo fornecedor para atendê-los. Os dois raramente coincidem item a item, porque o questionário presume uma forma de atender a um critério e o fornecedor pode ter escolhido outra.
um fornecedor pode responder não a uma pergunta específica sobre um controle e ainda assim atender ao critério subjacente por outro caminho. Registrar isso como lacuna e pressionar o fornecedor a adotar o seu controle preferido é pedir que ele mude algo que já funciona.
- Planejamento da estratégia de saída de fornecedores críticos
-
O planejamento da estratégia de saída é importante porque a incapacidade de encerrar o relacionamento com um fornecedor crítico sem uma catástrofe operacional já é, por si só, um risco: risco de concentração, risco de poder de barganha e risco de resiliência operacional que a empresa carrega independentemente da postura de segurança do fornecedor.
o planejamento da estratégia de saída é importante porque a incapacidade de encerrar o relacionamento com um fornecedor crítico sem uma catástrofe operacional já é, por si só, um risco: risco de concentração, risco de poder de barganha e risco de resiliência operacional que a empresa carrega independentemente da postura de segurança do fornecedor.
- Planejamento da estratégia de saída de fornecedores críticos: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias verbais: compromisso de assistência na transição, com cronograma; documentação da portabilidade de dados e do formato de exportação; disponibilidade da documentação API para a integração de saída.
- Riscos dos fluxos internacionais de dados
-
O risco de fluxo transfronteiriço de dados surge quando dados pessoais circulam entre jurisdições com padrões diferentes de proteção de dados, criando obrigações de conformidade regulatória que devem ser cumpridas a cada transferência.
a governança dos fluxos internacionais de dados é importante para TPRM porque as obrigações regulatórias aplicáveis às transferências internacionais de dados (cláusulas-padrão contratuais, normas corporativas globais, decisões de adequação) são de responsabilidade do exportador dos dados, não do importador.
- Riscos do fluxo transfronteiriço de dados: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias verbais: mapa da presença geográfica do tratamento, com todos os locais onde os dados do cliente são tratados; inventário dos mecanismos de transferência, com o tipo de mecanismo e a versão vigente para cada local de transferência; confirmação dos mecanismos de transferência dos suboperadores, não apenas a lista, mas a cobertura dos mecanismos.
- Transferências internacionais
-
O Capítulo V do GDPR restringe a transferência de dados pessoais para fora do Espaço Econômico Europeu, salvo se houver um mecanismo de transferência aplicável: uma decisão de adequação, cláusulas-padrão contratuais, normas corporativas globais ou uma das derrogações restritas. A restrição acompanha os dados aonde quer que eles vão, inclusive nas transferências posteriores feitas pelo destinatário.
o acesso é uma transferência. Um engenheiro de suporte em um terceiro país que visualiza o registro de um cliente europeu transferiu esses dados, mesmo que eles nunca tenham saído do servidor europeu. Administração remota, suporte ininterrupto entre fusos horários e desenvolvimento no exterior são todos transferências, e mapear apenas onde os dados estão armazenados deixa a maioria delas de fora.
- Prazos de resposta entre organizações
-
Os problemas de prazos de resposta entre organizações surgem quando incidentes de segurança que afetam várias organizações, especialmente incidentes na cadeia de suprimentos que atingem fornecedores e seus clientes na mesma campanha, são investigados de forma independente por cada organização afetada, e não por meio de compartilhamento coordenado de informações.
os prazos de resposta entre organizações importam para TPRM porque incidentes na cadeia de suprimentos frequentemente criam cenários de alvos simultâneos, em que uma resposta coordenada produziria detecção mais rápida e menor tempo de permanência do invasor para todas as partes.
- Prazos de resposta entre organizações: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias verbais: processo de notificação de clientes em cenários de ataque simultâneo a vários alvos; mecanismo de compartilhamento de IOC, seja STIX/TAXII, MISP ou acordo bilateral; participação em ISAC do setor em comum.
- Visibilidade entre plataformas
-
As lacunas de visibilidade entre plataformas são os pontos cegos de monitoramento de segurança que existem nas interfaces entre diferentes plataformas tecnológicas, serviços gerenciados e operadores terceiros, especificamente os sistemas e ambientes em que a fronteira de responsabilidade pelo monitoramento entre duas partes é ambígua, presumida em vez de confirmada, ou
a visibilidade entre plataformas é relevante para TPRM porque ambientes tecnológicos complexos de fornecedores, com vários serviços gerenciados, operadores terceiros e infraestrutura híbrida, criam oportunidades de lacunas de monitoramento em cada interface entre as partes.
- Visibilidade entre plataformas: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias verbais: confirmação do monitoramento de segurança em tempo de execução do Kubernetes; escopo do monitoramento de segurança do serviço gerenciado previsto em contrato; um fornecedor que confirma cobertura de endpoints, nuvem e rede deve ser questionado especificamente sobre o monitoramento de segurança de contêineres e do Kubernetes. As categorias confirmadas cobrem os componentes confirmados. O cluster Kubernetes que hospeda dados de clientes exige sua própria confirmação.
- Propagação de identidades entre sistemas
-
A propagação de identidades entre sistemas é o processo pelo qual os eventos do ciclo de vida das identidades, como criação de usuários, mudanças de função e desprovisionamento, são comunicados de uma fonte central de identidade (normalmente um IdP ou uma plataforma de IGA) a todos os sistemas conectados, garantindo que o estado das identidades seja consistente em todo o conjunto de aplicações.
a propagação de identidades entre sistemas é importante para TPRM porque fornecedores que acessam ambientes de clientes em vários sistemas (espaços de trabalho de projetos, ferramentas de colaboração com clientes, ambientes de desenvolvimento compartilhados) podem ter lacunas no desprovisionamento IGA dos sistemas adjacentes ao ambiente do cliente que foram implantados especificamente para o projeto.
- Propagação de identidades entre sistemas: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias verbais: lista de conectores IGA com a data da última reconciliação; capacidade ou processo de descoberta de aplicações paralelas; processo de verificação de acessos após o desligamento que abranja sistemas fora do IGA.
- Riscos de acesso entre locatários
-
O risco de acesso entre locatários é a possibilidade de que os dados, a carga de trabalho ou o ambiente de um cliente em uma plataforma de nuvem multilocatária sejam acessados, afetados ou comprometidos em consequência da presença de outro cliente na mesma plataforma, ou em consequência de fragilidades nos componentes compartilhados da plataforma que atendem a todos os locatários simultane
o risco entre tenants é uma das dimensões menos avaliadas do risco de terceiros em nuvem justamente porque é invisível no modelo padrão de avaliação.
- Riscos de acesso entre tenants: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias verbais: uma descrição arquitetural clara do isolamento entre locatários, não uma declaração de marketing, mas uma explicação técnica; documentação dos controles de acesso do suporte, incluindo os requisitos de autorização e o registro de auditoria; relatórios de testes de intrusão ou sumários executivos que confirmem que cenários entre locatários foram testados.
- Detecção de ataques entre tenants
-
A detecção de ataques entre locatários é o desafio de identificar quando um comprometimento de segurança que afeta o ambiente de um cliente em uma plataforma multilocatária acessou, ou pode acessar, os ambientes de outros clientes por meio de componentes de infraestrutura compartilhados.
a detecção de ataques entre tenants é relevante para TPRM porque clientes em plataformas multitenant enfrentam um risco de violação que se origina no ambiente de outro cliente, um risco totalmente fora do seu controle e que depende da capacidade do fornecedor de detectar acessos entre tenants e notificar os clientes afetados.
- Detecção de ataques entre locatários: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias verbais: checklist de investigação entre tenants, indicando quais camadas são verificadas; gatilho e prazo de notificação aos demais tenants; procedimento de revisão do controle de acesso ao banco de dados compartilhado.
- Tabelas de correspondência
-
Um mapeamento cruzado é uma correspondência entre os requisitos de dois ou mais frameworks, que mostra qual requisito de um corresponde a qual de outro. Os bons são graduados e indicam se a correspondência é total, parcial ou apenas temática. Os ruins são listas de números lado a lado, produzidas uma única vez por alguém que leu os títulos.
um mapeamento cruzado é a forma como um programa de controles evita fazer o mesmo trabalho três vezes, e também a forma como ele, discretamente, declara mais do que cumpre. Um mapeamento parcial registrado como completo é onde um programa começa a dizer aos avaliadores que um requisito foi atendido quando apenas a maior parte dele foi. Os mapeamentos cruzados publicados por organismos de normas e fornecedores vão do cuidadoso ao decorativo, e o leitor geralmente não consegue distinguir um do outro pelo formato.
D
- Padrões obscuros no consentimento
-
Padrões obscuros (dark patterns) são designs de interface que conduzem os usuários a uma escolha que, de outra forma, não fariam: um botão de aceitar em cor destacada ao lado de um link de rejeitar em cinza, um caminho de rejeição escondido a três cliques de distância, solicitações repetidas após a recusa, duplas negativas confusas ou um cookie wall que bloqueia o conteúdo até que o consentimento seja dado. Os reguladores agora nomeiam padrões específicos em orientações e em ações de fiscalização.
o consentimento obtido por meio de um padrão obscuro não é livre, e um consentimento que não é livre não é consentimento. O tratamento que se apoia nele não tem base legal. Reguladores europeus multaram empresas especificamente por interfaces de consentimento assimétricas, e o próprio design passou a ser evidência.
- Lacunas de cobertura de DAST em aplicações de fornecedores
-
O DAST é posicionado na maioria dos programas de segurança de fornecedores como complemento do SAST: enquanto a análise estática encontra vulnerabilidades no código antes da implantação, os testes dinâmicos encontram vulnerabilidades em tempo de execução na aplicação implantada.
O DAST é posicionado na maioria dos programas de segurança de fornecedores como complemento do SAST: enquanto a análise estática encontra vulnerabilidades no código antes da implantação, os testes dinâmicos encontram vulnerabilidades em tempo de execução na aplicação implantada.
- Lacunas de cobertura de DAST em aplicativos de fornecedores: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias verbais: percentual de cobertura da varredura de DAST mais recente, com declaração explícita do que está excluído do escopo; confirmação de testes autenticados, com descrição de como a autenticação é gerenciada no scanner; confirmação do ambiente, de produção ou equivalente à produção, com descrição de quaisquer diferenças relevantes em relação à produção.
- DAST no pipeline de CI/CD
-
a eficácia do DAST é relevante para TPRM porque as configurações de autenticação e de execução sob as quais o DAST é executado determinam quais vulnerabilidades ele consegue encontrar.
a eficácia do DAST é relevante para TPRM porque as configurações de autenticação e de execução sob as quais o DAST é executado determinam quais vulnerabilidades ele consegue encontrar.
- DAST no pipeline de CI/CD: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias verbais: descrição da configuração do ambiente-alvo do DAST; documentação do escopo do DAST, com os endpoints e fluxos de autenticação cobertos; um fornecedor que confirma varreduras de DAST deve ser questionado sobre a configuração do ambiente testado. O DAST testa o que está em execução. Se o que está em execução não corresponde à configuração de produção, os achados do DAST não descrevem as vulnerabilidades de produção.
- Lacunas no registro de acessos a dados
-
O registro de acessos a dados é a captura sistemática de registros que mostram qual usuário ou processo acessou quais dados, quando, de qual local e qual operação foi realizada: leitura, escrita, exportação, exclusão, consulta.
o registro de acessos a dados é relevante para TPRM porque a ameaça interna, ou seja, um empregado do fornecedor que abusa do seu acesso legítimo aos dados do cliente, é uma das categorias de ameaça de maior impacto e mais difíceis de detectar no panorama de risco de terceiros.
- Lacunas no registro de acessos a dados: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias verbais: descrição da capacidade de detecção de ameaças internas, com o controle específico que detectaria exportações em massa; confirmação do registro de acessos na camada de aplicação com alertas de exportação em massa; prazo de retenção dos logs e base de calibração.
- Acúmulo gradual de privilégios de acesso a dados
-
O acúmulo gradual de privilégios é a acumulação de direitos de acesso ao longo do tempo, à medida que as pessoas recebem novos acessos para finalidades específicas sem perder os acessos anteriores quando essas finalidades se encerram. Cada concessão individual segue o processo correto de provisionamento: solicitação, aprovação, acesso.
o acúmulo gradual de privilégios é relevante para TPRM porque cria um risco de ameaça interna invisível para avaliações focadas em concessões individuais de acesso.
- Acúmulo gradual de privilégios de acesso a dados: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias verbais: evidências de revisão do perfil cumulativo da população com longo tempo de casa; confirmação do gatilho de retirada de acessos na mudança de função; plataforma de gestão do ciclo de vida de IGA, se aplicável.
- Acesso a dados por meio de APIs
-
As APIs se tornaram a principal interface pela qual os dados circulam entre sistemas: o mecanismo pelo qual integrações de fornecedores, aplicativos móveis, conexões com parceiros e serviços internos acessam os dados mantidos por bancos de dados e sistemas de aplicação.
o acesso a dados via API é importante para TPRM porque as APIs são o mecanismo real de acesso a dados em praticamente todas as integrações com fornecedores, e os controles de segurança na camada de API determinam a proteção real que as integrações recebem, independentemente dos controles no nível do banco de dados que as avaliações de governança costumam examinar.
- Acesso a dados por meio de APIs: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias: confirmação da capacidade de filtragem de campos, com escopo de campos por integração ou retorno do registro completo; configuração de limitação de taxa, com limites por chave nos pontos de acesso de recuperação de dados; confirmação do escopo do teste de segurança de API, incluindo testes de autorização de campos e de enumeração.
- Mitos sobre a anonimização de dados
-
A anonimização de dados é o processo de transformar dados pessoais de forma a impedir irreversivelmente a identificação das pessoas a que se referem, removendo ou alterando informações identificadoras de modo que a reidentificação não seja razoavelmente possível com os meios que provavelmente estariam disponíveis a um potencial adversário.
a anonimização de dados é relevante para TPRM porque é usada com frequência como mecanismo para reduzir o ônus de governança sobre dados compartilhados com fornecedores de análise, pesquisa e AI/ML, com o argumento de que dados anonimizados não são dados pessoais e, portanto, não exigem os mesmos controles de acesso, as mesmas disposições de DPA e os mesmos requisitos de segurança que os ide
- Mitos sobre anonimização de dados: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias verbais: documentação da técnica de anonimização, com o método específico aplicado, e não apenas “identificadores removidos”; avaliação do risco de reidentificação com ferramentas formais e premissas realistas sobre dados auxiliares; confirmação de reavaliação periódica para dados anonimizados há mais de 12 meses.
- Desafios de auditabilidade de dados
-
A auditabilidade de dados é a capacidade de produzir, sob demanda, evidências de conformidade com as obrigações de proteção de dados, não por meio de um programa de conformidade que gera evidências quando um regulador pede, mas por meio de uma infraestrutura contínua de evidências que captura eventos de conformidade continuamente e os retém em um formato que permite a auditoria e a re
a auditabilidade dos dados é relevante para TPRM porque é a capacidade que converte a prática de conformidade em conformidade defensável: a capacidade de demonstrar a um regulador, a um cliente ou a um auditor que as obrigações de proteção de dados estão sendo cumpridas, quando são cumpridas, e que as evidências desse cumprimento estão disponíveis para revisão.
- Desafios de auditabilidade de dados: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias verbais: resultados das revisões de acesso em formato pesquisável e pronto para auditoria; log de exclusões com documentação de sistema, cronograma e confirmação; log de DSAR com status de atendimento e evidências de prazos.
- Lacunas na notificação de violação de dados
-
A governança da notificação de violação de dados nas relações com fornecedores é o conjunto de mecanismos contratuais e operacionais que garantem que um fornecedor comunique ao cliente os incidentes de segurança que afetam os dados do cliente em um prazo que permita ao cliente cumprir suas próprias obrigações regulatórias de notificação.
as lacunas na notificação de violações importam para TPRM porque as obrigações regulatórias do cliente não ficam suspensas enquanto o fornecedor investiga.
- Lacunas na notificação de violação de dados: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias verbais: documentação do processo de resposta a incidentes que mostre a notificação ao cliente como uma etapa definida e com prazo; especificação do prazo de notificação, com o máximo de horas entre a descoberta e a notificação; modelo de notificação inicial com confirmação do conteúdo mínimo.
- Classificação de dados
-
A classificação de dados atribui requisitos de manuseio às informações conforme sua sensibilidade. Um esquema típico tem quatro níveis: público, interno, confidencial e restrito, e cada nível traz regras de armazenamento, transmissão, acesso, compartilhamento e descarte. Os dados pessoais e os dados de categorias especiais geralmente são mapeados para os níveis mais altos.
controles, decisões de retenção e de acesso fazem todos referência à classificação, de modo que um ambiente sem classificação obriga a uma única política para tudo, que é rigorosa demais para o material público ou frouxa demais para o restrito. A classificação é o que permite um tratamento proporcional.
- Validação da exclusão de dados
-
A validação da exclusão de dados é o processo de confirmar que os dados foram removidos de forma completa e irreversível de todos os locais onde existiam, e não apenas de confirmar que uma ação de exclusão foi executada nos sistemas que estavam no escopo da solicitação de exclusão.
a validação da exclusão de dados é relevante para TPRM porque o direito à eliminação previsto no GDPR e direitos equivalentes previstos no CCPA, no LGPD e em outras estruturas criam obrigações juridicamente exigíveis que requerem a exclusão completa, de todos os sistemas, incluindo backups e arquivos, e não apenas a exclusão dos sistemas ativos principais.
- Validação da exclusão de dados: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias verbais: confirmação da cobertura de sistemas, com a lista dos sistemas pesquisados e a exclusão confirmada em cada um; registros de log de exclusão, quando disponíveis, como evidência da ação e não da ausência; confirmação explícita da exclusão em backups e arquivos.
- Lacunas na detecção de exfiltração de dados
-
As lacunas na detecção de exfiltração de dados são as limitações na capacidade de um programa de segurança de identificar quando dados estão sendo transferidos para fora da organização por um invasor, lacunas que decorrem da calibração de limites, da arquitetura de detecção e das técnicas específicas de exfiltração que os invasores usam para contornar a detecção configurada.
as lacunas na detecção de exfiltração de dados são relevantes para TPRM porque o DLP é a principal evidência, nas investigações pós-violação, sobre se os dados foram de fato exfiltrados e em que volume, e um sistema de DLP que avaliou doze transferências individualmente sem detectar a exfiltração no nível da sessão não fornece nenhuma evidência de uma violação que um investigador
- Lacunas na detecção de exfiltração de dados: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias verbais: confirmação da configuração de agregação por sessão no DLP; um fornecedor que confirma a implantação de DLP com limites configurados deve ser questionado se a configuração inclui agregação por sessão. Limites por evento detectam exfiltração em um único evento. A agregação por sessão detecta exfiltração fragmentada. Ambas exigem configuração específica. Ambas exigem confirmação específica.
- Caminhos de exfiltração de dados
-
A exfiltração de dados é a transferência não autorizada de dados de um ambiente controlado para um ambiente não controlado, seja por intenção maliciosa, negligência de empregados ou atalhos por conveniência que contornam os controles de segurança.
a governança dos caminhos de exfiltração de dados é importante para TPRM porque o risco de exfiltração que um fornecedor representa não é determinado pela robustez dos controles implementados nos canais que ele tratou, mas pela abrangência dos controles em todos os canais pelos quais os dados podem trafegar.
- Caminhos de exfiltração de dados: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias verbais: confirmação da cobertura de DLP sobre o encaminhamento para e-mails pessoais, com controle técnico ou reconhecimento explícito da lacuna; documentação da política sobre dispositivos e contas pessoais, com proibição explícita e mecanismo de aplicação; histórico de incidentes de exfiltração, com incidentes recentes, canal envolvido e resultado dos controles.
- Lacunas nas ferramentas de governança de dados
-
Ferramentas de governança de dados são a infraestrutura técnica que operacionaliza as políticas de governança: as plataformas, ferramentas e sistemas automatizados que executam a classificação, aplicam a retenção, gerenciam as revisões de acesso, mantêm os inventários de dados e monitoram a conformidade de forma contínua, em vez de depender de processos manuais periódicos.
as lacunas nas ferramentas de governança de dados são relevantes para TPRM porque determinam a consistência e a escala reais da execução do programa de governança: a distância entre o que a política descreve e o que os processos manuais conseguem entregar.
- Lacunas nas ferramentas de governança de dados: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias: nome da ferramenta de classificação e percentual de cobertura; nome da plataforma de IGA com confirmação de revogação automática; ferramentas de gestão do ciclo de vida com log de exclusão automatizada.
- Governança de dados versus aplicação efetiva
-
A governança de dados é a estrutura de políticas, padrões e processos que define como os dados devem ser coletados, classificados, protegidos, retidos e descartados dentro de uma organização.
a diferença entre governança de dados e aplicação efetiva é importante para TPRM porque o valor de asseguração da documentação de governança de dados de um fornecedor depende inteiramente de essa documentação refletir a realidade operacional.
- Governança de dados versus aplicação efetiva: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias verbais: evidências da implantação de ferramentas de classificação, não a política, mas o sistema implantado; configuração da automação de retenção, não a tabela da política, mas o processo de exclusão configurado; achados da auditoria interna e status da remediação, como evidência de testes de conformidade com a governança.
- Completude do inventário de dados
-
Um inventário de dados é um registro documentado de todos os sistemas, bancos de dados, locais de armazenamento e fluxos de dados que contêm ou tratam dados sensíveis no ambiente de uma organização ou de um fornecedor.
a completude do inventário de dados é importante para TPRM porque todos os controles de governança de dados subsequentes (gestão de acessos, criptografia, políticas de retenção, escopo da resposta a incidentes) dependem de o inventário identificar os sistemas aos quais esses controles devem ser aplicados.
- Completude do inventário de dados: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias verbais: evidências de varreduras de descoberta comparadas com o inventário documentado, com documentação das discrepâncias; documentação do processo de atualização do inventário, incluindo gatilhos e frequência; confirmação do escopo do inventário, com todas as categorias de sistemas relevantes incluídas.
- Má gestão do ciclo de vida dos dados
-
A gestão do ciclo de vida dos dados é a governança dos dados desde a criação ou coleta, passando pelo uso, retenção e arquivamento, até a eventual eliminação ou destruição.
a gestão inadequada do ciclo de vida dos dados é importante para TPRM porque a retenção não autorizada de dados, ou seja, manter dados além do período autorizado pela finalidade do tratamento, cria um risco residual puro, sem nenhum valor de negócio correspondente.
- Gestão inadequada do ciclo de vida dos dados: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias verbais: documentação do processo de exclusão, com o fluxo formal desde a solicitação até a execução e a verificação; responsável nomeado pelo ciclo de vida, com a função específica encarregada da execução e da entrega de evidências; evidência de verificação da exclusão em um desligamento recente de cliente, demonstrando que o processo funciona.
- Linhagem de dados entre terceiros
-
A linhagem de dados é o registro rastreável de onde os dados se originaram, como foram transformados e por onde circularam: uma cadeia de custódia que identifica cada sistema, processo e parte que teve contato com os dados desde a criação até o estado atual.
a linhagem de dados entre terceiros é importante para TPRM porque as obrigações regulatórias aplicáveis aos dados dos clientes (limitações de tratamento, restrições geográficas, requisitos de autorização de suboperadores, direitos dos titulares) se aplicam aos dados independentemente de quantos saltos os separem do cliente.
- Linhagem de dados entre terceiros: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias verbais: lista atual de suboperadores com nomes, jurisdições, dados recebidos e finalidade do tratamento; documentação do processo de notificação de mudanças, com direito de oposição do cliente; confirmação da proibição de reaproveitamento de dados, ou seja, os suboperadores estão contratualmente proibidos de usar os dados do cliente para finalidades não autorizadas.
- Mapa de dados inventário de dados
-
Um registro de quais dados são mantidos, onde estão, a quem pertencem e para onde vão as cópias, incluindo logs, dados analíticos, backups e ambientes que não são de produção.
É o insumo para as operações de direitos, a retenção, a delimitação de violações e a exposição de fornecedores. Fazê-lo uma única vez evita quatro exercícios de descoberta separados.
Ensinado em DGV-220 · Veja também: Registro das operações de tratamento, Tabela de retenção
- Mapeamento de dados
-
O mapeamento de dados é o exercício de identificar quais dados pessoais uma organização detém, onde ficam, como circulam entre sistemas e partes, quem pode acessá-los e o que acontece com eles ao longo do ciclo de vida. É a base empírica do registro das operações de tratamento, da tabela de retenção, do registro de transferências e de toda solicitação de direitos.
todas as outras obrigações de privacidade dependem dele. Uma organização não consegue atender a um pedido de eliminação sem saber onde os dados estão. Não consegue avaliar transferências sem saber para onde os dados vão. Não consegue definir a retenção sem saber o que mantém. Um programa sem mapa é um programa que adivinha.
- Minimização de dados
-
A minimização de dados exige que os dados pessoais sejam adequados, pertinentes e limitados ao necessário para as finalidades para as quais são tratados. Colete o que a finalidade exige e nada mais. Mantenha-os apenas pelo tempo que a finalidade exigir. É um dos sete princípios do Artigo 5 do GDPR e um dos mais difíceis de fazer valer junto a uma equipe de produto.
mais dados sempre parecem úteis mais tarde. Um formulário que pede a data de nascimento quando só a faixa etária é necessária, um log que captura o corpo completo das requisições quando só os códigos de status são necessários, um CRM que armazena todos os campos que a integração oferece. Cada um é uma falha de minimização, e cada um amplia a superfície de toda violação, de toda solicitação de acesso e de toda obrigação de retenção.
- Falhas de minimização de dados
-
A minimização de dados é importante para TPRM por um motivo ao mesmo tempo juridicamente relevante e intuitivo na prática: não é possível vazar dados que você não tem. Cada elemento de dado transferido a um fornecedor além do necessário para a finalidade declarada representa uma ampliação desnecessária da superfície de violação.
a minimização de dados é importante para TPRM por um motivo ao mesmo tempo juridicamente relevante e intuitivo na prática: não é possível vazar dados que você não tem.
- Falhas de minimização de dados: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias verbais: inventário específico dos campos de dados, com a justificativa da finalidade de cada campo recebido; confirmação de que nenhum campo é recebido sem uma finalidade operacional ativa; avaliação da capacidade de anonimização ou pseudonimização dos campos cuja identificação não é operacionalmente necessária.
- Ambiguidade sobre a propriedade dos dados
-
A propriedade dos dados nas relações com fornecedores abrange duas categorias distintas, mas frequentemente confundidas. A primeira é a propriedade dos próprios dados: os registros de clientes, logs de transações, dados comportamentais e informações operacionais que o cliente compartilha com o fornecedor para tratamento.
a ambiguidade sobre a propriedade dos dados importa para TPRM porque as consequências comerciais e competitivas de lacunas de propriedade podem ser tão significativas quanto as de violações de segurança.
- Ambiguidade sobre a propriedade dos dados: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias verbais: disposição sobre a propriedade de ativos derivados, com redação contratual explícita sobre a propriedade de modelos e algoritmos; confirmação da restrição de uso competitivo, com a proibição de oferecer a concorrentes capacidades derivadas do trabalho com o cliente; documentação do tratamento de ativos após o encerramento, com a exclusão ou devolução dos modelos treinados ao fim do contrato.
- Portabilidade dos dados
-
O direito à portabilidade de dados permite que uma pessoa receba os dados pessoais que forneceu a um controlador em formato estruturado, de uso comum e legível por máquina, e os transmita a outro controlador. Aplica-se apenas quando o tratamento se baseia no consentimento ou em contrato, e apenas quando é realizado por meios automatizados.
ele é frequentemente solicitado para dados que não abrange. Inferências que você fez, pontuações que calculou e registros que criou sobre a pessoa a partir de outras fontes não são dados fornecidos por ela e não são portáveis. Dados tratados com base em interesses legítimos ou em obrigação legal também não estão no escopo.
- Acordos de tratamento de dados
-
Um acordo de tratamento de dados é o contrato que o Artigo 28 do GDPR exige entre um controlador e um operador. Seu conteúdo obrigatório está listado no artigo: o objeto e a duração, a natureza e a finalidade, os tipos de dados e as categorias de titulares, e as obrigações de ambas as partes, incluindo tratar dados apenas mediante instrução, confidencialidade, segurança, regras para suboperadores, assistência no atendimento aos direitos e nos relatórios de impacto à proteção de dados, eliminação ou devolução ao término e direitos de auditoria.
um DPA que não contenha qualquer um dos termos obrigatórios não está em conformidade, por mais profissional que seja sua redação. O consentimento para suboperadores e os direitos de auditoria são os dois termos que mais faltam nos modelos dos fornecedores, e essa ausência geralmente não é deliberada. O modelo foi escrito para outra finalidade e nunca foi conferido com o artigo.
- Relatório de impacto à proteção de dados DPIA, PIA
-
Uma avaliação exigida quando o tratamento puder resultar em alto risco para as pessoas, abrangendo necessidade, proporcionalidade, riscos e medidas de mitigação.
Sua finalidade prática é mudar o projeto enquanto mudá-lo ainda é barato. Concluída depois que o projeto já está definido, ela só consegue documentar.
Ensinado em PRV-250 · Veja também: Registro das operações de tratamento, Interesse legítimo
- Relatórios de impacto à proteção de dados
-
Um relatório de impacto à proteção de dados é um processo documentado para identificar e minimizar os riscos de proteção de dados de um projeto antes de seu início. É obrigatório quando o tratamento puder resultar em alto risco para as pessoas, em especial com novas tecnologias, monitoramento em larga escala, avaliação sistemática ou definição de perfis, ou dados de categorias especiais em escala.
o DPIA é o momento documentado em que alguém perguntou se isso deveria ser construído da forma como está sendo construído e o que poderia ser feito de modo diferente. É também o que um regulador pede primeiro após uma reclamação, e sua ausência, quando era exigido, é por si só uma infração, independentemente de o tratamento ter se mostrado prejudicial.
- Encarregados de proteção de dados
-
O GDPR exige um encarregado de proteção de dados em três situações: a organização é uma autoridade pública, suas atividades principais envolvem monitoramento regular e sistemático de pessoas em larga escala, ou suas atividades principais envolvem tratamento em larga escala de categorias especiais de dados ou de dados relativos a condenações penais. Número de empregados e faturamento não são o critério.
muitas organizações nomeiam um DPO voluntariamente, e isso traz consigo todas as obrigações legais: independência, recursos adequados, reporte direto ao mais alto nível da administração, proteção contra demissão pelo exercício da função e envolvimento em todas as questões de proteção de dados. Um DPO voluntário não é uma versão mais leve.
- Riscos da replicação de dados
-
A replicação de dados é a criação de cópias de dados para fins operacionais, de disponibilidade e analíticos: réplicas em espera ativa que garantem a continuidade se o sistema principal falhar, cópias de backup que permitem a recuperação após eventos de perda de dados, ambientes de DR que espelham a produção para testes de failover, ambientes de desenvolvimento e teste preenchidos c
o risco de replicação de dados é importante para TPRM porque a avaliação de segurança do fornecedor normalmente cobre o sistema principal: o banco de dados que o fornecedor descreve em sua documentação de segurança, que sua avaliação SOC 2 abrange e que seu processo de revisão de acessos mantém.
- Riscos de replicação de dados: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias verbais: inventário de réplicas, com todos os sistemas que mantêm dados de clientes e o status de propriedade e de controle de acesso; confirmação dos dados em ambientes de desenvolvimento, sejam dados sintéticos/mascarados ou dados de produção com controles equivalentes; confirmação do escopo de exclusão, com todas as réplicas incluídas nos processos de exclusão.
- Residência e soberania de dados
-
Residência de dados é onde os dados estão fisicamente armazenados. Soberania de dados é quais leis podem obrigar o acesso a eles. Um conjunto de dados armazenado em uma região de Frankfurt operada por uma empresa sediada nos Estados Unidos reside na Alemanha e está sujeito a processos judiciais dos EUA, porque o operador pode ser obrigado pela legislação dos EUA, independentemente de onde estejam os servidores.
os clientes perguntam sobre soberania e recebem respostas sobre residência. Um seletor de região em um console de nuvem atende à residência com um clique e não diz nada sobre soberania, porque a exposição jurídica do operador acompanha o operador, não o data center.
- Residência dos dados versus acesso
-
A residência de dados é uma restrição sobre onde os dados são armazenados fisicamente: qual centro de dados, qual país, qual jurisdição. É um controle relevante no contexto de requisitos de soberania de dados, regras de jurisdição regulatória e restrições a transferências internacionais que especificam onde os dados pessoais podem ficar armazenados.
compromissos de residência de dados são cada vez mais usados como mecanismo principal de conformidade com o GDPR, com o argumento de que dados armazenados na UE nunca passam por uma transferência internacional restrita nos termos do Capítulo V do GDPR.
- Residência de dados vs. acesso: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias verbais: mapa geográfico de acesso, com todos os locais a partir dos quais os dados da região designada são acessados e o fundamento de autorização de cada um; confirmação da geografia de replicação dos backups, dentro da região designada ou com mecanismos de transferência aprovados; confirmação da disponibilidade de logs sobre a geografia de acesso.
- Falhas de segregação de dados
-
A segregação de dados em ambientes multilocatários é a abordagem arquitetural e técnica usada para garantir que os dados de um cliente não possam ser acessados por meio da sessão autenticada de outro cliente.
as falhas de segregação de dados são importantes para TPRM porque representam uma categoria de risco específica de plataformas multilocatárias, que pode expor dados de clientes a outros clientes sem nenhum envolvimento de atacantes, por meio de bugs, erros de configuração e falhas de projeto intrínsecos à arquitetura multilocatária.
- Falhas de segregação de dados: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias verbais: descrição da arquitetura multilocatária, com o mecanismo específico de isolamento; confirmação do escopo do teste de intrusão entre locatários, com a quebra do isolamento como objetivo explícito; confirmação de segurança em nível de linha no banco de dados ou de outro isolamento arquitetural.
- Acordos de compartilhamento de dados
-
Quando dois controladores compartilham dados pessoais, cada um para suas próprias finalidades, o arranjo é de controlador para controlador e exige um acordo de compartilhamento de dados, e não um DPA do Artigo 28. O acordo abrange a finalidade do compartilhamento, a base legal em que cada parte se apoia, os dados compartilhados, as medidas de segurança, a forma de tratar as solicitações de direitos, o que cada parte informa aos titulares dos dados e o que acontece no encerramento.
Os DPAs do Artigo 28 regem relações com operadores e não se ajustam de forma alguma ao compartilhamento entre controladores. Um DPA determina que o operador atue somente conforme as instruções do controlador, o que não faz sentido entre dois controladores que decidem, cada um, suas próprias finalidades. Assiná-lo para um arranjo de compartilhamento documenta as duas partes em papéis que nenhuma delas ocupa.
- Aplicação da soberania de dados
-
Soberania de dados é o princípio segundo o qual os dados estão sujeitos às leis e regulamentos da jurisdição em que são armazenados ou tratados, e a organização que controla esses dados está protegida contra o acesso de governos estrangeiros, exceto por meio de mecanismos legais definidos: tratados de assistência jurídica mútua, ordens judiciais formais com a devid
a aplicação efetiva da soberania de dados é importante para TPRM porque clientes do setor público, setores regulados e organizações com obrigações de tratamento de dados de segurança nacional exigem cada vez mais uma soberania de dados genuína, e não uma soberania baseada apenas no local de armazenamento, que pode ser contornada pela estrutura societária e por leis extraterritoriais.
- Aplicação efetiva da soberania de dados: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias verbais: divulgação da estrutura societária, com a controladora final e sua jurisdição; avaliação da exposição a leis extraterritoriais na jurisdição da controladora; confirmação da segregação do acesso operacional, ou seja, do acesso da empresa controladora à infraestrutura.
- Solicitações de acesso dos titulares dos dados
-
Uma solicitação de acesso do titular dos dados é o exercício, por uma pessoa, do direito de obter os dados pessoais que uma organização mantém sobre ela, juntamente com as finalidades, os destinatários, o prazo de retenção e a origem. O controlador tem um mês para responder, prorrogável por mais dois meses no caso de solicitações complexas ou numerosas, e o prazo conta a partir do recebimento.
as solicitações chegam por qualquer canal. Um chamado de suporte, uma resposta a um e-mail de marketing, uma mensagem em redes sociais, um comentário em uma reclamação. Não há formulário obrigatório, e o prazo corre a partir do momento em que a organização a recebeu, não do momento em que alguém a reconheceu como uma DSAR e a encaminhou à equipe certa.
- Direitos dos titulares além do acesso
-
Além do acesso e da eliminação, o GDPR concede às pessoas o direito à retificação de dados inexatos, à limitação do tratamento em circunstâncias específicas, à oposição ao tratamento baseado no interesse legítimo ou para marketing direto, e direitos relativos a decisões automatizadas. Cada um tem o mesmo prazo de resposta de um mês e a mesma obrigação de responder.
os processos são construídos para solicitações de acesso, porque são as mais comuns, e improvisados para todo o resto. Uma oposição é tratada como uma eliminação. Um pedido de restrição nem sequer é reconhecido. Uma correção é aplicada em um sistema e não nos outros. Cada um desses casos é uma falha em atender a um direito, com as mesmas consequências de ignorar uma DSAR.
- Inconsistências na marcação de dados
-
A marcação de dados é a aplicação de rótulos de classificação, como níveis de sensibilidade, categorias de dados e requisitos de manuseio, aos elementos de dados em todos os sistemas onde eles existem. Uma marcação consistente garante que um elemento de dados carregue a mesma classificação e os controles correspondentes, qualquer que seja o sistema em que esteja.
a inconsistência na marcação de dados é importante para TPRM porque significa que os controles de proteção aplicados aos dados em seu sistema principal não se aplicam necessariamente aos mesmos dados em sistemas secundários, e os sistemas secundários podem ter populações de acesso muito mais amplas.
- Inconsistências na marcação de dados: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias verbais: descrição do mecanismo de propagação de rótulos ou reconhecimento da lacuna; documentação de um esquema canônico de classificação que abranja todos os sistemas; evidências de validação da consistência da classificação entre sistemas.
- Monitoramento do uso de dados
-
O monitoramento do uso de dados é a capacidade de observar como os dados estão de fato sendo tratados no ambiente de um fornecedor: quais consultas são executadas sobre eles, quais pipelines os consomem, quais produtos fazem referência a eles e se seu uso real é coerente com a especificação contratual de uso.
o monitoramento do uso de dados é importante para TPRM porque é o mecanismo que transforma um DPA de uma declaração de uso autorizado em um instrumento de governança exigível.
- Monitoramento do uso de dados: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias verbais: confirmação do monitoramento do uso interno, com logs de consultas e atribuição de pipelines; descrição do monitoramento dos dados de treinamento de ML; descrição da capacidade de detecção de violações de escopo.
- Proteção contra DDoS e resiliência dos fornecedores
-
a proteção contra DDoS e a resiliência são importantes para TPRM porque a disponibilidade da plataforma do fornecedor é uma dependência direta para os clientes corporativos cujas operações dependem dessa plataforma.
a proteção contra DDoS e a resiliência são importantes para TPRM porque a disponibilidade da plataforma do fornecedor é uma dependência direta para os clientes corporativos cujas operações dependem dessa plataforma.
- Proteção contra DDoS e resiliência de fornecedores: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias verbais: provedor e capacidade de mitigação de DDoS; procedimento e prazo de notificação ao cliente; cobertura de SLA para indisponibilidades relacionadas a DDoS.
- Riscos da administração delegada
-
A administração delegada é um recurso de plataformas de nuvem que permite que uma organização (um parceiro ou provedor de serviços gerenciados) administre o ambiente de nuvem de outra organização em nome dela: a equipe do parceiro pode acessar o tenant do cliente com privilégios administrativos usando suas próprias credenciais organizacionais, sem ser cri
os riscos da administração delegada são importantes para TPRM porque as relações de administração delegada representam uma das concessões de acesso de maior privilégio que uma organização pode dar a um fornecedor: acesso administrativo a todo um tenant de nuvem, regido pelas políticas de segurança do fornecedor, e não pelas do cliente.
- Riscos da administração delegada: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias verbais: justificativa operacional atual para cada relação de administração delegada; política de MFA para a equipe do parceiro nas sessões de administração delegada; especificação de funções GDAP, se houver relação de parceria com a Microsoft.
- Exclusão versus destruição
-
A exclusão remove os dados dos sistemas ativos, de modo que deixam de estar disponíveis na operação normal. A destruição os torna irrecuperáveis em todos os lugares onde existem, incluindo backups, réplicas, snapshots, logs, exportações para análise e caches. Uma solicitação de eliminação é atendida pela primeira e auditada com base na segunda.
os backups são onde a exclusão falha. Dados removidos do banco de dados de produção persistem nos backups noturnos durante o prazo de retenção deles, nas réplicas até que sincronizem, nas extrações do data warehouse até a próxima carga completa e nos logs até que sejam rotacionados. Um controlador que confirmou a exclusão enquanto tudo isso ainda guarda os dados fez uma declaração que não é verdadeira.
- Pontos cegos de dependências (SCA)
-
A Análise de Composição de Software é a prática de identificar e avaliar as bibliotecas de código aberto e de terceiros incluídas na árvore de dependências de uma aplicação: mapear de quais componentes a aplicação depende, quais vulnerabilidades conhecidas existem nesses componentes e quais obrigações de licença eles criam.
O Log4Shell demonstrou em larga escala o que os profissionais de risco de terceiros já entendiam na teoria: a postura de segurança de um fornecedor para as aplicações que entrega é determinada em grande parte pela postura de segurança de cada biblioteca em sua árvore de dependências, incluindo dependências que ele não escolheu e cuja existência talvez desconheça.
- Pontos cegos de dependências (SCA): as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias verbais: confirmação da cobertura de dependências transitivas, com o nome da ferramenta e a descrição do escopo da varredura; SBOM em formato CycloneDX ou SPDX, atualizado no último ciclo de lançamento; compromisso de tempo médio até a ciência para CVEs críticas em dependências, com um prazo, não uma descrição de processo.
- Ataques de confusão de dependências
-
A confusão de dependências é relevante para TPRM porque é um ataque à cadeia de suprimentos ao qual seus fornecedores podem estar vulneráveis, em especial fornecedores de software e de ferramentas de desenvolvimento que usam registros internos de pacotes junto com dependências públicas.
a confusão de dependências é relevante para TPRM porque é um ataque à cadeia de suprimentos ao qual seus fornecedores podem estar vulneráveis, em especial fornecedores de software e de ferramentas de desenvolvimento que usam registros internos de pacotes junto com dependências públicas.
- Ataques de confusão de dependências: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias verbais: reserva dos nomes de pacotes internos em registros públicos; isolamento do ambiente de build em relação ao acesso à rede externa; um fornecedor que confirma práticas seguras de build deve ser questionado especificamente sobre a mitigação de confusão de dependências. A segurança do ambiente de build inclui a configuração dos registros, e não apenas a revisão de código e a análise estática.
- Fixação de versões de dependências versus versões flutuantes
-
A fixação de dependências é relevante para TPRM porque especificações de versão flutuantes no código dos fornecedores significam que o software que um fornecedor entregou ontem pode ser diferente do software que ele gerar amanhã, mesmo que nenhum código da aplicação tenha sido alterado. Para a segurança da cadeia de suprimentos, a reprodutibilidade da resolução de dependências é um controle fundamental.
a fixação de dependências é relevante para TPRM porque especificações de versão flutuantes no código dos fornecedores significam que o software que um fornecedor entregou ontem pode ser diferente do software que ele gerar amanhã, mesmo que nenhum código da aplicação tenha sido alterado.
- Fixação de dependências versus versões flutuantes: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias verbais: existência de arquivos de travamento de dependências nos repositórios de produção; exigência desses arquivos no pipeline de CI/CD; ferramentas de atualização automatizada de dependências, como Dependabot ou Renovate.
- Automação da atualização de dependências
-
A qualidade da automação de atualização de dependências é relevante para TPRM porque a presença de automação é a confirmação fácil: confirmar que o Dependabot está configurado leva segundos. Saber se essa automação está de fato reduzindo a exposição a vulnerabilidades de dependências exige entender as taxas de merge, o envelhecimento do backlog e a priorização de atualizações de segurança.
a qualidade da automação de atualização de dependências é relevante para TPRM porque a presença de automação é a confirmação fácil: confirmar que o Dependabot está configurado leva segundos.
- Automação da atualização de dependências: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias verbais: taxa de criação e de merge de PR de atualizações de segurança; configuração da priorização de atualizações de segurança em relação às demais; um fornecedor que confirma o uso do Dependabot ou de automação de atualização de dependências deve ser solicitado a informar a taxa de merge. A automação configurada é a ferramenta. A taxa de merge é a métrica de eficácia. 847 PRs gerados e 23 com merge não é gestão de segurança de dependências.
- Isolamento dos ambientes de implantação
-
O isolamento dos ambientes de implantação é importante para TPRM porque ambientes de pré-produção que tratam dados de produção ou compartilham credenciais com sistemas de produção criam riscos de segurança que não são capturados nas avaliações de segurança do ambiente de produção.
o isolamento dos ambientes de implantação é importante para TPRM porque ambientes de pré-produção que tratam dados de produção ou compartilham credenciais com sistemas de produção criam riscos de segurança que não são capturados nas avaliações de segurança do ambiente de produção.
- Isolamento de ambientes de implantação: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias verbais: processo de sanitização de dados e confirmação de validação; documentação de credenciais separadas para cada nível de ambiente; um fornecedor que confirma controles de acesso aos dados de produção deve ser questionado sobre o isolamento de dados e credenciais nos ambientes de pré-produção. Os controles de produção protegem os dados de produção. O isolamento de ambientes determina se esses dados chegam a ambientes onde os mesmos controles não se aplicam.
- Recursos de reversão e recuperação de implantações
-
As capacidades de rollback são relevantes para TPRM porque determinam a rapidez com que um fornecedor consegue se recuperar de uma implantação problemática, inclusive de uma implantação que contenha uma vulnerabilidade ou um comprometimento da cadeia de suprimentos.
as capacidades de reversão são importantes para TPRM porque determinam a rapidez com que um fornecedor consegue se recuperar de uma implantação problemática, inclusive de uma implantação que contenha uma vulnerabilidade ou um comprometimento da cadeia de suprimentos.
- Capacidades de rollback e recuperação de implantações: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias verbais: exemplo recente de execução de reversão com medição de tempo; processo de avaliação da reversibilidade de migrações de banco de dados; infraestrutura de sinalizadores de funcionalidades para cenários complexos de reversão.
- Critérios de descrição
-
Os critérios de descrição, publicados como DC seção 200, regem o que a descrição de um sistema deve conter: os serviços prestados, os principais compromissos de serviço e requisitos do sistema, os componentes do sistema, os aspectos relevantes do ambiente de controle, os incidentes durante o período e os critérios utilizados. Toda descrição SOC 2 segue essa estrutura.
isso explica por que as descrições de sistema de fornecedores sem relação entre si parecem ter sido escritas a partir do mesmo modelo. E foram, no sentido de que os mesmos critérios as moldaram. Também significa que a falta de um elemento é perceptível: uma descrição sem seção de incidentes, ou sem declaração dos compromissos de serviço, omitiu algo que os critérios exigem.
- Pontos cegos de detecção
-
Os pontos cegos de detecção são as partes de um ambiente tecnológico que não estão cobertas pela configuração atual de monitoramento de segurança: os sistemas, serviços e ambientes que geram eventos relevantes para a segurança, mas não estão configurados para encaminhá-los à plataforma de monitoramento onde o SOC pode detectá-los e responder a eles.
os pontos cegos de detecção são relevantes para TPRM porque a cobertura de monitoramento de um fornecedor é tão abrangente quanto sua auditoria de configuração mais recente, e em ambientes de rápido crescimento a distância entre a configuração e o ambiente real pode representar uma fração significativa da superfície de ataque.
- Pontos cegos de detecção: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias verbais: comparação entre o inventário de ambientes e a configuração de monitoramento; percentual de cobertura do ambiente atual; confirmação do processo de implantação da configuração de monitoramento.
- Lacunas na engenharia de detecção
-
A engenharia de detecção é a disciplina de projetar, construir, testar e manter a lógica de detecção (regras de correlação, análises comportamentais e políticas de detecção de anomalias) que permite a um SIEM e a um SOC identificar atividades maliciosas em um ambiente específico.
as lacunas na engenharia de detecção são relevantes para TPRM porque a capacidade de detecção do SOC é tão boa quanto as regras que foram construídas e mantidas.
- Lacunas na engenharia de detecção: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias verbais: proporção entre regras personalizadas e regras padrão; quantidade de regras específicas do setor e cobertura de técnicas; frequência de testes das regras e data do último teste.
- Equilíbrio entre detecção e prevenção
-
O problema do equilíbrio entre detecção e prevenção na avaliação de segurança de fornecedores é o desafio de entender se o histórico limpo de violações de um fornecedor reflete uma capacidade de prevenção eficaz ou simplesmente uma baixa exposição a ataques. Ambos produzem o mesmo histórico de violações.
o equilíbrio entre detecção e prevenção é relevante para TPRM porque os alvos de ataques à cadeia de suprimentos são escolhidos especificamente por seu acesso a dados de alto valor, e fornecedores que guardam ou tratam dados de alto valor enfrentarão pressão crescente de ataques à medida que o valor desses dados se torna conhecido pelos agentes de ameaça.
- Equilíbrio entre detecção e prevenção: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias verbais: histórico de quase incidentes, ou seja, ataques significativos evitados; taxa e volume de bloqueios da segurança de e-mail; prazos de correção de vulnerabilidades críticas.
- Falhas de paridade entre desenvolvimento e produção
-
A paridade entre desenvolvimento e produção é o princípio de que os ambientes de desenvolvimento, homologação e produção devem ser o mais semelhantes possível, para evitar que surjam em produção problemas que não foram detectados nos testes.
para os profissionais de TPRM, a paridade entre desenvolvimento e produção é o problema de confiabilidade por trás de todo resultado de teste de segurança de fornecedores.
- Problemas de paridade entre desenvolvimento e produção: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias verbais: documentação do escopo do teste de intrusão que confirme testes no ambiente de produção ou uma verificação documentada de paridade entre o ambiente de homologação e a produção; divulgação das configurações específicas da produção, ou seja, quaisquer ajustes, funcionalidades ou integrações em produção não cobertos pelos testes de segurança; documentação do processo de gestão de mudanças em produção, incluindo revisão de segurança e sincronização dos testes.
- Confiança em dispositivos para acesso de fornecedores
-
A confiança no dispositivo é o componente da governança de acessos que avalia a postura de segurança do endpoint a partir do qual o acesso está sendo solicitado, determinando se o dispositivo é gerenciado pela organização (ou por uma organização confiável), atende a requisitos de conformidade definidos, tem proteção de endpoint atualizada e é capaz de responder a org
a confiança no dispositivo é relevante para TPRM porque o acesso do fornecedor aos ambientes do cliente faz com que dados de sessão, arquivos baixados e conteúdo em cache dos sistemas do cliente fiquem nos dispositivos dos engenheiros do fornecedor, e a segurança desses dados, uma vez no endpoint do fornecedor, depende inteiramente da postura de segurança de endpoints do fornecedor.
- Confiança em dispositivos para acesso de fornecedores: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias verbais: confirmação do registro em MDM dos dispositivos usados para acessar o cliente; documentação da política de conformidade dos dispositivos, com nível de atualização, proteção de endpoint e criptografia; confirmação da capacidade de apagamento remoto e do tempo de resposta.
- DevSecOps para sistemas legados
-
O DevSecOps em sistemas legados é importante para TPRM porque fornecedores corporativos frequentemente mantêm sistemas legados que continuam tratando dados críticos de negócio enquanto o fornecedor investe em modernização.
o DevSecOps de sistemas legados é relevante para TPRM porque fornecedores corporativos frequentemente mantêm sistemas legados que continuam a lidar com dados críticos de negócio enquanto o fornecedor investe em modernização.
- DevSecOps para sistemas legados: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias verbais: testes de segurança do processo de entrega legado, incluindo varredura de dependências e SAST; trilha de segurança do legado durante a migração; inventário da dívida de segurança do legado e plano de remediação.
- Modelo de maturidade de DevSecOps para avaliação de TPRM
-
A avaliação de maturidade em DevSecOps é relevante para TPRM porque a qualidade do software de um fornecedor, especificamente a densidade de vulnerabilidades não detectadas no código entregue, está diretamente correlacionada com a eficácia do seu programa de DevSecOps, e não apenas com a sofisticação com que ele é descrito.
a avaliação de maturidade em DevSecOps é importante para TPRM porque a qualidade do software de um fornecedor, especificamente a densidade de vulnerabilidades não detectadas no código entregue, está diretamente correlacionada à eficácia do seu programa de DevSecOps, e não apenas à sofisticação com que ele é descrito.
- Modelo de maturidade em DevSecOps para avaliação de TPRM: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias: número de controles de bloqueio obrigatório vs. consultivos; acúmulo atual de achados críticos e altos; variação líquida desse acúmulo no último trimestre.
- Digital Trust Common Framework DTCF
-
O framework comum de controles da associação: objetivos normalizados e mapeados para os frameworks com que os profissionais trabalham, publicado gratuitamente.
Os mapeamentos são graduados, e uma célula vazia é registrada como ausência deliberada, com seu motivo, em vez de ser ocultada.
Veja também: Escopo, Responsável pelo controle
- Regras de marketing direto
-
O marketing direto eletrônico na Europa é regido pela Diretiva ePrivacy, implementada nacionalmente como PECR no Reino Unido e por equivalentes em outros países, em conjunto com o GDPR, e não substituída por ele. A ePrivacy estabelece regras para e-mails, SMS e chamadas não solicitados, geralmente exigindo consentimento prévio de pessoas físicas, com uma exceção de soft opt-in para clientes existentes, e aplica regras diferentes a assinantes corporativos.
as equipes atendem ao GDPR identificando uma base legal e presumem que o marketing está coberto. Não está. O GDPR rege o tratamento dos dados pessoais; a ePrivacy rege o envio da mensagem, e ambas precisam ser atendidas. Uma base de interesses legítimos nos termos do GDPR não se sobrepõe a uma exigência de consentimento da ePrivacy.
- Segurança de DNS e risco de fornecedores
-
a segurança de DNS é importante para TPRM porque os controles na camada de DNS são uma capacidade de prevenção e detecção de bom custo-benefício que reduz significativamente a eficácia do phishing e da comunicação C2 de malware, ambos vetores de ataque primários contra funcionários de fornecedores.
a segurança de DNS é importante para TPRM porque os controles na camada de DNS são uma capacidade de prevenção e detecção de bom custo-benefício que reduz significativamente a eficácia do phishing e da comunicação C2 de malware, ambos vetores de ataque primários contra funcionários de fornecedores.
- Segurança de DNS e risco de fornecedores: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias verbais: confirmação de filtragem de DNS com inteligência de ameaças; um fornecedor que confirma a segurança de rede deve ser questionado sobre a segurança de DNS. A filtragem de DNS bloqueia phishing e a resolução de C2 na camada de rede. O registro de DNS dá visibilidade sobre indicadores de comprometimento. Ambos são controles na camada de rede que reduzem significativamente a eficácia dos ataques a baixo custo.
- Profundidade da diligência prévia versus nível do fornecedor
-
A profundidade da diligência prévia é importante porque o risco que um fornecedor representa não é reduzido pela coleta de evidências que confirmam que os controles do fornecedor estão documentados, mas sim pela compreensão de se esses controles estão efetivamente implementados.
a profundidade da due diligence é importante porque o risco que um fornecedor representa não diminui com a coleta de evidências de que os controles do fornecedor estão documentados; ele diminui com o entendimento de se esses controles estão implementados de forma eficaz.
- Profundidade da due diligence versus nível do fornecedor: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias verbais: relatório SOC 2 com a descrição dos testes realizados; esclarecimento das inclusões e exclusões do escopo; carta-ponte para atualização, se o relatório tiver mais de seis meses.
- Questionários de diligência prévia
-
Um questionário de due diligence é um conjunto de perguntas enviado a um fornecedor sobre suas práticas de segurança e privacidade. As respostas mostram o que o fornecedor está disposto a assumir por escrito, o que é útil, e quais práticas ele diz que existem, o que é uma alegação. O questionário não mostra se um controle funciona, porque o fornecedor está descrevendo uma intenção e ninguém a testou.
os questionários são o instrumento mais usado e menos examinado de toda a disciplina. Centenas de perguntas são enviadas, as respostas voltam semanas depois, alguém as pontua e, depois disso, ninguém consegue dizer o que foi estabelecido além do fato de que o fornecedor preenche questionários. Ainda assim, os compradores continuam a enviá-los, porque são a única coisa que escala.
E
- Monitoramento de empregados
-
O monitoramento no ambiente de trabalho, seja de e-mail, uso da web, localização, digitação ou produtividade, é tratamento de dados pessoais e atrai plenamente a legislação de proteção de dados. O consentimento geralmente é uma base inválida para ele, porque o desequilíbrio de poder entre empregador e empregado significa que o consentimento não pode ser dado livremente. Os interesses legítimos, com uma avaliação documentada e transparência real, são o caminho defensável habitual, e algumas jurisdições acrescentam requisitos específicos da legislação trabalhista.
ferramentas de monitoramento são frequentemente implantadas com base em uma cláusula de consentimento no contrato de trabalho, sob a tese de que assinar o contrato foi consentimento. Não foi, e os reguladores já disseram isso repetidamente. O empregado não tinha uma escolha realista, e consentimento sem escolha não é consentimento.
- Criptografia em repouso versus em uso
-
A confirmação de criptografia em repouso é um dos controles de segurança citados com mais frequência nas respostas a questionários de fornecedores: é visível, auditável e documentada nos relatórios SOC 2.
a confirmação de criptografia em repouso é um dos controles de segurança citados com mais frequência nas respostas a questionários de fornecedores: é visível, auditável e documentada nos relatórios SOC 2.
- Criptografia em repouso versus em uso: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias verbais: descrição da arquitetura de gestão de chaves, com o serviço de KMS e a segregação entre o acesso às chaves e o acesso aos dados; descrição da proteção em uso, com controles de acesso, criptografia em nível de campo ou computação confidencial para os dados de maior sensibilidade; confirmação de cobertura de TLS para a comunicação entre serviços internos.
- Níveis de risco da Lei de IA da UE
-
A Lei de IA da UE classifica os sistemas de IA pelo uso, e não pela técnica. As práticas proibidas são vedadas por completo. Os usos de alto risco, listados em seus anexos e que incluem emprego, crédito, educação, serviços essenciais e aplicação da lei, implicam obrigações substanciais. Os sistemas com obrigações de transparência, como os que interagem com pessoas ou geram conteúdo, devem informar isso. Todo o restante tem poucas obrigações além da legislação comum.
o nível decide tudo, e a maioria das organizações avalia como se a pergunta não existisse. Um modelo que prioriza a reposição de estoque e um que classifica candidatos a emprego têm arquitetura semelhante e obrigações totalmente diferentes, porque o segundo é um uso de alto risco. Seu papel também importa: os fornecedores que colocam um sistema no mercado assumem mais do que os responsáveis pela implantação que o utilizam, embora os responsáveis pela implantação de sistemas de alto risco tenham deveres reais, incluindo supervisão humana e monitoramento.
- Evidências
-
Um artefato que mostra que um controle operou: datado, atribuível, completo e produzido quando o controle foi executado.
A contemporaneidade é a propriedade violada com mais frequência, e de boa-fé. Evidências reunidas no momento em que são solicitadas custam semanas e parecem exatamente o que são.
Ensinado em GRC-220 · Veja também: População e amostra, Responsável pelo controle
- Calendários de evidências
-
Um calendário de evidências lista, para cada controle, o artefato que comprova sua execução, o sistema de origem, o produtor nomeado, a cadência, a retenção e o local de armazenamento. As evidências para um relatório Tipo II ou para uma certificação precisam cobrir todo o período, por isso são produzidas mensal e trimestralmente durante a janela, e não reunidas no final, e é o calendário que faz isso acontecer.
a maior parte da dor de uma auditoria é dor de evidências. Os controles geralmente funcionam. O que falha é a capacidade de mostrar que funcionaram, durante o período, a partir de uma fonte em que o auditor possa confiar, sem três semanas de pessoas vasculhando sistemas. Chega uma lista de quarenta itens solicitados, cada um vai para um responsável pelo controle que exporta uma coisa e tira captura de tela de outra, metade dos artefatos não tem data, e dois foram produzidos nesta semana para um controle que deveria ser executado trimestralmente.
- Suficiência das evidências
-
Uma evidência suficiente mostra o que aconteceu, quando aconteceu, em qual sistema, por quem, e cobre o período testado. É completa o bastante para que o auditor não precise confiar na palavra de ninguém sobre as partes que ela não mostra.
a maioria das evidências rejeitadas não está errada. Está incompleta. Uma captura de tela sem data e hora, sem identificador do sistema e sem indicação de escopo prova que algo existiu em um momento desconhecido, em uma tela desconhecida. Ela não pode ser vinculada ao controle, ao período ou à população, então não pode sustentar uma conclusão.
- Evidência versus atestação
-
Atestação é uma declaração feita por uma pessoa autorizada afirmando que uma condição é verdadeira, normalmente com base em seu conhecimento, convicção ou entendimento das políticas, padrões e práticas da organização.
a distinção entre evidência e atestação é relevante para TPRM porque o risco de segurança criado por uma relação com fornecedor é determinado pela configuração real dos sistemas que lidam com os dados do cliente, e não pelo padrão da organização nem pela convicção do CISO de que cumpre esse padrão.
- Evidência versus atestação: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias verbais: registros de configuração de criptografia por sistema ou saída do CSPM; lista de todos os sistemas que mantêm dados de clientes, com sua configuração de criptografia; documentação das exceções, ou seja, sistemas que não seguem o padrão declarado.
- Abuso da gestão de exceções
-
A gestão de exceções é o mecanismo de governança para reconhecer que circunstâncias operacionais específicas criam restrições reais que impedem a implementação de um requisito de segurança de referência, e para gerenciar formalmente essas situações com controles compensatórios, aceitação documentada do risco residual e prazos definidos para r
o abuso da gestão de exceções é importante para TPRM porque as linhas de base de segurança dos fornecedores confirmadas por questionários podem ter registros de exceções extensos que excluem sistematicamente partes significativas do ambiente dos requisitos da linha de base.
- Abuso da gestão de exceções: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias verbais: distribuição das exceções por idade e contagem de recorrências; taxa de conformidade de referência para requisitos críticos; roteiros de implementação para exceções de adiamento.
- Processos de exceção
-
Uma exceção é a decisão de que um controle ou uma política não se aplicará em um caso específico por um período específico. Ela exige tudo o que uma aceitação exige, além de um escopo e de uma revisão antes do vencimento. A patologia é a exceção permanente: concedida para uma migração de seis meses, nunca revista, ainda em vigor quatro anos depois e agora utilizada por sistemas construídos depois dela.
um programa de controles sem uma via de exceção produz dois resultados, e ambos são ruins. As pessoas contornam o controle discretamente, ou param e o negócio fica bloqueado. O processo de exceção é o que permite que o controle se mantenha enquanto o caso realmente excepcional é tratado de forma visível, com um nome, um motivo e uma data.
- Remediação de exceções e resposta da administração
-
Quando um relatório Tipo II descreve uma exceção, a administração pode incluir uma resposta: o que aconteceu, por quê, o que foi feito a respeito e quando. A resposta é da administração, não do auditor, e o auditor a reporta sem testá-la.
a resposta diz mais sobre a organização do que a exceção. Uma remediação específica e datada, com um responsável nomeado e uma mudança no controle, é lida de forma muito diferente de um parágrafo de garantias, e essa diferença é um sinal direto de como a organização trata as próprias falhas.
- Exceções
-
Uma exceção é um caso em que um controle não funcionou conforme descrito durante o período de observação. Uma revisão trimestral de acessos feita com atraso. Um usuário desligado cujo acesso continuou ativo por uma semana. Uma mudança implantada sem a aprovação registrada. O relatório descreve a exceção, os testes do auditor e a resposta da administração.
exceções são normais. Qualquer organização que opere controles por doze meses deixará passar algo, e um relatório que descreve o que falhou e o que foi feito a respeito está fazendo exatamente o que um relatório deve fazer. O número de exceções importa menos do que quais são e como a administração respondeu.
F
- Falsos positivos versus riscos ignorados
-
A governança de falsos positivos nos programas de segurança dos fornecedores é diretamente relevante para TPRM porque determina o que as ferramentas de segurança do fornecedor estão de fato encontrando e tratando, em comparação com o que estão encontrando e descartando.
a governança de falsos positivos nos programas de segurança dos fornecedores é diretamente relevante para TPRM porque determina o que as ferramentas de segurança do fornecedor estão de fato encontrando e tratando, em comparação com o que estão encontrando e descartando.
- Falsos positivos versus riscos ignorados: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias verbais: dados da taxa de supressão por nível de severidade, ou seja, que percentual dos achados de cada severidade é suprimido em vez de remediado; documentação do fluxo de aprovação de supressões que confirme a exigência de revisão de segurança para achados altos e críticos; confirmação da correlação entre o teste de intrusão e o SAST, ou seja, se algum achado do teste de intrusão correspondeu a achados de SAST suprimidos anteriormente.
- Higiene das regras de firewall e redes de fornecedores
-
A higiene das regras de firewall é relevante para TPRM porque a arquitetura de segurança de rede declarada por um fornecedor só é precisa na medida em que seu conjunto de regras de firewall a reflete.
a higiene das regras de firewall é relevante para TPRM porque a arquitetura de segurança de rede declarada por um fornecedor só é precisa na medida em que seu conjunto de regras de firewall a reflete.
- Higiene das regras de firewall e redes de fornecedores: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias verbais: quantidade de regras de firewall e data da última revisão; um fornecedor que confirma a segurança do firewall deve ser questionado sobre a higiene das regras. A segurança do firewall é a combinação da arquitetura do firewall com a qualidade das regras que a implementam. Um firewall com 3,847 regras de justificativa desconhecida não implementa com precisão a arquitetura de segurança pretendida.
- Desafios de acesso para perícia forense
-
Os desafios de acesso para perícia são os obstáculos práticos, jurídicos e contratuais para obter as evidências forenses, como logs, imagens forenses, capturas de memória e registros de tráfego de rede, necessárias para conduzir uma investigação independente de um incidente de segurança ocorrido no ambiente de um fornecedor.
os desafios de acesso para perícia são relevantes para TPRM porque clientes que não conseguem conduzir uma investigação forense independente de uma violação em um fornecedor não conseguem determinar a própria exposição com a especificidade necessária para comunicações regulatórias, acionamento de seguros e processos judiciais.
- Desafios de acesso para perícia: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias verbais: procedimento de acesso forense em cenário de violação; compromisso de preservação de evidências antes da remediação; limitação da retenção para fins de litígio quando se tratar de investigação do cliente.
- Quarta parte
-
O fornecedor do seu fornecedor: os provedores por trás das empresas com as quais você contrata.
Você não os escolheu e não consegue vê-los sem procurar. Os mesmos poucos nomes estão por trás de muitos fornecedores, por isso a aparente diversificação muitas vezes não existe.
Ensinado em TPR-250 · Veja também: Risco de concentração, Organização subcontratada
- Risco de quartas partes
-
Uma quarta parte é o fornecedor do seu fornecedor: a nuvem em que o software dele roda, o processador de pagamentos dentro da ferramenta de faturamento, o serviço de transcrição dentro da plataforma de suporte. Você não os escolheu, não tem contrato com eles, e uma interrupção ou uma violação em um deles chega até você por meio de uma empresa da qual você nunca ouviu falar.
aqui vivem dois problemas, e eles exigem respostas diferentes. Visibilidade, quando você não consegue dizer quem está na cadeia até que algo quebre. E concentração, quando muitos dos seus fornecedores supostamente independentes acabam rodando sobre o mesmo punhado de provedores, de modo que uma única falha chega por várias portas ao mesmo tempo e sua diversificação era um conjunto de logotipos sobre uma só plataforma.
- Cegueira ao risco de quartas partes
-
O risco de quartas partes é importante porque a superfície de ataque da empresa se estende pelas cadeias de suprimentos dos seus fornecedores, e não apenas pelos próprios fornecedores.
o risco de quartas partes é importante porque a superfície de ataque da empresa se estende pelas cadeias de suprimentos dos seus fornecedores, e não apenas pelos próprios fornecedores.
- Cegueira ao risco de quartas partes: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias verbais: lista completa de subcontratados com a função de cada um; identificação dos provedores de infraestrutura e de autenticação; confirmação do próprio programa de risco de terceiros do fornecedor.
G
- Risco geopolítico na seleção de fornecedores
-
O risco geopolítico é importante porque cria uma categoria de risco de fornecedores que as avaliações técnicas de segurança tradicionais não tratam: o risco decorrente do ambiente jurídico em que existem o pessoal, a estrutura societária e as operações do fornecedor. Os controles técnicos protegem os dados contra o acesso não autorizado por atacantes.
o risco geopolítico é importante porque cria uma categoria de risco de fornecedores que as avaliações técnicas de segurança tradicionais não abordam: o risco decorrente do ambiente jurídico em que existem o pessoal, a estrutura societária e as operações do fornecedor.
- Risco geopolítico na seleção de fornecedores: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias verbais: divulgação das jurisdições do pessoal em funções com acesso a dados; análise das leis de acesso governamental nas jurisdições divulgadas; base jurídica para notificar o cliente caso ocorra acesso governamental.
- Padrões de segurança em GitOps
-
A segurança de GitOps é importante para TPRM porque implementações de GitOps que concedem permissões amplas ao operador criam um caminho direto entre o acesso de merge no repositório Git e o controle do cluster de produção.
a segurança de GitOps é importante para TPRM porque implementações de GitOps que concedem permissões amplas ao operador criam um caminho direto entre o acesso de merge no repositório Git e o controle do cluster de produção.
- Padrões de segurança de GitOps: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias verbais: controles de acesso ao repositório GitOps e aprovação de merge; um fornecedor que confirma a implantação via GitOps deve ser questionado sobre o RBAC do operador. As permissões do operador GitOps definem o raio de impacto do acesso de merge ao repositório GitOps. Um operador com perfil cluster-admin e acesso de merge aberto cria autoridade de implantação cluster-admin para qualquer pessoa com acesso de merge.
- Global Privacy Control GPC
-
Um sinal do navegador que indica que o usuário se opõe à venda ou ao compartilhamento de suas informações pessoais.
Em vários estados dos EUA, um sinal recebido é uma oposição válida. Ele chega como cabeçalho, por isso precisa ser tratado por código antes de qualquer tag ser disparada, e não por um banner.
Ensinado em PRV-230 · Veja também: Venda e compartilhamento, Plataforma de gestão de consentimento
- Lacunas de responsabilização na governança
-
A responsabilização na governança é o senso pessoal de obrigação e de responsabilidade, sentido por uma pessoa específica, de garantir que o relacionamento com um fornecedor seja governado de forma eficaz, que os riscos sejam gerenciados e que, quando algo dá errado, sejam tomadas ações decisivas sem esperar permissão ou instruções.
as lacunas de responsabilização na governança são importantes para TPRM porque uma gestão eficaz de riscos de fornecedores, especialmente em situações críticas como incidentes de segurança em fornecedores, exige pessoas que assumam pessoalmente o resultado e ajam com determinação.
- Lacunas de responsabilização na governança: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias verbais: pessoa nomeada com responsabilidade sobre todo o relacionamento; dados de contato direto, incluindo número de celular para notificação de incidentes fora do horário comercial; confirmação de que ela conhece as obrigações contratuais de notificação.
- Ambiguidade sobre a responsabilidade pela governança
-
A ambiguidade sobre quem é dono da governança nas relações com fornecedores é a ausência de um único responsável pela relação como um todo, a pessoa ou função encarregada de garantir que a relação funcione como previsto, que os riscos sejam gerenciados em todas as dimensões e que o escalonamento e a resposta sejam coordenados quando surgem problemas a
a ambiguidade sobre a responsabilidade pela governança é importante para TPRM porque relacionamentos complexos com fornecedores inevitavelmente enfrentam situações que exigem resposta coordenada: incidentes de segurança, falhas de serviço, consultas regulatórias, disputas contratuais e mudanças relevantes no fornecedor.
- Ambiguidade sobre a responsabilidade pela governança: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias verbais: responsável nomeado pelo relacionamento com o cliente; processo de encaminhamento das notificações de incidentes, mostrando como as notificações chegam ao responsável; prazo de escalonamento entre incidentes de segurança e a notificação ao cliente.
- Limitações das ferramentas de GRC
-
As limitações das ferramentas de GRC são as lacunas entre o que uma plataforma de GRC é tecnicamente capaz de gerenciar e o que o programa de gestão de riscos efetivamente a usa para gerenciar.
as limitações das ferramentas de GRC são importantes para TPRM porque a plataforma de GRC é cada vez mais usada como evidência da maturidade do programa de riscos: em fiscalizações regulatórias, nos relatórios ao conselho e na documentação de due diligence de fornecedores.
- Limitações das ferramentas de GRC: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias verbais: documentação do processo de entrada de informações no programa de GRC; registros da formalização de canais informais de risco; avaliação da cobertura da plataforma em relação ao panorama de riscos.
H
- Credenciais embutidas no código de aplicações de fornecedores
-
Credenciais embutidas no código são valores de autenticação (nomes de usuário, senhas, chaves de API, chaves criptográficas, tokens ou certificados) inseridos diretamente no código-fonte, no binário compilado, no firmware, no arquivo de configuração ou no script de implantação de uma aplicação, de forma que não podem ser alterados pelos mecanismos normais de configuração.
as credenciais embutidas no código de aplicações de fornecedores representam uma categoria de risco que está inteiramente fora do controle do cliente e inteiramente dentro do código do fornecedor, uma combinação que cria uma posição de governança específica e desconfortável.
- Credenciais embutidas no código de aplicações de fornecedores: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias verbais: evidências da configuração de SAST que confirmem que as regras de detecção de credenciais estão ativas e aplicadas a todo o código; documentação das credenciais padrão, com a divulgação completa de quaisquer padrões entregues com a aplicação e do mecanismo de alteração disponível aos clientes; confirmação de que o escopo do teste de intrusão inclui explicitamente a descoberta de credenciais embutidas no código.
- Sistemas de IA de alto risco
-
Um sistema de IA de alto risco, nos termos da Lei de IA da UE, é aquele usado em um contexto que a lei lista em seus anexos: recrutamento e gestão de trabalhadores, avaliação de crédito, educação e correção de provas, acesso a serviços essenciais, aplicação da lei, migração e administração da justiça, entre outros. A lista trata do que o sistema decide e sobre quem. Um modelo simples em um uso de alto risco é de alto risco; um modelo sofisticado que resume suas atas de reunião não é.
a maioria das organizações é responsável pela implantação de sistemas comprados de fornecedores, e esse é o caso avaliado com mais frequência como se não houvesse deveres aplicáveis. Quem implanta um sistema de alto risco deve garantir supervisão humana por pessoas competentes, monitorar o funcionamento do sistema, manter registros, usá-lo de acordo com as instruções do fornecedor e informar as pessoas afetadas. Nada disso é um controle de segurança, e nada disso aparece no SOC 2 do fornecedor.
- Supervisão humana
-
A supervisão humana é o desenho que permite a uma pessoa intervir nas decisões de um sistema de IA, e ela só é real sob quatro condições. O revisor vê o suficiente para julgar, ou seja, o resultado e os fatores por trás dele, e não apenas uma pontuação. Ele tem tempo, medido em relação à meta real de atendimento. Tem competência para a decisão. E contrariar o sistema é profissionalmente seguro, ou seja, ele não é avaliado de uma forma que o penalize por isso.
"um humano revisa todas as saídas" é a frase mais comum na documentação de governança de IA e uma das menos informativas. Remova qualquer uma das quatro condições e a supervisão vira uma assinatura. A quarta é a que as organizações raramente examinam e costuma ser a restrição determinante: um revisor avaliado por casos por hora não vai gastar dois minutos discordando de um modelo.
I
- Lacunas na detecção de anomalias de identidade
-
A detecção de anomalias de identidade é a capacidade de identificar padrões de acesso que se desviam do comportamento normal estabelecido, detectando eventos de autenticação, padrões de acesso, transferências de dados e características de sessão incompatíveis com o comportamento de referência de um usuário ou que representam padrões de ataque conhecidos.
a detecção de anomalias de identidade é relevante para TPRM porque a equipe do fornecedor que acessa os ambientes do cliente cria um padrão de comportamento de identidade que deveria ser detectável como anômalo quando se desvia da atividade normal de suporte ou de operação.
- Lacunas na detecção de anomalias de identidade: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias verbais: análise de detecção do cenário de ataque, ou seja, quais sinais o ataque descrito acionaria; implantação de UEBA com linhas de base comportamentais individuais; processo de estabelecimento da linha de base de acesso do fornecedor.
- Expansão da superfície de ataque de identidades
-
A superfície de ataque de identidades é o conjunto de todos os pontos de autenticação, sistemas de identidade e repositórios de credenciais que uma organização opera: todo sistema em que um atacante poderia tentar se autenticar como usuário válido e obter acesso.
a expansão da superfície de ataque de identidade é relevante para TPRM porque fornecedores que cresceram por meio de aquisições, adoção de SaaS e migração para a nuvem podem ter uma superfície de ataque de identidade significativamente maior do que sugere a descrição do seu IdP centralizado.
- Expansão da superfície de ataque de identidades: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias verbais: inventário completo dos sistemas de identidade, além do IdP corporativo; comparação das políticas de autenticação entre todos os sistemas de identidade; configuração de autenticação em SaaS, comparando IdP corporativo e diretório local.
- Raio de impacto do comprometimento de identidades
-
O raio de impacto é o conjunto de sistemas, dados e capacidades que se tornam acessíveis a um invasor ao comprometer uma credencial de identidade específica. É a resposta à pergunta: se esta credencial fosse roubada agora, quanto um invasor poderia fazer com ela?
o raio de impacto é relevante para TPRM porque relações com fornecedores que atendem vários clientes criam a possibilidade de ataques à cadeia de suprimentos com uma única credencial, em que comprometer uma identidade do fornecedor dá acesso simultâneo aos ambientes de vários clientes.
- Raio de impacto do comprometimento de identidades: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias verbais: escopo máximo de acesso a ambientes de clientes por credencial; política de limite do raio de impacto, se definida; acesso JIT para credenciais com grande raio de impacto.
- Riscos de confiança na federação de identidades
-
A federação de identidades é uma relação de confiança entre provedores de identidade que permite que usuários de uma organização acessem recursos de outra organização usando as credenciais de sua organização de origem.
os riscos de confiança na federação de identidades são relevantes para TPRM porque representam o equivalente, em IAM, do ataque à cadeia de suprimentos: o adversário que não consegue invadir o alvo diretamente compromete um parceiro confiável e usa a relação de confiança para obter acesso.
- Riscos de confiança na federação de identidades: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias verbais: documentação da política de MFA do IdP do parceiro, com o nível de aplicação e eventuais exceções; processo de notificação de comprometimento do IdP do parceiro, com prazos; governança do ciclo de vida de identidades, com a cadência de revisão de contas e o processo de desprovisionamento.
- Lacunas na governança de identidades
-
A governança de identidades é o programa de políticas, processos e ferramentas que garante que as identidades digitais (contas de usuário, contas de serviço, credenciais API e outras entidades de acesso) sejam criadas de forma adequada, mantidas de forma proporcional e desativadas no momento certo ao longo de sua vida operacional.
as lacunas na governança de identidades são relevantes para TPRM porque revelam uma diferença sistemática de maturidade de governança entre a forma como um fornecedor gerencia as identidades de seus próprios empregados e a forma como gerencia as identidades da equipe do fornecedor que acessa os ambientes do cliente.
- Lacunas na governança de identidades: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias verbais: documentação do escopo de cobertura do IGA, com as populações de identidades incluídas; inventário de contas de fornecedores com a data da última conciliação; dados da taxa de conclusão das revisões de acesso por população de identidades.
- Lacunas no registro de identidades
-
O registro de eventos de identidade é a captura abrangente de todos os eventos relacionados à identidade em um ambiente: tentativas de autenticação (bem-sucedidas e malsucedidas), decisões de autorização (acesso concedido e negado), eventos do ciclo de vida de sessões (criação, extensão, expiração e encerramento de sessões), registros de ações privilegiadas (o que os usuários privilegiados fizeram du
as lacunas no registro de identidades são importantes para TPRM porque fornecedores que acessam ambientes de clientes precisam de um registro abrangente de identidades para detectar ataques contra seus próprios ambientes antes que esses ataques cheguem aos dados dos clientes.
- Lacunas no registro de eventos de identidade: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias verbais: documentação do escopo dos eventos de log de identidade, com os tipos de evento capturados; confirmação do registro de falhas de autenticação com alertas de SIEM; prazo de retenção dos logs calibrado conforme os requisitos de investigação.
- Verificação de identidade de fornecedores
-
A verificação de identidade é o processo de confirmar que a pessoa que solicita o acesso, ou para quem o acesso está sendo solicitado, é quem diz ser, estabelecendo um vínculo confiável entre uma identidade digital (uma conta e uma credencial) e uma pessoa específica do mundo real com identidade confirmada.
a verificação de identidade de fornecedores é relevante para TPRM porque as propriedades de segurança do acesso de fornecedores, como menor privilégio, responsabilização individual e monitoramento comportamental, dependem todas da premissa de que a identidade do titular da conta é exata.
- Verificação de identidade de fornecedores: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias verbais: confirmação da verificação de vínculo empregatício da equipe indicada; documentação do processo autorizado de indicação, ou seja, quem pode indicar e em que nível; política de divulgação de subcontratados e governança de acessos.
- Premissas de confiança em identidades
-
Premissas de confiança em identidades são as crenças implícitas sobre a postura de segurança e a confiabilidade dos sistemas de identidade e das práticas de acesso dos fornecedores que sustentam as concessões de acesso, os controles de acesso e as configurações de monitoramento aplicados aos relacionamentos com fornecedores.
as premissas de confiança em identidades são relevantes para TPRM porque os controles de acesso, as configurações de monitoramento e as mitigações de risco aplicados ao acesso das identidades do fornecedor são calibrados de acordo com o nível de confiança atribuído ao fornecedor na avaliação.
- Premissas de confiança em identidades: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias verbais: divulgação de mudanças organizacionais, como aquisições, mudanças na liderança e migrações de infraestrutura; divulgação de incidentes de segurança, inclusive os abaixo do limite de notificação; dados de monitoramento contínuo da postura de segurança.
- Movimentação lateral baseada em identidade
-
A movimentação lateral baseada em identidade é a técnica de percorrer um ambiente encadeando etapas legítimas de identidade e permissão: usar um conjunto de credenciais válidas para obter outro, usar o acesso a um recurso para descobrir ou acessar credenciais de outro e avançar progressivamente em direção a um alvo de alto valor por meio de uma sequência de i
a movimentação lateral baseada em identidades é importante para TPRM porque os ambientes de fornecedores com acesso aos sistemas dos clientes são justamente aqueles em que o comprometimento de uma credencial pode se propagar por cadeias de permissões até chegar aos dados ou à infraestrutura dos clientes.
- Movimentação lateral baseada em identidades: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias verbais: ferramenta de análise de caminhos de ataque e data da última análise; registros de remediação de caminhos de movimentação lateral; documentação das restrições de acesso aos repositórios de credenciais.
- Classificação de incidentes
-
A classificação de incidentes é a escala de severidade que decide, nos primeiros minutos, quem é acordado, com que frequência são emitidas atualizações de status, se o jurídico é acionado e se um engenheiro pode tirar um sistema do ar sem pedir autorização. Três ou quatro níveis, cada um com gatilhos objetivos que a pessoa que encontra o problema consegue aplicar, e cada um com uma resposta definida.
a primeira hora de um incidente é gasta com perguntas que poderiam ter sido respondidas com antecedência, e a discussão sobre se isso é grave o bastante para ser escalonado é a mais cara delas. Uma escala sem gatilhos vira essa discussão no pior momento. Uma escala com gatilhos a transforma em uma consulta, e a resposta segue automaticamente.
- Falhas de comunicação de incidentes
-
As falhas de comunicação de incidentes nas relações com fornecedores são as falhas no fluxo de informações específicas e tecnicamente úteis da equipe de IR do fornecedor para a equipe de IR do cliente durante um incidente compartilhado, falhas que prejudicam a capacidade do cliente de entender a própria exposição, cumprir suas próprias obrigações regulatórias e con
as falhas de comunicação em incidentes são importantes para TPRM porque a capacidade do cliente de cumprir suas próprias obrigações regulatórias (avaliação de risco de violação segundo o HIPAA, notificação GDPR, comunicação de incidentes no setor de serviços financeiros) depende de obter do fornecedor informações técnicas específicas dentro dos prazos regulatórios aplicáveis.
- Falhas de comunicação em incidentes: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias verbais: contato IR nomeado para comunicação técnica durante incidentes; compromisso de fornecer detalhes técnicos específicos dentro de um prazo definido; processo de comunicação de IR para IR que evite o atraso da revisão jurídica.
- Escalonamento de incidentes entre fornecedores
-
O escalonamento de incidentes entre fornecedores é o desafio de garantir que incidentes de segurança em ambientes de fornecedores que afetam dados de clientes sejam escalonados ao cliente, e às autoridades regulatórias, em prazos que atendam às obrigações regulatórias do cliente, e não apenas aos SLAs internos de gestão de incidentes do fornecedor.
o escalonamento de incidentes entre fornecedores é importante para TPRM porque as obrigações regulatórias do cliente são determinadas pela lei, não pela classificação de incidentes do fornecedor.
- Escalonamento de incidentes entre fornecedores: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias verbais: critérios de classificação de incidentes para sistemas relevantes ao cliente; prazo de notificação preliminar a partir da detecção; confirmação de que o SLA de notificação está calibrado conforme o prazo regulatório do cliente.
- Confusão sobre a responsabilidade por incidentes
-
A confusão sobre a responsabilidade por incidentes é a ausência de uma única pessoa ou equipe com autoridade clara e previamente atribuída para tomar decisões específicas de alto impacto durante um incidente de segurança.
a confusão sobre a responsabilidade por incidentes importa para TPRM porque a notificação de violação do fornecedor dá início ao prazo regulatório do cliente, e o ciclo de escalonamento do cliente é o mecanismo que determina quanto desse prazo é consumido antes de se tomar uma decisão de notificação.
- Confusão sobre a responsabilidade por incidentes: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias verbais: responsável nomeado pela decisão de notificar os clientes; responsável nomeado pela decisão de notificar os reguladores; contatos fora do horário comercial dos responsáveis pelas decisões.
- Lacunas nos playbooks de incidentes
-
As lacunas nos playbooks de incidentes são as deficiências nos procedimentos de resposta a incidentes específicos de cada cenário que impedem uma execução eficaz em condições reais de incidente: lacunas de completude, acessibilidade, precisão e especificidade operacional que causam atrasos, erros ou falhas quando os responsáveis pela resposta tentam executar o playbook durante um incidente ativ
as lacunas nos playbooks de incidentes são importantes para TPRM porque a qualidade da resposta a incidentes de um fornecedor durante uma violação que afeta dados de clientes depende da eficácia com que seus playbooks são executados em condições reais de incidente, que podem ser às duas da manhã de um sábado, com um analista de plantão usando o próprio dispositivo pessoal, sem acesso à wiki da equipe de rede
- Lacunas nos playbooks de incidentes: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias verbais: data e método do teste de operabilidade; lacunas identificadas no teste de operabilidade; desenho de procedimentos autossuficientes versus procedimentos que dependem de referências externas.
- SLAs de resposta a incidentes
-
Os SLAs de resposta a incidentes nos contratos com fornecedores definem os requisitos de tempo para ações de resposta específicas: prazos de notificação, compromissos de atualização da investigação e prazos para concluir a remediação. O cumprimento do SLA é medido pela ocorrência das ações dentro dos prazos definidos.
os SLAs de IR importam para TPRM porque são o principal mecanismo contratual para proteger o prazo de resposta do cliente, mas SLAs que protegem o prazo sem exigir o conteúdo que viabiliza a resposta protegem a relação contratual sem proteger a capacidade do cliente de efetivamente responder.
- SLAs de resposta a incidentes: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias verbais: requisitos de conteúdo da notificação, ou seja, o que a notificação conterá; SLA de confirmação do escopo, quando o escopo confirmado vier após a notificação preliminar; um fornecedor que confirma um SLA de notificação em quarenta e oito horas deve ser questionado sobre o que a notificação conterá quando chegar. O prazo é uma dimensão do SLA. O conteúdo é a outra. Ambos são necessários para que a notificação permita a resposta que ela foi concebida para proteger.
- Resposta a incidentes nos termos do CC7
-
O CC7 abrange as operações do sistema: detectar e monitorar anomalias, avaliar eventos, responder a incidentes e se recuperar deles. Também abrange a comunicação de incidentes às partes afetadas. É o critério que pergunta se você perceberia que algo está dando errado e o que faria a respeito.
os auditores pedem os incidentes ocorridos durante o período e os acompanham ao longo do processo. Não ter nenhum já é uma questão, porque um ano sem eventos de segurança provavelmente é um ano sem detecção, e não um ano sem ataques. O plano é testado contra o que de fato aconteceu.
- Informações produzidas pela entidade
-
As informações produzidas pela entidade, IPE, são qualquer relatório, lista ou extração que você gera e oferece ao auditor como evidência. Uma listagem de usuários do sistema de identidade. Um log de mudanças da ferramenta de chamados. Uma planilha com os resultados da revisão de acessos. Antes de poder confiar nela, o auditor precisa se certificar de que está completa e correta.
é por isso que o auditor pede para ver a consulta, os parâmetros, a data em que foi executada e o sistema de origem e, às vezes, para acompanhar sua geração. Uma lista que chegou por e-mail sem procedência é uma alegação, não uma evidência, e validá-la costuma custar mais do que teria custado produzi-la corretamente.
- Detecção de desvios de infraestrutura
-
O desvio de infraestrutura é relevante para TPRM porque a postura de segurança da infraestrutura de produção de um fornecedor só é tão precisa quanto a configuração de IaC que a descreve, e o desvio significa que a postura real pode ser menos segura do que a documentação de IaC sugere.
o desvio de infraestrutura é importante para TPRM porque a postura de segurança da infraestrutura de produção de um fornecedor só é tão precisa quanto a configuração de IaC que a descreve, e o desvio significa que a postura real pode ser menos segura do que a documentação de IaC sugere.
- Detecção de desvios de infraestrutura: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias verbais: implementação e monitoramento da detecção de desvios; data e achados da última avaliação de desvios; processo de mudanças emergenciais com exigência de codificação em IaC.
- Segurança no provisionamento de infraestrutura
-
A segurança do provisionamento de infraestrutura é relevante para TPRM porque fornecedores que provisionam infraestrutura automaticamente por meio de pipelines de CI/CD estão concedendo a esses pipelines credenciais de provedores de nuvem e capacidades de gestão de infraestrutura.
a segurança no provisionamento de infraestrutura é importante para TPRM porque fornecedores que provisionam infraestrutura automaticamente por meio de pipelines de CI/CD estão dando a esses pipelines credenciais do provedor de nuvem e capacidade de gerenciar a infraestrutura.
- Segurança no provisionamento de infraestrutura: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias verbais: local de armazenamento do estado, com confirmação de versionamento e de registro de acessos; documentação do controle de acesso ao estado, indicando quem pode ler e gravar; processo de revisão de planos para mudanças em produção.
- Risco da cadeia de suprimentos de infraestrutura como código
-
o risco da cadeia de suprimentos de IaC é importante para TPRM porque fornecedores que usam automação de infraestrutura, cada vez mais a norma em ambientes nativos de nuvem, estão construindo sua infraestrutura sobre cadeias de dependências que incluem módulos de registros públicos.
o risco da cadeia de suprimentos de IaC é relevante para TPRM porque fornecedores que usam automação de infraestrutura, cada vez mais a norma em ambientes nativos de nuvem, estão construindo sua infraestrutura sobre cadeias de dependências que incluem módulos de registros públicos.
- Risco da cadeia de suprimentos de infraestrutura como código: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias verbais: cobertura da varredura de IaC, incluindo o conteúdo dos módulos; registro interno de módulos verificados ou equivalente; um fornecedor que confirma práticas de segurança de IaC deve ser questionado sobre a cobertura da cadeia de suprimentos de módulos. A varredura de segurança de IaC do próprio código confirma o invólucro. A varredura completa do conteúdo dos módulos cobre a cadeia de suprimentos.
- Risco inerente e risco residual
-
Risco inerente é a exposição antes que qualquer controle atue. Risco residual é o que resta depois dos controles que você realmente tem, funcionando como realmente funcionam. A distância entre eles é o quanto vale seu programa de controles, e confundir os dois gera relatórios alarmantes sem motivo ou tranquilizadores sem motivo.
um conselho pergunta qual é o grau de exposição da organização, e a resposta honesta depende de qual número você apresenta. Um cadastro de fornecedores que registra o risco inerente mostra todo fornecedor crítico em vermelho e não diz a ninguém o que fazer. Um que registra apenas o risco residual esconde o fato de que um controle barato é tudo o que separa uma pontuação baixa de uma alta, que é exatamente o que um conselho deveria saber.
- Classificação por risco inerente
-
A classificação por risco inerente é o processo de classificar os relacionamentos com fornecedores pelo risco potencial que representam para a organização, antes da avaliação dos controles, com base em características objetivas do relacionamento: os dados que acessam, os serviços que prestam, os sistemas aos quais se conectam e a criticidade operacional que representam.
a classificação por risco inerente é importante porque, sem ela, o esforço de due diligence é alocado por conveniência administrativa, e não pelo risco.
- Classificação por risco inerente: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias verbais: critérios específicos de classificação por nível, com limites; questionário ou escopo de avaliação diferenciado por nível; um fornecedor que confirma due diligence rigorosa para todos os fornecedores deve ser questionado sobre seus critérios de classificação. Avaliar todos os fornecedores da mesma forma é teatro de proporcionalidade ou falha de proporcionalidade, dependendo de o questionário estar calibrado para o nível de risco mais alto ou o mais baixo.
- Confusão entre risco inerente e risco residual
-
O framework de risco inerente versus risco residual é importante porque as pontuações de risco residual orientam a alocação de recursos: quais fornecedores recebem monitoramento intensivo e quais recebem uma supervisão mais leve.
o modelo de risco inerente versus residual importa porque as pontuações de risco residual orientam a alocação de recursos: quais fornecedores recebem monitoramento intensivo e quais recebem supervisão mais leve.
- Confusão entre risco inerente e risco residual: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias verbais: inclusões e exclusões do escopo da avaliação; confirmação de que os sistemas de interação estão no escopo; metodologia de teste dos controles para os sistemas no escopo.
- Vulnerabilidades de injeção no código de fornecedores
-
As vulnerabilidades de injeção são uma classe de fragilidade de segurança de aplicações que surge quando uma aplicação incorpora dados não confiáveis (normalmente entradas fornecidas pelo usuário) a um comando ou consulta de forma que permita que esses dados sejam interpretados como parte do comando, e não como dados a serem processados por ele.
as vulnerabilidades de injeção em aplicações de fornecedores são particularmente graves da perspectiva do risco de terceiros porque seu impacto não se limita aos dados do próprio fornecedor: estende-se a tudo o que a aplicação pode acessar, o que, em um contexto SaaS multitenant, frequentemente inclui os dados de todos os clientes ao mesmo tempo.
- Vulnerabilidades de injeção no código de fornecedores: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias: documentação do escopo do teste de intrusão que inclua explicitamente a cobertura de injeção nos recursos adicionados recentemente e em superfícies de entrada não óbvias; histórico de achados de injeção com prazos de remediação e evidências de verificação (achados anteriores remediados e verificados tranquilizam mais do que nenhum achado jamais registrado); confirmação da configuração de detecção de injeção do SAST com o escopo de cobertura da base de código.
- Indagação, observação, inspeção, reexecução
-
Há quatro procedimentos que um auditor usa para testar um controle. Indagação é perguntar a alguém como ele funciona. Observação é vê-lo acontecer. Inspeção é examinar as evidências que ele produziu. Reexecução é executá-lo novamente de forma independente e comparar o resultado. Eles estão listados aqui em ordem de robustez.
a indagação, por si só, quase nunca é suficiente para um Tipo II, porque ouvir que um controle opera não é evidência de que ele operou. É por isso que “explicamos o processo a eles” nunca encerra uma solicitação de auditoria, e por isso que o auditor continua pedindo o artefato depois da reunião.
- Acesso interno nos fornecedores
-
A ameaça interna nos fornecedores é o risco de que funcionários do fornecedor com acesso legítimo aos dados do cliente usem esse acesso de forma indevida (para ganho financeiro, vantagem competitiva, ressentimento pessoal ou coação externa) de maneiras que não são impedidas pelos controles de acesso, porque o acesso é autorizado, e não são detectadas pela segurança de perímetro porqu
o acesso interno nos fornecedores é relevante para TPRM porque a relação com o fornecedor cria uma classe de pessoas, os funcionários do fornecedor, que têm acesso autorizado aos dados do cliente, mas não estão sujeitas aos processos de RH, ao treinamento de segurança, ao monitoramento comportamental ou aos controles de vínculo empregatício do cliente.
- Acesso interno em fornecedores: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias verbais: descrição da implementação de análise comportamental, com UEBA aplicada ao acesso a dados, linhas de base estabelecidas e detecção de anomalias configurada; confirmação do monitoramento de exportação de dados, com detecção de padrões cumulativos e calibração de limites; histórico de incidentes de ameaça interna, com eventos de detecção e resultados das investigações.
- Ameaças internas nos fornecedores
-
As ameaças internas nos fornecedores são o risco de que empregados, terceirizados ou usuários confiáveis do fornecedor com acesso legítimo a sistemas que contêm dados de clientes façam uso indevido desse acesso, de forma intencional, negligente ou sob coação, de maneiras que prejudiquem o cliente.
as ameaças internas nos fornecedores são importantes para TPRM porque o cliente não consegue monitorar diretamente o comportamento dos funcionários do fornecedor: o cliente não tem acesso ao UEBA que detectaria a mudança no padrão de consultas do engenheiro de dados, nenhuma visibilidade sobre o monitoramento de destinos de exportação que sinalizaria a transferência para o Dropbox e nenhum mecanismo direto para dete
- Ameaças internas nos fornecedores: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias verbais: confirmação da implantação de UEBA para a equipe com acesso a dados de clientes; documentação da delimitação do acesso ao mínimo necessário; configuração de DLP para detecção de exportações em pequenos lotes.
- Exposição à internet e gestão da superfície de ataque
-
A gestão da exposição à internet é importante para TPRM porque as superfícies de ataque externas confirmadas pelos fornecedores costumam diferir dos serviços realmente acessíveis externamente, devido à TI paralela, a configurações incorretas e à natureza dinâmica da infraestrutura em nuvem.
a gestão da exposição à internet é importante para TPRM porque as superfícies de ataque externas confirmadas pelos fornecedores costumam diferir dos serviços realmente acessíveis externamente, devido à TI paralela, a configurações incorretas e à natureza dinâmica da infraestrutura em nuvem.
- Exposição à internet e gestão da superfície de ataque: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias verbais: comparação entre o inventário obtido por varredura e o inventário documentado.
- Segurança de IPv6: o protocolo que sua equipe de segurança pode ter esquecido
-
IPv6 ativado: por padrão em todos os endpoints. Monitoramento de IPv6: nenhum.
a segurança de IPv6 é importante para TPRM porque o IPv6 vem ativado por padrão na maioria dos ambientes modernos, e atacantes que sabem disso podem usar caminhos de comunicação IPv6 para contornar os controles de segurança de IPv4.
- ISAE 3402 e equivalentes internacionais
-
A ISAE 3402 é a norma internacional de asseguração para relatórios sobre controles em uma organização prestadora de serviços, emitida pelo IAASB, e não pelo AICPA, e amplamente equivalente a um SOC 1. A ISAE 3000 é a norma mais ampla para trabalhos de asseguração que não sejam auditorias de informações financeiras, sob a qual são emitidos, fora dos Estados Unidos, relatórios que cobrem controles de segurança e operacionais.
fornecedores na Europa, no Reino Unido, na Austrália e em outros lugares frequentemente possuem esses relatórios em vez de um SOC 2, e eles são legítimos. Um fornecedor do Reino Unido com um relatório ISAE 3000 sobre controles de segurança foi examinado por um profissional independente segundo uma norma reconhecida, e rejeitá-lo porque não se chama SOC 2 é um erro.
- Declaração de Aplicabilidade ISO 27001
-
A Declaração de Aplicabilidade é o documento da ISO 27001 que lista todos os controles do Anexo A da norma, se cada um se aplica à sua organização, a justificativa e o status de implementação. É exigida pela norma, referenciada no certificado, e é o primeiro documento que um auditor de certificação abre, porque todo o resto da auditoria decorre dela.
o certificado diz que uma organização é certificada. A Declaração de Aplicabilidade diz o que isso significa: quais controles estão na auditoria, quais foram excluídos e por quê, e se as exclusões se devem à pertinência ou à conveniência. Um fornecedor que não consegue apresentar sua Declaração de Aplicabilidade quando solicitado já revelou algo sobre como a certificação foi obtida.
- ISO 42001
-
A ISO 42001 é a norma de sistema de gestão para IA, estruturada como a ISO 27001: cláusulas de contexto, liderança, planejamento, apoio, operação, avaliação e melhoria, com um anexo de controles específicos para IA. É certificável, ou seja, um organismo acreditado pode auditar com base nela e emitir um certificado com uma declaração de escopo.
compradores que pedem ISO 27001 para segurança estão começando a pedir ISO 42001 para IA, especialmente quando um produto toma decisões sobre pessoas. O tema também surge internamente como a forma de dar à governança de IA os mesmos mecanismos que a governança de segurança tem: um escopo, uma avaliação de riscos, uma declaração de aplicabilidade, auditoria interna e análise crítica pela direção.
- Controles gerais de TI ITGC
-
Controles sobre o acesso a programas e dados, mudanças em programas, desenvolvimento de programas e operações de computador.
Se eles falharem, o auditor não pode confiar em nenhum controle automatizado executado nesses sistemas, por mais bem projetado que seja.
Ensinado em GRC-230 · Veja também: Declaração de Aplicabilidade, População e amostra
J
- Admissão, movimentação e desligamento
-
Admissão, movimentação e desligamento é o processo pelo qual o acesso é concedido quando alguém começa, ajustado quando a pessoa muda de função e removido quando ela sai. As admissões são tratadas porque alguém precisa trabalhar. Os desligamentos são tratados, em algum momento, porque uma auditoria verifica. As movimentações são onde o acesso se acumula, porque adicionar acesso é um pedido que alguém faz e remover o acesso antigo não é tarefa de ninguém.
é o controle por trás de metade dos achados em qualquer auditoria de acessos, é o mecanismo que a maioria dos controles complementares da entidade usuária nos relatórios de fornecedores presume que você opera, e é onde a conta de um usuário desligado altera dados bancários dezoito meses depois de ele ter saído. Os auditores o testam conciliando o feed de RH com as criações e remoções de contas, e é na conciliação que as lacunas aparecem.
- Controladores conjuntos
-
Quando duas ou mais organizações determinam conjuntamente as finalidades e os meios do tratamento, elas são controladoras conjuntas. O GDPR exige que determinem suas respectivas responsabilidades em um acordo transparente, incluindo quem atende aos direitos dos titulares dos dados e quem fornece o aviso de privacidade, e que disponibilizem aos titulares dos dados a essência desse acordo.
a controladoria conjunta surge sem que ninguém tenha essa intenção. Uma campanha com marca compartilhada em que as duas partes decidem quem será o público. Uma plataforma compartilhada em que as duas partes definem o que é coletado. Um acordo de indicação em que ambas usam os mesmos dados para seus próprios fins. Os tribunais já reconheceram controladoria conjunta em arranjos que as partes descreviam como outra coisa.
- Acesso just-in-time versus acesso permanente
-
O acesso just-in-time é um modelo de acesso privilegiado em que credenciais elevadas são concedidas quando necessárias para uma tarefa específica e revogadas automaticamente quando a tarefa é concluída ou quando expira um período de tempo definido.
o acesso JIT versus o acesso permanente é importante para TPRM porque os acordos de suporte e de serviços gerenciados com fornecedores frequentemente envolvem acesso privilegiado permanente aos ambientes dos clientes, um acesso que foi provisionado por disponibilidade e representa exposição contínua de credenciais durante todo o relacionamento com o fornecedor.
- Acesso sob demanda vs. acesso permanente: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias verbais: confirmação de acesso JIT ou documentação que justifique o acesso permanente; métricas de uso do acesso, comparando horas usadas com horas de validade da credencial; confirmação da plataforma PAM para o provisionamento JIT.
K
- Segurança do Kubernetes em CI/CD
-
A segurança da configuração do Kubernetes importa para TPRM porque configurações incorretas de clusters Kubernetes são frequentemente o caminho explorável que converte uma vulnerabilidade de contêiner em comprometimento do cluster.
a segurança da configuração do Kubernetes é relevante para TPRM porque configurações incorretas de clusters Kubernetes são frequentemente o caminho explorável que transforma uma vulnerabilidade de contêiner no comprometimento do cluster.
- Segurança de Kubernetes em CI/CD: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias verbais: varredura de manifestos do Kubernetes no pipeline de CI/CD; mecanismo de aplicação do contexto de segurança dos pods; implementação das políticas de rede e postura padrão.
L
- Movimentação lateral e redes planas
-
Movimentação lateral e redes planas importam para TPRM porque o valor de um ataque à cadeia de suprimentos muitas vezes não é determinado pelo ponto de apoio inicial, mas pela capacidade de movimentação lateral que a arquitetura de rede permite.
a movimentação lateral e as redes planas são importantes para TPRM porque o valor de um ataque à cadeia de suprimentos muitas vezes não é determinado pela base inicial, mas pela capacidade de movimentação lateral que a arquitetura de rede permite.
- Movimentação lateral e redes planas: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias verbais: descrição da segmentação de rede por função de negócio; barreiras à movimentação lateral entre zonas; resultados de testes de intrusão internos para caminhos de movimentação lateral.
- Base legal
-
O GDPR exige uma base legal para cada atividade de tratamento e prevê seis: consentimento, execução de contrato, cumprimento de obrigação legal, proteção de interesses vitais, execução de uma missão de interesse público e interesses legítimos. Uma delas deve se aplicar antes do início do tratamento, e deve ser identificada e documentada desde o princípio.
o consentimento é a base à qual as pessoas recorrem primeiro porque parece a mais segura. É a mais exigente. Deve ser livre, específico, informado e inequívoco, tão fácil de revogar quanto de dar, e cria obrigações que persistem enquanto durar o tratamento. A maior parte do tratamento sob o B2B se apoia no interesse legítimo ou na execução de contrato, e escolher o consentimento por padrão constrói um programa sobre a base mais difícil disponível.
- Privilégio mínimo no acesso de fornecedores
-
O menor privilégio é o princípio segundo o qual toda entidade, seja usuário, conta de serviço, aplicação ou integração de fornecedor, deve receber o acesso mínimo necessário para desempenhar sua função específica, e nada além disso.
o menor privilégio no acesso de fornecedores é relevante para TPRM porque o raio de impacto do comprometimento de uma credencial do fornecedor é determinado não pelo que o fornecedor precisava, mas pelo que lhe foi concedido.
- Privilégio mínimo no acesso de fornecedores: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias verbais: documentação das permissões das contas de serviço, com permissões específicas e justificativa funcional; histórico de revisões do escopo de acesso, com a proporcionalidade revisada, e não apenas a existência confirmada; ausência de acesso de nível administrativo para funções não administrativas.
- Preservação legal retenção para litígio
-
Uma instrução que suspende a exclusão de informações relevantes para uma disputa, investigação ou questão regulatória.
Ela se sobrepõe à tabela de retenção e precisa de uma liberação: retenções aplicadas e nunca suspensas se tornam uma política de retenção permanente que ninguém decidiu.
Ensinado em PRV-270 · Veja também: Tabela de temporalidade
- Interesse legítimo em marketing
-
Se uma organização pode enviar marketing a alguém que nunca deu opt-in depende de onde o destinatário está. Em grande parte da Europa, o e-mail B2B para um endereço corporativo pode se apoiar em interesses legítimos, sujeito a opt-out. No Canadá, a CASL trata o consentimento implícito de forma restrita, vincula-o a uma relação existente e lhe impõe prazo de validade. Nos Estados Unidos, o CAN-SPAM permite o envio com opt-out e endereço postal. O PECR do Reino Unido fica entre os dois.
uma única lista de campanha frequentemente abrange todos esses regimes, e uma regra aplicada de maneira uniforme está errada em algum lugar. A base que é defensável para um endereço corporativo alemão não é defensável para um canadense, e os regimes de sanções diferem em uma ordem de grandeza.
- Interesses legítimos LIA, teste de ponderação
-
Uma base legal que permite o tratamento necessário para atender a um interesse genuíno, desde que esse interesse não prevaleça sobre os direitos da pessoa.
É uma alegação positiva, e não uma categoria residual, e o teste de ponderação pode resultar contra você. A avaliação precisa existir no papel.
Ensinado em PRV-201 · Veja também: Relatório de impacto à proteção de dados, Termos do operador
- Interesse legítimo e criação de perfis
-
A definição de perfis, a avaliação automatizada de aspectos pessoais para prever comportamento, interesses ou características, pode se apoiar em interesses legítimos como base legal. Mas o teste de ponderação deve considerar o grau de intrusão do perfil, as expectativas razoáveis da pessoa e o efeito que a definição de perfis tem sobre ela. Quanto mais relevante o perfil, mais difícil é alcançar o equilíbrio.
pontuações comportamentais, modelos de propensão e previsões de engajamento são rotineiramente justificados por uma LIA que considera apenas o benefício para o negócio. O teste de ponderação pergunta o que a pessoa esperaria, se ela se oporia caso soubesse e o que o perfil faz com a forma como ela é tratada. Um perfil que afeta preços, elegibilidade ou o conteúdo que alguém vê não é uma intrusão menor.
- Riscos de integração de LLM
-
Os riscos de integração de LLM são os riscos de segurança e de privacidade decorrentes da conexão de grandes modelos de linguagem a repositórios de dados corporativos, como bibliotecas de documentos, bancos de dados, sistemas de e-mail e bases de conhecimento, criando um sistema de IA capaz de recuperar e tratar dados corporativos em resposta a consultas de usuários.
os riscos de integração de LLM importam para TPRM porque implantações corporativas de LLM conectadas a repositórios de documentos sensíveis criam uma nova categoria de risco de acesso a dados para a qual os controles de acesso tradicionais não foram projetados.
- Riscos de integração de LLM: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias verbais: comparação entre o escopo de permissões da conta de serviço e o dos usuários; monitoramento de consultas para identificar padrões de extração; um fornecedor que confirma a segurança da integração de LLM deve ser questionado sobre o escopo de permissões da conta de serviço e a exclusão de categorias de documentos sensíveis. Os controles de acesso protegem o acesso direto aos documentos. O escopo de recuperação da conta de serviço e o monitoramento da janela de contexto protegem o caminho indireto que o LLM cria.
- Ingestão de logs de fornecedores
-
A ingestão de logs de fornecedores é o desafio de obter, acessar e reter dados de logs de segurança dos ambientes dos fornecedores para fins de investigação de incidentes, evidência de conformidade e detecção contínua de ameaças no SIEM do cliente.
a ingestão de logs de fornecedores é importante para TPRM porque as investigações de segurança exigem cada vez mais evidências de logs dos ambientes dos fornecedores, e a disponibilidade dessas evidências depende de políticas de retenção e acordos de acesso que a maioria das avaliações de fornecedores confirma existirem sem verificar se são adequados para fins de investigação.
- Ingestão de logs de fornecedores: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias verbais: período de retenção por categoria de log; procedimento e prazo de acesso aos logs para investigações; capacidade de encaminhamento de logs para sistemas críticos.
- Registro de logs e retenção de evidências
-
O registro de logs captura o que aconteceu: quem fez login, o que mudou, o que foi acessado, o que o sistema fez. A retenção define por quanto tempo esse registro sobrevive. Juntos, são a evidência por trás da maioria dos outros controles, já que uma revisão de acessos, uma aprovação de mudança ou a linha do tempo de um incidente só podem ser demonstradas se o log que as registrou ainda existir quando alguém pedir.
o achado de auditoria raramente é que um controle não foi executado. É que ninguém consegue demonstrar que ele foi executado durante o período, porque o log foi sobrescrito após noventa dias e o período de auditoria é de doze meses. Isso aparece em incidentes, quando não é possível responder desde quando o acesso começou porque o log já expirou. E aparece em privacidade, quando logs que capturam o conteúdo das requisições acabam contendo dados pessoais que ninguém havia mapeado.
- Acesso lógico segundo o CC6
-
O CC6 abrange o acesso lógico e físico: como o acesso é provisionado, autenticado, autorizado, revisado e removido, como o acesso físico às instalações é controlado e como os dados são protegidos em trânsito, em repouso e no descarte. É, com folga, o maior dos nove grupos de critérios comuns.
CC6 abrange todos os sistemas e todas as admissões, movimentações e desligamentos. O volume de evidências é maior do que o de qualquer outro grupo, a população muda constantemente e os modos de falha são os que causam violações. Gera mais exceções do que qualquer outro grupo, e o auditor dedica mais tempo a ele do que a qualquer outro.
M
- Identidades de máquina versus identidades humanas
-
As identidades de máquina são relevantes para TPRM porque são o principal caminho pelo qual os ataques à cadeia de suprimentos se propagam dos ambientes dos fornecedores para os ambientes dos clientes. O ataque à SolarWinds comprometeu as identidades de máquina do pipeline de build.
as identidades de máquina importam para TPRM porque são o principal caminho pelo qual ataques à cadeia de suprimentos se propagam dos ambientes de fornecedores para os ambientes de clientes.
- Identidades de máquina versus identidades humanas: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias verbais: contagem de identidades de máquina e capacidade de inventário; implantação de plataforma de gestão de segredos para credenciais de máquina; inclusão das identidades de máquina no ciclo de revisão da governança.
- Complexidade de TPRM em prestadores de serviços gerenciados
-
a complexidade de MSP TPRM é importante porque as relações com MSP estão entre as relações com fornecedores de maior risco da empresa: envolvem amplo acesso a sistemas, controle operacional de funções críticas e profunda exposição de dados.
a complexidade de MSP TPRM é importante porque as relações com MSP estão entre as relações com fornecedores de maior risco da empresa: envolvem amplo acesso a sistemas, controle operacional de funções críticas e profunda exposição de dados.
- Complexidade de TPRM de provedores de serviços gerenciados: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias verbais: lista completa das ferramentas de MSP, com a caracterização do acesso; certificações de segurança das ferramentas com acesso direto; requisitos de segurança aplicados aos fornecedores dessas ferramentas.
- Materialidade em uma asseguração
-
A materialidade é o limite a partir do qual um desvio importa o suficiente para afetar a opinião do auditor ou para ser relatado como exceção. É um julgamento feito pelo auditor, com base no critério afetado, na natureza do desvio e em seu provável efeito sobre as decisões de um leitor.
isso explica por que um controle que falhou uma vez em uma amostra de vinte e cinco pode não aparecer como exceção, e por que uma única falha em um controle crítico pode aparecer. Também explica por que o relatório não é um registro completo de tudo o que saiu imperfeito durante o ano. É uma opinião, moldada pelo julgamento sobre o que importa.
- Medindo o ROI do programa de DevSecOps
-
a medição de ROI em DevSecOps é importante para TPRM porque fornecedores que não conseguem demonstrar os resultados de segurança do seu investimento em DevSecOps podem estar investindo em teatro de segurança, e não em melhoria da segurança.
a medição de ROI em DevSecOps é importante para TPRM porque fornecedores que não conseguem demonstrar os resultados de segurança do seu investimento em DevSecOps podem estar investindo em teatro de segurança, e não em melhoria da segurança.
- Medindo o programa de DevSecOps ROI: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias verbais: registros de acompanhamento de MTTR e tendência; taxa de descoberta de vulnerabilidades antes versus depois da produção; modelo de custo evitado para o programa de segurança.
- Riscos de exposição de metadados
-
Metadados são dados sobre dados: as informações contextuais, estruturais e técnicas que descrevem, situam e apoiam os dados primários sem serem os próprios dados primários.
a exposição de metadados importa para TPRM porque representa uma categoria de divulgação de informações em grande parte invisível para avaliações focadas na proteção dos dados primários.
- Riscos de exposição de metadados: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias verbais: revisão da configuração dos cabeçalhos HTTP, com supressão dos cabeçalhos que identificam o servidor; configuração do tratamento de erros, com mensagens genéricas sem detalhes do sistema; processo de gestão de metadados de documentos, com remoção antes da distribuição externa.
- Métricas que sobrevivem a uma reunião do conselho
-
Um conselho responde pela supervisão, não pelos controles: se a organização entende sua exposição, se o programa tem recursos e se a administração está dizendo a verdade. As métricas para um conselho devem servir a essas três perguntas. Ameaças bloqueadas, conclusão de treinamentos e um mapa de calor que não se move há três trimestres não servem a nenhuma delas, e um conselho que acena com a cabeça e segue adiante está respondendo de forma justa a um relatório que não pede nada.
o relatório que gera uma decisão é aquele que mostra algo se movendo em uma direção que importa e termina com um pedido. O tempo para remediar achados críticos subindo de nove para vinte e seis dias motivou uma conversa sobre recursos. A contagem de compromissos de segurança com clientes sem nenhuma evidência por trás levou diretamente ao financiamento de um recurso de conformidade que um ano de mapas de calor não havia conseguido.
- Lacunas na aplicação de MFA
-
As lacunas na exigência de MFA são os caminhos de autenticação de um ambiente em que o segundo fator não é exigido: caminhos pelos quais identidades podem se autenticar usando apenas um fator (normalmente uma senha, uma chave de API ou um certificado), sem a verificação adicional que o MFA oferece.
as lacunas na aplicação de MFA são relevantes para TPRM porque fornecedores que tratam dados de clientes são alvos atraentes justamente porque seus sistemas guardam dados de vários clientes ao mesmo tempo.
- Lacunas na exigência de MFA: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias verbais: inventário dos caminhos de autenticação, com todos os caminhos e o status de MFA; documentação do método de autenticação das contas de serviço; inventário de endpoints legados com plano de migração ou de controle compensatório.
- Microssegmentação em ambientes de fornecedores
-
A microssegmentação é importante para TPRM porque a confirmação da segmentação de rede sem avaliação da qualidade das regras pode descrever uma separação topológica com conectividade funcional: uma segmentação que existe no diagrama de rede, mas pode ser atravessada por meio de regras amplas no nível das zonas.
a microssegmentação é relevante para TPRM porque a confirmação da segmentação de rede sem avaliação da qualidade das regras pode descrever uma separação topológica com conectividade funcional: uma segmentação que existe no diagrama de rede, mas que pode ser atravessada por meio de regras amplas no nível de zona.
- Microssegmentação em ambientes de fornecedores: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias verbais: descrição das regras de fronteira da segmentação, com especificidade de origem, destino e porta; política de negação por padrão nas fronteiras entre zonas; processo de revisão de regras e data da última revisão.
- Exposição de armazenamento em nuvem mal configurado via fornecedores
-
O armazenamento de objetos em nuvem (AWS S3, Azure Blob Storage, Google Cloud Storage) é um dos serviços mais usados e mais frequentemente mal configurados em ambientes corporativos de nuvem. É barato, escalável e projetado para tornar os dados acessíveis com rapidez.
a configuração incorreta de armazenamento em nuvem está na interseção de duas categorias de risco que os programas de TPRM costumam tratar separadamente: o manuseio de dados pelos fornecedores e a segurança em nuvem.
- Exposição de armazenamento em nuvem mal configurado via fornecedores: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias verbais: capturas de tela ou exportações de configuração que confirmem que os bloqueios de acesso público estão ativados, e não uma caixa marcada em um questionário; documentação da configuração de criptografia que especifique o padrão de criptografia e a abordagem de gestão de chaves; confirmação do registro de acessos com o período de retenção especificado.
- Segurança de CI/CD de aplicativos móveis
-
A segurança de CI/CD para dispositivos móveis é relevante para TPRM porque aplicativos móveis distribuídos por lojas de aplicativos chegam aos dispositivos dos usuários com a configuração de segurança que o pipeline de build tiver produzido.
a segurança de CI/CD para dispositivos móveis é relevante para TPRM porque aplicativos móveis distribuídos por lojas de aplicativos chegam aos dispositivos dos usuários com a configuração de segurança que o pipeline de build tiver produzido.
- Segurança de aplicativos móveis CI/CD: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias verbais: validação da configuração dos binários no pipeline de CI/CD; verificação do registro de depuração nos builds de produção; ferramentas de testes de segurança específicas para dispositivos móveis utilizadas.
- Controle de acesso a modelos
-
O controle de acesso a modelos no contexto da segurança de IA trata de um desafio que não existe na segurança de software tradicional: um modelo pode ser roubado por meio da sua API sem qualquer violação dos controles de acesso do API. Os controles de acesso tradicionais impedem o acesso não autorizado a um recurso.
o controle de acesso a modelos é importante para TPRM porque fornecedores que expõem APIs de modelos de IA a clientes corporativos, e por meio deles possivelmente aos próprios clientes e parceiros da empresa, criam uma superfície de ataque de extração de modelo que a segurança tradicional de API não trata.
- Controle de acesso a modelos: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias verbais: monitoramento do volume de consultas por chave de API; resultados da avaliação de ataques de extração de modelo; um fornecedor que confirma autenticação de API e limitação de taxa deve ser questionado sobre a detecção de extração. A autenticação confirma o acesso autorizado. A detecção de extração determina se o acesso autorizado está sendo usado para reconstruir o modelo.
- Fichas de modelo
-
Um cartão de modelo é um documento estruturado que descreve um modelo de IA: o que ele foi treinado para fazer, com que tipo de dados, como seu desempenho foi avaliado e para quais populações, suas limitações conhecidas e os usos para os quais ele se destina ou não. Os fornecedores os publicam para os modelos que fornecem; as organizações os escrevem para os modelos que constroem.
é o documento que responde às perguntas que uma avaliação de impacto de IA precisa fazer, e sua ausência já é, por si só, um achado. Quando um fornecedor não consegue dizer em quais populações o desempenho do modelo foi medido, você descobre que foi medido em uma só, que geralmente é o caso que importava: uma ferramenta de triagem de suporte testada em inglês enquanto um terço dos seus clientes escreve em espanhol.
- Riscos de desvio de modelo
-
O desvio de modelo é a degradação do alinhamento entre o comportamento de um modelo de aprendizado de máquina em produção e o comportamento pretendido, um desalinhamento que se desenvolve ao longo do tempo à medida que a distribuição dos dados do mundo real que o modelo encontra em produção se afasta da distribuição dos dados de treinamento a partir dos quais foi construído.
o desvio de modelo é importante para TPRM porque os modelos de IA que os fornecedores implantam para decisões relevantes (detecção de fraudes, pontuação de crédito, classificação de segurança, avaliação de risco de clientes) vão se desviar ao longo do tempo de formas nem sempre visíveis nas métricas de desempenho padrão.
- Riscos de desvio de modelo: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias verbais: monitoramento específico de desvio, além das métricas de desempenho; acompanhamento da estabilidade da importância das variáveis em modelos de aprendizado online; avaliação de desvio de conceito e cadência de retreinamento.
- Riscos de roubo de modelos
-
O risco de roubo de modelo é o risco de que a lógica de decisão e as capacidades de um modelo de IA proprietário possam ser reconstruídas por um invasor por meio de consultas sistemáticas à API do modelo, seja diretamente, seja por meio de um terceiro com acesso legítimo à API, sem que o invasor jamais acesse os pesos, a arquitetura ou os dados de treinamento do modelo.
o roubo de modelos importa para TPRM por dois lados.
- Riscos de roubo de modelos: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias verbais: requisitos de segurança de API para clientes corporativos; confirmação do monitoramento do volume de consultas por chave; um fornecedor que confirma a segurança de API deve ser questionado sobre a segurança das integrações dos clientes corporativos. O API do fornecedor controla o acesso direto. As integrações dos clientes são a superfície ampliada pela qual o modelo pode ser acessado indiretamente.
- Considerações de segurança em CI/CD multinuvem
-
A segurança de CI/CD multinuvem é importante para TPRM porque inconsistências na arquitetura de segurança entre nuvens criam um único elo mais fraco: a nuvem com a gestão de credenciais ou a configuração de segurança mais fraca é o ponto de maior vulnerabilidade de um pipeline que abrange as duas.
a segurança de CI/CD em múltiplas nuvens é relevante para TPRM porque inconsistências na arquitetura de segurança entre nuvens criam um único elo mais fraco: a nuvem com a gestão de credenciais ou a configuração de segurança mais fraca é o ponto de maior vulnerabilidade de um pipeline que abrange ambas.
- Considerações de segurança em CI/CD multinuvem: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias verbais: documentação do mecanismo de autenticação por nuvem; status de implementação de Workload Identity por nuvem; datas de rotação das credenciais das contas de serviço.
- Risco de fornecedores multinuvem
-
O risco de fornecedores multinuvem é a lacuna de governança que surge quando a infraestrutura de um fornecedor abrange vários provedores de nuvem, mas a due diligence, os controles contratuais e o monitoramento contínuo do cliente se limitam a apenas um, geralmente aquele de que o cliente tem conhecimento ou aquele que o fornecedor apresentou durante o onboarding.
a arquitetura de fornecedores em múltiplas nuvens desafia diretamente uma das premissas fundamentais do modelo padrão de avaliação de TPRM: a de que o fornecedor é um ambiente de segurança único e coerente que pode ser avaliado por meio de um questionário e de uma certificação de conformidade.
- Risco de fornecedores multinuvem: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias verbais: lista completa dos provedores de nuvem e das regiões usados no tratamento de dados do cliente, não apenas a plataforma principal; documentação do escopo do SOC 2 que confirme a cobertura de todos os ambientes relevantes, ou o reconhecimento explícito do que está fora do escopo e por quê; um diagrama de fluxo de dados que mostre como os dados do cliente circulam pela arquitetura multinuvem do fornecedor.
N
- Segurança de NAT e riscos de tradução de endereços de rede
-
os equívocos sobre a segurança de NAT são importantes para TPRM porque fornecedores que descrevem seus sistemas internos como 'protegidos por NAT' podem estar descrevendo corretamente a ausência de roteamento IP direto enquanto mantêm regras de redirecionamento de portas que tornam esses mesmos sistemas acessíveis pela internet por meio de configurações de caminho deliberadas ou esquecidas.
os equívocos sobre a segurança de NAT são importantes para TPRM porque fornecedores que descrevem seus sistemas internos como 'protegidos por NAT' podem estar descrevendo corretamente a ausência de roteamento IP direto enquanto mantêm regras de redirecionamento de portas que tornam esses mesmos sistemas acessíveis pela internet por meio de configurações de caminho deliberadas ou esquecidas.
- Segurança de NAT e riscos de tradução de endereços de rede: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias verbais: inventário e revisão das regras de redirecionamento de portas.
- Natureza, época e extensão
-
Natureza é o tipo de teste que o auditor realiza. Época é o momento dentro do período. Extensão é a quantidade, ou seja, o tamanho da amostra e a profundidade. Juntas, descrevem quanto trabalho o auditor fará em cada controle, e as três respondem ao nível de risco que o auditor percebe.
entender esses três fatores explica por que uma solicitação parece trivial e outra parece excessiva. Um controle com bom histórico, boas evidências e baixo risco recebe testes leves. Um controle em uma área com exceções anteriores, documentação fraca ou alta exposição tem os três parâmetros elevados.
- Controle de acesso à rede em ambientes corporativos
-
O NAC é importante para TPRM porque redes de fornecedores que permitem que dispositivos não gerenciados entrem na rede corporativa têm uma superfície de acesso à rede sem controle: qualquer local físico com uma porta de rede ou sinal sem fio se torna um possível ponto de entrada na rede para qualquer dispositivo.
O NAC é importante para TPRM porque redes de fornecedores que permitem que dispositivos não gerenciados entrem na rede corporativa têm uma superfície de acesso à rede sem controle: qualquer local físico com uma porta de rede ou sinal sem fio se torna um possível ponto de entrada na rede para qualquer dispositivo.
- Controle de acesso à rede em ambientes corporativos: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias verbais: confirmação da implantação de NAC em redes cabeadas e sem fio; acesso diferenciado para dispositivos gerenciados e não gerenciados; um fornecedor que confirma a segurança de rede deve ser questionado sobre NAC. A segurança de endpoints em dispositivos gerenciados protege os dispositivos gerenciados. O NAC controla o que os dispositivos não gerenciados podem acessar quando se conectam à rede. Ambos são necessários para gerenciar a superfície de acesso à rede.
- Gestão de acessos à rede para prestadores de serviço e terceiros
-
A gestão do acesso de terceirizados à rede é relevante para TPRM porque terceirizados com acesso à rede corporativa que encerraram seu contrato representam o mesmo risco de acesso órfão que ex-empregados, mas por meio de uma lacuna na gestão do ciclo de vida que os sistemas de identidade integrados ao RH não tratam automaticamente.
a gestão do acesso de terceirizados à rede é relevante para TPRM porque terceirizados com acesso à rede corporativa que encerraram seu contrato representam o mesmo risco de acesso órfão que ex-empregados, mas por meio de uma lacuna na gestão do ciclo de vida que os sistemas de identidade integrados ao RH não tratam automaticamente.
- Gestão do acesso à rede para terceirizados e terceiros: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias verbais: processo de desligamento de terceirizados e registros de SLA; verificação da integração com a data de término do contrato; registros da auditoria mensal de acessos de terceirizados.
- Revisão e certificação de acessos à rede
-
A qualidade da revisão de acesso à rede é importante para TPRM porque a confirmação de revisões de acesso sem avaliação da metodologia pode descrever uma atividade de conformidade, e não um controle de segurança eficaz.
a qualidade da revisão de acesso à rede é relevante para TPRM porque a confirmação da revisão de acesso sem avaliação da metodologia pode descrever uma atividade de conformidade, e não um controle de segurança eficaz.
- Revisão e certificação de acessos à rede: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias verbais: acompanhamento das contas removidas em cada revisão.
- Detecção de anomalias de rede e desvios da linha de base
-
A detecção de anomalias de rede é importante para TPRM porque o roubo de credenciais seguido de um abuso cuidadoso e lento dessas credenciais é o padrão de ataque que agentes de ameaça focados em credenciais usam especificamente para escapar da detecção baseada em assinaturas.
a detecção de anomalias de rede é relevante para TPRM porque o roubo de credenciais seguido de abuso cuidadoso e lento dessas credenciais é o padrão de ataque que agentes de ameaça focados em credenciais usam especificamente para escapar da detecção baseada em assinaturas.
- Detecção de anomalias de rede e desvios da linha de base: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias: cobertura de detecção de anomalias junto com assinaturas.
- Criptografia de rede: o que é e o que não é criptografado
-
A criptografia da rede interna é importante para TPRM porque determina o que um atacante que já estabeleceu uma base dentro da rede consegue observar.
a criptografia da rede interna é relevante para TPRM porque determina o que um atacante que estabeleceu uma posição interna consegue observar.
- Testes de intrusão de rede no contexto de TPRM
-
O escopo dos testes de intrusão de rede é relevante para TPRM porque os achados de um relatório de pentest descrevem o que foi testado, e não o que existe. Um pentest externo de aplicação sem achados confirma que a aplicação externa testada é razoavelmente segura.
o escopo dos testes de intrusão de rede é importante para TPRM porque os achados dos relatórios de pentest descrevem o que foi testado, não o que existe.
- Testes de intrusão de rede no contexto de TPRM: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias verbais: exigência de escopo de rede interna para fornecedores críticos; requisitos de escopo nos contratos com fornecedores críticos.
- Perímetro de rede versus perímetro de identidade
-
A distinção entre perímetro de rede e perímetro de identidade é relevante para TPRM porque respostas de fornecedores a questionários de segurança de rede que confirmam controles robustos de firewall e de perímetro descrevem um modelo de segurança que não aborda o principal vetor de ataque, baseado em credenciais.
a distinção entre perímetro de rede e perímetro de identidade é relevante para TPRM porque respostas de fornecedores a questionários de segurança de rede que confirmam controles robustos de firewall e de perímetro descrevem um modelo de segurança que não aborda o principal vetor de ataque, baseado em credenciais.
- Perímetro de rede versus perímetro de identidade: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias verbais: aplicação de MFA com confirmação de que não há caminho para contorná-la; gestão de dispositivos para controle de acesso; detecção de anomalias para comprometimento de credenciais.
- Resiliência de rede e pontos únicos de falha
-
A resiliência de rede importa para TPRM porque a disponibilidade da plataforma do fornecedor é uma dependência operacional direta para clientes corporativos.
a resiliência de rede importa para TPRM porque a disponibilidade da plataforma do fornecedor é uma dependência operacional direta para clientes corporativos.
- Resiliência de rede e pontos únicos de falha: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias verbais: avaliação de redundância de ISP e de circuitos.
- Arquitetura de segurança de rede para ambientes com prioridade para SaaS
-
A arquitetura de segurança de rede com prioridade para SaaS é importante para TPRM porque usar frameworks tradicionais de avaliação de segurança de rede em ambientes com prioridade para SaaS produz resultados de avaliação que descrevem incompatibilidades de arquitetura, e não lacunas de segurança.
a arquitetura de segurança de rede para ambientes SaaS-first é relevante para TPRM porque usar estruturas tradicionais de avaliação de segurança de rede em ambientes SaaS-first produz resultados que descrevem incompatibilidades de arquitetura, e não lacunas de segurança.
- Arquitetura de segurança de rede para ambientes SaaS-first: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias verbais: revisão da gestão da postura de segurança em SaaS.
- Segurança de rede na fronteira de OT/IT
-
a segurança da fronteira OT/IT é importante para TPRM porque fornecedores que fabricam hardware, operam instalações de produção ou executam sistemas logísticos têm redes OT cuja postura de segurança afeta diretamente a integridade e a disponibilidade de seus processos operacionais.
a segurança da fronteira OT/IT é importante para TPRM porque fornecedores que fabricam hardware, operam instalações de produção ou executam sistemas logísticos têm redes OT cuja postura de segurança afeta diretamente a integridade e a disponibilidade de seus processos operacionais.
- Segurança de rede para fornecedores em rápido crescimento: a lacuna de escala
-
A segurança na lacuna de escala é relevante para TPRM porque fornecedores em rápido crescimento podem descrever controles de segurança no nível de qualidade atual enquanto esses controles, na prática, operam abaixo do nível de qualidade exigido para a escala atual.
a segurança na lacuna de escala é relevante para TPRM porque fornecedores em rápido crescimento podem descrever controles de segurança no nível de qualidade atual enquanto esses controles, na prática, operam abaixo do nível de qualidade exigido para a escala atual.
- Segurança de rede para fornecedores em rápido crescimento: a lacuna de escala: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias verbais: revisão da trajetória de crescimento e do investimento em segurança.
- Segurança de rede em avaliações de terceiros
-
A lacuna entre questionário e avaliação técnica importa para TPRM porque determina o valor real de garantia da avaliação de segurança de rede. Para fornecedores críticos, uma avaliação de segurança de rede baseada apenas em questionário pode confirmar que os controles existem sem detectar os problemas de qualidade de implementação que criam o risco real de segurança.
a lacuna entre questionário e avaliação técnica é relevante para TPRM porque determina o valor real de garantia da avaliação de segurança de rede.
- Segurança de rede em avaliações de terceiros: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias verbais: amostra das regras de firewall externas para revisão; resultados recentes de varreduras de vulnerabilidades externas; confirmação de uma superfície de ataque externa sem exposições no Shodan.
- Resposta a incidentes de segurança de rede: os primeiros 60 minutos
-
A velocidade de resposta a incidentes de segurança de rede é importante para TPRM porque o tempo de permanência durante um incidente ativo, o período entre a detecção e a contenção, é quando o atacante conclui seus objetivos. Um fornecedor com uma janela de duas horas entre a deliberação e o isolamento dá aos atacantes duas horas de acesso ativo após a detecção.
a velocidade de resposta a incidentes de segurança de rede é relevante para TPRM porque o tempo de permanência durante um incidente ativo, o período entre a detecção e a contenção, é quando o atacante conclui seus objetivos.
- Métricas de segurança de rede que realmente importam
-
A qualidade das métricas de segurança de rede é relevante para TPRM porque métricas que descrevem atividade sem descrever risco não conseguem sustentar decisões de avaliação baseadas em risco.
a qualidade das métricas de segurança de rede importa para TPRM porque métricas que descrevem atividade sem descrever risco não podem sustentar decisões de avaliação baseadas em risco.
- Métricas de segurança de rede que realmente importam: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias verbais: definição e acompanhamento de métricas baseadas em risco; medição do tempo de detecção de ameaças na rede.
- Monitoramento de segurança de rede e integração com SIEM
-
a cobertura de logs do SIEM importa para TPRM porque a presença do SIEM confirma que a plataforma de monitoramento existe, enquanto a cobertura de logs determina o que essa plataforma consegue realmente detectar.
a cobertura de logs do SIEM importa para TPRM porque a presença do SIEM confirma que a plataforma de monitoramento existe, enquanto a cobertura de logs determina o que essa plataforma consegue realmente detectar.
- Monitoramento de segurança de rede e integração com SIEM: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias verbais: identificação das fontes de log críticas ausentes; um fornecedor que confirma SIEM deve ser questionado sobre a lista de fontes de log. A presença de SIEM é a plataforma. A amplitude das fontes de log é a cobertura de detecção. A proporção entre fontes de log conectadas e potenciais revela o que o SIEM consegue e não consegue detectar.
- Requisitos de segurança de rede nos contratos com fornecedores
-
Os requisitos contratuais de segurança de rede são relevantes para TPRM porque determinam se a postura de segurança confirmada na avaliação é exigível, ou seja, se a empresa tem recurso contratual quando o fornecedor deixa de manter os controles de segurança que a avaliação confirmou.
os requisitos contratuais de segurança de rede são importantes para TPRM porque determinam se a postura de segurança confirmada na avaliação é exigível, ou seja, se a empresa tem recurso contratual quando o fornecedor deixa de manter os controles de segurança que a avaliação confirmou.
- Requisitos de segurança de rede em contratos com fornecedores: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias verbais: revisão da especificidade das cláusulas contratuais de segurança; obrigações de segurança específicas nos contratos críticos.
- Avaliação da segmentação de rede em TPRM
-
A avaliação da segmentação de rede é importante para TPRM porque o valor de segurança da segmentação de rede de um fornecedor é determinado pela sua regra de fronteira mais permissiva, e não pela mais restritiva.
a avaliação da segmentação de rede é relevante para TPRM porque o valor de segurança da segmentação de rede de um fornecedor é determinado pela sua regra de fronteira mais permissiva, e não pela mais restritiva.
- Avaliação de segmentação de rede em TPRM: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias verbais: arquitetura de jump servers para acesso à produção; regra de fronteira interna mais permissiva; testes de eficácia da segmentação a partir de posições internas.
- Segurança do protocolo NTP e integridade dos logs
-
a segurança do NTP e a precisão dos carimbos de data e hora dos logs são relevantes para TPRM porque determinam a confiabilidade forense dos logs de segurança de um fornecedor durante a investigação de incidentes.
a segurança do NTP e a precisão dos carimbos de data e hora dos logs são relevantes para TPRM porque determinam a confiabilidade forense dos logs de segurança de um fornecedor durante a investigação de incidentes.
- Documentação da topologia de rede e governança de segurança
-
A atualização da documentação da topologia de rede é relevante para TPRM porque avaliações de segurança de rede conduzidas com base em diagramas desatualizados avaliam uma arquitetura que não existe.
a atualização da documentação da topologia de rede é relevante para TPRM porque avaliações de segurança de rede conduzidas com base em diagramas desatualizados avaliam uma arquitetura que não existe.
- Visibilidade de rede e análise de tráfego
-
A visibilidade do tráfego leste-oeste é importante para TPRM porque determina a rapidez com que um comprometimento da cadeia de suprimentos ou uma violação interna é detectado. Um atacante que comprometeu qualquer sistema dentro da rede de um fornecedor fará movimentação lateral para acessar alvos de maior valor: repositórios de código-fonte, infraestrutura de build, bancos de dados de produção.
a visibilidade do tráfego leste-oeste é importante para TPRM porque determina a rapidez com que um comprometimento da cadeia de suprimentos ou uma violação interna é detectado.
- Visibilidade de rede e análise de tráfego: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias verbais: NDR ou análise equivalente do tráfego interno; segmentos de rede com cobertura de monitoramento; um fornecedor que confirma ter monitoramento de rede deve ser questionado se esse monitoramento inclui o tráfego leste-oeste. O monitoramento de perímetro detecta o que entra e o que sai. O monitoramento leste-oeste detecta o que se move internamente. Os ataques atuais exigem ambos.
- NIST SP 800-161 para profissionais
-
NIST 800-161 importa para TPRM porque oferece um framework específico, endossado pelo governo, para avaliar a segurança da cadeia de suprimentos de software, dando aos profissionais um vocabulário estruturado para fazer perguntas que vão além de declarações binárias de conformidade.
NIST 800-161 importa para TPRM porque oferece um framework específico, endossado pelo governo, para avaliar a segurança da cadeia de suprimentos de software, dando aos profissionais um vocabulário estruturado para fazer perguntas que vão além de declarações binárias de conformidade.
- NIST SP 800-161 para profissionais: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias verbais: autoavaliação do nível de implementação NIST 800-161; documentação dos controles da cadeia de suprimentos de SR-3; evidências da implementação do rastreamento de procedência de SR-4.
O
- Excesso de escopo em OAuth
-
O OAuth é um framework de autorização que permite que aplicações obtenham acesso limitado a contas de usuários em serviços de terceiros, permitindo que um usuário autorize uma aplicação a agir em seu nome para finalidades específicas sem compartilhar suas credenciais com a aplicação.
O excesso de escopo do OAuth importa para TPRM porque as autorizações OAuth concedidas a aplicações de fornecedores persistem, muitas vezes por anos, e o escopo que elas conferem continua disponível para a aplicação do fornecedor, independentemente de os recursos que poderiam usar esse escopo chegarem a ser construídos ou usados.
- Excesso de escopo em OAuth: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias verbais: justificativa por permissão, com cada escopo vinculado a uma funcionalidade específica; opção de escopo mínimo necessário, ou seja, se há configurações de escopo reduzido disponíveis; identificação de permissões não utilizadas, ou seja, permissões que não são exercidas atualmente por funcionalidades ativas.
- Registro de obrigações
-
A lista de obrigações legais, regulatórias e contratuais aplicáveis, cada uma em linguagem simples, com um responsável, as evidências e o prazo.
É o primeiro artefato de qualquer programa, porque escopo, controles e retenção dependem de saber o que se aplica.
Ensinado em DTF-120 · Veja também: Escopo, Evidência
- O código aberto como risco de terceiros
-
O código aberto como risco de terceiros importa porque os ataques mais significativos à cadeia de suprimentos da última década tiveram como alvo componentes de código aberto: Log4Shell, o backdoor do XZ Utils, event-stream e ataques semelhantes exploraram a confiança que o software construído sobre componentes de código aberto deposita nesses componentes.
o código aberto como risco de terceiros é importante porque os ataques à cadeia de suprimentos mais significativos da última década tiveram como alvo componentes de código aberto: Log4Shell, o backdoor no XZ Utils, event-stream e ataques semelhantes exploraram a confiança que o software construído sobre componentes de código aberto deposita nesses componentes.
- Código aberto como risco de terceiros: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias verbais: lista de materiais de software do produto; confirmação das ferramentas de SCA e do monitoramento de vulnerabilidades; SLA de remediação para vulnerabilidades de código aberto.
- Risco de licenças de código aberto
-
O risco de licenças de código aberto é relevante para TPRM porque o software que sua empresa implanta pode impor obrigações legais que nem a empresa nem o fornecedor identificaram, obrigações que podem surgir após a implantação, quando as implicações jurídicas de uma combinação de licenças são avaliadas.
o risco de licenças de código aberto é relevante para TPRM porque o software que sua empresa implanta pode impor obrigações legais que nem a empresa nem o fornecedor identificaram, obrigações que podem surgir após a implantação, quando as implicações jurídicas de uma combinação de licenças são avaliadas.
- Risco de licenças de código aberto: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias verbais: SBOM com informações de licença de todos os componentes; resultados de varredura de licenças que identifiquem componentes copyleft; avaliação de conformidade jurídica para componentes AGPL e copyleft forte.
- Risco da cadeia de suprimentos de código aberto
-
O risco da cadeia de suprimentos de código aberto é a categoria de risco de segurança que decorre da dependência de uma aplicação em relação a componentes de software desenvolvidos, mantidos e distribuídos fora do controle da organização, normalmente por comunidades de voluntários, desenvolvedores individuais ou fundações que operam sob licenças de código aberto.
o risco da cadeia de suprimentos de código aberto é onde o framework de risco de terceiros encontra o framework de segurança da cadeia de suprimentos em sua interseção mais fundamental.
- Risco da cadeia de suprimentos de código aberto: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias verbais: documentação do processo de avaliação prévia à adoção, com critérios, aprovações e ferramentas usadas; confirmação da capacidade de detecção de pacotes maliciosos, com o nome da ferramenta e a capacidade de análise comportamental além das bases de CVE; confirmação da fixação de dependências e dos arquivos de lock, com evidências no controle de versões.
- Contas órfãs de fornecedores
-
Contas órfãs de fornecedores são contas de usuário e contas de serviço ativas nos sistemas de uma organização que pertencem a funcionários de fornecedores, terceirizados ou entidades de serviço cuja relação operacional com a organização já terminou.
as contas órfãs de fornecedores são importantes para TPRM porque representam uma superfície de ataque que persiste depois que a justificativa de risco para ela deixou de existir.
- Contas órfãs de fornecedores: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias verbais: inventário de contas do fornecedor em todos os sistemas; documentação do processo de desligamento que abranja todos os tipos de conta; um fornecedor que confirma ter procedimentos de desligamento deve ser solicitado a fornecer um inventário atualizado de todas as contas que mantém no ambiente do cliente, não apenas o acesso principal provisionado, mas também contas de serviço e contas específicas de aplicações em todos os sistemas. Esse inventário passa a ser o escopo do desligamento. Sem ele, o escopo do desligamento é o que estiver no checklist.
- Risco da terceirização versus responsabilidade na terceirização
-
A responsabilidade na terceirização é importante porque define o risco residual da empresa diante de falhas de fornecedores.
a responsabilização na terceirização importa porque define o risco residual da empresa decorrente de falhas de fornecedores.
- Terceirizar o risco versus terceirizar a responsabilidade: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias verbais: detalhes dos seguros de responsabilidade civil profissional e de riscos cibernéticos; valores de cobertura e exclusões relevantes para a responsabilidade regulatória; programa de conformidade regulatória para atividades terceirizadas.
- Contas de serviço com privilégios excessivos
-
Contas de serviço são identidades não humanas: contas criadas para aplicações, tarefas de automação, processos agendados, ferramentas de monitoramento e pipelines de integração, e não para usuários humanos individuais. Elas se autenticam em sistemas e recebem permissões para executar as funções para as quais foram criadas.
as contas de serviço com privilégios excessivos são importantes para TPRM porque representam a categoria de identidade mais explorada em ataques à cadeia de suprimentos.
- Contas de serviço com privilégios excessivos: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias verbais: inventário de contas de serviço, com quantidade, registro e documentação de responsáveis; confirmação da revisão de acesso das contas de serviço, incluídas no ciclo formal de revisão e com a data da última revisão; abordagem de gestão de credenciais, com plataforma de gestão de segredos ou política para credenciais estáticas.
P
- Modelo de confiança dos registros de pacotes
-
O modelo de confiança dos registros de pacotes é relevante para TPRM porque os produtos de software dos seus fornecedores são construídos sobre pacotes cuja confiabilidade depende não da sua legitimidade passada, mas da segurança atual das contas de seus mantenedores.
o modelo de confiança dos registros de pacotes é importante para TPRM porque os produtos de software dos seus fornecedores são construídos sobre pacotes cuja confiabilidade não depende da legitimidade passada, mas da segurança atual das contas de seus mantenedores.
- Modelo de confiança dos registros de pacotes: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias verbais: MFA para contas de publicação de pacotes; fixação de dependências e uso obrigatório de arquivos de lock; processo de revisão de atualizações de versões menores.
- Integração de testes de intrusão em CI/CD
-
A integração de testes de intrusão é relevante para TPRM porque pentests anuais em fornecedores com cadência frequente de lançamentos oferecem uma linha de base de segurança em um momento específico que pode não representar a postura de segurança atual.
a integração de testes de intrusão é relevante para TPRM porque pentests anuais em fornecedores com cadência frequente de lançamentos oferecem uma linha de base de segurança em um momento específico que pode não representar a postura de segurança atual.
- Integração de testes de intrusão em CI/CD: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias verbais: data do pentest e quantidade de releases desde então; programa de testes acionados por release ou testes contínuos; documentação do escopo do pentest anual, com a inclusão do pipeline e da infraestrutura.
- Escopo do teste de intrusão
-
Um relatório de teste de intrusão descreve o que foi testado, como, o que foi encontrado e o que foi recomendado. A seção de escopo é a que define o significado de todo o resto. Um relatório limpo sobre um escopo restrito diz que o testador não encontrou nada nos lugares em que tinha permissão para procurar, e os lugares em que não tinha permissão para procurar são de onde virá o próximo incidente.
os compradores pedem o relatório, as seguradoras perguntam se os testes acontecem, e o relatório é lido pela contagem de achados, e não pelo escopo. Um relatório com dois achados de baixa severidade sobre o site institucional é apresentado como evidência sobre o produto. Do lado de quem recebe, o relatório limpo de um fornecedor é aceito sem perguntar se a API com a qual você de fato se integra estava no escopo.
- Controles de fim de período versus controles ao longo do período
-
Os controles diferem em frequência. Alguns operam continuamente, como a autenticação. Alguns operam periodicamente, como as revisões de acesso trimestrais. Alguns operam uma vez por ano, como a avaliação anual de riscos ou o teste de recuperação de desastres. O auditor testa cada um de acordo com sua frequência, e a expectativa de evidências é completamente diferente entre eles.
um controle anual tem exatamente uma chance de ser executado e evidenciado dentro do período. Se essa chance for perdida, não há remediação possível dentro desse período, e o relatório registrará uma exceção que nenhuma recuperação posterior pode eliminar.
- Dados pessoais informações pessoais
-
Qualquer informação que identifique uma pessoa viva ou que possa ser vinculada a ela, incluindo identificadores, dados de dispositivos e opiniões registradas sobre alguém.
É mais amplo do que a maioria das pessoas supõe. Dados separados dos nomes, mas ainda vinculáveis, continuam sendo dados pessoais.
Ensinado em PRV-201 · Veja também: Categorias especiais de dados, Mapa de dados
- Dados pessoais e PII
-
PII, informações de identificação pessoal, é um termo norte-americano mais restrito para dados que identificam uma pessoa específica: um nome, um número de seguridade social, um número de conta. Dados pessoais segundo o GDPR são um conceito mais amplo. Abrangem qualquer informação relativa a uma pessoa identificável, seja a identificação direta ou indireta, o que inclui endereços IP, identificadores de dispositivos, IDs de cookies, rastros de localização e registros pseudonimizados.
as equipes definem o escopo de um programa de privacidade com a definição restrita, concluem que seus logs e dados analíticos não contêm PII e descobrem mais tarde que, pela definição mais ampla, metade da sua telemetria sempre foi composta de dados pessoais. A palavra escolhida no início decide o que o programa abrange.
- Riscos de segurança de pipeline como código
-
A segurança de pipeline como código é relevante para TPRM porque o pipeline de CI/CD é a ponte de confiança entre o código-fonte e o software em produção.
a segurança do pipeline como código importa para TPRM porque o pipeline de CI/CD é a ponte de confiança entre o código-fonte e o software em produção.
- Riscos de segurança de pipeline como código: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias verbais: configuração de CODEOWNERS para os arquivos de configuração do pipeline; processo de revisão de mudanças na configuração do pipeline; delimitação do acesso a credenciais pelos jobs do pipeline.
- Pontos de foco
-
Abaixo de cada critério há uma lista de pontos de foco. Eles parecem requisitos. Não são. São orientações ilustrativas do AICPA que descrevem como o atendimento ao critério poderia ser na prática, e uma organização pode atender a um critério sem abordar todos os pontos de foco, ou abordando alguns de formas que a lista nunca menciona.
as equipes leem os pontos de foco como uma lista de verificação obrigatória, criam um controle para cada um e mantêm esses controles por anos, produzindo evidências que ninguém pediu. Os auditores não testam pontos de foco. Eles testam se o critério é atendido.
- Política versus aplicação efetiva
-
Política versus aplicação efetiva é a lacuna entre os requisitos de segurança documentados (as normas, procedimentos e diretrizes que definem como os controles de segurança devem funcionar) e os mecanismos técnicos e operacionais que de fato implementam esses requisitos nos sistemas em execução.
a diferença entre política e aplicação efetiva é importante para TPRM porque avaliações de segurança de fornecedores que confirmam a existência de políticas estão confirmando o padrão que o fornecedor documentou, não o padrão que seus sistemas aplicam.
- Política versus aplicação efetiva: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias: configuração da plataforma de identidade mostrando os requisitos de senha efetivamente aplicados; configuração de senhas de contas de serviço documentada separadamente; inventário da configuração de senhas de sistemas legados.
- Política, norma, procedimento
-
Uma política declara o que deve ser feito e por quê, em um nível que muda raramente e é aprovado pela alta administração. Um padrão declara os requisitos específicos que implementam a política: o algoritmo de criptografia, a cadência de revisão, o tamanho da senha. Um procedimento descreve como uma pessoa nomeada executa uma tarefa, passo a passo. Três documentos, três públicos, três ritmos de mudança.
as organizações redigem vinte políticas a partir de um modelo, cada uma misturando os três, e depois não conseguem mudar uma cadência de revisão sem um ciclo de aprovação no nível do conselho, de modo que a cadência continua errada. Os auditores testam as políticas em relação à prática, e uma política que contém um requisito específico que a organização não cumpre é um achado que você escreveu para si mesmo. Funcionários a quem se pergunta o que uma política exige deles não sabem dizer, porque ela tem doze páginas de intenções.
- População e amostra
-
O conjunto completo de ocorrências em que um controle deveria ter operado durante um período, e o subconjunto selecionado para teste.
Uma conclusão sobre uma amostra só se sustenta se a população estava completa, e a exportação de um único sistema é uma lista, não uma população.
Ensinado em AUD-210 · Veja também: Evidência, Controles gerais de TI
- Considerações sobre o auditor anterior
-
Quando uma organização troca de auditor de serviços, a nova firma considera o relatório e a opinião do período anterior ao planejar o trabalho. Ela pode solicitar acesso à documentação do antecessor e lerá com particular interesse as exceções e as respostas da administração no relatório anterior.
trocar de firma é normal e muitas vezes sensato, por razões de custo, capacidade ou relacionamento. A transição corre melhor quando a organização consegue mostrar que as exceções anteriores foram remediadas e que os motivos da troca são comuns. Corre pior quando parece uma fuga.
- Privacidade desde a concepção e por padrão
-
Privacidade desde a concepção significa que a proteção de dados é considerada durante todo o desenvolvimento de um produto ou processo, incorporada à arquitetura em vez de acrescentada depois. Privacidade por padrão significa que, antes que o usuário altere qualquer coisa, aplicam-se as configurações mais protetivas: o mínimo de dados coletados, a retenção mais curta, o compartilhamento mais restrito. Ambas são obrigações previstas no Artigo 25 do GDPR.
por padrão é o mais testável dos dois, e o mais fácil de descumprir. Um produto pode ser cuidadosamente projetado e ainda assim ser lançado com o compartilhamento ativado, retenção ilimitada e uma opção de privacidade desativada. Os padrões são o que a maioria dos usuários experimenta, porque a maioria dos usuários nunca os altera.
- Privacidade na descoberta de produtos
-
Envolver a privacidade na descoberta do produto significa levantar as questões sobre dados quando o produto ainda é um esboço: o que será coletado, por quê, de quem, por quanto tempo e se o mesmo resultado poderia ser alcançado com menos. Nessa fase, uma mudança é uma conversa. No lançamento, a mesma mudança é uma nova versão, uma migração e um atraso.
a revisão de privacidade colocada no fim do processo só pode aprovar ou bloquear. Bloquear um produto pronto é politicamente tão caro que raramente acontece, então a revisão tardia aprova com condições que nunca são cumpridas. A função se torna um carimbo porque foi posicionada onde um carimbo era tudo o que ela podia ser.
- Métricas de privacidade
-
Métricas de privacidade úteis medem se o programa está funcionando, e não o quanto ele está ocupado. O tempo de resposta às solicitações de direitos em relação ao prazo legal. A proporção de atividades de tratamento com base legal documentada. Quão recentemente o registro das operações de tratamento foi atualizado. O número de projetos alterados na revisão de privacidade. A proporção de fornecedores com um DPA em conformidade. Cada uma responde a uma pergunta sobre eficácia.
os conselhos perguntam se o programa está funcionando, e a resposta oferecida costuma ser uma contagem: solicitações recebidas, avaliações concluídas, treinamentos realizados. O volume cresce com a conscientização e com o tamanho do negócio, o que faz um bom ano parecer ruim e não diz nada ao conselho sobre risco.
- Avisos de privacidade
-
Os artigos 13 e 14 do GDPR determinam o que deve ser informado aos titulares dos dados quando seus dados são coletados: a identidade do controlador, as finalidades e a base legal, os destinatários, eventuais transferências, o prazo de retenção, seus direitos e a origem dos dados, caso não tenham sido obtidos deles. As informações devem ser fornecidas de forma concisa, transparente, inteligível e de fácil acesso, em linguagem clara e simples.
os avisos costumam ser completos e ilegíveis. Todos os elementos exigidos estão presentes, enterrados em quatro mil palavras de redação jurídica que nenhum titular dos dados lerá. Isso não atende ao requisito de transparência, ainda que atenda ao de completude, porque uma informação que não pode ser compreendida não foi fornecida.
- Ferramentas de operações de privacidade
-
As ferramentas de operações de privacidade cuidam do trabalho recorrente de um programa: recebimento e acompanhamento de solicitações de direitos com prazos, manutenção do registro das operações de tratamento, registro de consentimentos e gestão de preferências, fluxos de trabalho de DPIA, avaliações de fornecedores e evidências de tudo isso. São elas que transformam um conjunto de obrigações em um conjunto de rotinas.
o trabalho de privacidade é repetitivo, sujeito a prazos e intensivo em evidências, que é exatamente o formato que falha quando é conduzido de memória e por e-mail. Uma solicitação de direitos acompanhada em uma caixa de entrada compartilhada perde o prazo. Um RoPA em uma planilha fica desatualizado. Um registro de consentimento em uma coluna booleana não prova nada.
- Gestão de acessos privilegiados
-
Acesso privilegiado é a capacidade de alterar sistemas, dados ou o acesso de outras pessoas: funções de administrador, acesso de escrita a bancos de dados, direitos de implantação, contas de emergência (break-glass). Gerenciá-lo significa saber quem o detém, concedê-lo para uma finalidade e por um período em vez de permanentemente, separá-lo das contas que as pessoas usam no dia a dia e registrar o que foi feito com ele.
o acesso privilegiado permanente é o achado que aparece em quase toda primeira avaliação, é a primeira coisa que um auditor de SOX procura nos sistemas que produzem os números, e é o motivo pelo qual as credenciais de um engenheiro vítima de phishing se tornam uma violação, e não apenas um incidente. É também o achado que mais demora para ser desfeito, porque eliminá-lo muda a forma como as pessoas trabalham.
- Lacunas na gestão de acessos privilegiados (PAM)
-
A gestão de acessos privilegiados é um conjunto de ferramentas e processos concebidos para controlar, monitorar e auditar o uso de credenciais privilegiadas, ou seja, contas com acesso elevado a sistemas, dados e infraestrutura.
as lacunas de PAM são importantes para TPRM porque prestadores de serviços gerenciados e fornecedores de infraestrutura que têm acesso privilegiado aos ambientes dos clientes representam alguns dos pontos de risco da cadeia de suprimentos de maior impacto no cenário corporativo.
- Lacunas na gestão de acessos privilegiados (PAM): as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias verbais: confirmação do armazenamento de credenciais do ambiente do cliente em cofre PAM corporativo; confirmação da gravação das sessões de acesso do cliente, com período de retenção; documentação do escopo de cobertura de PAM, para acessos internos e externos.
- Gestão de Acesso Privilegiado (PAM) no Contexto de Fornecedores
-
A Gestão de Acessos Privilegiados (PAM) não se resume a proteger credenciais de administrador; trata-se de controlar as condições em que ações de alto impacto podem ocorrer em um ambiente. Em essência, a PAM governa o acesso a sistemas, dados e capacidades que podem alterar materialmente o estado da empresa.
em ambientes de terceiros, o acesso privilegiado raramente tem um escopo tão restrito quanto deveria.
- Gestão de acesso privilegiado à rede
-
A gestão de acessos privilegiados à rede importa para TPRM porque os administradores de rede têm acesso para modificar os controles de segurança que protegem todos os outros sistemas.
a gestão do acesso privilegiado à rede é relevante para TPRM porque os administradores de rede têm acesso para modificar os controles de segurança que protegem todos os demais sistemas.
- Gestão de acesso privilegiado à rede: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias verbais: implementação de gravação de sessões na infraestrutura de acesso privilegiado; um fornecedor que confirma uma arquitetura de bastion host para acesso privilegiado deve ser questionado sobre a gravação de sessões e o encaminhamento de SSH. A presença do bastion é o ponto de estrangulamento. A gravação de sessões e a prevenção de contornos do registro de eventos são os controles de observabilidade que tornam o ponto de estrangulamento útil para fins de segurança.
- Termos do operador Artigo 28, DPA
-
Os termos contratuais obrigatórios entre um controlador e um operador: instruções documentadas, confidencialidade, segurança, suboperadores, apoio ao exercício de direitos, eliminação e auditoria.
As cláusulas são específicas o bastante para servir de referência de verificação, e a falta de uma delas é um achado que um regulador consegue descrever em uma frase.
Ensinado em PRV-203 · Veja também: Contrato de associado comercial, Mecanismo de transferência
- Segurança dos runtimes de linguagens de programação
-
A segurança do runtime é relevante para TPRM porque um fornecedor que entrega código de aplicação bem corrigido rodando sobre um runtime EOL está entregando um software cujo ambiente de execução de base tem vulnerabilidades permanentes sem correção.
a segurança do runtime é relevante para TPRM porque um fornecedor que entrega código de aplicação bem corrigido rodando sobre um runtime EOL está entregando um software cujo ambiente de execução de base tem vulnerabilidades permanentes sem correção.
- Segurança do runtime de linguagens de programação: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias verbais: cronograma de migração para runtimes em EOL ou próximos de EOL; um fornecedor que confirma a atualização das dependências da aplicação deve ser questionado sobre a atualização do runtime. A SCA da aplicação cobre as dependências. A avaliação do runtime cobre a camada sobre a qual as dependências rodam. Ambas são necessárias para uma avaliação completa da saúde da cadeia de suprimentos.
- Injeção de prompt
-
A injeção de prompt é um ataque a um sistema construído sobre um modelo de linguagem, no qual um conteúdo que o modelo lê, como um documento, uma página da web, um e-mail ou a mensagem de um usuário, contém texto que o modelo trata como instruções, e não como dados. O modelo então faz o que o texto do atacante diz: exfiltra informações que recebeu, ignora suas regras ou executa uma ação por meio de uma ferramenta à qual tem acesso.
é a vulnerabilidade específica desta classe de sistema, e ela não tem correção. Um modelo não consegue distinguir de forma confiável instruções de dados no mesmo canal, de modo que qualquer sistema que permita a um modelo ler conteúdo não confiável e depois agir com base nele carrega a exposição por concepção. O risco cresce com o que o modelo pode fazer: um modelo que só responde causa constrangimento quando sofre injeção; um que pode enviar e-mails ou alterar registros é perigoso.
- Injeção de prompt por meio de fornecedores
-
A injeção de prompt é uma técnica de ataque que explora a incapacidade dos LLMs de distinguir com confiabilidade entre instruções legítimas do operador do sistema, normalmente entregues por meio de um prompt de sistema, e instruções controladas pelo atacante inseridas na entrada do usuário ou nos dados que o LLM processa. O LLM é projetado para seguir instruções.
a injeção de prompt por meio de fornecedores importa para TPRM porque todo produto de IA implantado por um fornecedor com acesso a dados corporativos é uma potencial superfície de ataque de injeção de prompt.
- Injeção de prompt por meio de fornecedores: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias verbais: metodologia e resultados de testes de injeção de prompt; documentação do escopo de acesso a ferramentas por agentes; controles arquiteturais, como gateway de LLM e guardrails.
- Informações de saúde protegidas PHI
-
Informações de saúde individualmente identificáveis mantidas ou transmitidas por uma entidade abrangida ou por um associado comercial.
Aparece onde ninguém a previu: tickets de suporte, logs de aplicações, rastreamento de erros e ambientes de teste carregados a partir da produção.
Ensinado em PRV-203 · Veja também: Acordo com associado de negócios, Dados pessoais
- Pseudonimização e anonimização
-
A pseudonimização substitui campos identificadores por um token ou chave, de modo que os dados não possam ser atribuídos a uma pessoa sem informações adicionais mantidas separadamente. Os dados continuam sendo dados pessoais segundo o GDPR, porque a reidentificação é possível. A anonimização torna os dados tais que uma pessoa não pode ser identificada por nenhum meio razoavelmente provável de ser utilizado, e dados anônimos ficam inteiramente fora do GDPR.
quase nada do que é vendido como anonimizado atende de fato ao teste. Remover nomes e manter datas de nascimento, CEPs e cargos produz dados que podem ser reidentificados com esforço modesto. O critério é se a reidentificação é razoavelmente provável, levando em conta o custo, o tempo, a tecnologia e os demais dados disponíveis.
- Limitação da finalidade
-
A limitação da finalidade exige que os dados pessoais sejam coletados para finalidades determinadas, explícitas e legítimas e não sejam tratados posteriormente de forma incompatível com essas finalidades. Dados coletados para prestar um serviço não podem passar a servir a outra finalidade sem uma avaliação de compatibilidade ou uma nova base legal para o novo uso.
o exemplo típico é o de dados de suporte que viram dados de treinamento. Conversas com clientes coletadas para resolver problemas são usadas depois para treinar um modelo, melhorar um produto ou gerar um sinal de vendas. Ninguém decidiu dar outra finalidade aos dados; eles simplesmente estavam ali e eram úteis. A limitação da finalidade é o princípio que diz que utilidade não é fundamento.
Q
- Opiniões com ressalva
-
A opinião do auditor tem quatro formas. Sem ressalva significa que os controles foram adequadamente desenhados e operaram de forma eficaz. Com ressalva significa que sim, exceto por uma questão específica que o auditor descreve. Adversa significa que não. Abstenção significa que o auditor não conseguiu formar nenhuma opinião. A opinião fica na primeira página, em uma linguagem pensada para não chamar atenção.
a opinião é a frase mais importante do relatório, e é rotineiramente ignorada em favor das tabelas de testes. Uma opinião com ressalva não é uma auditoria reprovada, mas é o auditor dizendo que algo relevante não se sustentou, e o parágrafo que explica o quê merece ser lido antes de qualquer outra coisa.
- Risco quantificado análise no estilo FAIR
-
Um risco expresso como uma faixa de perdas ao longo de um período, construída a partir de estimativas declaradas de frequência e magnitude.
Escalas ordinais não podem ser comparadas com o custo de um controle. Uma faixa com nível de confiança declarado pode.
Ensinado em RSK-210 · Veja também: Apetite a risco, Tratamento de riscos
- Fadiga de questionários versus risco real
-
A fadiga de questionários é importante para TPRM porque representa a abordagem dominante de avaliação de risco de terceiros e tem desempenho sistematicamente fraco na pergunta que a gestão de riscos mais precisa responder: quais são os riscos específicos criados por este relacionamento específico com o fornecedor, e esses riscos estão adequadamente controlados?
a fadiga de questionários é relevante para TPRM porque representa a abordagem dominante na avaliação de risco de terceiros e tem desempenho sistematicamente insuficiente na pergunta que a gestão de riscos mais precisa responder: quais são os riscos específicos criados por esta relação específica com o fornecedor, e esses riscos estão adequadamente controlados?
- Fadiga de questionários versus risco real: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias verbais: respostas a perguntas específicas do relacionamento, com evidências de suporte; reconhecimento do perfil de risco específico que o relacionamento cria; evidências de controles que tratam os riscos específicos identificados.
R
- Avaliações de prontidão
-
Uma avaliação de prontidão é uma revisão do escopo, dos controles e das evidências pretendidos antes do início do período de observação, geralmente realizada pelo auditor ou por um consultor. Ela identifica lacunas enquanto ainda são baratas de corrigir e antes que se tornem exceções em um relatório que seus clientes vão ler.
uma exceção encontrada na fase de preparação é uma tarefa. A mesma lacuna encontrada na auditoria é um achado, registrado permanentemente, em um documento que será lido por todos os potenciais clientes durante o próximo ano. A diferença econômica não é pequena.
- Registro das operações de tratamento RoPA, registro do Artigo 30
-
O registro de quais dados pessoais uma organização trata, para quais finalidades, com quem são compartilhados, por quanto tempo e com quais salvaguardas.
Um regulador pode pedi-lo pelo nome e esperar recebê-lo imediatamente. Construído por meio de levantamentos, já está errado no dia em que fica pronto; construído a partir dos sistemas, ele se mantém.
Ensinado em PRV-220 · Veja também: Mapa de dados, Relatório de impacto à proteção de dados
- Registros das operações de tratamento
-
O registro das operações de tratamento, exigido pelo artigo 30 do GDPR, é um inventário de todas as atividades de tratamento que um controlador ou operador realiza: as finalidades, as categorias de dados e de titulares, os destinatários, eventuais transferências internacionais, os prazos de retenção e uma descrição das medidas de segurança. É o mapa do que a organização faz com dados pessoais.
é a primeira coisa que uma autoridade de controle pede, porque revela em um único documento se um programa sequer existe. Ninguém mantém um RoPA por acaso. Sua existência, completude e atualidade dizem mais sobre a governança de dados da organização do que qualquer política.
- Objetivos de recuperação
-
O objetivo de tempo de recuperação é quanto tempo um serviço pode ficar fora do ar antes que a perda se torne inaceitável. O objetivo de ponto de recuperação é quanta informação, medida em tempo, você pode se dar ao luxo de perder: o intervalo entre a última cópia íntegra e a falha. São compromissos distintos. Um RTO de quatro horas com um RPO de vinte e quatro horas significa que você estará de volta na hora do almoço, tendo perdido o dia anterior.
os clientes pedem ambos nos anexos de segurança, as seguradoras os pedem nas propostas, e os frameworks de continuidade os exigem por serviço. Eles também surgem no dia em que uma restauração é necessária, quando a organização descobre que o RPO escrito na política pressupunha cópias de segurança noturnas que foram alteradas para semanais durante uma revisão de custos.
- Pontos cegos regulatórios
-
Pontos cegos regulatórios são as estruturas regulatórias aplicáveis a uma relação com fornecedor, determinadas pela localização dos dados, pela residência dos titulares dos dados, pelo setor de atuação ou pela geografia operacional, que não são avaliadas porque o programa de avaliação foi concebido em torno de outro contexto regulatório.
os pontos cegos regulatórios são relevantes para TPRM porque estruturas regulatórias não avaliadas criam uma exposição de conformidade não gerenciada.
- Pontos cegos regulatórios: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias verbais: geografia da infraestrutura, com as regiões de nuvem específicas onde os dados são armazenados; confirmação da residência dos titulares dos dados, ou seja, quais jurisdições têm residentes no escopo; confirmação da formalização de DPA para as relações às quais o GDPR se aplica.
- Lacunas de interpretação regulatória
-
As lacunas de interpretação regulatória são divergências entre a forma como diferentes partes, como reguladores, organizações, fornecedores e assessores jurídicos, interpretam os requisitos específicos das regulamentações aplicáveis.
as lacunas de interpretação regulatória são relevantes para TPRM porque a obrigação regulatória do cliente é cumprida quando o fornecedor implementa o requisito segundo a interpretação que o regulador usará, e não segundo a interpretação que o fornecedor considera mais conveniente do ponto de vista operacional ou mais defensável juridicamente.
- Lacunas de interpretação regulatória: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias verbais: cálculo específico do prazo de retenção, com evento inicial, evento final e exceções; confirmação de que o cálculo corresponde à interpretação do cliente; fundamento regulatório da interpretação do fornecedor.
- Mapeamento regulatório em TPRM
-
O mapeamento regulatório é importante porque lacunas de conformidade descobertas durante uma fiscalização regulatória são significativamente mais caras do que lacunas identificadas e remediadas por meio de uma gestão proativa do programa. Uma lacuna na avaliação do risco de concentração do DORA ICT identificada em uma análise de lacunas em 2023 pode ser remediada antes da data de aplicação do 2025.
o mapeamento regulatório é importante porque lacunas de conformidade descobertas durante uma fiscalização regulatória são significativamente mais caras do que lacunas identificadas e remediadas por meio de uma gestão proativa do programa.
- Mapeamento regulatório em TPRM: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias verbais: lista de estruturas regulatórias aplicáveis a TPRM; análise de lacunas de DORA (quando aplicável); um fornecedor que confirma um programa de TPRM maduro deve ser questionado sobre quais regulamentações ele foi concebido para atender e se essas regulamentações estão atualizadas. Maturidade do programa para os requisitos de 2020 não é maturidade do programa para os de 2024.
- Confusão por sobreposição regulatória
-
A sobreposição regulatória ocorre quando várias estruturas regulatórias se aplicam à mesma organização, aos mesmos dados ou aos mesmos sistemas, cada uma impondo requisitos que podem ser complementares, equivalentes ou conflitantes. HIPAA e PCI-DSS são a sobreposição mais comum no tratamento de dados de saúde.
a confusão por sobreposição regulatória é importante para TPRM porque fornecedores que atuam em contextos regulatórios sobrepostos podem ter lacunas de conformidade na interseção: áreas em que seu programa de HIPAA não atende aos requisitos do PCI-DSS e seu programa de PCI-DSS não trata das especificidades do HIPAA, deixando a sobreposição descoberta.
- Confusão por sobreposição regulatória: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias: mapeamento dos sistemas com sobreposição regulatória, identificando os sistemas sujeitos a múltiplos frameworks; análise do requisito mais rigoroso nas principais áreas de sobreposição; avaliação de conformidade unificada para os sistemas com sobreposição.
- Fluxos de aprovação de releases
-
Os fluxos de aprovação de liberação são relevantes para TPRM porque implantações automáticas em produção sem pontos de aprovação humana significam que achados de segurança não configurados como bloqueios obrigatórios serão implantados em produção a cada merge.
os fluxos de aprovação de releases são importantes para TPRM porque implantações automáticas em produção sem pontos de aprovação humana significam que os achados de segurança não configurados como bloqueios obrigatórios serão implantados em produção a cada merge.
- Fluxos de aprovação de versões: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias verbais: configuração de proteção do ambiente de produção com revisores obrigatórios; processo de aceitação de achados consultivos para implantação em produção; exigência de status dos achados de segurança na revisão de liberação de versão.
- Segurança do acesso remoto para equipes híbridas
-
A segurança dos endpoints de acesso remoto é importante para TPRM porque a força de trabalho BYOD cria um cenário em que o acesso à rede corporativa ocorre a partir de dispositivos sem nenhuma linha de base de segurança obrigatória.
a segurança dos endpoints de acesso remoto é importante para TPRM porque a força de trabalho BYOD cria um cenário em que o acesso à rede corporativa ocorre a partir de dispositivos sem nenhuma linha de base de segurança obrigatória.
- Segurança do acesso remoto para equipes híbridas: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias verbais: implementação da verificação de postura do dispositivo para acesso via VPN; requisitos de dispositivos gerenciados para sistemas sensíveis; requisitos de MDM e de agentes de segurança de endpoint.
- Distribuição do relatório e NDA
-
Um relatório SOC 2 Tipo II é um documento de uso restrito, destinado à empresa auditada, aos seus clientes e aos auditores deles, e a pessoas com entendimento suficiente do sistema para interpretá-lo. Não se destina à publicação geral. O SOC 3 existe para essa finalidade.
o relatório contém detalhes sobre seus controles, seu sistema e as exceções encontradas, que é exatamente o que um atacante gostaria de ler. Ele também traz o nome e a opinião do auditor, que não quer vê-los interpretados por pessoas sem o contexto necessário para isso.
- Relatório versus percepção
-
O reporte é a comunicação das métricas e atividades do programa: contagens, médias, taxas de conclusão e atualizações de status que descrevem o que o programa fez.
relatórios versus conhecimento útil importa para TPRM porque o valor de governança do programa é determinado pela qualidade das decisões que ele possibilita, não pelo volume de suas saídas.
- Relatório versus percepção: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias verbais: avaliação honesta de como o perfil de risco do fornecedor mudou nos últimos doze meses; riscos relevantes em aberto no programa de segurança do fornecedor; melhorias feitas nos últimos doze meses.
- Builds reproduzíveis na prática
-
Compilações reproduzíveis importam para TPRM porque são o pré-requisito técnico para a verificação independente da proveniência do software no nível binário.
builds reproduzíveis são relevantes para TPRM porque são o pré-requisito técnico para a verificação independente da procedência do software no nível binário.
- Builds reproduzíveis na prática: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias verbais: referência ao commit do código-fonte dos artefatos distribuídos; participação no projeto Reproducible Builds ou equivalente; um fornecedor que confirma segurança da cadeia de suprimentos deve ser questionado sobre a reprodutibilidade. A reprodutibilidade é a base técnica para a verificação independente. Sem ela, a procedência dos binários precisa ser aceita apenas com base na confiança na infraestrutura de distribuição.
- Tabela de temporalidade
-
O registro de por quanto tempo cada categoria de dados é mantida, por quê, o que aciona a exclusão e onde está cada cópia.
Uma tabela de prazos que ninguém executa é um compromisso por escrito que você está visivelmente deixando de cumprir. A parte difícil são as cópias, não o sistema principal.
Ensinado em PRV-270 · Veja também: Preservação legal, Mapa de dados
- Tabelas de temporalidade
-
Uma tabela de temporalidade define por quanto tempo cada categoria de dados pessoais é mantida, e por quê. Cada prazo está vinculado a um motivo legal, regulatório, contratual ou operacional específico. Quando o motivo deixa de existir, a retenção também termina, e os dados são eliminados ou anonimizados. A tabela é a expressão operacional do princípio da limitação da conservação.
sete anos são aplicados a tudo porque parecem defensáveis. São defensáveis para registros financeiros em muitas jurisdições e para quase nada além disso. Dados de marketing, chamados de suporte, logs de aplicações e registros de candidatos têm cada um seu próprio prazo justificado, e ele costuma ser bem mais curto.
- Recuperação e vazamento de dados
-
Sistemas com geração aumentada por recuperação respondem a perguntas pesquisando um índice de documentos e repassando os relevantes a um modelo. Por isso, o modelo pode expor qualquer coisa que esteja no índice, e o índice frequentemente contém material que a pessoa que pergunta nunca teve direito de ver. O modelo não sabe disso; recebeu o documento e foi instruído a resumi-lo.
é a forma mais comum de um assistente interno se tornar uma violação de dados. Um índice útil construído sobre um drive compartilhado, um sistema de chamados e uma wiki inclui a pasta de RH que alguém compartilhou de forma ampla demais, a planilha de salários, a exportação de registros de clientes que um engenheiro de suporte fez dois anos atrás. O assistente responde a uma pergunta sobre um deles, com educação e precisão, a alguém que não deveria ter perguntado.
- Direito de auditoria
-
Uma cláusula de direito de auditoria dá a você a capacidade contratual de examinar os controles de um fornecedor, diretamente, por meio de um terceiro ou recebendo seus relatórios de asseguração independentes. A maioria das organizações nunca exerce a versão presencial. O que elas usam, todos os anos, é a cláusula que diz que o fornecedor entregará seu relatório de asseguração mediante solicitação.
é uma das seis cláusulas contratuais que concentram o risco de terceiros, e é aquela pela qual as pessoas mais negociam enquanto planejam nunca usá-la. Seu valor real é duplo: ela entrega o relatório de asseguração sem discussão e muda o comportamento do fornecedor pelo simples fato de existir. Clientes regulados também precisam dela para seus supervisores, o que a torna inegociável nesses contratos.
- Conjuntos de controles do tamanho certo
-
Um conjunto de controles deve cobrir os critérios com o menor número de controles que a organização consiga de fato operar e evidenciar em cada período. Cada controle do conjunto é uma obrigação recorrente: ele deve ser executado, no prazo, e deixar um registro, enquanto permanecer no conjunto.
conjuntos de controles grandes parecem rigorosos e falham na prática. Um conjunto de duzentos controles, adotado integralmente de uma estrutura, contém dezenas que ninguém de fato opera, e cada um deles se torna uma exceção na primeira auditoria que o amostrar. A organização criou os próprios achados.
- Cláusulas de direito de auditoria na prática
-
O direito de auditoria é importante porque é o mecanismo pelo qual a empresa pode obter uma verificação direta e independente dos controles de segurança do fornecedor, que não pode ser obtida por meio de questionários e análise de documentos. A resposta de um fornecedor a um questionário descreve o que o fornecedor diz que são seus controles.
o direito de auditoria é importante porque é o mecanismo pelo qual a empresa pode obter uma verificação direta e independente dos controles de segurança do fornecedor, que não pode ser obtida por meio de questionários e análise de documentos.
- Cláusulas de direito de auditoria na prática: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias verbais: confirmação do escopo e das limitações da cláusula de auditoria; detalhes da cláusula de substituição, ou seja, o que pode ser substituído e para qual finalidade; prazo de aviso prévio e processo logístico.
- Aceitação de riscos
-
Uma decisão, tomada por alguém com autoridade para tomá-la, de que um risco conhecido não será tratado além do ponto atual por enquanto.
É um tratamento com data marcada. Sem um vencimento, torna-se um risco que ninguém está acompanhando, aceito por alguém que talvez já tenha saído.
Ensinado em RSK-220 · Veja também: Tratamento de riscos, Apetite a risco
- Governança da aceitação de riscos
-
A governança da aceitação de riscos é importante porque riscos aceitos são riscos que a organização escolheu conscientemente assumir. Se essa escolha for feita sem controles compensatórios, monitoramento ou limites de tempo adequados, a organização está apenas adiando a materialização do risco em vez de gerenciá-lo.
a governança da aceitação de riscos é importante porque riscos aceitos são riscos que a organização escolheu conscientemente assumir.
- Governança da aceitação de riscos: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias verbais: política de aceitação de riscos com limites de prazo e níveis de autorização; registro ativo de riscos aceitos com datas de revisão; controles compensatórios para riscos aceitos materiais.
- Uso indevido da aceitação de riscos
-
A aceitação de risco é um mecanismo de governança para reconhecer formalmente que um risco ou uma lacuna de controle específica não será remediada dentro do prazo padrão de remediação, e para documentar a justificativa de negócio dessa decisão, o nível de risco residual, o responsável de negócio que assume a responsabilidade e as condições sob as quais a acei
O uso indevido da aceitação de riscos é relevante para TPRM porque produz registros de riscos que parecem abrangentes (todos os riscos identificados estão documentados e gerenciados), mas que, na prática, contêm uma quantidade crescente de aceitações antigas que representam riscos reais não mitigados, mantidos sem supervisão ativa.
- Uso indevido da aceitação de riscos: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias verbais: registro de riscos filtrado pelas aceitações antigas, com datas e histórico de revisões; acompanhamento dos compromissos de remediação para aceitações com remediação planejada; configuração de vencimento das aceitações na plataforma de GRC.
- Apetite a risco
-
Declaração de quanto risco uma organização está disposta a assumir, expressa de modo que a sua extrapolação seja observável.
Dois testes decidem se ele significa alguma coisa: poderíamos ultrapassá-lo, e saberíamos se isso acontecesse?
Ensinado em RSK-230 · Veja também: Tratamento de riscos, Risco quantificado
- Desalinhamento do apetite a risco
-
O desalinhamento do apetite a risco na gestão de fornecedores é a lacuna entre a tolerância formalmente definida da organização para riscos relacionados a fornecedores (expressa em limites de concentração, requisitos mínimos de segurança, limites de volume de dados e critérios de profundidade de integração) e o perfil de risco real da carteira de fornecedores existente.
o desalinhamento do apetite a risco é importante para TPRM porque os frameworks de apetite a risco são compromissos de governança: o conselho definiu o nível de concentração em fornecedores e de risco de segurança que está disposto a aceitar.
- Desalinhamento do apetite a risco: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias: detalhamento dos componentes de tratamento de dados, ou seja, o que é tratado e onde; avaliação de viabilidade técnica da redução do escopo de tratamento; cronograma de transição e estimativas de custo para a redução da concentração.
- Avaliação de riscos segundo o CC3
-
CC3 exige que a organização especifique seus objetivos, identifique os riscos à consecução desses objetivos, analise esses riscos, incluindo o risco de fraude, e os reavalie quando ocorrerem mudanças significativas. Na prática, exige uma avaliação de riscos documentada que seja de fato mantida, e não produzida uma única vez para a auditoria.
O CC3 é o critério que conecta todo o resto. Os controles existem porque riscos foram identificados e, sem um registro desse raciocínio, o conjunto de controles parece arbitrário. É também onde os auditores procuram evidências de que a organização pensa sobre a própria exposição, em vez de simplesmente seguir uma lista de verificação.
- Lacunas na comunicação de riscos
-
A comunicação de riscos é o processo de garantir que os riscos identificados cheguem às pessoas que têm autoridade, recursos ou responsabilidade operacional para agir sobre eles, e não apenas às pessoas que têm a responsabilidade técnica de acompanhá-los.
As lacunas de comunicação de riscos são relevantes para TPRM porque o valor do programa para a organização é determinado pela qualidade das decisões que ele possibilita, e as decisões exigem uma comunicação que chegue aos tomadores de decisão em formatos que apoiem uma ação informada.
- Lacunas na comunicação de riscos: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias: matriz de públicos para a comunicação de riscos; registros de notificação aos responsáveis de negócio sobre achados de alta prioridade; documentação dos formatos de comunicação para diferentes públicos.
- Falhas na priorização de riscos
-
A priorização de riscos é o processo de ordenar os riscos pela urgência e intensidade da resposta da gestão com base em sua consequência real, ou seja, a combinação de probabilidade e impacto que determina quais riscos, se não mitigados, causariam o maior dano.
as falhas de priorização de riscos são importantes para TPRM porque determinam onde se concentram os recursos de remediação e a atenção da gestão e, consequentemente, onde a redução de risco de fato acontece.
- Falhas na priorização de riscos: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias: metodologia ou critérios de classificação de risco dentro de cada nível; prazos de remediação diferenciados conforme a consequência; achados abertos de maior consequência e o status de sua remediação.
- Desafios da quantificação de riscos
-
A quantificação de riscos é a prática de expressar o risco em termos de probabilidade e magnitude: a probabilidade de que um evento adverso específico ocorra e o impacto financeiro ou operacional caso ocorra.
Os desafios de quantificação de riscos são relevantes para TPRM porque as decisões de governança e de negócios que dependem das avaliações de risco de fornecedores (alocação de orçamento, seguros, transferência de riscos, relatórios ao conselho e priorização da remediação) exigem cada vez mais expressões financeiras do risco, e não classificações ordinais.
- Desafios na quantificação de riscos: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias: volume e classificação dos dados de clientes tratados; estimativas de custo de notificação e resposta a violações; limites de cobertura do seguro cibernético e exclusões relevantes.
- Precisão do registro de riscos
-
Um registro de riscos é o inventário oficial dos riscos identificados que estão sendo gerenciados atualmente: o panorama de riscos ativos que os processos de governança usam para priorizar a remediação, alocar recursos e reportar à liderança.
A precisão do registro de riscos é relevante para TPRM porque o registro é a principal ferramenta para a tomada de decisões de governança: priorizar os recursos de remediação, monitorar os itens de alto risco e reportar o risco atual à liderança.
- Precisão do registro de riscos: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias verbais: evidências das etapas de remediação concluídas para achados de longa duração; etapas de remediação restantes, com datas previstas de conclusão; causa raiz do atraso, se a remediação estiver atrasada.
- Subjetividade na pontuação de riscos
-
A subjetividade na pontuação de riscos é a variação nos resultados das avaliações decorrente de diferenças na interpretação dos avaliadores sobre evidências, controles compensatórios e critérios de pontuação dentro de uma metodologia de avaliação de riscos definida. Não é uma falha na estrutura da metodologia; a estrutura pode ser totalmente consistente e bem definida.
A subjetividade na pontuação de riscos é relevante para TPRM porque as pontuações de risco orientam decisões de grande consequência: aprovação ou rejeição de fornecedores, medidas obrigatórias de mitigação de riscos, intensidade do monitoramento e exigências contratuais.
- Subjetividade na pontuação de riscos: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias: evidências técnicas da implementação do controle compensatório; explicação específica de como o controle compensatório reduz o risco do controle ausente; qualquer validação independente da eficácia do controle compensatório.
- Tratamento de riscos
-
A decisão tomada sobre um risco avaliado: modificar, compartilhar, evitar ou aceitar, com os controles que a concretizam.
Os controles devem derivar das decisões de tratamento. Um conjunto de controles escolhido a partir de um modelo não consegue explicar por que qualquer controle está ali.
Ensinado em RSK-201 · Veja também: Aceitação de riscos, Declaração de Aplicabilidade
- Acesso baseado em funções versus uso real
-
O acesso baseado em funções versus o uso real é relevante para TPRM porque fornecedores que usam RBAC na gestão de acessos de seus funcionários podem ter uma população de usuários com acesso significativamente mais amplo do que o trabalho real exige, e esse excesso de acesso representa um raio de impacto do comprometimento de credenciais maior do que a necessidade funcional.
O acesso baseado em funções versus o uso real é relevante para TPRM porque fornecedores que usam RBAC na gestão de acessos de seus funcionários podem ter uma população de usuários com acesso significativamente mais amplo do que o trabalho real exige, e esse excesso de acesso representa um raio de impacto do comprometimento de credenciais maior do que a necessidade funcional.
- Acesso baseado em funções versus uso real: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias: dados de utilização de permissões, ou seja, permissões usadas versus não usadas nas funções relevantes; integração da análise de uso ao processo de revisão de acessos; histórico de recalibração de funções, ou seja, quando as funções foram atualizadas pela última vez com base nos padrões de uso.
- Autoproteção de aplicações em tempo de execução no contexto de CI/CD
-
RASP é relevante para TPRM porque representa a camada de segurança entre os controles de perímetro de rede que um fornecedor confirmou e o comportamento real da aplicação em tempo de execução.
RASP é relevante para TPRM porque representa a camada de segurança entre os controles de perímetro de rede que um fornecedor confirmou e o comportamento real da aplicação em tempo de execução.
- Autoproteção de aplicações em tempo de execução no contexto de CI/CD: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias verbais: confirmação da implantação de RASP ou de proteção em tempo de execução; cobertura e capacidade de detecção da proteção em tempo de execução; integração com CI/CD para a implantação da proteção em tempo de execução.
S
- Postura de segurança de SaaS versus avaliação tradicional de fornecedores
-
A postura de segurança de SaaS é relevante porque o vetor de ataque mais comum contra plataformas SaaS não é o comprometimento no nível da plataforma, e sim o acesso baseado em credenciais por meio de contas de usuário comprometidas, contas de serviço com privilégios excessivos e tokens API persistentes.
A postura de segurança de SaaS é relevante porque o vetor de ataque mais comum contra plataformas SaaS não é o comprometimento no nível da plataforma, e sim o acesso baseado em credenciais por meio de contas de usuário comprometidas, contas de serviço com privilégios excessivos e tokens API persistentes.
- Postura de segurança em SaaS versus avaliação tradicional de fornecedores: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias verbais: confirmação de acesso por API para integração com SSPM; recursos de relatório de usuários e permissões; suporte à funcionalidade de rotação de credenciais de API.
- Venda e compartilhamento
-
Divulgação de informações pessoais em troca de dinheiro ou de outro valor (venda), ou para que a publicidade possa acompanhar uma pessoa entre sites (compartilhamento ou publicidade direcionada).
A maioria das organizações que afirmam não vender dados os compartilha por meio de tags de publicidade, e é daí que vem o escopo inesperado.
Ensinado em PRV-202 · Veja também: Global Privacy Control, Plataforma de gestão de consentimento
- Venda e compartilhamento segundo a CPRA
-
A CPRA da Califórnia define venda como a divulgação de informações pessoais a um terceiro em troca de contraprestação monetária ou de outro valor, e compartilhamento como a divulgação a um terceiro para publicidade comportamental entre contextos, haja ou não troca de algo de valor. Ambos acionam o direito do consumidor de se opor e a obrigação de respeitar essa oposição.
Os pixels de publicidade pegaram a maioria das empresas de surpresa. Um pixel de rastreamento que envia dados de navegação a uma plataforma de publicidade em troca de mensuração ou formação de públicos é uma venda ou um compartilhamento segundo essa definição, mesmo que não exista nenhuma fatura. A contraprestação é o serviço recebido, e a obrigação de oferecer a opção de recusa se aplica.
- Amostragem e populações
-
Os auditores não testam todas as ocorrências de um controle. Eles fazem amostragem, e o tamanho da amostra acompanha a frequência do controle e o tamanho da população. Um controle diário pode ser amostrado em 25 ocorrências ao longo do ano; um trimestral, em duas; um controle executado uma única vez, em uma. A abordagem é padrão e os tamanhos são convencionais.
A população vem primeiro, e produzi-la geralmente é tarefa sua. O auditor precisa de uma lista completa e precisa de cada ocorrência em que o controle foi executado, cada mudança, cada novo funcionário, cada revisão de acessos, antes de selecionar a partir dela. Uma população gerada a partir de um relatório filtrado, ou de um sistema que não captura todas as ocorrências, fornece ao auditor uma amostra de um subconjunto, e a conclusão tirada dela não tem fundamento.
- SAST, o que detecta e o que não detecta
-
As lacunas de SAST são relevantes para TPRM porque a confirmação de SAST sem avaliação de cobertura e de remediação oferece garantia sobre a presença da ferramenta, e não sobre a sua eficácia.
As lacunas de SAST são relevantes para TPRM porque a confirmação de SAST sem avaliação de cobertura e de remediação oferece garantia sobre a presença da ferramenta, e não sobre a sua eficácia.
- SAST, o que detecta e o que não detecta: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias: mapa de cobertura de SAST com os módulos excluídos e a justificativa; SLA de remediação de SAST por severidade; a um fornecedor que confirme SAST deve-se solicitar a cobertura e o backlog de remediação. A presença de SAST é a ferramenta. A cobertura e a velocidade de remediação são as métricas de eficácia.
- SAST versus a redução real de riscos
-
O SAST é uma das práticas de segurança de aplicações mais citadas nas respostas a questionários de fornecedores, e uma das mais distorcidas, não por engano deliberado, mas porque a pergunta 'vocês usam SAST?' pode ser respondida com precisão por qualquer fornecedor cuja cadeia de ferramentas de desenvolvimento inclua um scanner, independentemente de o
O SAST é uma das práticas de segurança de aplicações mais citadas nas respostas a questionários de fornecedores, e uma das mais distorcidas, não por engano deliberado, mas porque a pergunta 'vocês usam SAST?' pode ser respondida com precisão por qualquer fornecedor cuja cadeia de ferramentas de desenvolvimento inclua um scanner, independentemente de o
- SAST versus a redução real de riscos: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias: quantidade de achados críticos e altos em aberto para a aplicação específica, com dados de tendência que mostrem a direção da mudança; tempo médio de remediação de achados críticos, ou seja, um número, e não uma declaração de política; confirmação da política de bloqueio com a documentação do processo de exceção.
- Escopo
-
A decisão sobre quais entidades, sistemas, produtos, ambientes e dados um programa ou uma certificação abrange, e sobre o que é excluído e por quê.
É a maior alavanca isolada sobre o custo, e é uma decisão, não uma descoberta. Um escopo sem limites é como noventa dias se tornam dezoito meses.
Ensinado em AUD-250 · Veja também: Registro de obrigações, Declaração de Aplicabilidade
- Escopo e fronteira do sistema
-
A fronteira do sistema define quais sistemas, pessoas, processos e dados estão dentro da auditoria e quais não estão. Tudo o que está dentro é descrito e testado. Tudo o que está fora não é testado, e o relatório não diz nada a respeito. Quem traça a fronteira é a empresa auditada.
Uma fronteira estreita produz uma auditoria mais barata e mais rápida e um relatório que cobre menos do que o leitor supõe. Uma fronteira ampla produz o oposto. Nenhuma das duas está errada, mas a escolha deve ser feita deliberadamente, e a fronteira deve corresponder ao que os clientes de fato compram.
- Ampliação do escopo entre ciclos de auditoria
-
Os produtos mudam mais rápido do que o escopo da auditoria. Entre um relatório e o seguinte, um fornecedor pode lançar novos serviços, abrir novas regiões, adquirir uma empresa ou migrar sua infraestrutura. O relatório que você tem descreve o sistema como era durante um período que terminou há algum tempo.
O relatório é preciso e, ao mesmo tempo, não cobre aquilo que você está comprando agora. Um cliente que adotou uma nova funcionalidade há seis meses pode estar se baseando em um relatório cuja descrição do sistema é anterior à existência dessa funcionalidade.
- Segredos & gestão de chaves
-
A gestão de segredos é a disciplina de controlar como as credenciais sensíveis (chaves de API, senhas, certificados, chaves de criptografia, tokens e strings de conexão) são criadas, armazenadas, distribuídas, usadas e desativadas. Parece um problema simples de higiene de TI, e é exatamente por isso que é subestimado de forma tão consistente.
As integrações de fornecedores funcionam quase inteiramente com base em segredos.
- Segredos & gestão de chaves: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias: plataforma de gestão de segredos identificada, com controles de acesso e registro de auditoria documentados; política de rotação com tempo de vida máximo definido para credenciais, idealmente de 90 dias ou menos; processo de revogação imediata quando pessoas com acesso se desligam.
- Segredos no código-fonte
-
Os segredos no código-fonte são importantes para TPRM porque os repositórios de desenvolvimento dos seus fornecedores podem conter credenciais que dão acesso a sistemas que tratam os seus dados: credenciais de bancos de dados de produção, chaves de provedores de nuvem, tokens de API de serviços que lidam com os seus dados.
Os segredos no código-fonte são relevantes para TPRM porque os repositórios de desenvolvimento dos seus fornecedores podem conter credenciais que dão acesso a sistemas que tratam os seus dados: credenciais de bancos de dados de produção, chaves de provedores de nuvem, tokens de API de serviços que lidam com os seus dados.
- Segredos no código-fonte: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias: implementação de verificação de segredos antes do commit; confirmação da rotação de credenciais para quaisquer exposições históricas; política de gestão de segredos e sua aplicação.
- Gestão de segredos em CI/CD
-
A higiene na gestão de segredos é relevante para TPRM porque as credenciais de pipeline de CI/CD (chaves de acesso a provedores de nuvem, tokens de registros de artefatos, credenciais de implantação em produção) estão entre as credenciais de maior valor no ambiente de uma empresa.
A higiene na gestão de segredos é relevante para TPRM porque as credenciais de pipeline de CI/CD (chaves de acesso a provedores de nuvem, tokens de registros de artefatos, credenciais de implantação em produção) estão entre as credenciais de maior valor no ambiente de uma empresa.
- Gestão de segredos em CI/CD: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias: cronograma de rotação de segredos e datas das últimas rotações; documentação do escopo dos segredos, ou seja, quais etapas acessam quais segredos; a um fornecedor que confirme a gestão de segredos deve-se perguntar sobre rotação, mascaramento e higiene do histórico do git. A gestão de segredos é o mecanismo de armazenamento. A rotação, o mascaramento e a higiene do histórico determinam se os segredos armazenados continuam secretos.
- Aplicação de padrões de codificação segura
-
Um padrão de codificação segura é um conjunto definido de regras, diretrizes e requisitos que especificam como os desenvolvedores devem escrever código para evitar a introdução de vulnerabilidades de segurança.
Os padrões de codificação segura são o controle a montante que determina a qualidade de segurança do código antes que as ferramentas de varredura automatizada tenham a chance de detectar o que os padrões foram concebidos para prevenir.
- Aplicação de padrões de codificação segura: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias: documentação do mapeamento de regras de SAST que mostre quais requisitos do padrão são aplicados automaticamente por meio de ferramentas; confirmação da plataforma de treinamento, com a descrição do conteúdo específico por linguagem e relevante para o padrão; métricas de conformidade, ou seja, o percentual da base de código que atende aos requisitos do padrão por meio de ferramentas mensuráveis.
- SDLC seguro em ambientes de fornecedores
-
A segurança de aplicações de fornecedores é a categoria de risco mais diretamente ligada ao que a sua organização de fato vivencia quando o software de um fornecedor é violado, explorado ou apresenta vulnerabilidades. Todas as outras dimensões da segurança de fornecedores (configuração de nuvem, gestão de acessos, criptografia) operam na camada de infraestrutura.
a segurança das aplicações de fornecedores é a categoria de risco mais diretamente ligada ao que a sua organização de fato vivencia quando o software de um fornecedor é violado, explorado ou apresenta vulnerabilidades.
- SDLC seguro em ambientes de fornecedores: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias: sumário executivo do teste de intrusão com escopo na aplicação específica, datado dos últimos 12 meses, com a quantidade de achados em aberto por severidade; confirmação da ferramenta de SAST com frequência de varredura, cobertura da base de código e documentação de SLA de remediação; documentação do processo de divulgação de vulnerabilidades com prazo de notificação assumido e SLA de remediação por severidade.
- Programa de campeões de segurança em DevSecOps
-
Os programas de campeões de segurança são relevantes para TPRM porque representam o mecanismo organizacional que distribui a segurança pelo fluxo de desenvolvimento, onde ela pode prevenir vulnerabilidades com mais eficácia antes que sejam incorporadas ao código.
Os programas de campeões de segurança são relevantes para TPRM porque representam o mecanismo organizacional que distribui a segurança pelo fluxo de desenvolvimento, onde ela pode prevenir vulnerabilidades com mais eficácia antes que sejam incorporadas ao código.
- Programa de campeões de segurança em DevSecOps: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias: número de campeões de segurança ativos por equipe de desenvolvimento; data do último treinamento ou reunião de campeões; achados de segurança atribuídos a campeões no último trimestre.
- Acompanhamento da dívida de segurança e velocidade de remediação
-
O acompanhamento da dívida de segurança é importante para TPRM porque a proporção entre achados gerados e achados remediados é o indicador disponível mais preciso de que um programa de DevSecOps está de fato melhorando a postura de segurança.
O acompanhamento da dívida de segurança é relevante para TPRM porque a razão entre os achados gerados e os achados remediados é o indicador disponível mais preciso de que um programa de DevSecOps está de fato melhorando a postura de segurança.
- Acompanhamento da dívida de segurança e velocidade de remediação: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias verbais: backlog atual de achados por severidade; variação líquida do backlog no último trimestre, com crescimento ou redução; distribuição por idade dos achados críticos e altos.
- Contornos dos controles de segurança em CI/CD
-
Os contornos dos controles de segurança são importantes para TPRM porque representam a diferença entre controles de segurança como controles e controles de segurança como monitoramento. Um controle que pode ser contornado unilateralmente por administradores a qualquer momento é uma ferramenta de monitoramento que gera alertas quando o alerta é inconveniente.
Os contornos de barreiras de segurança são relevantes para TPRM porque representam a diferença entre barreiras de segurança como controles e barreiras de segurança como monitoramento.
- Contornos de barreiras de segurança em CI/CD: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias: política de governança de contornos, ou seja, quem pode contornar e com qual aprovação; disponibilidade do log de auditoria de eventos de contorno; processo e frequência de revisão do log de contornos.
- Silos nas operações de segurança
-
Os silos nas operações de segurança são as separações organizacionais e técnicas entre equipes de segurança especializadas por domínio (segurança de aplicações, segurança em nuvem, segurança de endpoints, SOC, segurança de redes) que impedem a visibilidade entre domínios, a correlação de achados entre domínios e a identificação de cadeias de ataque entre domínios.
Os silos nas operações de segurança são relevantes para TPRM porque as cadeias de ataque que atacantes sofisticados da cadeia de suprimentos usam para chegar aos dados dos clientes normalmente abrangem vários domínios de segurança: exploram vulnerabilidades de aplicações para obter acesso inicial, configurações incorretas de endpoints para escalar privilégios e configurações incorretas de nuvem para alcançar dados sensí
- Silos nas operações de segurança: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias: mecanismo de correlação entre domínios, seja ferramenta ou processo; escopo dos exercícios de red team, com as cadeias entre domínios testadas; capacidade de avaliação de caminhos de ataque em múltiplos domínios.
- Questionários de segurança em escala
-
Responder a questionários de segurança de compradores é um custo recorrente de vender para organizações reguladas, e a forma padrão de lidar com isso é ruim de um jeito específico: cada um é respondido de memória por quem respondeu o anterior, de forma um pouco diferente a cada vez, e ninguém registra o que foi dito. Seis meses depois chega um questionário parecido e o trabalho começa do zero.
três questionários em um trimestre perguntando sobre criptografia em repouso recebem três respostas diferentes, nenhuma errada, cada uma enfatizando algo diferente. Um quarto, respondido às pressas, assume um controle que a empresa não opera, e essa resposta passa a ser uma declaração contratual que ninguém da engenharia sabe que foi feita.
- Testes de segurança em sinalizadores de funcionalidade
-
A segurança dos sinalizadores de funcionalidade é relevante para TPRM porque os sinalizadores de funcionalidade representam um mecanismo de implantação que contorna os controles do pipeline de CI/CD se o processo de ativação dos sinalizadores não tiver uma governança de segurança equivalente.
a segurança dos sinalizadores de funcionalidades é importante para TPRM porque esses sinalizadores representam um mecanismo de implantação que contorna os controles do pipeline de CI/CD se o processo de ativação do sinalizador não tiver uma governança de segurança equivalente.
- Testes de segurança em sinalizadores de funcionalidade: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias: documentação do controle de acesso aos sinalizadores de funcionalidade, ou seja, quem pode ativá-los em produção; fluxo de aprovação para novas ativações de sinalizadores de funcionalidade; vínculo entre a revisão de segurança e o estado dos sinalizadores de funcionalidade.
- Segregação de funções
-
A segregação de funções é o princípio de que nenhuma pessoa sozinha pode concluir uma ação sensível do início ao fim: quem solicita não aprova, quem desenvolve não implanta em produção, quem concede acesso não o revisa, quem altera um beneficiário não libera o pagamento. É um controle contra erros e contra fraudes, e é o controle que as organizações pequenas têm mais dificuldade de operar.
Os auditores a testam diretamente, os controles financeiros dependem dela, e sua ausência é o que faz uma única pessoa comprometida ou descuidada se tornar um evento material. Ela também aparece nas revisões de acessos, em que o revisor que aprova o próprio acesso já disse algo ao auditor, e no controle de mudanças, em que um desenvolvedor que pode fazer merge e implantar sozinho eliminou a revisão do processo.
- Como selecionar a metodologia certa de avaliação de segurança de rede
-
A escolha da metodologia de avaliação é importante para a eficácia do programa de TPRM porque uma metodologia inadequada (avaliação superficial para fornecedores de alta criticidade) cria uma lacuna de falsa garantia: o fornecedor foi avaliado, a avaliação não encontrou problemas, mas a metodologia de avaliação não era suficiente para encontrar os problemas existentes.
A seleção da metodologia de avaliação é relevante para a eficácia do programa de TPRM porque uma metodologia inadequada (avaliação de baixa profundidade para fornecedores de alta criticidade) cria uma falsa lacuna de garantia: o fornecedor foi avaliado, a avaliação não encontrou problemas, mas a metodologia de avaliação era insuficiente para encontrar os problemas que existem.
- Escolha da metodologia adequada de avaliação de segurança de rede: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias: requisitos de evidência técnica para fornecedores críticos; integração de varreduras externas para fornecedores críticos; revisão da metodologia como parte da governança de TPRM.
- Lacunas na descoberta de dados sensíveis
-
A descoberta de dados sensíveis é o processo sistemático de varredura do ambiente de dados de uma organização para identificar onde existem dados sensíveis (informações pessoais, dados financeiros, informações de saúde, credenciais e outras categorias de dados regulados ou de alto valor) em sistemas de armazenamento, documentos, plataformas de colaboração e i
As lacunas na descoberta de dados sensíveis são relevantes para TPRM porque representam a categoria de exposição de dados que é invisível para as avaliações de segurança de fornecedores padrão.
- Lacunas na descoberta de dados sensíveis: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias: documentação do escopo do programa de descoberta, com todos os sistemas incluídos e confirmação específica da cobertura das plataformas de suporte e de colaboração; resumo dos resultados da varredura de descoberta mais recente nos sistemas de suporte; documentação do processo de remediação para dados sensíveis descobertos fora do escopo.
- Segurança serverless em CI/CD
-
A segurança serverless é importante para TPRM porque funções de execução do Lambda com permissões excessivas são um achado comum em ambientes serverless que não aplicaram o princípio do privilégio mínimo à configuração de IAM das funções.
a segurança serverless é importante para TPRM porque funções de execução do Lambda com permissões excessivas são um achado comum em ambientes serverless que não aplicaram o princípio do privilégio mínimo à configuração de IAM das funções.
- Segurança serverless em CI/CD: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias: registros de revisão de privilégio mínimo das funções de execução; uso do IAM Access Analyzer ou equivalente; varredura de IaC para a segurança das funções de execução.
- Auditor de serviços e organização de serviços
-
A organização de serviços é a empresa auditada. O auditor de serviços é a firma de CPA que realiza o trabalho. A entidade usuária é o cliente que se baseia no relatório, e o auditor usuário é o auditor do próprio cliente, que pode, por sua vez, se basear no relatório. O relatório é escrito para esses dois últimos.
Saber qual papel você ocupa muda a forma como você lê o documento. Os CUECs são escritos para a entidade usuária e o seu auditor, e é por isso que se leem como instruções. A descrição do sistema é escrita pela organização de serviços sobre si mesma. A opinião é do auditor de serviços, dirigida à administração da organização de serviços.
- Riscos de sequestro de sessão
-
O sequestro de sessão é a técnica de ataque que consiste em roubar a credencial de sessão obtida após a autenticação (normalmente um cookie de sessão, um token de acesso ou um token de atualização) e usá-la para acessar sistemas como o usuário autenticado, sem repetir o processo de autenticação.
O risco de sequestro de sessão é relevante para TPRM porque fornecedores que detêm tokens de sessão válidos para acesso ao ambiente do cliente oferecem um vetor de ataque adicional além do roubo de credenciais.
- Riscos de sequestro de sessão: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias: documentação do tempo de vida dos tokens de acesso e de atualização; confirmação da implementação da avaliação contínua de acesso; capacidade de revogação de sessões e tempo de resposta.
- IA paralela
-
IA paralela é o uso de ferramentas e funcionalidades de IA que ninguém aprovou e ninguém registrou: assistentes de consumo usados em contas pessoais, modelos chamados a partir de código de produção sem revisão e assistentes ativados dentro de produtos que a organização já compra. Esta última é a maior categoria e a menos visível, porque a nova funcionalidade de um fornecedor não parece uma adoção de IA.
A proibição não funciona. Banir uma categoria sem oferecer uma alternativa aprovada leva a atividade para contas pessoais, onde você não consegue ver nada. E uma pesquisa também não a encontra, porque as pessoas descrevem as ferramentas que escolheram deliberadamente, e não a funcionalidade que surgiu na plataforma de suporte no último trimestre e que agora resume todos os chamados.
- Uso de nuvem paralela por fornecedores
-
O uso de nuvem paralela por fornecedores é a criação, modificação ou operação de recursos de nuvem dentro do ambiente de um cliente, ou usando a identidade e o faturamento de nuvem do cliente, sem o conhecimento e a aprovação explícitos do cliente para essas atividades específicas.
O uso de nuvem paralela por fornecedores é um dos exemplos mais claros de como o risco de terceiros em ambientes de nuvem não pode ser avaliado apenas no nível da organização do fornecedor.
- Uso de nuvem paralela por fornecedores: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias: uma descrição clara dos tipos de recursos que o fornecedor precisa ter acesso para criar, com justificativa operacional; evidências de controles internos que impeçam os engenheiros do fornecedor de provisionar recursos não autorizados nos ambientes dos clientes; um processo definido de descomissionamento dos recursos criados pelo fornecedor ao término do trabalho.
- Limitações de cobertura de SIEM
-
As limitações de cobertura de SIEM são as lacunas entre os sistemas e ambientes que uma plataforma de SIEM monitora e todo o conjunto tecnológico que gera eventos relevantes para a segurança. Uma plataforma de SIEM monitora aquilo de que recebe telemetria: os sistemas, serviços e ambientes configurados para encaminhar logs e eventos ao SIEM.
as limitações de cobertura de SIEM são importantes para TPRM porque os atacantes da cadeia de suprimentos visam especificamente os caminhos menos monitorados para os ambientes dos fornecedores: os serviços gerenciados, os sistemas de acesso de terceirizados e os pipelines de desenvolvimento, que têm maior probabilidade de apresentar lacunas na cobertura de monitoramento.
- Limitações de cobertura de SIEM: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias: confirmação da cobertura dos serviços gerenciados ou divulgação das lacunas; a um fornecedor com um SIEM maduro deve-se solicitar o inventário de integrações. A implantação do SIEM descreve a capacidade. O inventário descreve o que a capacidade cobre.
- SIG e SIG Lite
-
O questionário Standardized Information Gathering é um grande conjunto estruturado de perguntas mantido pelo programa Shared Assessments, que abrange segurança, privacidade, resiliência e domínios relacionados. O SIG Lite é a versão básica, mais curta. Seu valor está no fato de que o fornecedor pode já ter preenchido um, o que transforma sua avaliação em uma revisão de respostas existentes, em vez de um novo interrogatório.
Quando o seu programa estiver decidindo qual instrumento usar em cada nível, os conjuntos padrão são os candidatos óbvios para o nível superior, e fornecedores que vendem para compradores regulados costumam manter um SIG preenchido e atualizado exatamente por esse motivo. Aceitar um deles poupa semanas para ambos os lados, desde que você o leia em vez de apenas arquivá-lo.
- O Sigstore e a revolução dos logs de transparência
-
O Sigstore é relevante para TPRM porque oferece um padrão gratuito e acessível de assinatura e transparência para a cadeia de suprimentos de software, que elimina a barreira técnica à adoção por fornecedores menores.
O Sigstore é relevante para TPRM porque oferece um padrão gratuito e acessível de assinatura e transparência para a cadeia de suprimentos de software, que elimina a barreira técnica à adoção por fornecedores menores.
- O Sigstore e a revolução dos logs de transparência: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias: confirmação ou roteiro de adoção do Sigstore cosign; verificação das entradas no log Rekor para as versões recentes; abordagem atual de assinatura e gestão de chaves, caso não use o Sigstore.
- SLA versus aplicação efetiva
-
Os acordos de nível de serviço definem os padrões de desempenho que um fornecedor deve cumprir: percentuais de disponibilidade, tempos de resposta, janelas de processamento e prazos de resolução.
a diferença entre SLA e sua aplicação efetiva é importante para TPRM porque os SLAs são uma das principais ferramentas contratuais de gestão de riscos: eles estabelecem padrões de desempenho que deveriam garantir que os fornecedores prestem serviços confiáveis e de alta qualidade.
- SLA versus aplicação efetiva: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias verbais: análise de causa raiz de cada descumprimento do SLA; ações de remediação específicas, com prazos; investimentos em infraestrutura ou mudanças operacionais planejadas.
- SOC 1, SOC 2 e SOC 3
-
Um SOC 1 relata controles relevantes para as demonstrações financeiras de um cliente e é o que o auditor financeiro de um cliente quer de um prestador de serviços de folha de pagamento ou de faturamento. Um SOC 2 relata com base nos Trust Services Criteria, para clientes preocupados com segurança e operações. Um SOC 3 é um resumo público, de uso geral, de um SOC 2, sem o detalhamento dos testes.
Um único fornecedor pode ter dois desses relatórios por motivos diferentes, e receber o errado desperdiça um ciclo de revisão. O SOC 1 de um provedor de folha de pagamento não diz nada sobre sua postura de segurança, e o SOC 2 dele não diz nada sobre a precisão do seu processamento financeiro.
- SOC 2 plus
-
Um SOC 2 plus, às vezes escrito SOC 2+, é um trabalho de SOC 2 ampliado para reportar sobre critérios adicionais, além dos Critérios de Serviços de Confiança, comumente ISO 27001, HIPAA, a Cloud Controls Matrix da CSA ou NIST CSF. O auditor mapeia os controles da organização para cada estrutura e reporta sobre todas elas em um único documento.
Para um fornecedor que atende clientes que pedem estruturas diferentes, isso é realmente eficiente. Um ciclo de evidências, uma auditoria, vários resultados de garantia. Para um cliente, significa que o SOC 2 que ele recebe pode já responder às suas perguntas de ISO ou HIPAA sem um exercício separado.
- SOC 2 Tipo I e Tipo II
-
Um relatório Tipo I examina se os controles estavam adequadamente desenhados e implementados em uma única data. Um Tipo II examina se esses controles de fato funcionaram, conforme descrito, ao longo de um período, geralmente de três a doze meses. Ambos são emitidos segundo a mesma norma e parecem iguais na capa, e é aí que começa a confusão.
Um Tipo I comprova que um controle existia em um único dia. Um Tipo II comprova que ele continuou funcionando por meses, apesar de mudanças de equipe, lançamentos de versões e da pressão comum para pular etapas. As equipes de compras aprenderam a pedir o segundo porque o primeiro diz quase nada sobre se um fornecedor se comporta de forma consistente.
- Limitações da automação de SOC
-
As limitações da automação de SOC são os modos de falha, as lacunas de cobertura e as vulnerabilidades por desvio que impedem que as ferramentas automatizadas de operações de segurança (plataformas de SOAR, sistemas de triagem automatizada e fluxos de orquestração) executem de forma confiável as funções para as quais foram implantadas.
as limitações da automação do SOC são importantes para TPRM porque a implantação de SOAR cria a aparência de maior cobertura de detecção e capacidade dos analistas, sem garantir que a automação esteja executando corretamente as funções que substituiu.
- Limitações da automação de SOC: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias: data da última revisão de alinhamento com o ambiente; procedimento de integração entre a gestão de mudanças e o SOAR; a um fornecedor que confirme a implantação de SOAR deve-se perguntar sobre o monitoramento da integridade dos playbooks. A implantação descreve o que foi instalado. O monitoramento da integridade descreve se o que foi instalado continua funcionando corretamente. O desvio do ambiente torna essa distinção crítica.
- Opt-in flexível
-
O opt-in flexível é uma exceção prevista nas regras de ePrivacy que permite marketing por e-mail ou SMS sem consentimento prévio, quando os dados do destinatário foram obtidos no contexto de uma venda ou negociação de venda, o marketing se refere a produtos ou serviços semelhantes e foi oferecida a oportunidade de recusa no momento da coleta e em cada mensagem subsequente.
É a base mais comumente invocada para marketing dirigido a clientes existentes, e frequentemente é estendida além dos seus termos. A exceção exige uma venda ou a negociação de uma venda. Exige produtos semelhantes. Exige que a opção de recusa tenha sido oferecida no momento em que os dados foram coletados, e não acrescentada depois.
- Lista de materiais de software SBOM
-
Lista legível por máquina de todos os componentes de um build, com versões e relações.
É o inventário, não o entregável. Publicado sem avaliações de explorabilidade, ele entrega aos clientes uma lista de preocupações que eles não conseguem priorizar.
Ensinado em CYB-201 · Veja também: Intercâmbio de explorabilidade de vulnerabilidades, Gestão de vulnerabilidades
- Lista de materiais de software: além da exigência legal
-
a qualidade do SBOM é importante para TPRM porque um SBOM desatualizado, incompleto ou sem informações sobre o status das vulnerabilidades dá a aparência de transparência da cadeia de suprimentos sem a substância.
a qualidade do SBOM é importante para TPRM porque um SBOM desatualizado, incompleto ou sem informações sobre o status das vulnerabilidades dá a aparência de transparência da cadeia de suprimentos sem a substância.
- Lista de materiais de software, além da obrigatoriedade: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias: SBOM específico por versão em formato padrão (CycloneDX ou SPDX); documentação VEX para componentes com vulnerabilidades críticas conhecidas; processo de geração do SBOM e cadência de atualização.
- Automação da lista de materiais de software
-
A automação de SBOM é relevante para TPRM porque o valor de inteligência de um programa de SBOM é proporcional à rapidez com que novos CVEs no inventário geram conscientização e ação na empresa. Um programa que revisa SBOMs anualmente, na reavaliação, oferece conscientização sobre CVE com doze meses de atraso.
a automação do SBOM é importante para TPRM porque o valor de inteligência de um programa de SBOM é proporcional à rapidez com que novas CVEs no inventário geram conhecimento e ação na empresa.
- Automação da lista de materiais de software: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias: SBOM em formato CycloneDX JSON para a versão atualmente implantada; processo de notificação CVE para vulnerabilidades em componentes; cadência de atualização do SBOM, ou seja, com que frequência é atualizado.
- Lacunas da análise de composição de software
-
as lacunas de SCA são importantes para TPRM porque o relatório de 'zero vulnerabilidades críticas' de uma ferramenta de SCA cobre apenas o que a ferramenta foi configurada para varrer.
as lacunas de SCA são importantes para TPRM porque o relatório de 'zero vulnerabilidades críticas' de uma ferramenta de SCA cobre apenas o que a ferramenta foi configurada para varrer.
- Lacunas da análise de composição de software: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias: documentação do escopo de SCA, ou seja, repositórios e ecossistemas cobertos; frequência de varredura e integração com o fluxo de desenvolvimento; a um fornecedor que confirme a implementação de uma ferramenta de SCA deve-se solicitar a documentação do escopo. A existência da ferramenta confirma a capacidade. A documentação do escopo revela o que a capacidade cobre e o que deixa de cobrir.
- Análise de composição de software em CI/CD
-
A cobertura de SCA em CI/CD é importante para TPRM porque a exposição a vulnerabilidades de software é determinada pelo componente com a pior cobertura, e não pelo que tem a melhor.
A cobertura de SCA em CI/CD é importante para TPRM porque a exposição a vulnerabilidades de software é determinada pelo componente com a pior cobertura, e não pelo que tem a melhor.
- Análise de composição de software em CI/CD: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias verbais: mapa de cobertura do SCA com todos os repositórios de produção; taxa de merge de PR do bot de atualização de dependências para achados críticos; configuração de exigência do CI/CD para SCA.
- Verificação da proveniência de software
-
A verificação da procedência de software é importante para TPRM porque o comprometimento da infraestrutura de distribuição é um vetor de ataque documentado: o mecanismo usado no ataque NotPetya (por meio da infraestrutura de atualização do M.E.Doc), no ataque ao Live Update da ASUS e em incidentes semelhantes na cadeia de suprimentos.
A verificação da proveniência de software é relevante para TPRM porque comprometimentos da infraestrutura de distribuição são um vetor de ataque documentado: o mecanismo usado no ataque NotPetya (por meio da infraestrutura de atualização do M.E.Doc), no ataque ao ASUS Live Update e em incidentes semelhantes na cadeia de suprimentos.
- Verificação da proveniência de software: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias: atestação de proveniência SLSA para versões específicas; processo de verificação de entradas no log de transparência; a um fornecedor que confirme versões assinadas deve-se perguntar sobre a verificação da atestação de proveniência. A assinatura confirma que a chave assinou o artefato. A atestação de proveniência confirma que o sistema de build produziu o que a chave assinou. O comprometimento da infraestrutura de distribuição contorna a assinatura se o atacante também tinha acesso de assinatura. A atestação de proveniência registrada em um log de transparência imutável antes do comprometimento é a evidência que o comprometimento não consegue apagar.
- Cadeia de suprimentos de software para produtos SaaS
-
A segurança da cadeia de suprimentos de SaaS é relevante para TPRM porque as empresas que mais investiram em controles da cadeia de suprimentos de software instalado (SBOMs, SCA, proveniência) dependem, ao mesmo tempo, de serviços SaaS cuja segurança da cadeia de suprimentos é gerida inteiramente pelo fornecedor.
A segurança da cadeia de suprimentos de SaaS é relevante para TPRM porque as empresas que mais investiram em controles da cadeia de suprimentos de software instalado (SBOMs, SCA, proveniência) dependem, ao mesmo tempo, de serviços SaaS cuja segurança da cadeia de suprimentos é gerida inteiramente pelo fornecedor.
- Cadeia de suprimentos de software para produtos SaaS: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias: SBOM da plataforma SaaS ou inventário de dependências equivalente; programa de monitoramento de vulnerabilidades em dependências de código aberto; processo de detecção e notificação de comprometimento do pipeline de build.
- Segurança da cadeia de suprimentos de software
-
A segurança da cadeia de suprimentos de software trata de uma questão fundamental: é possível confiar não apenas no software que um fornecedor entrega, mas em todo o processo que o produziu? A maioria dos controles de segurança se concentra no que o software faz depois de estar em execução: varredura de vulnerabilidades, monitoramento de anomalias, controle de acesso.
as avaliações tradicionais de terceiros tratam o fornecedor como a unidade de risco: seus controles, suas certificações, suas políticas.
- Segurança da cadeia de suprimentos de software: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias: um SBOM legível por máquina no formato CycloneDX ou SPDX, atualizado até a última versão; documentação das práticas de assinatura de artefatos e de gestão de chaves; evidência de que as credenciais do pipeline são de curta duração e de escopo restrito, e não estáticas e amplas.
- Segurança dos mecanismos de atualização de software
-
A segurança do mecanismo de atualização é relevante para TPRM porque fornecedores de software que entregam produtos com mecanismos de atualização automática estão entregando um canal persistente de implantação de código no ambiente da empresa.
a segurança dos mecanismos de atualização é importante para TPRM porque fornecedores de software que entregam produtos com mecanismos de atualização automática estão entregando um canal permanente de implantação de código no ambiente da empresa.
- Segurança do mecanismo de atualização de software: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias: descrição da arquitetura de segurança do mecanismo de atualização; política de gestão e rotação de certificados e chaves; processo de notificação de comprometimento da infraestrutura de atualização.
- Perímetro definido por software para acesso de fornecedores
-
O SDP para acesso de fornecedores é relevante para TPRM porque a confiança no nível da rede estabelecida para um fornecedor não se reduz automaticamente quando mudam o controle societário, a postura de segurança ou o pessoal desse fornecedor.
O SDP para acesso de fornecedores é relevante para TPRM porque a confiança no nível da rede estabelecida para um fornecedor não se reduz automaticamente quando mudam o controle societário, a postura de segurança ou o pessoal desse fornecedor.
- Perímetro definido por software para acesso de fornecedores: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias verbais: histórico de mudanças de controle societário desde a concessão do acesso; cláusula contratual de notificação de mudança de controle societário; reavaliação do acesso a cada mudança de controle societário.
- Dados de categoria especial dados sensíveis
-
Categorias com proteção adicional: saúde, origem racial ou étnica, crenças, filiação sindical, orientação sexual, dados biométricos e genéticos.
O uso indevido causa danos desproporcionais, por isso as regras de tratamento são mais rígidas onde quer que esses dados apareçam, inclusive dentro de um chamado de suporte comum.
Ensinado em PRV-201 · Veja também: Dados pessoais
- SSAE 18 e AT-C 205
-
SSAE 18 é a norma de atestação emitida pelo AICPA segundo a qual os trabalhos de SOC são realizados nos Estados Unidos. A seção 205 do AT-C, dentro dela, trata dos trabalhos de exame, que é o que um SOC 2 é. A norma rege como o trabalho é planejado, executado e reportado, e quem pode executá-lo.
isso explica por que um SOC 2 só pode ser emitido por uma firma de CPA habilitada, por mais capaz que seja uma consultoria de segurança, e por que o relatório traz o nome da firma, seu registro e suas obrigações de independência. Também explica por que o auditor não pode corrigir o que encontra, já que a norma exige sua independência em relação aos controles examinados.
- Cláusulas-padrão contratuais
-
As cláusulas-padrão contratuais são os termos contratuais aprovados pela Comissão Europeia para a transferência de dados pessoais a um terceiro país. A versão de 2021 é modular: o módulo um abrange de controlador para controlador, o módulo dois de controlador para operador, o módulo três de operador para operador e o módulo quatro de operador para controlador. As partes escolhem o módulo que corresponde à sua relação real.
O módulo deve corresponder à forma como os dados realmente fluem. Um controlador que exporta para um operador e assina o módulo um tem um contrato que não descreve a transferência, e a transferência não tem mecanismo válido. Os fornecedores frequentemente oferecem seu módulo padrão sem considerar o papel do cliente.
- Declaração de Aplicabilidade SoA
-
O documento ISO 27001 que lista cada controle do Anexo A, indicando se ele se aplica, a justificativa e o status de implementação.
Ela é referenciada pelo certificado e lida em primeiro lugar em toda auditoria. Exclusões são esperadas; a justificativa precisa se basear na relevância, não na dificuldade.
Ensinado em GRC-202 · Veja também: Controles gerais de TI, Tratamento de riscos
- Risco de dados estruturados versus não estruturados
-
A dimensão de risco dos dados não estruturados é relevante para TPRM porque as avaliações de fornecedores focadas na segurança de dados estruturados (criptografia de bancos de dados, controles de acesso, registro de auditoria) deixam escapar sistematicamente a maior parte da superfície de dados em que as informações sensíveis dos clientes têm maior probabilidade de existir e menor probabilidade de ser governadas.
a dimensão de risco dos dados não estruturados é importante para TPRM porque as avaliações de fornecedores focadas na segurança de dados estruturados (criptografia de bancos de dados, controles de acesso, registro de auditoria) deixam de fora, sistematicamente, a maior parte da superfície de dados em que as informações sensíveis dos clientes têm maior probabilidade de existir e menor probabilidade de ser governadas.
- Risco de dados estruturados versus não estruturados: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias: inventário de dados abrangente, incluindo repositórios não estruturados ao lado dos bancos de dados principais; confirmação da cobertura da ferramenta de descoberta de dados, com os repositórios não estruturados incluídos no escopo de descoberta e classificação; evidências de governança das plataformas de colaboração, com controles de acesso, políticas de DLP e registro de auditoria habilitados.
- Suboperadores
-
Um suboperador é um terceiro contratado por um operador para realizar tratamento em nome do controlador. O Artigo 28 exige que o operador obtenha autorização prévia do controlador, seja específica para cada suboperador, seja geral com aviso das alterações e oportunidade de objeção, e que repasse as mesmas obrigações por contrato.
A lista de suboperadores de um fornecedor é onde a sua real pegada de dados se torna visível, e ela geralmente é mais longa do que o esperado. Um produto SaaS pode envolver um provedor de hospedagem, uma ferramenta de suporte, um serviço de e-mail, uma plataforma de análise, um processador de pagamentos e um serviço de monitoramento, cada um dos quais lida com parte dos seus dados.
- Visibilidade dos suboperadores
-
A visibilidade dos suboperadores é relevante porque as obrigações de proteção de dados da empresa, e sua exposição ao risco da cadeia de suprimentos, se estendem a todos os suboperadores do fornecedor, independentemente de esses suboperadores serem divulgados.
a visibilidade dos suboperadores é importante porque as obrigações de proteção de dados da empresa, e sua exposição ao risco da cadeia de suprimentos, se estendem a todos os suboperadores do fornecedor, independentemente de esses suboperadores terem sido divulgados.
- Visibilidade dos suboperadores: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias: compromisso de notificação prévia de novos suboperadores; evidência de aplicação de testes funcionais aos suboperadores; a um fornecedor que forneça uma lista de suboperadores do DPA deve-se solicitar, junto com ela, a pilha tecnológica de produção. A lista do DPA mostra os suboperadores divulgados. A pilha de produção revela o ambiente real de tratamento. A distância entre as duas é o risco de visibilidade dos suboperadores.
- Eventos subsequentes
-
Eventos que ocorram após o término do período de observação, mas antes da emissão do relatório, podem precisar ser divulgados no relatório se afetarem a apresentação adequada da descrição do sistema ou a compreensão dos controles pelo leitor. Uma violação, uma interrupção grave, uma mudança de controle societário ou uma falha material de controle nesse intervalo são os candidatos habituais.
O período delimita os testes, não a obrigação de divulgação. Uma violação nas semanas entre o fim do período e a emissão é exatamente essa situação, e um relatório que nada diz sobre ela não é neutro. A administração tem a obrigação de informar o auditor, e o auditor tem a obrigação de considerá-la.
- Organização subprestadora de serviços exclusão
-
Um fornecedor do seu fornecedor cujos controles importam para o serviço que você recebe, incluído no relatório ou dele excluído e identificado nominalmente.
Uma exclusão é uma fronteira, não um achado. Ela indica quais objetivos de controle dependem de uma empresa cujo relatório você ainda não tem.
Ensinado em TPR-210 · Veja também: Controle complementar da entidade usuária, Quarta parte
- Organizações subprestadoras de serviços
-
Uma organização subprestadora de serviços é um fornecedor de cujos controles o seu próprio serviço depende para atender a um critério. O seu provedor de nuvem. O seu processador de pagamentos. O provedor de detecção gerenciada que monitora os seus logs. O teste é a dependência, não o gasto: um fornecedor se enquadra se um critério não puder ser atendido sem que os controles dele estejam operando.
Você não pode testar os controles de outra empresa, e o seu auditor também não, então o relatório precisa dizer algo sobre eles, e a forma como faz isso molda o documento inteiro. As organizações subprestadoras de serviços mencionadas em um relatório indicam ao leitor onde termina a garantia da empresa auditada e onde começa a de outra.
- Concentração de prestadores de subserviços nos relatórios
-
O SOC 2 do seu fornecedor exclui o provedor de hospedagem dele. O relatório do provedor de hospedagem exclui uma instalação de colocation. O relatório da instalação faz referência a um provedor de energia e conectividade. A cadeia continua abaixo do ponto até onde alguém normalmente lê, e a garantia se dilui a cada camada.
O risco de concentração está na base da pilha. Vinte dos seus fornecedores podem, cada um, excluir o mesmo hiperescalador, na mesma região, e cada relatório parece adequado individualmente. A dependência só fica visível quando a cadeia é rastreada e os relatórios são lidos em conjunto.
- Fronteiras de confiança de IA na cadeia de suprimentos
-
As fronteiras de confiança de IA definem o escopo do que um sistema de IA deve e não deve fazer, revelar ou possibilitar, com base em quem está perguntando e em qual contexto.
As fronteiras de confiança de IA são relevantes para TPRM porque produtos de IA de fornecedores que agregam informações operacionais sensíveis em bases de conhecimento consultáveis criam capacidades de reconhecimento que se estendem a qualquer usuário capaz de se autenticar, incluindo usuários com credenciais comprometidas, ataques de engenharia social e ameaças internas com credenciais que exce
- Fronteiras de confiança da IA na cadeia de suprimentos: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias: avaliação de conteúdo sensível na base de conhecimento; controles de acesso sensíveis ao contexto além da autenticação; a um fornecedor que confirme controles de autenticação de IA deve-se perguntar sobre o escopo da fronteira de confiança. A autenticação confirma a identidade. O escopo da fronteira de confiança determina se a solicitação da identidade autenticada está dentro do escopo de acesso adequado às informações sensíveis.
- Detecção de ataques à cadeia de suprimentos
-
A detecção de ataques à cadeia de suprimentos é relevante para TPRM porque o fornecedor cujo monitoramento de segurança em produção é excelente, mas cujo pipeline de build não gera sinais para o SOC, tem uma lacuna de detecção exatamente no vetor de ataque que os ataques à cadeia de suprimentos utilizam.
a detecção de ataques à cadeia de suprimentos é importante para TPRM porque o fornecedor cujo monitoramento de segurança em produção é excelente, mas cujo pipeline de build não gera nenhum sinal de SOC, tem uma lacuna de detecção exatamente no vetor de ataque que os ataques à cadeia de suprimentos usam.
- Detecção de ataques à cadeia de suprimentos: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias: escopo do monitoramento do pipeline de build e ingestão de logs; regras de detecção específicas para a cadeia de suprimentos no SIEM; prazo esperado de detecção de um comprometimento do pipeline de build.
- Ataques à cadeia de suprimentos
-
Um ataque à cadeia de suprimentos compromete um fornecedor confiável, um componente de software ou um mecanismo de atualização para atingir todos os clientes desse fornecedor de uma só vez. Em vez de atacar mil organizações, o atacante compromete aquilo que essas mil compartilham: um pipeline de build, uma biblioteca amplamente utilizada, a ferramenta de acesso remoto de um provedor de serviços gerenciados ou a chave de assinatura de um fornecedor.
É o motivo pelo qual o risco de terceiros deixou de ser uma formalidade de compras. Os ataques que atingiram mais organizações nos últimos anos chegaram por meio de atualizações de software confiáveis e de prestadores de serviços com acesso legítimo, e não pelos perímetros das próprias vítimas. Os seus controles estavam operando. A confiança que você havia depositado em um fornecedor era a vulnerabilidade.
- Resposta a incidentes na cadeia de suprimentos
-
A resposta a incidentes na cadeia de suprimentos é relevante para TPRM porque o fornecedor cujo programa de IR é maduro para incidentes de produção, mas que não tem um manual de resposta para a cadeia de suprimentos, será significativamente menos eficaz ao responder a um comprometimento da cadeia de suprimentos, e a empresa cujo fornecedor foi comprometido receberá uma notificação mais lenta, informações menos comple
A resposta a incidentes na cadeia de suprimentos é relevante para TPRM porque o fornecedor cujo programa de IR é maduro para incidentes de produção, mas que não tem um manual de resposta para a cadeia de suprimentos, será significativamente menos eficaz ao responder a um comprometimento da cadeia de suprimentos, e a empresa cujo fornecedor foi comprometido receberá uma notificação mais lenta, informações menos comple
- Resposta a incidentes na cadeia de suprimentos: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias: existência de um manual de resposta a incidentes na cadeia de suprimentos; inventário de implantações nos clientes e processo de notificação; registros de exercícios de mesa sobre a cadeia de suprimentos.
- Risco da cadeia de suprimentos em fusões e aquisições
-
O risco da cadeia de suprimentos em M&A é relevante porque a dívida técnica de dependências de software, acumulada ao longo de anos em que a velocidade de entrega de funcionalidades foi priorizada em detrimento da segurança, não é visível na diligência tecnológica padrão, mas é herdada diretamente pela empresa adquirente.
o risco da cadeia de suprimentos em M&A é importante porque a dívida técnica das dependências de software, acumulada ao longo de anos em que a velocidade de entrega de funcionalidades foi priorizada em detrimento da segurança, não é visível na due diligence tecnológica padrão, mas é herdada diretamente pela empresa adquirente.
- Risco da cadeia de suprimentos em fusões e aquisições: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias verbais: SBOM atual da base de código de produção; identificação de dependências EOL, com avaliação de remediação; inventário de vulnerabilidades críticas com o status de correção.
- Quantificação de riscos da cadeia de suprimentos
-
A quantificação de riscos da cadeia de suprimentos é importante porque transforma a documentação de riscos em gestão de riscos. O CISO e o conselho precisam de estimativas de exposição financeira para tomar decisões de investimento, priorizar iniciativas de segurança concorrentes e comunicar a postura de risco às partes interessadas que decidem a alocação de recursos.
A quantificação de riscos da cadeia de suprimentos é relevante porque converte a documentação de riscos em gestão de riscos.
- Quantificação de riscos da cadeia de suprimentos: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias verbais: metodologia de quantificação dos riscos da cadeia de suprimentos; estimativas de exposição financeira para cenários críticos da cadeia de suprimentos; priorização de investimentos com base no risco quantificado.
- Segurança da cadeia de suprimentos em pipelines de CI/CD
-
A segurança da cadeia de suprimentos em pipelines de CI/CD é relevante para TPRM porque um fornecedor que confirma a varredura de dependências de aplicações sem confirmar a segurança dos componentes do pipeline tratou de uma superfície de ataque da cadeia de suprimentos e deixou outra sem tratamento.
A segurança da cadeia de suprimentos em pipelines de CI/CD é relevante para TPRM porque um fornecedor que confirma a varredura de dependências de aplicações sem confirmar a segurança dos componentes do pipeline tratou de uma superfície de ataque da cadeia de suprimentos e deixou outra sem tratamento.
- Segurança da cadeia de suprimentos em pipelines de CI/CD: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias: inventário de componentes do pipeline com o status de fixação por SHA; implementação do monitoramento dos mantenedores das ações do pipeline; processo de verificação da instalação das ferramentas de build.
- Segurança da cadeia de suprimentos em setores regulados
-
A segurança da cadeia de suprimentos em setores regulados é relevante para TPRM porque as empresas de setores regulados enfrentam exigências regulatórias específicas e documentadas que seus fornecedores também devem cumprir, e que as avaliações gerais de segurança da cadeia de suprimentos podem não abordar no formato exigido.
A segurança da cadeia de suprimentos em setores regulados é relevante para TPRM porque as empresas de setores regulados enfrentam exigências regulatórias específicas e documentadas que seus fornecedores também devem cumprir, e que as avaliações gerais de segurança da cadeia de suprimentos podem não abordar no formato exigido.
- Segurança da cadeia de suprimentos em setores regulados: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias: SBOM e VEX no formato regulatório para fornecedores de dispositivos médicos; conformidade com as disposições sobre cadeia de suprimentos do DORA ICT para serviços financeiros; exemplos de submissões regulatórias com documentação da cadeia de suprimentos.
- Avaliação de maturidade da segurança da cadeia de suprimentos
-
A avaliação de maturidade da segurança da cadeia de suprimentos é relevante para TPRM porque oferece o panorama, por domínio, de onde foram feitos investimentos em segurança da cadeia de suprimentos e de onde estão as lacunas, o que orienta diretamente tanto a priorização interna das melhorias do programa quanto as perguntas que as equipes de TPRM devem fazer aos fornecedores sobre os domí
A avaliação de maturidade da segurança da cadeia de suprimentos é relevante para TPRM porque oferece o panorama, por domínio, de onde foram feitos investimentos em segurança da cadeia de suprimentos e de onde estão as lacunas, o que orienta diretamente tanto a priorização interna das melhorias do programa quanto as perguntas que as equipes de TPRM devem fazer aos fornecedores sobre os domí
- Avaliação de maturidade da segurança da cadeia de suprimentos: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias: classificações de maturidade específicas para seis domínios de segurança da cadeia de suprimentos; reconhecimento de nível 0 para domínios ausentes, em vez de "não se aplica"; roteiro de investimentos para os domínios de menor maturidade.
T
- Exercícios de mesa
-
Um exercício de mesa conduz as pessoas que responderiam a um incidente por um cenário realista, em uma sala, sem tocar em nenhum sistema, para descobrir onde o plano falha. Noventa minutos, os responsáveis reais pela resposta, nenhuma preparação e um registro de decisões mantido durante todo o exercício. O resultado não é uma pontuação; são as mudanças no runbook que o exercício expôs.
os planos de incidentes são escritos por pessoas que imaginam um incidente, e elas se comportam de outra forma sob a pressão de um incidente real. O exercício de mesa é a única forma de encontrar essa diferença antes que ela custe algo. O tema também surge porque frameworks e seguradoras perguntam se o plano é testado, e um plano testado uma vez, vinte meses atrás, antes da chegada do atual líder, não está testado em nenhum sentido que importe.
- Períodos de teste e lacunas entre relatórios
-
Um relatório Tipo II cobre um período definido. O relatório seguinte cobre o período seguinte. Mas os relatórios são emitidos semanas ou meses depois do fim do período, e os períodos nem sempre são contíguos. Um fornecedor com relatório anual pode deixar o cliente, a cada ano, com vários meses sem cobertura de nenhum relatório.
Um cliente que registra a data do relatório, e não o período coberto, não sabe quando sua garantia expirou. As cartas-ponte existem exatamente para tratar disso, e conhecer a lacuna é o que indica quando solicitar uma.
- O método de exclusão
-
No método de exclusão (carve-out), os controles de uma organização subprestadora de serviços ficam fora da auditoria. O relatório descreve o que a empresa auditada espera que esse prestador faça, declara que esses controles não foram testados e os lista como controles complementares da organização subprestadora. É o método usado por quase todo SOC 2, porque a alternativa exige a participação do prestador.
é por isso que o SOC 2 de um fornecedor pode conter controles atribuídos à AWS ou ao Azure que ninguém testou no trabalho. A empresa auditada depende deles, declara essa dependência, e a opinião do auditor cobre apenas o que a própria empresa opera.
- Os Critérios Comuns, CC1 a CC9
-
A categoria Segurança é organizada em nove grupos chamados Critérios Comuns. CC1 trata do ambiente de controle, CC2 da comunicação, CC3 da avaliação de riscos, CC4 do monitoramento, CC5 das atividades de controle, CC6 do acesso lógico e físico, CC7 das operações de sistemas e da resposta a incidentes, CC8 da gestão de mudanças e CC9 da mitigação de riscos, incluindo a gestão de fornecedores. Todo SOC 2 aborda os nove.
Os grupos não são iguais em esforço nem em risco. CC6 sozinho abrange provisionamento, autenticação, autorização, remoção, acesso físico e descarte de dados, envolve todos os sistemas e produz mais exceções do que qualquer outro grupo. CC1 e CC2 tratam essencialmente de governança e documentação. Saber qual é qual muda a forma como você lê um relatório e planeja uma auditoria.
- O controlador
-
O controlador é quem determina as finalidades e os meios do tratamento de dados pessoais: por que são tratados e, em linhas gerais, como. O título segue a decisão, não o contrato. Uma empresa que decide quais dados coletar e o que fazer com eles é a controladora desse tratamento, independentemente de como qualquer contrato a denomine.
O controlador carrega as obrigações principais: base legal, transparência, direitos dos titulares, notificação de violações, prestação de contas. Um fornecedor que começa a usar os dados dos seus clientes para melhorar o próprio produto tomou uma decisão sobre finalidade e se tornou controlador para esse uso, independentemente do que o DPA diga sobre ele ser um operador.
- As cinco categorias de serviços de confiança
-
Segurança, Disponibilidade, Integridade de Processamento, Confidencialidade e Privacidade são as cinco categorias que um SOC 2 pode abranger. Somente Segurança é obrigatória. As outras quatro são opcionais, escolhidas pela empresa auditada, e a maioria dos relatórios inclui apenas Segurança ou Segurança com Disponibilidade.
Quando alguém diz que tem um SOC 2, quase sempre se refere a Segurança. Se aquilo sobre o que você precisa de garantia é disponibilidade, tratamento de dados ou informações pessoais, o relatório pode nem sequer abordar o tema, e a capa diz isso em uma única linha que a maioria dos leitores não verifica.
- O futuro do DevSecOps
-
O futuro do DevSecOps é relevante para TPRM porque os fornecedores de cujo software as empresas dependerão daqui a cinco anos estão construindo esse software hoje, com os programas de DevSecOps atuais e com qualquer investimento prospectivo que estejam fazendo nas cinco trajetórias acima.
O futuro do DevSecOps é relevante para TPRM porque os fornecedores de cujo software as empresas dependerão daqui a cinco anos estão construindo esse software hoje, com os programas de DevSecOps atuais e com qualquer investimento prospectivo que estejam fazendo nas cinco trajetórias acima.
- O futuro do DevSecOps: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias: roteiro do programa de DevSecOps para um horizonte de 3 anos; abordagem e cronograma de segurança para código gerado por IA; meta e cronograma de adoção de SLSA.
- O futuro da segurança de redes, cinco tendências que estão redefinindo o perímetro
-
Perímetro tradicional: em dissolução. Identidade: o novo perímetro.
O futuro da segurança de redes é relevante para TPRM porque os fornecedores que estão se preparando para o cenário futuro de segurança de redes (adotando SASE, desenvolvendo detecção baseada em IA, planejando transições pós-quânticas) são fornecedores cuja postura de segurança será mais adequada ao cenário de ameaças de 2028 do que a dos fornecedores que mantêm a ar
- O futuro da segurança da cadeia de suprimentos de software
-
O futuro da segurança da cadeia de suprimentos é relevante para TPRM porque os investimentos feitos hoje no programa devem levar em conta as capacidades que serão necessárias daqui a três a cinco anos, e não apenas o estado atual.
O futuro da segurança da cadeia de suprimentos é relevante para TPRM porque os investimentos feitos hoje no programa devem levar em conta as capacidades que serão necessárias daqui a três a cinco anos, e não apenas o estado atual.
- O futuro da segurança da cadeia de suprimentos de software: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias: política de governança da geração de código por IA; requisitos de profundidade de revisão para código gerado por IA; conhecimento e planejamento da transição para a criptografia pós-quântica.
- O futuro do TPRM, da garantia à inteligência
-
A transição da garantia para a inteligência é relevante porque trata da limitação fundamental da avaliação pontual: sua incapacidade de prever o que acontecerá a seguir.
A transição da garantia para a inteligência é relevante porque trata da limitação fundamental da avaliação pontual: sua incapacidade de prever o que acontecerá a seguir.
- O futuro do TPRM, da garantia à inteligência: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias: capacidade ou roteiro de pontuação preditiva de riscos; análise de padrões históricos a partir dos dados do programa; integração de sinais externos para previsão de tendências.
- O método inclusivo
-
O método inclusivo é a alternativa à exclusão. Os controles relevantes da organização subprestadora de serviços são descritos e testados dentro do próprio relatório da empresa auditada, de modo que o leitor não precisa supor nada sobre a camada inferior. A opinião realmente cobre toda a pilha.
Ele produz uma garantia mais forte do que a exclusão, e os compradores às vezes perguntam por que um fornecedor não o utilizou. A resposta é prática. A organização subprestadora de serviços precisa concordar em ser incluída, em ser descrita na descrição do sistema e em assinar a sua própria asserção da administração para o trabalho.
- A avaliação de interesse legítimo
-
Uma avaliação de interesse legítimo, LIA, é o raciocínio documentado que sustenta o uso do interesse legítimo como base legal. Ela tem três partes. O teste de finalidade: qual é o interesse e se ele é legítimo. O teste de necessidade: se o tratamento é necessário para esse interesse ou se ele poderia ser alcançado de outra forma. O teste de ponderação: se o interesse prevalece sobre os direitos e as expectativas razoáveis da pessoa.
a maior parte do tratamento em contextos B2B, da prevenção a fraudes, do monitoramento de segurança e boa parte da análise de dados se baseia no interesse legítimo. Os reguladores pedem para ver a avaliação, não a afirmação. Um controlador que alega interesse legítimo, mas não consegue apresentar o raciocínio, não fez a avaliação aos olhos do regulador.
- A asserção da administração
-
Antes da opinião do auditor vem a asserção da administração: uma declaração assinada pela empresa auditada de que a descrição do sistema é precisa e de que os controles foram adequadamente desenhados e, no caso de um Tipo II, operaram com eficácia. A opinião do auditor é uma opinião sobre essa asserção.
Tudo no relatório depende de a administração ter descrito seu sistema com veracidade. Se a descrição subestima o escopo, omite um componente ou representa uma fronteira de forma incorreta, cada resultado de teste sem ressalvas é um teste de algo menor do que o leitor supôs, e a opinião do auditor, embora correta, refere-se a esse algo menor.
- A Estrutura de Gestão de Riscos de IA do NIST
-
A Estrutura de Gestão de Riscos de IA do NIST é uma estrutura voluntária para gerenciar os riscos de sistemas de IA por meio de quatro funções. Governar estabelece a responsabilização e a cultura. Mapear identifica o contexto, as pessoas afetadas e os riscos. Medir avalia esses riscos, incluindo o desempenho entre os grupos afetados pelo sistema. Gerenciar atua sobre o que foi medido, por meio de supervisão e monitoramento. Ela indica como trabalhar, enquanto uma regulamentação indica o que você deve fazer.
É a referência da qual a maioria dos processos de avaliação se vale, citando-a ou não, e é a estrutura que um comprador ou um regulador reconhecerá quando você descrever como avalia riscos de IA. Combina naturalmente com a Lei de IA da UE: a Lei classifica e impõe obrigações, e o RMF oferece o método para cumpri-las.
- O período de observação
-
O período de observação é a janela ao longo da qual uma auditoria Tipo II testou o funcionamento dos controles. Ele é indicado na opinião e geralmente abrange três, seis ou doze meses. Tanto um período de três meses quanto um de doze meses produzem um relatório válido.
Um período de três meses cobre no máximo uma revisão trimestral de acessos, possivelmente nenhuma. Um período de doze meses cobre quatro, além de um fechamento de ano, uma temporada de festas, pelo menos uma reorganização e diversos lançamentos. O período mais longo é uma afirmação muito mais forte sobre se os controles se mantêm sob a pressão normal.
- O operador
-
Um operador trata dados pessoais em nome de um controlador, agindo apenas de acordo com as instruções documentadas do controlador. Ele não decide por que os dados são tratados. Suas obrigações são mais restritas do que as de um controlador, mas reais: segurança, confidencialidade, gestão de suboperadores, apoio no atendimento a solicitações de direitos e exclusão ou devolução ao final.
No momento em que um operador decide uma finalidade própria, ele deixa de ser operador para essa atividade e assume diretamente as obrigações de controlador. O exemplo mais comum é a análise de dados: um provedor de SaaS que processa dados de clientes em seus próprios modelos para melhorar o produto tomou uma decisão sobre finalidade que o cliente não instruiu.
- O direito à eliminação
-
O direito à eliminação, frequentemente chamado de direito ao esquecimento, permite que uma pessoa exija a exclusão de seus dados pessoais em circunstâncias específicas: os dados não são mais necessários, o consentimento é revogado, a pessoa se opõe e não há fundamento prevalente, o tratamento foi ilícito ou uma obrigação legal exige a exclusão. É um dos direitos mais solicitados e um dos menos corretamente aplicados.
Ele não é absoluto. Cede quando o tratamento é necessário para o cumprimento de uma obrigação legal, para o exercício ou a defesa de direitos em processos judiciais, para a liberdade de expressão, para a saúde pública ou para arquivamento de interesse público. Um controlador que exclui tudo mediante solicitação pode ter destruído registros que a lei o obrigava a manter.
- As lições da SolarWinds ainda não aprendidas
-
As lições não aprendidas da SolarWinds são importantes para TPRM porque representam uma lacuna sistemática entre as capacidades atuais de ataque à cadeia de suprimentos e as perguntas de avaliação que a maioria dos programas de TPRM faz.
As lições da SolarWinds não aprendidas são relevantes para TPRM porque representam uma lacuna sistemática entre as capacidades atuais de ataque à cadeia de suprimentos e as perguntas de avaliação que a maioria dos programas de TPRM faz.
- As lições da SolarWinds ainda não aprendidas: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias verbais: controles de isolamento e monitoramento do pipeline de build; proteção das chaves de assinatura, com HSM ou equivalente; segurança do mecanismo de atualização e governança corporativa.
- A descrição do sistema
-
A descrição do sistema é o relato da própria empresa auditada sobre o sistema no escopo: o que o serviço faz, a infraestrutura e o software envolvidos, as pessoas e os processos, os dados tratados e a fronteira em torno de tudo isso. O auditor examina se ela está apresentada de forma adequada. Quem a redige é a empresa.
a descrição decide o que foi auditado. Uma descrição que traça a fronteira de forma restrita, em torno de um núcleo bem controlado e longe dos serviços mais novos e desorganizados, produz uma auditoria mais fácil e um relatório que cobre menos do que o leitor supõe. Não há nada de impróprio nisso, mas o leitor que não compara a descrição com o serviço que de fato usa não tem ideia do que a opinião cobre.
- Ações de terceiros e fluxos de trabalho reutilizáveis
-
A segurança de fluxos de trabalho compartilhados e ações reutilizáveis é relevante para TPRM porque um único fluxo de trabalho compartilhado comprometido pode ser o ponto de entrada na cadeia de suprimentos para todos os serviços do portfólio de um fornecedor.
A segurança de fluxos de trabalho compartilhados e ações reutilizáveis é relevante para TPRM porque um único fluxo de trabalho compartilhado comprometido pode ser o ponto de entrada na cadeia de suprimentos para todos os serviços do portfólio de um fornecedor.
- Ações de terceiros e fluxos de trabalho reutilizáveis: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias verbais: controles de acesso ao repositório de fluxos de trabalho compartilhados; requisitos de revisão para mudanças nos fluxos de trabalho compartilhados; fixação de SHA nos fluxos de trabalho compartilhados.
- Integrações de IA de terceiros
-
Os riscos de integração de IA de terceiros são os riscos de segurança, conformidade, governança e operacionais criados quando plataformas SaaS corporativas incorporam capacidades de IA (funcionalidades baseadas em modelos de aprendizado de máquina, grandes modelos de linguagem ou automação orientada por IA) em seus produtos.
As integrações de IA de terceiros são relevantes para TPRM porque a IA de maior consequência na pilha tecnológica de uma empresa costuma estar embutida em plataformas SaaS padrão, e não implantada como produto de IA independente.
- Integrações de IA de terceiros: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias: inventário de funcionalidades de IA com o escopo de acesso a dados; documentação dos dados de treinamento das funcionalidades de IA de maior consequência; avaliação de equidade das funcionalidades de IA que afetam indivíduos.
- Confiança em relatórios de auditoria de terceiros
-
Os relatórios de auditoria de terceiros (SOC 2, ISO 27001, asseguração PCI-DSS, relatórios de testes de intrusão de empresas conceituadas) fornecem evidências de asseguração valiosas. Eles representam o julgamento profissional de especialistas independentes que examinaram os controles do fornecedor com base em critérios definidos.
A confiança em auditorias de terceiros é relevante para TPRM porque os relatórios de auditoria são a evidência mais comumente aceita e de maior peso nas avaliações de fornecedores, e seu valor depende de fatores específicos de cada relatório e de cada relação com o cliente, e não da reputação da firma ou da opinião sem ressalvas do relatório.
- Confiança em auditorias de terceiros: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias: confirmação de escopo para os sistemas relevantes para o cliente; descrição da metodologia para as categorias de controle relevantes para o cliente; avaliação complementar para quaisquer exclusões de escopo que afetem os dados do cliente.
- Notificação de incidentes por terceiros
-
Quando um fornecedor sofre uma violação, as suas próprias obrigações de notificação a reguladores e clientes podem começar a contar a partir do momento em que você toma conhecimento, que pode ser o momento em que você lê a notícia, e não o momento em que o fornecedor confirma qualquer coisa. O prazo contratual do fornecedor para informar você e o seu prazo regulatório para informar terceiros são prazos diferentes, e o segundo não espera o primeiro.
uma empresa fica sabendo do comprometimento de um fornecedor por uma página da web, passa um fim de semana decidindo se aquilo conta como violação e se o seu prazo já começou a correr, e perde por um dia o prazo de um contrato com um cliente. As três perguntas tinham respostas predefinidas que poderiam ter sido escritas meses antes, e o fim de semana foi gasto com questões jurídicas em vez de perícia forense.
- Gestão de riscos de terceiros
-
A gestão de riscos de terceiros é a disciplina de saber quais organizações externas têm contato com os seus dados, os seus sistemas ou os seus clientes, avaliá-las na proporção dessa exposição, contratar o que importa, acompanhar os eventos que alteram seu risco e recuperar os seus dados quando o relacionamento termina. Cinco etapas. A maioria dos programas é construída em torno da segunda e negligencia as outras quatro.
Todos os frameworks pelos quais você é avaliado perguntam sobre isso, todos os compradores corporativos perguntam sobre isso, e um número crescente de reguladores pede para ver o registro. O tema também surge porque a violação que mais frequentemente chega até você não é sua. É de um fornecedor, e o questionário que ele preencheu na homologação não dizia nada sobre o suboperador que foi efetivamente comprometido.
- Risco de SDK de terceiros
-
o risco de SDK é importante para TPRM porque os SDKs em aplicações móveis e web corporativas criam riscos de coleta e transmissão de dados dos quais a empresa pode não estar totalmente ciente, e que mudam ao longo do tempo à medida que os provedores de SDK atualizam seus produtos.
o risco de SDK é importante para TPRM porque os SDKs em aplicações móveis e web corporativas criam riscos de coleta e transmissão de dados dos quais a empresa pode não estar totalmente ciente, e que mudam ao longo do tempo à medida que os provedores de SDK atualizam seus produtos.
- Risco de SDK de terceiros: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias: inventário de SDK com documentação do comportamento de coleta de dados; processo de revisão de atualizações de SDK para mudanças relevantes para a privacidade; resultados de análise de tráfego de rede para os SDKs de alto risco.
- Risco de terceiros versus risco de quartos
-
O risco de quartos é o risco de segurança criado pelos fornecedores dos seus fornecedores: os suboperadores, os subprestadores de serviços e os participantes da cadeia de suprimentos que os seus terceiros utilizam para prestar serviços a você.
O risco de quartos é relevante porque as violações de dados não respeitam as fronteiras organizacionais da cadeia de dependências.
- Risco de terceiros versus risco de quartos: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias: inventário completo de suboperadores, com funções e categorias de dados; certificações de segurança dos suboperadores, como SOC 2 ou equivalente; documentação dos prazos da cadeia de notificação de violações.
- Pontos cegos na detecção de ameaças
-
Os pontos cegos de detecção de ameaças são as lacunas na capacidade de um programa de monitoramento de segurança de detectar atividades de ataque: as técnicas de ataque, os comportamentos de atacantes e os padrões de atividade maliciosa que a lógica de detecção atual do programa não identifica como anômalos ou maliciosos.
os pontos cegos na detecção de ameaças são importantes para TPRM porque a avaliação da capacidade de detecção de um fornecedor normalmente confirma a existência e a configuração do programa de detecção, em vez de testar sua eficácia contra técnicas de ataque atuais e realistas.
- Pontos cegos na detecção de ameaças: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias: metodologia de exercícios de red team ou purple team, indicando se técnicas LotL foram incluídas; taxa de detecção de técnicas LotL no último exercício; mapa de cobertura ou percentual de cobertura do ATT&CK.
- Caça a ameaças entre fornecedores
-
A caça a ameaças é a busca proativa, orientada por hipóteses, por atividade de atacantes em um ambiente: a busca por indicadores de comprometimento que a detecção automatizada não sinalizou, com base em inteligência de ameaças sobre técnicas específicas de atacantes, comportamentos conhecidos de atacantes ou padrões de anomalia compatíveis com atividade maliciosa.
A caça a ameaças nos ambientes de fornecedores é relevante para TPRM porque atacantes sofisticados da cadeia de suprimentos visam especificamente os ambientes com maior probabilidade de ficar fora do escopo das caças a ameaças padrão: o pipeline de CI/CD, o ambiente de desenvolvimento, o sistema de acesso de terceirizados e os serviços gerenciados.
- Caça a ameaças entre fornecedores: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias verbais: documentação do escopo da caça a ameaças mais recente; confirmação da inclusão de CI/CD ou justificativa da exclusão; um fornecedor que confirma caça proativa a ameaças deve ser questionado sobre se o escopo da caça abrangeu os ambientes específicos que a inteligência que a motivou identificou como de alto risco. A atividade de caça é a evidência de que o programa funciona. O alinhamento do escopo é a evidência de que o programa é eficaz.
- Lacunas na integração da inteligência de ameaças
-
As lacunas de integração de inteligência de ameaças são os atrasos, as limitações de cobertura e as falhas de fluxo de trabalho que impedem que a inteligência de ameaças seja convertida em detecção ativa no prazo que o cenário de ameaças exige.
As lacunas de integração da inteligência de ameaças são relevantes para TPRM porque a assinatura de inteligência de ameaças e o investimento em plataforma de um fornecedor só se traduzem em melhoria da detecção se a inteligência chegar ao SIEM a tempo de detectar a ameaça que descreve.
- Lacunas de integração da inteligência de ameaças: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias: cadência de integração por categoria de IOC; métrica de latência da integração, ou seja, o tempo entre a publicação e a ativação da detecção; a um fornecedor que confirme a integração de TI-SIEM deve-se fazer a pergunta do cenário das 11 da manhã. A existência da integração descreve a conexão. A resposta à pergunta do cenário descreve quando a conexão gera valor.
- Inteligência de ameaças
-
Informações sobre violações, vulnerabilidades e comportamento de atacantes, cruzadas com o que você mantém, usa e de que depende.
Sem inventários com os quais cruzar as informações, ele produz leitura em vez de ação. Meça o programa pelas decisões, e não pelos itens processados.
Ensinado em CYB-210 · Veja também: Gestão de vulnerabilidades, Risco de concentração
- Inteligência de ameaças para ataques à cadeia de suprimentos
-
A operacionalização da inteligência de ameaças é importante para TPRM porque a inteligência de ameaças à cadeia de suprimentos fornece o sinal de risco prospectivo que as avaliações históricas não conseguem fornecer: ela descreve o que os atacantes estão fazendo agora, quais setores estão visando e quais vetores de ataque estão usando.
A operacionalização da inteligência de ameaças é relevante para TPRM porque a inteligência de ameaças sobre a cadeia de suprimentos fornece o sinal de risco prospectivo que as avaliações históricas não conseguem fornecer: ela descreve o que os atacantes estão fazendo agora, quais setores estão visando e quais vetores de ataque estão usando.
- Inteligência de ameaças para ataques à cadeia de suprimentos: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias verbais: conhecimento do fornecedor sobre o alerta de ameaça descrito; avaliação da exposição aos vetores de ataque descritos; ações de remediação ou mitigação tomadas em resposta.
- Modelagem de ameaças no SDLC
-
A modelagem de ameaças é relevante para TPRM porque é a única atividade de segurança capaz de detectar de forma confiável vulnerabilidades no nível do design antes da implementação.
A modelagem de ameaças é relevante para TPRM porque é a única atividade de segurança capaz de detectar de forma confiável vulnerabilidades no nível do design antes da implementação.
- Modelagem de ameaças no SDLC: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias verbais: exemplo recente de modelo de ameaças, com a funcionalidade que o motivou; acompanhamento das mitigações desde o modelo de ameaças até a implementação; metodologia e ferramentas de modelagem de ameaças utilizadas.
- Frequência de reavaliação por nível
-
A frequência de reavaliação por nível é relevante porque a capacidade de TPRM é limitada. Cada ciclo de avaliação consumido por um fornecedor de baixo risco que não mudou materialmente é um ciclo que deixa de estar disponível para um fornecedor de alto risco cujo perfil de risco evoluiu desde a última avaliação.
A frequência de reavaliação por nível é relevante porque a capacidade de TPRM é limitada.
- Frequência de reavaliação por nível: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias: divulgação de mudanças materiais desde a última avaliação; compromisso de notificação proativa de mudanças entre avaliações; relatório de confiança ou registro de alterações de segurança do período.
- Inspeção de TLS e tráfego criptografado
-
A segurança da inspeção de TLS é relevante para TPRM porque fornecedores que implantam a inspeção de TLS sem a devida proteção da chave privada e sem correções no equipamento criaram um risco criptográfico que inverte o propósito de segurança da inspeção de TLS.
A segurança da inspeção de TLS é relevante para TPRM porque fornecedores que implantam a inspeção de TLS sem a devida proteção da chave privada e sem correções no equipamento criaram um risco criptográfico que inverte o propósito de segurança da inspeção de TLS.
- Inspeção de TLS e tráfego criptografado: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias: implementação de HSM para a chave privada de CA; cronograma de correções do equipamento de inspeção e data da última correção; limitação do escopo de confiança da inspeção de TLS.
- Riscos de persistência de tokens
-
O risco de persistência de tokens é a exposição de segurança criada por tokens de acesso OAuth, tokens de API e outras credenciais ao portador que permanecem válidos além da vida operacional da aplicação, da integração ou do caso de uso que os solicitou.
o risco de persistência de tokens é importante para TPRM porque plataformas que mantêm tokens OAuth para integrações com fornecedores acumulam credenciais que sobrevivem às integrações que sustentam.
- Riscos de persistência de tokens: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias verbais: inventário de tokens OAuth com datas de último uso e aplicações associadas; documentação do processo de revogação de tokens, incluindo o gatilho de descontinuação de aplicações; política de expiração de tokens, com os prazos máximos de validade dos tokens emitidos.
- Confusão entre tokenização e mascaramento
-
A tokenização e o mascaramento de dados são técnicas para substituir valores de dados sensíveis por substitutos não sensíveis em sistemas em que o valor original não é necessário para a função principal.
A confirmação de tokenização e mascaramento é frequentemente citada como evidência de proteção de dados sensíveis nas avaliações de fornecedores dos setores de pagamentos, saúde e serviços financeiros.
- Confusão entre tokenização e mascaramento: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias verbais: lista de acessos à destokenização com histórico de revisões, indicando quem tem acesso, a última revisão e a justificativa documentada; confirmação do log de auditoria da destokenização, com o registro implementado e o processo de revisão definido; política de consistência do mascaramento, com a documentação dos contextos que recebem valores mascarados e não mascarados.
- TPRM como viabilizador de negócios
-
O enquadramento como viabilizador de negócios é relevante porque determina a sustentabilidade do programa de TPRM. Programas que geram atrito para o negócio sem um valor de negócio correspondente enfrentam uma pressão crescente para serem contornados, perderem recursos ou serem substituídos por alternativas de conformidade menos onerosas.
o enquadramento como viabilizador do negócio é importante porque determina a sustentabilidade do programa de TPRM.
- TPRM como viabilizador de negócios: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias verbais: relatório SOC 2 e certificações relevantes prontos para envio; contato de segurança designado para facilitar a avaliação; a um fornecedor que deseja um onboarding rápido deve ser pedido seu pacote de pré-qualificação. Fornecedores que investiram em facilitar a própria avaliação ajudam a empresa a conduzir um processo de TPRM mais rápido e de melhor qualidade. Esse investimento já é, por si só, um sinal positivo.
- Reporte de TPRM ao conselho e à alta direção
-
O reporte ao conselho é importante porque é o mecanismo pelo qual se exerce, no nível do conselho, a governança de riscos dos relacionamentos com terceiros. Um conselho que não recebe as informações necessárias para fazer perguntas fundamentadas sobre o risco de terceiros é um conselho que não consegue exercer uma supervisão de riscos eficaz.
Os relatórios ao conselho são relevantes porque são o mecanismo pelo qual se exerce a governança de riscos, no nível do conselho, das relações com terceiros.
- Relatórios de TPRM ao conselho e à alta administração: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias: relatórios ao comitê de riscos do conselho sobre TPRM; identificação de riscos materiais no nível do conselho; a um fornecedor que confirme uma governança de TPRM madura deve-se perguntar se essa governança chega ao nível do conselho. A maturidade operacional do programa não é o mesmo que a supervisão de riscos no nível do conselho.
- TPRM em fusões e aquisições
-
TPRM em M&A é relevante porque o risco de herdar relações com fornecedores não divulgadas, incidentes de segurança ativos e contratos de fornecedores com restrições é real, quantificável e evitável por meio de diligência antes do fechamento.
TPRM em M&A é relevante porque o risco de herdar relações com fornecedores não divulgadas, incidentes de segurança ativos e contratos de fornecedores com restrições é real, quantificável e evitável por meio de diligência antes do fechamento.
- TPRM para fusões e aquisições: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias: lista completa de fornecedores com a caracterização do acesso a dados; achados de TPRM em aberto de qualquer severidade; a uma empresa-alvo de aquisição deve-se solicitar sua carteira de fornecedores, os achados em aberto e o histórico de incidentes como parte da diligência de M&A. Essas informações determinam o risco de terceiros que a empresa está adquirindo, que deve ser precificado e gerenciado, e não descoberto dezoito meses após o fechamento.
- Lacunas de responsabilidade e prestação de contas em TPRM
-
As lacunas de responsabilidade e de prestação de contas são relevantes porque riscos identificados que permanecem sem gestão não são menos perigosos do que riscos não identificados: são mais perigosos, porque a organização tem conhecimento documentado do risco e não pode alegar desconhecimento em uma análise pós-incidente ou em uma fiscalização regulatória.
As lacunas de responsabilidade e de prestação de contas são relevantes porque riscos identificados que permanecem sem gestão não são menos perigosos do que riscos não identificados: são mais perigosos, porque a organização tem conhecimento documentado do risco e não pode alegar desconhecimento em uma análise pós-incidente ou em uma fiscalização regulatória.
- Lacunas de responsabilidade e responsabilização em TPRM: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias: processo formal de resposta à remediação de achados; contato de escalonamento para achados críticos não resolvidos; compromisso de prazo de remediação para achados críticos.
- Automação do programa de TPRM e seus limites
-
Os limites da automação são relevantes porque os ganhos de eficiência da automação de TPRM são reais e valiosos, mas devem ser obtidos sem comprometer a qualidade analítica que torna útil a inteligência de riscos do programa.
Os limites da automação são relevantes porque os ganhos de eficiência da automação de TPRM são reais e valiosos, mas devem ser obtidos sem comprometer a qualidade analítica que torna útil a inteligência de riscos do programa.
- Automação do programa de TPRM e seus limites: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias: etapa de revisão humana no fluxo de avaliação automatizada; processo de verificação cruzada de evidências paralelo à pontuação do questionário; métricas de qualidade paralelas às métricas de eficiência.
- Modelos de maturidade de programas de TPRM
-
A avaliação de maturidade de TPRM é relevante porque fornece a análise estruturada necessária para priorizar o investimento no programa.
A avaliação de maturidade de TPRM é relevante porque fornece a análise estruturada necessária para priorizar o investimento no programa.
- Modelos de maturidade de programas de TPRM: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias: alinhamento com os marcos regulatórios em cada domínio; roteiro de melhoria do programa orientado pelas lacunas de maturidade; validação independente da avaliação de maturidade.
- Métricas & KPIs do programa de TPRM
-
As métricas do programa são relevantes porque determinam se o investimento em TPRM se justifica e para onde ele deve ser direcionado. Um programa medido apenas por métricas de conclusão de processos não consegue demonstrar valor à liderança nem identificar onde as melhorias do programa teriam o maior impacto de redução de riscos.
as métricas do programa são importantes porque determinam se o investimento em TPRM se justifica e para onde ele deve ser direcionado.
- Métricas & KPIs do programa de TPRM: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias: taxa de achados por nível de fornecedor; taxa de remediação e prazo médio; a um fornecedor que confirme um programa de TPRM maduro deve-se solicitar as métricas de resultado de risco. A conclusão de processos mostra que ele está executando o programa. As métricas de resultado de risco mostram o que o programa alcançou.
- Falhas no desenho de questionários de TPRM
-
O desenho do questionário é importante porque a qualidade da inteligência de riscos que orienta as decisões de TPRM é limitada pela qualidade das informações que o questionário gera. Um questionário bem desenhado, que faz as quarenta perguntas certas, produz melhor inteligência de riscos em menos tempo do que um questionário mal desenhado de 187 perguntas.
O desenho do questionário é relevante porque a qualidade da inteligência de riscos que orienta as decisões de TPRM é limitada pela qualidade das informações que o questionário gera.
- Falhas no desenho de questionários de TPRM: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias verbais: configurações técnicas específicas, em vez de declarações genéricas de política; documentos que evidenciem a implementação dos controles declarados; documentação de arquitetura para os domínios de segurança críticos.
- Envenenamento de dados de treinamento
-
O envenenamento de dados de treinamento é a contaminação do conjunto de dados de treinamento de um modelo de aprendizado de máquina de formas que levam o modelo a aprender padrões incorretos, enviesados ou deliberadamente manipulados, resultando em um modelo que se comporta de forma incorreta e previsível, beneficiando um atacante ou refletindo os erros estruturais do corpus de treinamento.
O envenenamento de dados de treinamento é relevante para TPRM porque produtos de IA com bom desempenho nas métricas de teste fornecidas pelo fornecedor ainda podem conter pontos cegos sistemáticos causados por dados de treinamento contaminados.
- Envenenamento de dados de treinamento: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias: documentação da composição temporal do corpus de treinamento; metodologia e resultados da avaliação da qualidade dos rótulos; resultados de testes de pontos cegos adversariais.
- Avaliação de impacto de transferência TIA
-
A avaliação sobre se a legislação e a prática do país de destino comprometem a proteção prometida por um mecanismo de transferência.
Redigido por destino, é fácil de manter; redigido por fornecedor, vira um modelo em que só se troca o nome.
Ensinado em PRV-280 · Veja também: Mecanismo de transferência
- Avaliações de impacto de transferência
-
Uma avaliação de impacto de transferência analisa se a legislação e as práticas do país de destino, especialmente quanto ao acesso governamental aos dados, comprometem as proteções que as cláusulas-padrão contratuais deveriam oferecer. Se comprometerem, devem ser adotadas medidas suplementares, ou a transferência não deve prosseguir. Essa exigência decorre do acórdão Schrems II de 2020.
é a etapa mais frequentemente pulada, porque exige formar uma opinião sobre o regime de vigilância de outro país, o que parece trabalho para um advogado, e não para uma equipe de privacidade. Mas as cláusulas a exigem, os reguladores a solicitam, e uma transferência para os Estados Unidos com base em cláusulas-padrão contratuais sem uma TIA arquivada é uma transferência cujo mecanismo um regulador pode invalidar.
- Mecanismo de transferência SCCs, adequação
-
A base legal para transferir dados pessoais para fora de uma jurisdição: uma decisão de adequação, cláusulas-padrão contratuais, normas corporativas globais ou uma derrogação.
O acesso remoto conta como transferência. A maioria dos registros lista apenas os locais de armazenamento e subestima substancialmente a situação.
Ensinado em PRV-280 · Veja também: Avaliação de impacto da transferência, Cláusulas contratuais com o operador
- Risco de dependências transitivas
-
O risco de dependências transitivas é relevante para TPRM porque os fornecedores de software cujos produtos você implanta têm árvores de dependências transitivas que podem conter componentes vulneráveis que eles não monitoram ativamente.
O risco de dependências transitivas é relevante para TPRM porque os fornecedores de software cujos produtos você implanta têm árvores de dependências transitivas que podem conter componentes vulneráveis que eles não monitoram ativamente.
- Risco de dependências transitivas: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias: confirmação da varredura de SCA transitiva completa; cronograma de resposta ao Log4Shell como estudo de caso de vulnerabilidade transitiva; a um fornecedor que confirme a gestão de vulnerabilidades de SCA deve-se perguntar sobre a cobertura em profundidade transitiva. SCA para dependências diretas é um ponto de partida. A varredura transitiva completa é o panorama completo. O Log4Shell é o caso de teste clássico para saber se essa distinção foi operacionalizada.
- Estrutura de Transparência e Consentimento TCF
-
Padrão do setor para transmitir as escolhas de consentimento de um usuário pela cadeia de fornecimento de publicidade, codificadas como uma string de consentimento.
É um formato de transporte, não uma proteção jurídica. Uma string dizendo que o usuário consentiu não torna o consentimento válido se o banner que a gerou era enganoso.
Ensinado em PRV-230 · Veja também: Plataforma de gestão de consentimento
- Central de confiança
-
A página voltada aos compradores que reúne as certificações e seu escopo, os suboperadores, resumos da arquitetura e das políticas, com as evidências sensíveis protegidas por um controle de acesso.
Uma bem construída elimina parte dos questionários e encurta os demais. Uma desatualizada é uma alegação pública que você visivelmente não está mantendo.
Ensinado em TRS-201 · Veja também: Atestação, Biblioteca de respostas
- Centrais de confiança
-
Uma central de confiança é uma página pública que apresenta a postura de segurança e privacidade de uma organização: certificações obtidas, relatórios disponíveis mediante NDA, lista de suboperadores, políticas e respostas às perguntas que os compradores fazem com mais frequência. Algumas restringem documentos mediante solicitação; outras publicam abertamente.
Ela converte o trabalho repetido de questionários um a um em autoatendimento e sinaliza maturidade a um comprador antes mesmo de qualquer conversa começar. Um potencial cliente que consegue ver que o SOC 2 existe, que os suboperadores estão listados e que as perguntas estão respondidas é um potencial cliente que chega à revisão de segurança já tranquilizado.
- Critérios de Serviços de Confiança
-
Os Trust Services Criteria não são uma lista de controles. São critérios, declarações do que precisa ser verdade, e cada organização desenha seus próprios controles para atendê-los. O AICPA declara o resultado exigido; a empresa auditada decide o que faz para alcançar esse resultado; o auditor testa o que a empresa decidiu.
É por isso que duas empresas do mesmo mercado podem ter relatórios SOC 2 que parecem completamente diferentes, com quantidades de controles, redação e evidências diferentes, e ambos serem válidos. É também por isso que um questionário elaborado com base nos controles de uma empresa não pode ser respondido a partir do relatório de outra.
- Tipo I e Tipo II
-
Um relatório Tipo I emite opinião sobre se os controles estão adequadamente desenhados em um determinado momento; um Tipo II acrescenta testes sobre se eles operaram ao longo de um período.
Um Tipo I pode ser obtido por uma empresa que redigiu suas políticas no mês passado. Compradores experientes leem as exceções do Tipo II antes da opinião.
Ensinado em TPR-210 · Veja também: Carta-ponte, Controle complementar da entidade usuária
- Typosquatting em registros de pacotes
-
O typosquatting é relevante para TPRM porque os produtos de software dos seus fornecedores são construídos sobre árvores de dependências que podem incluir pacotes com nomes falsificados sem o conhecimento do fornecedor, porque o pacote falsificado era uma dependência transitiva, porque não tinha CVE e porque, por definição, as varreduras de SCA deles não detectam pacotes maliciosos.
O typosquatting é relevante para TPRM porque os produtos de software dos seus fornecedores são construídos sobre árvores de dependências que podem incluir pacotes com nomes falsificados sem o conhecimento do fornecedor, porque o pacote falsificado era uma dependência transitiva, porque não tinha CVE e porque, por definição, as varreduras de SCA deles não detectam pacotes maliciosos.
- Typosquatting em registros de pacotes: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias: detecção de pacotes maliciosos além da varredura de CVE; fixação de versões de dependências e uso obrigatório de arquivos de bloqueio; a um fornecedor que confirme a varredura de vulnerabilidades de SCA deve-se perguntar sobre a detecção de pacotes maliciosos. SCA verifica vulnerabilidades conhecidas. Pacotes com nomes falsificados não são vulnerabilidades conhecidas: são código malicioso sem CVE. Ferramentas diferentes, modelo de ameaça diferente.
V
- Acúmulo gradual de acessos de fornecedores ao longo do tempo
-
O acúmulo gradual de acessos de fornecedores é relevante porque cria uma divergência sistemática entre o perfil de risco que o programa de TPRM avaliou e o perfil de risco que a relação com o fornecedor realmente apresenta.
O acúmulo gradual de acessos de fornecedores é relevante porque cria uma divergência sistemática entre o perfil de risco que o programa de TPRM avaliou e o perfil de risco que a relação com o fornecedor realmente apresenta.
- Acúmulo gradual de acessos de fornecedores ao longo do tempo: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias: inventário atual do escopo de acesso a dados; alterações de acesso desde a última avaliação; confirmação de que não existe nenhum acesso a dados não divulgado.
- Acesso de fornecedores por meio de entidades de serviço
-
Uma entidade de serviço é uma identidade não humana criada em uma plataforma de identidade em nuvem (mais comumente o Azure Active Directory, mas o conceito existe em todos os principais provedores de nuvem sob nomes diferentes) que representa uma aplicação, um serviço ou um processo automatizado, e não uma pessoa.
As entidades de serviço são a espinha dorsal operacional das integrações de fornecedores em ambientes Azure e Microsoft 365 e, cada vez mais, também em AWS e GCP, sob construções equivalentes, como as funções IAM para aplicações e as contas de serviço do GCP.
- Acesso de fornecedores por meio de entidades de serviço: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias: uma lista específica das entidades de serviço usadas no seu ambiente, com a descrição dos respectivos escopos de permissão; uma política de rotação de credenciais com período máximo de validade definido, idealmente de 90 dias ou menos para segredos de cliente; evidência de armazenamento seguro de credenciais no lado do fornecedor, ou seja, um cofre de segredos, e não um arquivo de configuração ou uma variável de ambiente.
- Proliferação de contas de administrador do fornecedor
-
A proliferação de contas de administrador é o acúmulo, ao longo do tempo, de contas administrativas privilegiadas, resultante de uma combinação de decisões legítimas de provisionamento e de uma gestão insuficiente do ciclo de vida.
a proliferação de contas administrativas em plataformas de fornecedores é importante para TPRM porque cada conta administrativa excedente é uma credencial de alto privilégio que um agente de ameaça poderia usar para obter controle total da plataforma.
- Proliferação de contas administrativas de fornecedores: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias: quantidade de contas de administrador com a sua composição (funcionários atuais, terceirizados, partes externas); histórico atual de revisões de justificativa, ou seja, quando foi revisada pela última vez a necessidade ativa; confirmação de acesso administrativo JIT ou documentação da governança de contas permanentes.
- Transparência no uso de IA pelos fornecedores
-
A transparência sobre o uso de IA pelo fornecedor é a estrutura de divulgação e prestação de contas para todas as formas pelas quais um fornecedor usa IA que afetam o cliente corporativo, incluindo tanto as funcionalidades de produto baseadas em IA comercializadas ao cliente quanto os sistemas internos de IA que usam os dados do cliente para fins operacionais do fornecedor, como a pontuação de clientes,
A transparência sobre o uso de IA pelo fornecedor é relevante para TPRM porque os dados da empresa (seus padrões de uso, histórico de suporte e comportamento operacional) podem ser usados por sistemas de IA do fornecedor de maneiras que afetam o serviço que a empresa recebe, os preços que lhe são oferecidos e as decisões estratégicas que o fornecedor toma sobre o relacionamento.
- Transparência no uso de IA pelos fornecedores: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias: divulgação dos sistemas internos de IA que usam dados da empresa; cobertura dos usos internos de IA no acordo de tratamento de dados; divulgação da classificação e do direcionamento de clientes.
- Lacunas de visibilidade de alertas do fornecedor
-
As lacunas de visibilidade de alertas do fornecedor são a ausência de acesso do cliente aos dados de monitoramento, alertas e eventos de detecção gerados pela infraestrutura de operações de segurança de um fornecedor para os sistemas e dados relevantes para a relação com o cliente.
As lacunas de visibilidade de alertas do fornecedor são relevantes para TPRM porque a avaliação da capacidade de SOC de um fornecedor indica o que o fornecedor consegue detectar.
- Lacunas de visibilidade de alertas do fornecedor: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias: procedimento de escalonamento de alertas para os sistemas relevantes ao cliente; disposição para encaminhar categorias específicas de alertas ao SOC do cliente; processo para que o cliente forneça contexto de detecção ao SOC do fornecedor.
- Riscos de acesso analítico pelo fornecedor
-
O risco de acesso analítico surge quando o acesso a dados concedido às equipes de análise (as pessoas responsáveis por criar painéis, relatórios e modelos analíticos) é significativamente mais amplo do que qualquer tarefa analítica específica exige e é mantido sem os controles de acesso, o registro em log e a cadência de revisão aplicados a outras formas de
o risco de acesso analítico é importante para TPRM porque o cenário de ameaça interna com maior probabilidade de causar uma violação de dados de clientes significativa em um fornecedor de SaaS multilocatário não é um ataque externo sofisticado: é um usuário de análise autorizado, com acesso irrestrito de leitura a todo o conjunto de dados dos clientes, que decide usar esse acesso fora
- Riscos de acesso analítico pelo fornecedor: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias verbais: documentação do escopo do acesso analítico, com o número de analistas, a amplitude do acesso e a restrição por cliente; confirmação do registro em nível de consulta nas sessões analíticas; histórico de revisão dos acessos analíticos, com a inclusão nas revisões periódicas e a data da última revisão.
- Efetivação dos direitos de auditoria sobre fornecedores
-
Os direitos de auditoria sobre fornecedores são disposições contratuais que permitem ao cliente realizar, ou contratar, avaliações de segurança do ambiente, dos controles e das práticas do fornecedor.
A efetivação dos direitos de auditoria sobre fornecedores é relevante para TPRM porque a verificação independente é o mecanismo de governança que distingue a gestão de riscos da documentação de riscos.
- Efetivação dos direitos de auditoria sobre fornecedores: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias: evidências técnicas dos controles especificados, em vez de respostas a questionários; cooperação conforme especificado na cláusula de direito de auditoria; proteção da confidencialidade dos achados, conforme acordado.
- Risco dos dados de backup do fornecedor
-
Os dados de backup contêm as mesmas informações que os dados de produção no momento em que o backup foi feito. Têm a mesma sensibilidade, a mesma classificação regulatória e as mesmas implicações de notificação de violação, se expostos.
o risco dos dados de backup de fornecedores é importante para TPRM porque os sistemas de backup representam o maior ponto de acumulação de dados históricos no ambiente de um fornecedor: eles guardam cópias de dados de clientes de anos atrás, com uma governança que reflete o estado da organização no momento em que cada backup foi criado, e não os padrões de segurança atuais.
- Risco dos dados de backup de fornecedores: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias: histórico de revisões de acesso aos backups, ou seja, quando foi a última revisão e qual é a população atual com acesso; ciclo de vida das chaves de criptografia dos backups, com o cronograma de rotação e a política de nova criptografia de backups históricos; histórico de varreduras de segurança do armazenamento de backups, com a varredura mais recente e quaisquer achados.
- Exposição do armazenamento de backups do fornecedor
-
A exposição do armazenamento de backups do fornecedor é o risco que surge quando um fornecedor mantém cópias de backup dos dados do cliente sob controles de segurança mais fracos, menos monitorados e governados com menos rigor do que o ambiente de produção principal avaliado durante a diligência do fornecedor.
O armazenamento de backups é onde os dados vão para ser esquecidos, não intencionalmente, mas como consequência estrutural da forma como os sistemas de backup são projetados e priorizados.
- Exposição do armazenamento de backups do fornecedor: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias: documentação do local de armazenamento dos backups, do padrão de criptografia e dos controles de acesso, equivalentes ou superiores aos padrões de produção; confirmação de escopo do SOC 2 que trate explicitamente da infraestrutura de backup, ou um mecanismo alternativo de garantia para ambientes de backup; processo definido de expurgo de backups acionado pelo término do contrato, com prazo assumido e padrão de evidência.
- Atrasos na detecção de violações pelo fornecedor
-
Os atrasos na detecção de violações em fornecedores são o intervalo entre o momento em que um incidente de segurança começa no ambiente de um fornecedor, o momento em que o fornecedor o detecta e o momento em que os clientes do fornecedor são notificados. São três eventos distintos na linha do tempo, e cada um cria uma categoria diferente de risco para o cliente.
Os atrasos na detecção de violações pelo fornecedor são relevantes para TPRM porque as obrigações regulatórias do cliente, o cronograma de resposta a incidentes e as opções de mitigação de riscos são diretamente afetados pela rapidez com que o fornecedor o notifica após a detecção de uma violação.
- Atrasos na detecção de violações pelo fornecedor: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias verbais: prazo entre a detecção e a notificação em incidentes anteriores; procedimento de notificação que distinga a notificação preliminar da confirmada; compromisso de notificação preliminar dentro de um número definido de horas após a detecção.
- Contas de acesso emergencial de fornecedores
-
Contas de acesso emergencial são credenciais de emergência de alto privilégio projetadas para situações em que os caminhos normais de acesso estão indisponíveis e sistemas críticos exigem intervenção imediata: bloqueios catastróficos de acesso, incidentes ativos que exigem acesso administrativo mais rápido do que os fluxos normais permitem e cenários de recuperação de desastres em que os padr
As contas de acesso emergencial são relevantes para TPRM porque fornecedores que gerenciam ambientes de clientes têm mecanismos de acesso emergencial a esses ambientes, e esses mecanismos podem estar sujeitos ao mesmo problema de retorno gradual às configurações padrão.
- Contas de acesso emergencial do fornecedor: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias: registro de uso de contas de acesso emergencial com o status de declaração de emergência de cada uso; confirmação da aplicação técnica de autorização dupla; política de consequências para o uso não autorizado de acesso emergencial.
- Continuidade de negócios & resiliência do fornecedor
-
A continuidade de negócios e a resiliência dos fornecedores são relevantes porque interrupções operacionais em fornecedores críticos afetam diretamente as operações da própria empresa, e a capacidade da empresa de manter a continuidade do serviço para os seus próprios clientes durante interrupções de fornecedores depende de informações precisas sobre a capacidade realista de recupera
A continuidade de negócios e a resiliência dos fornecedores são relevantes porque interrupções operacionais em fornecedores críticos afetam diretamente as operações da própria empresa, e a capacidade da empresa de manter a continuidade do serviço para os seus próprios clientes durante interrupções de fornecedores depende de informações precisas sobre a capacidade realista de recupera
- Continuidade de negócios & resiliência dos fornecedores: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias: resultados do teste de BCP mais recente com o RTO efetivamente alcançado; documentação da arquitetura geográfica da infraestrutura primária e de backup; confirmação da independência da infraestrutura, quanto a energia e rede.
- Práticas de revisão de código dos fornecedores
-
A revisão de código é a prática de fazer com que um ou mais desenvolvedores examinem uma mudança de código antes que ela seja incorporada à base de código principal, verificando se ela está correta, legível, fácil de manter e alinhada aos padrões do projeto.
A revisão de código fica no último ponto de controle humano antes de o código ser entregue: o ponto do processo de desenvolvimento em que um revisor atento à segurança pode identificar vulnerabilidades que as ferramentas automatizadas deixaram passar, falhas de lógica de negócio que os scanners não conseguem detectar e decisões de design cujas implicações de segurança só são visíveis para alguém que entende tanto o
- Práticas de revisão de código do fornecedor: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias: documentação da lista de verificação de revisão de segurança cobrindo autenticação, autorização, tratamento de entradas e dados sensíveis para os tipos de mudança relevantes; descrição do programa de campeões de segurança, ou seja, como os revisores são selecionados, treinados e mantidos; confirmação do treinamento de segurança para desenvolvedores, com o nome da plataforma, a descrição da cobertura e a frequência de realização.
- Indicadores de comprometimento de fornecedores
-
Os indicadores de comprometimento de fornecedores são as evidências técnicas (eventos de autenticação, conexões de rede, alterações no sistema de arquivos, modificações de registro e execuções de processos) que demonstram a presença de um atacante no ambiente de um fornecedor. Os indicadores de comprometimento confirmam que o acesso ocorreu.
Os indicadores de comprometimento de fornecedores são relevantes para TPRM porque a avaliação de risco de violação do cliente, e sua decisão sobre a notificação regulatória, depende de entender não apenas que um fornecedor foi comprometido, mas o que o comprometimento alcançou em relação aos dados que o cliente compartilha com esse fornecedor.
- Indicadores de comprometimento de fornecedores: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias: confirmação de API no nível dos dados e de logs de consultas; capacidade de investigação para confirmar as consequências do acesso aos dados; a um fornecedor que confirme capacidade de detecção de comprometimentos deve-se perguntar se o seu registro em log permite confirmar consequências, e não apenas detectar indicadores. O indicador informa aos investigadores que o acesso ocorreu. O log de consequências informa para que o acesso foi usado.
- Risco de concentração em fornecedores
-
O risco de concentração de fornecedores é relevante porque é uma propriedade da carteira que as avaliações individuais de fornecedores são estruturalmente incapazes de identificar: sua medição exige agregar dados de toda a carteira de fornecedores.
O risco de concentração de fornecedores é relevante porque é uma propriedade da carteira que as avaliações individuais de fornecedores são estruturalmente incapazes de identificar: sua medição exige agregar dados de toda a carteira de fornecedores.
- Risco de concentração de fornecedores: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias: avaliação do próprio fornecedor sobre seu risco de concentração; plano de continuidade de negócios para a falha do seu maior provedor; prontidão de provedores alternativos para funções críticas.
- Coordenação da contenção com fornecedores
-
A coordenação da contenção com fornecedores é o desafio de alinhar as decisões de contenção tomadas pela equipe de IR de um fornecedor, que precisa ponderar o impacto operacional das ações de contenção sobre todos os seus clientes, com a urgência de contenção de um cliente específico cujos dados estão em risco ativo.
a coordenação da contenção com fornecedores é importante para TPRM porque a perda de dados do cliente durante uma violação ativa em um fornecedor é função direta de quanto tempo o atacante mantém o acesso, e quanto tempo o atacante mantém o acesso depende, em parte, da rapidez com que o fornecedor executa a contenção.
- Coordenação da contenção com o fornecedor: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias: autoridade e processo de decisão sobre a contenção; prazo máximo de contenção a partir da solicitação do cliente; gatilhos de contenção pré-aprovados, se disponíveis.
- Desvio de controles do fornecedor
-
O desvio de controles é a degradação gradual do programa de segurança de um fornecedor entre os eventos formais de avaliação: a erosão progressiva da postura de segurança por rotatividade de pessoal, redução de orçamento, desgaste da governança e desativação de ferramentas que, individualmente, podem não atingir o limite de 'mudança relevante no programa', mas que, em conjunto, repr
o desvio de controles é importante para TPRM porque a qualidade do programa de segurança que justificou a classificação de risco de um fornecedor pode já não descrever com precisão a postura atual do fornecedor dois anos depois do início do relacionamento.
- Desvio de controles nos fornecedores: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias: comparação do quadro de pessoal da equipe de segurança com a última avaliação; frequência das reuniões de governança nos últimos seis meses; a um fornecedor que confirme não ter havido mudanças materiais no programa devem ser feitas as quatro perguntas específicas sobre desvio. Cada resposta individual pode estar abaixo do limite de mudança material. O quadro combinado pode descrever um desvio significativo.
- Revisões de acesso a dados de fornecedores
-
As revisões de acesso, o processo periódico de verificar se todas as contas com acesso a sistemas e dados sensíveis ainda devem ter esse acesso, são um controle fundamental de governança de identidades, exigido por PCI-DSS, SOC 2, ISO 27001 e pela maioria dos frameworks regulatórios que tratam de segurança da informação.
a qualidade das revisões de acesso é importante para TPRM porque é o controle que determina se o acesso concedido aos funcionários de um fornecedor continua proporcional às suas funções atuais ao longo do tempo.
- Revisões de acesso a dados de fornecedores: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias: taxa de revogação na revisão de acessos do ciclo mais recente; formato dos dados da revisão de acessos, mostrando o contexto das contas fornecido aos revisores; confirmação do desprovisionamento automatizado e descrição da integração com o RH.
- Riscos de agregação de dados pelo fornecedor
-
O risco de agregação de dados é o risco que surge da combinação de conjuntos de dados que, individualmente, não chamam a atenção, mas que, em conjunto, são sensíveis.
O risco de agregação de dados é relevante para TPRM porque representa uma categoria de risco que é invisível no nível da avaliação de cada cliente e visível apenas no nível da carteira do fornecedor.
- Riscos de agregação de dados pelo fornecedor: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias: divulgação da concentração setorial da base de clientes, ou seja, quantos concorrentes do setor compartilham dados equivalentes; confirmação, no DPA, da restrição ao uso de dados entre clientes; descrição da arquitetura técnica de isolamento de dados.
- Riscos do enriquecimento de dados pelo fornecedor
-
O enriquecimento de dados é a prática de ampliar um conjunto de dados de base com atributos adicionais obtidos de provedores externos, acrescentando aos registros de clientes dados demográficos, comportamentais, firmográficos e psicográficos para criar perfis mais completos.
O enriquecimento de dados pelo fornecedor é relevante para TPRM porque representa uma categoria de tratamento de dados que ocorre no sistema do fornecedor sem que o cliente tenha decidido explicitamente coletar ou tratar os dados enriquecidos.
- Riscos do enriquecimento de dados pelo fornecedor: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias: divulgação das funcionalidades de enriquecimento, ou seja, o que é acrescentado, de quais fontes e de quais categorias; inventário de dados para solicitações de acesso do titular, incluindo as categorias enriquecidas; disposições do DPA sobre enriquecimento, com base legal, retenção e obrigações de exclusão para os dados enriquecidos.
- Lacunas nos acordos de tratamento de dados com fornecedores
-
As lacunas nos acordos de tratamento de dados são relevantes porque determinam se as obrigações de controlador da empresa segundo o GDPR, especificamente garantir que os operadores só tratem dados pessoais conforme instruções documentadas e para finalidades especificadas, estão sendo cumpridas.
as lacunas nos acordos de tratamento de dados são importantes porque determinam se as obrigações da empresa como controlador segundo o GDPR, especificamente garantir que os operadores tratem dados pessoais apenas mediante instruções documentadas e para finalidades especificadas, estão sendo cumpridas.
- Lacunas nos acordos de tratamento de dados com fornecedores: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias verbais: confirmação clara de que o uso para treinamento de IA é proibido ou não é praticado; compromisso de aviso prévio sobre mudanças de política; confirmação de uso restrito, apenas para a finalidade do serviço contratado.
- Exposição do data lake do fornecedor
-
Um data lake é um repositório centralizado projetado para armazenar grandes volumes de dados brutos e não processados de várias fontes (bancos de dados de aplicações, fluxos de eventos, logs de API, feeds externos) em seu formato nativo, permitindo consultas analíticas flexíveis sem as restrições de esquema de um banco de dados relacional tradicional.
a exposição do data lake do fornecedor é importante para TPRM porque representa uma concentração de dados sensíveis em um ponto da arquitetura do fornecedor projetado especificamente para ser amplamente acessível.
- Exposição do data lake do fornecedor: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias: confirmação da existência de um data lake, com a descrição do controle de acesso; evidência de revisão de acessos, ou seja, quando o acesso ao data lake foi revisado pela última vez e qual é a população atual com acesso; confirmação do uso de dados para treinamento de ML e respectivo processo de autorização.
- Práticas de retenção de dados dos fornecedores
-
A retenção de dados pelo fornecedor é relevante para TPRM porque dados mantidos por um fornecedor além do período em que são necessários representam risco residual puro, ou seja, risco sem nenhum benefício operacional correspondente. Dados de que o fornecedor não precisa mais para nenhuma finalidade de tratamento não estão gerando valor.
A retenção de dados pelo fornecedor é relevante para TPRM porque dados mantidos por um fornecedor além do período em que são necessários representam risco residual puro, ou seja, risco sem nenhum benefício operacional correspondente.
- Práticas de retenção de dados do fornecedor: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias: documentação do escopo da exclusão, com todos os sistemas incluídos no processo de exclusão e confirmação explícita de que backups, ambientes de desenvolvimento e suboperadores estão cobertos; política de retenção de backups, com os períodos máximos de retenção e a indicação de se as solicitações de exclusão acionam o expurgo dos backups; evidência técnica de verificação da exclusão, ou seja, além da confirmação do gerente de conta, um registro tecnicamente verificável do escopo da exclusão.
- Riscos de transformação de dados pelo fornecedor
-
A transformação de dados é o processo pelo qual dados de entrada são modificados, enriquecidos, derivados ou calculados para gerar dados de saída com características diferentes: a normalização, que padroniza formatos; a derivação, que calcula novos atributos a partir dos existentes; o enriquecimento, que combina dados externos com os registros de entrada; e a agregação, que produz
A transformação de dados pelo fornecedor é relevante para TPRM porque a transformação cria novos dados (dados que não existiam antes de o fornecedor tratar a entrada) com características que podem diferir materialmente dos dados de entrada quanto ao status regulatório, à sensibilidade e às obrigações relativas a direitos.
- Riscos de transformação de dados pelo fornecedor: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias: inventário de atributos derivados, ou seja, o que é criado a partir dos dados fornecidos pelo cliente; disposições do DPA sobre derivação, base legal e retenção para atributos derivados; confirmação do escopo do DSAR incluindo os atributos derivados.
- Segurança dos ambientes de desenvolvimento dos fornecedores
-
A segurança do ambiente de desenvolvimento é relevante para TPRM porque a cadeia de suprimentos de software começa nas estações de trabalho dos desenvolvedores.
A segurança do ambiente de desenvolvimento é relevante para TPRM porque a cadeia de suprimentos de software começa nas estações de trabalho dos desenvolvedores.
- Segurança dos ambientes de desenvolvimento dos fornecedores: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias: confirmação de MDM e de segurança dos dispositivos nas estações de trabalho dos desenvolvedores; gestão centralizada das credenciais de desenvolvimento; política e monitoramento de extensões do IDE.
- Riscos de integração do fornecedor ao diretório
-
A integração de diretórios conecta dois sistemas de identidade por meio de uma relação de sincronização: os objetos, atributos e eventos de ciclo de vida de um diretório se propagam para o outro e, nas integrações bidirecionais, as mudanças fluem nos dois sentidos.
a integração de diretórios é importante para TPRM porque é uma das relações de identidade de maior confiança que uma organização pode estabelecer com um fornecedor: as mudanças no diretório do parceiro se propagam diretamente para a infraestrutura de identidade do cliente.
- Riscos da integração de diretórios com fornecedores: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias: documentação do escopo da sincronização de diretório, com os tipos de objetos e atributos incluídos; confirmação do monitoramento da sincronização de entrada, com alertas de anomalias; postura de segurança das contas de administrador de parceiros com acesso à sincronização de diretório.
- Caminhos de escalonamento do fornecedor
-
Os caminhos de escalonamento do fornecedor são os procedimentos documentados e os mecanismos de contato que os clientes usam para chegar à liderança de segurança e de resposta a incidentes do fornecedor durante um incidente de segurança.
Os caminhos de escalonamento do fornecedor são relevantes para TPRM porque a capacidade do cliente de obter informações técnicas, coordenar ações de resposta e influenciar decisões de contenção durante uma violação no fornecedor depende inteiramente da eficácia do caminho de escalonamento até a liderança de segurança do fornecedor.
- Caminhos de escalonamento do fornecedor: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias verbais: contato direto com a equipe de segurança, com uma pessoa nomeada e celular para fora do horário comercial; tempo de resposta esperado para escalonamentos urgentes; protocolo para incidentes ativos com escalonamento pelo cliente.
- Saúde financeira do fornecedor como sinal de TPRM
-
O monitoramento da saúde financeira é relevante porque elimina a lacuna entre a precisão de uma avaliação pontual e a realidade atual do risco do fornecedor.
O monitoramento da saúde financeira é relevante porque elimina a lacuna entre a precisão de uma avaliação pontual e a realidade atual do risco do fornecedor.
- Saúde financeira do fornecedor como sinal de TPRM: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias verbais: confirmação da estabilidade do quadro da equipe de segurança; atualidade do calendário de avaliações e certificações; ausência de investimentos em segurança adiados de importância material.
- Funções IAM do fornecedor na sua nuvem
-
Uma função IAM em um ambiente de nuvem é um conjunto nomeado de permissões que define quais ações podem ser executadas sobre quais recursos e, o que é crucial, pode ser assumida por entidades que não são usuários humanos.
as funções de IAM de fornecedores são uma das manifestações mais concretas e diretas do risco de terceiros em um ambiente de nuvem.
- Funções IAM do fornecedor na sua nuvem: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias: uma lista das funções IAM ou entidades de serviço específicas que o fornecedor usa no seu ambiente, com a descrição das permissões; evidência de governança de credenciais no lado do fornecedor, ou seja, como as credenciais da equipe do fornecedor são gerenciadas e revogadas; um processo definido de descomissionamento que inclua etapas explícitas para a entrega ou a confirmação da revogação do acesso à nuvem.
- Evidências de auditoria de identidades do fornecedor
-
As evidências de auditoria da governança de identidades são a documentação que demonstra, a um examinador externo, que os controles de governança de identidades operaram conforme descrito: não atestações de que existem, mas registros de sua operação.
As evidências de auditoria de identidades do fornecedor são relevantes para TPRM porque clientes que dependem de atestações do fornecedor sobre governança de identidades para o seu próprio cumprimento regulatório podem descobrir que essas atestações não se sustentam quando o regulador solicita as evidências subjacentes.
- Evidências de auditoria de identidades do fornecedor: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias verbais: registro das decisões da revisão de acessos, com decisões individuais, revisor e data e hora; documento de definição de funções, com o escopo de permissões de cada função; configuração de MFA com documentação das exceções.
- Cenários de comprometimento de identidades de fornecedores
-
O comprometimento de identidades de fornecedores é a categoria de ataque em que um agente de ameaça obtém o controle das credenciais de um funcionário do fornecedor, ou compromete a infraestrutura de gestão de identidades do fornecedor, e usa essas credenciais para acessar os ambientes dos clientes pelos caminhos de acesso legítimos do fornecedor.
O comprometimento de identidades de fornecedores é relevante para TPRM porque representa a ameaça de acesso que os controles de segurança do lado do cliente estão menos preparados para detectar.
- Cenários de comprometimento de identidades de fornecedores: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias: descrição da análise comportamental aplicada ao acesso da equipe de suporte aos clientes; confirmação da implantação de MFA resistente a phishing para a equipe com acesso a clientes; confirmação da gravação de sessões no acesso ao ambiente do cliente.
- Gestão do ciclo de vida de identidades de fornecedores
-
A gestão do ciclo de vida de identidades é o conjunto de processos que regem a criação, a manutenção e a desativação de contas de usuário ao longo de sua vida operacional, garantindo que as contas sejam criadas quando o acesso é necessário, mantidas de forma proporcional à medida que as necessidades mudam e desativadas quando o acesso deixa de ser necessário.
o ciclo de vida das identidades de fornecedores é importante para TPRM porque contas de plataforma pertencentes a ex-funcionários de fornecedores representam um risco específico e bem documentado de comprometimento de credenciais.
- Gestão do ciclo de vida de identidades de fornecedores: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias: documentação do processo de notificação de desligamentos, com o desligamento da plataforma incluído na lista de verificação de desligamento de funcionários; verificação do vínculo empregatício atual de todas as contas ativas na plataforma; data e achados da última conciliação da lista de pessoal.
- Monitoramento de identidades de fornecedores
-
O monitoramento de identidades na fronteira com o fornecedor abrange dois domínios de monitoramento distintos, mas complementares. O monitoramento do lado do cliente captura o que as identidades do fornecedor fazem dentro do ambiente do cliente: eventos de acesso, consultas a dados, alterações de configuração, duração das sessões e padrões de acesso que se desviam da linha de base.
O monitoramento de identidades do fornecedor é relevante para TPRM porque a capacidade de detecção do comprometimento de identidades de fornecedores deve atravessar a fronteira entre fornecedor e cliente: o monitoramento do cliente, sozinho, não consegue detectar a cadeia de ataque anterior à sessão, e o monitoramento do fornecedor, sozinho, pode não agir sobre os sinais antes que os ambientes dos clientes sejam alcançados.
- Monitoramento de identidades do fornecedor: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias: capacidade de monitoramento de identidades no lado do fornecedor, com alertas de falhas de autenticação e limites de prioridade; obrigação e prazo de notificação sobre a segurança de identidades; um fornecedor cujo monitoramento detecta sessenta e três tentativas de autenticação malsucedidas contra um membro da equipe, mas não gera um alerta prioritário nem notifica o cliente, tem um monitoramento que capta o sinal sem agir sobre ele. As duas metades importam: o sinal e a resposta. Pergunte sobre ambas.
- Pontuação de risco de identidade de fornecedores
-
A pontuação de risco de identidade é a prática de calcular um nível de risco composto para entidades de identidade individuais (contas de usuário, contas de serviço e credenciais de API) com base em múltiplos sinais que afetam a probabilidade e o impacto de seu comprometimento.
A pontuação de risco de identidades de fornecedores é relevante para TPRM porque a equipe do fornecedor que acessa ambientes de clientes representa uma superfície de risco concentrada, em que o comprometimento de um único indivíduo pode ter impacto sobre vários clientes.
- Pontuação de risco de identidades de fornecedores: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias: descrição da pontuação de risco de identidade, sinais utilizados e metodologia de pontuação; controles reforçados para indivíduos acima dos limites de risco; um fornecedor que responde 'todos os funcionários passam pelo nosso programa de segurança padrão' descreveu uma governança no nível do programa. Pergunte especificamente se algum indivíduo da equipe dele foi identificado como de risco elevado com base na combinação do seu escopo de acesso e dos sinais da sua postura de segurança individual. O programa padrão estabelece o piso. A pontuação de risco identifica quem está acima dele.
- Falhas na notificação de incidentes por fornecedores
-
A notificação de incidentes é relevante porque a capacidade da empresa de responder a uma violação no fornecedor depende diretamente de quando e de quão completamente ela é informada. Uma notificação atrasada ou incompleta significa resposta atrasada, cumprimento regulatório atrasado, notificação atrasada dos indivíduos e exposição prolongada às consequências da violação.
A notificação de incidentes é relevante porque a capacidade da empresa de responder a uma violação no fornecedor depende diretamente de quando e de quão completamente ela é informada.
- Falhas na notificação de incidentes por fornecedores: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias: confirmação por escrito da interpretação do gatilho e do prazo de notificação; contato direto da equipe de segurança para notificação de violações; modelo de conteúdo da notificação ou compromisso de conteúdo mínimo.
- Completude do inventário de fornecedores
-
A completude do inventário de fornecedores é o grau em que o programa de TPRM de uma organização identificou e contabilizou todos os relacionamentos ativos com terceiros: não apenas os fornecedores incluídos intencionalmente no programa de gestão de riscos, mas toda a população de fornecedores que têm acesso aos dados, aos sistemas ou às opera
A completude do inventário de fornecedores é o requisito fundamental de TPRM: um programa que não sabe o que não sabe não consegue gerenciar o risco que não identificou.
- Completude do inventário de fornecedores: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias: implementação de gatilhos de entrada em todos os canais de compras; índice de completude do inventário reportado à liderança; a um fornecedor que confirme um programa de TPRM maduro deve-se perguntar como ele sabe que seu inventário está completo. A maturidade do processo diz respeito aos fornecedores que o programa conhece. A completude do inventário diz respeito a se o programa conhece todos os fornecedores que deveria conhecer.
- Maturidade do plano de IR do fornecedor
-
A maturidade do plano de IR é o grau em que um plano de resposta a incidentes reflete uma capacidade operacional real e testada, e não apenas a existência de documentação que descreve os procedimentos pretendidos.
A maturidade do plano de IR do fornecedor é relevante para TPRM porque o resultado do cliente em uma violação no fornecedor depende da qualidade da execução do IR pelo fornecedor, e a qualidade da execução depende de uma maturidade que a documentação, por si só, não consegue demonstrar.
- Maturidade do plano de IR do fornecedor: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias: data e cenário do exercício mais recente; disponibilidade de manuais específicos por cenário, como ransomware e exfiltração de dados; métricas de desempenho de IR obtidas nos exercícios, como MTTD e MTTC.
- Frequência de testes de IR do fornecedor
-
A frequência de testes de IR do fornecedor abrange não apenas a frequência com que os exercícios ocorrem, mas também a amplitude com que cobrem os cenários de ataque, os ambientes tecnológicos e os participantes organizacionais que um incidente real envolveria. A frequência de testes é um indicador necessário, mas insuficiente, da eficácia do programa de IR.
A frequência de testes de IR do fornecedor é relevante para TPRM porque a capacidade de IR mais importante, a resposta coordenada que envolve as áreas jurídica, de comunicação, de operações e de segurança trabalhando juntas sob a pressão de um incidente, só se desenvolve por meio de exercícios que praticam exatamente essa coordenação.
- Frequência de testes de IR do fornecedor: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias: registro de exercícios, com datas, cenários e participantes; a um fornecedor que confirme testes regulares de IR deve-se solicitar o registro de exercícios. O registro revela o que a confirmação não revela: frequência específica, diversidade de cenários, cobertura de participantes e escopo do red team. O registro de exercícios é a evidência. A confirmação é a descrição.
- Gestão de fornecedores segundo o CC9
-
CC9 exige que a organização identifique e mitigue riscos de interrupção dos negócios e de fornecedores e parceiros de negócios. Na prática, a metade referente a fornecedores exige que você saiba quem são seus fornecedores, avalie o risco que eles representam, monitore-os ao longo do relacionamento e gerencie o seu encerramento.
Este é o critério que torna auditável o seu próprio programa de risco de terceiros. É também por isso que um fornecedor que pede a você um SOC 2 vai, na mesma conversa, perguntar como você avalia os seus fornecedores. As duas perguntas são o mesmo critério visto de cada lado.
- Cobertura do monitoramento de fornecedores
-
A cobertura do monitoramento de fornecedores, da perspectiva do cliente, é a medida em que o cliente tem visibilidade sobre eventos de segurança no ambiente do fornecedor que são relevantes para o risco do cliente, especificamente eventos que possam indicar um ataque à cadeia de suprimentos em andamento, que possam prever ameaças que surgirão no
A cobertura do monitoramento de fornecedores é relevante para TPRM porque determina em que ponto do ciclo de vida de um ataque à cadeia de suprimentos o cliente consegue detectar um ataque originado no ambiente do fornecedor.
- Cobertura do monitoramento de fornecedores: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias: procedimento de alerta de comprometimento de credenciais de desenvolvedores; compromisso de encaminhamento de eventos da cadeia de suprimentos; a um fornecedor de software cujo produto é implantado no ambiente do cliente, deve-se perguntar se o pipeline de build dele é monitorado e se comprometimentos de credenciais nesse ambiente seriam encaminhados ao cliente. O monitoramento do fornecedor cobre o fornecedor. O acordo de encaminhamento cobre o cliente.
- Desligamento de fornecedores
-
O desligamento é o que acontece quando um relacionamento com um fornecedor termina: o acesso é revogado, os dados são devolvidos ou destruídos com evidências, as integrações e as chaves de API são desativadas, o contrato é encerrado e o registro é marcado com uma data. É a etapa do ciclo de vida que com mais frequência é pulada, porque os relacionamentos geralmente terminam sem alarde e ninguém é responsável por esse momento.
O fim de um relacionamento é onde os dados ficam para trás. Um ex-fornecedor ainda guarda uma cópia, ainda tem uma conta de serviço no seu diretório, ainda tem um webhook apontando para os seus sistemas, e ninguém percebe até que uma auditoria examine uma amostra de fornecedores desligados ou que uma violação nesse fornecedor exponha dados que você pensava terem sido destruídos dois anos antes.
- Risco no desligamento de fornecedores
-
O risco no desligamento de fornecedores é importante porque acessos órfãos e dados retidos representam uma exposição contínua que não gera nenhum valor de negócio. A chave de API que permaneceu ativa após o encerramento do contrato é uma credencial que pode ser usada por um atacante que a obtenha, seja pelos sistemas do antigo fornecedor, seja pelos dispositivos do ex-funcionário.
O risco no desligamento de fornecedores é relevante porque acessos órfãos e dados retidos representam uma exposição contínua que não gera nenhum valor para o negócio.
- Risco no desligamento de fornecedores: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias verbais: processo e prazo de devolução e exclusão de dados; capacidade de exclusão certificada, com evidências de auditoria; inventário de dados ao final do contrato.
- Barreiras de segurança na homologação de fornecedores
-
As barreiras de segurança na homologação de fornecedores são relevantes porque o risco que um fornecedor representa não espera a conclusão da avaliação: ele está presente desde o momento em que o acesso é concedido. Um fornecedor não avaliado com acesso a dados de produção representa o mesmo risco que um fornecedor avaliado com fragilidades de controle identificadas.
As barreiras de segurança na homologação de fornecedores são relevantes porque o risco que um fornecedor representa não espera a conclusão da avaliação: ele está presente desde o momento em que o acesso é concedido.
- Controles de segurança no onboarding de fornecedores: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias: fluxo de homologação com ponto de verificação de aprovação de TPRM; índice de conformidade com a barreira como métrica do programa; a um fornecedor que confirme a maturidade do programa de TPRM deve-se perguntar se as suas próprias avaliações de fornecedores são concluídas antes da concessão do acesso. O valor da barreira está inteiramente no seu momento. Uma avaliação após o acesso não é uma barreira, é uma revisão retrospectiva.
- Atrasos no onboarding e no desligamento de fornecedores
-
Os atrasos na concessão e na revogação de acessos de fornecedores são as defasagens entre o momento em que o acesso deveria ser criado ou removido e o momento em que isso de fato acontece.
Os riscos de tempo na concessão e na revogação de acessos são relevantes para TPRM porque representam os modos de falha práticos de processos de governança de acessos que estão corretos no desenho, mas mal calibrados na execução.
- Atrasos na concessão e na revogação de acessos de fornecedores: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias: SLA de notificação de desligamento, ou seja, o tempo máximo entre o desligamento e a notificação ao cliente; confirmação do momento da remoção do acesso, acionada por evento ou agendada; dados de tempo de conclusão da integração, médio e máximo, desde a indicação até o acesso.
- Risco de contribuição em código aberto do fornecedor
-
O risco de contribuição em código aberto é relevante para TPRM porque as bibliotecas de código aberto sobre as quais o software do fornecedor é construído são mantidas por colaboradores humanos cujas motivações podem mudar, e porque o modelo de confiança que torna o desenvolvimento de código aberto eficiente é também o modelo de confiança que os atacantes da cadeia de suprimentos visam especificamente.
O risco de contribuição em código aberto é relevante para TPRM porque as bibliotecas de código aberto sobre as quais o software do fornecedor é construído são mantidas por colaboradores humanos cujas motivações podem mudar, e porque o modelo de confiança que torna o desenvolvimento de código aberto eficiente é também o modelo de confiança que os atacantes da cadeia de suprimentos visam especificamente.
- Risco das contribuições de fornecedores para código aberto: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias: consciência de ataques no estilo do XZ Utils no modelo de segurança da cadeia de suprimentos; a um fornecedor que confirme a gestão de dependências de código aberto deve-se perguntar sobre o monitoramento de riscos de colaboradores. A gestão de versões de dependências cobre qual pacote é usado. O monitoramento de colaboradores cobre quem é considerado confiável para modificar esse pacote.
- Riscos da adoção de autenticação sem senha pelo fornecedor
-
A autenticação sem senha substitui o segredo compartilhado (a senha) por uma credencial criptográfica, como uma chave de acesso, uma chave de segurança física ou um certificado, que comprova a identidade por meio de uma chave privada que nunca sai do dispositivo de autenticação.
Os riscos da adoção de autenticação sem senha são relevantes para TPRM porque anúncios de autenticação sem senha são cada vez mais usados como evidência de segurança avançada de autenticação nas avaliações de fornecedores, e a distância entre o anúncio da implantação e a migração completa raramente é divulgada.
- Riscos da adoção de autenticação sem senha pelo fornecedor: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias verbais: percentual de cobertura sem senha, comparando o total de eventos de autenticação com os migrados; status da migração dos caminhos de infraestrutura (VPN, SSH, banco de dados); roteiro de migração dos caminhos restantes, com cronograma.
- A realidade da frequência de correções dos fornecedores
-
A realidade da cadência de correções é relevante porque o software que a sua empresa implanta continua acumulando risco de vulnerabilidades entre a avaliação inicial e a próxima revisão planejada do fornecedor. Um fornecedor que aplica correções de forma lenta ou incompleta é um fornecedor cujo software se torna progressivamente mais vulnerável com o tempo.
A realidade da cadência de correções é relevante porque o software que a sua empresa implanta continua acumulando risco de vulnerabilidades entre a avaliação inicial e a próxima revisão planejada do fornecedor.
- A realidade da cadência de correções do fornecedor: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias verbais: dados históricos de prazos de correção, comparando a publicação do CVE com a liberação da correção; lista de CVEs críticas não corrigidas, com cronograma de remediação; frequência média de correção por severidade.
- SLAs de correção dos fornecedores versus a realidade
-
A velocidade de correção é a métrica operacional que determina por quanto tempo os dados da sua organização ficam expostos por meio de vulnerabilidades conhecidas em aplicações de fornecedores. Não é um indicador teórico de risco: é um cálculo de calendário.
a velocidade de correção é a métrica operacional que determina por quanto tempo os dados da sua organização ficam expostos por meio de vulnerabilidades conhecidas em aplicações de fornecedores.
- SLAs de correção do fornecedor versus a realidade: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias verbais: dados reais de tempo de correção das últimas quatro a seis CVEs críticas que afetaram a aplicação do fornecedor, com números específicos, e não declarações de política; documentação do processo de notificação ao cliente sobre CVEs críticas, com prazo, canal e compromisso de orientação provisória; documentação do processo de exceções, com dados de frequência, indicando com que frequência são concedidas exceções ao SLA e a transparência oferecida aos clientes quando isso ocorre.
- Avaliações de privacidade de fornecedores
-
Uma avaliação de privacidade de fornecedores pergunta quais dados pessoais o fornecedor tratará, com qual finalidade, com qual base legal, para onde irão, por quanto tempo serão mantidos, quem mais terá contato com eles e o que acontecerá com eles quando o relacionamento terminar. É um conjunto de perguntas diferente de uma avaliação de segurança, e um fornecedor pode ser aprovado plenamente em uma e reprovado na outra.
os questionários de segurança cobrem os controles e ignoram completamente a finalidade. Um fornecedor perfeitamente seguro que usa dados de clientes para treinar os próprios modelos, os retém indefinidamente e os transfere para três países sem nenhum mecanismo passaria em uma revisão de segurança sem um único achado.
- Frequência de reavaliação de fornecedores
-
A frequência de reavaliação de fornecedores é a cadência com que uma relação com um fornecedor recebe uma avaliação formal de segurança: a análise aprofundada periódica que confirma a postura de segurança do fornecedor, identifica mudanças nos controles e atualiza a classificação de risco da relação.
A frequência de reavaliação de fornecedores é relevante para TPRM porque a frequência da avaliação formal deve refletir o perfil de risco atual do relacionamento, que muda à medida que o fornecedor e o relacionamento evoluem.
- Frequência de reavaliação de fornecedores: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias: volume atual de tratamento de dados comparado ao da data da última avaliação; incidentes de segurança que afetaram outros clientes desde a última avaliação; mudanças materiais de infraestrutura, como novas regiões de nuvem e novas integrações de sistemas.
- Vazamentos de dados nos relatórios de fornecedores
-
O reporte de fornecedores, ou seja, a entrega de relatórios analíticos, painéis, exportações de dados e resumos de inteligência de negócios a clientes ou partes interessadas internas, é uma atividade de transferência de dados que frequentemente não é governada com o mesmo rigor que outras formas de acesso a dados. Relatórios contêm dados.
Os vazamentos de dados em relatórios de fornecedores são relevantes para TPRM porque os relatórios são um dos fluxos contínuos de dados de maior volume na maioria das relações com fornecedores (transferências semanais ou mensais de dados de clientes para destinatários externos) e quase nunca são avaliados com o rigor aplicado a outras transferências de dados de volume e sensibilidade equivalentes.
- Vazamentos de dados em relatórios de fornecedores: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias verbais: confirmação do conteúdo dos relatórios, indicando se são apenas agregados ou se os registros subjacentes são acessíveis; histórico de revisão da lista de distribuição, com confirmação da autorização dos destinatários atuais; descrição do mecanismo de entrega, criptografado ou em texto claro.
- Testes de resiliência de fornecedores e exercícios de mesa
-
O teste de resiliência de fornecedores é relevante porque a resiliência real da empresa a interrupções de fornecedores é determinada pela exequibilidade dos seus planos de contingência, e não pela existência deles. Um BCP bem documentado que não pode ser executado no cenário de interrupção que descreve oferece uma falsa garantia.
O teste de resiliência de fornecedores é relevante porque a resiliência real da empresa a interrupções de fornecedores é determinada pela exequibilidade dos seus planos de contingência, e não pela existência deles.
- Testes de resiliência e exercícios de mesa com fornecedores: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias verbais: registros do exercício de mesa mais recente para cenários de interrupção de fornecedores; tempo de recuperação testado versus o RTO projetado; atualizações do BCP motivadas pelos achados do exercício.
- Validação das respostas dos fornecedores
-
A validação da resposta do fornecedor é o processo do cliente para verificar de forma independente que a resposta a incidentes de um fornecedor alcançou uma remediação completa e duradoura: não apenas a erradicação das ameaças identificadas, mas a confiança de que não resta nenhuma presença residual do atacante no ambiente do fornecedor.
a validação das respostas dos fornecedores é importante para TPRM porque, quando o cliente retoma o compartilhamento de dados com um fornecedor após um relatório de remediação, volta a expor seus dados a qualquer presença residual do atacante que a remediação não tenha erradicado.
- Validação da resposta do fornecedor: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias: compromisso de compartilhamento de IOC, ou seja, IOCs da investigação fornecidos ao cliente; métricas de monitoramento reforçado durante o período de monitoramento; disposição para contratar validação independente em violações significativas.
- Agregação de riscos de fornecedores
-
A agregação de riscos de fornecedores é a análise das exposições a risco no nível da carteira que surgem da combinação de relacionamentos com fornecedores avaliados individualmente, especificamente os riscos correlacionados criados por dependências de infraestrutura compartilhadas, acesso compartilhado a dados e caminhos operacionais compartilhados que fazem com que vários fornecedores de baixo risco individual se torn
A agregação de riscos de fornecedores é relevante para TPRM porque conselhos e reguladores esperam cada vez mais que as organizações compreendam sua exposição agregada ao risco proveniente das relações com fornecedores: não apenas a distribuição das pontuações de risco individuais, mas os riscos de concentração criados por dependências compartilhadas.
- Agregação de riscos de fornecedores: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias: divulgação do principal provedor de infraestrutura de nuvem; plano de continuidade de negócios para eventos de indisponibilidade do provedor de infraestrutura; infraestrutura alternativa ou capacidade de failover.
- Alinhamento do apetite a risco de fornecedores
-
O alinhamento ao apetite a risco é importante porque aceitações de risco que violam o apetite a risco declarado da empresa criam uma lacuna entre a postura de risco que o conselho e a alta liderança acreditam que a empresa aceitou e a postura de risco que as decisões operacionais de fato criaram.
o alinhamento ao apetite a risco é importante porque aceitações de risco que violam o apetite a risco declarado da empresa criam uma lacuna entre a postura de risco que o conselho e a alta liderança acreditam que a empresa aceitou e a postura de risco que as decisões operacionais de fato criaram.
- Alinhamento do apetite a risco de fornecedores: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias: confirmação da implementação dos controles mínimos; prazo para quaisquer mínimos não implementados; aceitação dos requisitos básicos de segurança sem barreira de custo.
- Precisão do registro de riscos de fornecedores
-
A precisão do registro de riscos é relevante porque as decisões de risco da liderança (para onde direcionar os recursos de remediação, quais fornecedores escalar ao conselho, quais relacionamentos revisar) são tomadas com base nos dados do registro. Um registro impreciso produz uma priorização de riscos imprecisa.
a precisão do registro de riscos é importante porque as decisões de risco da liderança (para onde direcionar recursos de remediação, quais fornecedores escalar ao conselho, quais relacionamentos revisar) são tomadas com base nos dados do registro.
- Precisão do registro de riscos de fornecedores: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias verbais: documentação do processo de atualização do registro e de seus gatilhos; um fornecedor que confirma ter um registro de riscos abrangente deve ser questionado sobre como ele é mantido atualizado. O valor do registro está na sua precisão. O processo de atualização é o mecanismo que mantém essa precisão entre as revisões formais.
- Programas de divulgação de segurança dos fornecedores
-
Os programas de divulgação de segurança dos fornecedores são relevantes para TPRM porque determinam a rapidez com que vulnerabilidades no software do fornecedor são descobertas, remediadas e comunicadas aos clientes.
Os programas de divulgação de segurança dos fornecedores são relevantes para TPRM porque determinam a rapidez com que vulnerabilidades no software do fornecedor são descobertas, remediadas e comunicadas aos clientes.
- Programas de divulgação de segurança dos fornecedores: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias verbais: dados de cumprimento dos prazos de correção para divulgações críticas; processo e prazo de notificação prévia aos clientes; escopo do programa de divulgação e informações de contato.
- Fadiga dos fornecedores com questionários de segurança
-
A fadiga com questionários é relevante porque compromete a qualidade da inteligência que os questionários deveriam gerar. Fornecedores que preenchem grandes volumes de questionários de clientes respondem de maneira a minimizar o tempo de preenchimento, e não de maneira a oferecer uma visão real de segurança.
A fadiga com questionários é relevante porque compromete a qualidade da inteligência que os questionários deveriam gerar.
- Fadiga de questionários de segurança de fornecedores: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias: estrutura de questionário padronizado preenchida (SIG, CAIQ), se disponível; relatório SOC 2 para os domínios de controle relevantes; perfil de segurança do fornecedor em plataforma padronizada, se mantido.
- Lacunas de escopo nos testes de segurança de fornecedores
-
As lacunas de escopo nos testes de segurança são as partes da superfície de ataque de uma aplicação que ficam excluídas dos testes de segurança, seja por decisões deliberadas de limitação de escopo, seja por falha em atualizar o escopo à medida que a aplicação evolui, seja pela exclusão implícita de componentes que nunca foram considerados para inclusão.
as lacunas no escopo dos testes de segurança são o problema de validade mais fundamental na avaliação da segurança de aplicações de fornecedores, mais fundamental do que a metodologia de teste, a habilidade do testador ou a remediação dos achados.
- Lacunas de escopo nos testes de segurança de fornecedores: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias verbais: documentação do escopo do teste de intrusão, com a definição real do escopo, e não o sumário executivo; confirmação explícita de que os componentes de integração com clientes estão incluídos no escopo testado; inventário completo da superfície de API, com o mapeamento da cobertura do escopo, indicando quais APIs são testadas e quais não são.
- Integração de SOC com o fornecedor
-
A integração de SOC com o fornecedor é a coordenação operacional entre as equipes de operações de segurança do fornecedor e do cliente, especificamente os mecanismos de comunicação em tempo real durante incidentes compartilhados, de escalonamento de detecções relevantes para o ambiente da outra parte e de correlação de eventos entre os dois ambientes para identificar ataques
A integração de SOC com o fornecedor é relevante para TPRM porque atacantes sofisticados da cadeia de suprimentos entendem e exploram as lacunas investigativas entre equipes de operações de segurança independentes.
- Integração de SOC com o fornecedor: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias: a um fornecedor com um SOC maduro deve-se perguntar o que aciona uma ligação direta ao SOC do cliente, em vez de concluir primeiro uma investigação interna. A maturidade do SOC é a capacidade. O gatilho de escalonamento e o contato direto são a integração.
- Riscos de integração de SSO de fornecedores
-
O logon único é um mecanismo de federação de autenticação: permite que os usuários se autentiquem em vários sistemas usando um único conjunto de credenciais gerenciado por um provedor de identidade central.
Os riscos de integração de SSO de fornecedores são relevantes para TPRM porque o SSO é cada vez mais apresentado como controle de segurança nas avaliações de fornecedores, com a confirmação da integração de SSO servindo como evidência de que o acesso é governado de forma centralizada.
- Riscos de integração de SSO de fornecedores: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias verbais: documentação do escopo da autenticação, com os grupos ou critérios que a restringem; mapeamento de atributos SAML para a definição de funções, com os atributos usados e a lógica de atribuição de funções; nível de acesso padrão para usuários autenticados sem atributos de função, confirmando o comportamento de contingência.
- Limitações da telemetria do fornecedor
-
As limitações de telemetria são as lacunas no volume, no detalhamento e na cobertura dos dados relevantes para a segurança aos quais a infraestrutura de monitoramento de um fornecedor tem acesso, lacunas que restringem o que o SIEM consegue detectar, independentemente do grau de maturidade das regras de detecção e das operações de SOC.
As limitações da telemetria do fornecedor são relevantes para TPRM porque criam lacunas de visibilidade dos caminhos de ataque que são invisíveis para o SOC do fornecedor e para a avaliação de TPRM do cliente.
- Limitações da telemetria do fornecedor: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias: nível de registro em log por sistema de origem para os sistemas relevantes ao caminho de ataque; status de integração ao SIEM de cada fonte; a um fornecedor que confirme cobertura abrangente de SIEM deve-se solicitar o inventário de telemetria dos sistemas específicos que estão no caminho de ataque até os dados do cliente. A cobertura de SIEM descreve o que está conectado. A qualidade da telemetria descreve o que essa conexão fornece.
- Visibilidade de ameaças do fornecedor
-
A visibilidade de ameaças do fornecedor é a capacidade do cliente de ver a atividade relevante para a segurança no ambiente do fornecedor que é diretamente relevante para a segurança dos dados e da integração do cliente, especificamente a atividade que, combinada com os dados de monitoramento do próprio cliente, revelaria um ataque entre fronteiras que o moni
a visibilidade das ameaças aos fornecedores é importante para TPRM porque os ataques mais sofisticados à cadeia de suprimentos visam deliberadamente as junções entre ambientes de monitoramento, usando a integração entre fornecedor e cliente ao mesmo tempo como caminho de ataque e como técnica para escapar da detecção.
- Visibilidade das ameaças aos fornecedores: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias verbais: disposição para compartilhar dados de monitoramento das integrações; métricas de atividade API disponíveis para compartilhamento; protocolo de compartilhamento de alertas de anomalias nas integrações.
- Classificação de fornecedores
-
A classificação por níveis ordena os fornecedores pelo dano que poderiam causar, para que o esforço de avaliação acompanhe a exposição, em vez de ser distribuído igualmente por uma lista em que a maioria dos itens não poderia prejudicar você. Dois ou três níveis, definidos por testes objetivos: o fornecedor mantém dados pessoais ou confidenciais, tem acesso ao seu ambiente e está no caminho crítico de algo de que os clientes dependem?
Um programa que avalia quatrocentos fornecedores com a mesma profundidade não avalia bem nenhum deles. A classificação por níveis é o mecanismo que permite dedicar quatro horas à ferramenta de suporte que guarda anexos de chamados repletos de dados pessoais e dez minutos ao fornecedor de plantas, sem que ninguém precise discutir isso a cada vez.
- Imprecisões na classificação de fornecedores por nível
-
A classificação de fornecedores por nível é o processo de categorizar as relações com fornecedores por nível de risco para aplicar profundidade de avaliação, intensidade de monitoramento e requisitos de governança proporcionais.
As imprecisões na classificação de fornecedores por nível são relevantes para TPRM porque toda a estrutura de gestão de riscos do programa depende de os níveis estarem corretos.
- Imprecisões na classificação de fornecedores por nível: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias: descrição completa de todos os serviços e integrações fornecidos pela entidade fornecedora e por subsidiárias relacionadas; divulgação de quaisquer aquisições que tenham afetado o relacionamento; confirmação do cruzamento com o inventário de integrações de TI.
- Chaves de criptografia gerenciadas pelo fornecedor
-
A gestão de chaves de criptografia é a disciplina de controlar quem pode gerar, acessar, usar, rotacionar e revogar as chaves criptográficas que protegem os dados. Criptografia sem gestão de chaves é como trancar um cofre e deixar a combinação escrita em cima dele: o mecanismo é sólido, mas o controle está ausente.
no contexto de risco de terceiros, a governança das chaves de criptografia determina se a criptografia é um controle significativo ou apenas um item marcado para fins de conformidade.
- Chaves de criptografia gerenciadas pelo fornecedor: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias: uma descrição clara do modelo de gestão de chaves, ou seja, não 'usamos criptografia', mas o modelo específico e quem controla as chaves; um processo definido de revogação de chaves vinculado ao término do contrato, com prazo específico; disponibilidade do log de auditoria de uso das chaves, ou seja, evidência de que as operações de descriptografia são registradas e passíveis de revisão.
- VEX, Vulnerability Exploitability eXchange
-
VEX é relevante para TPRM porque, sem ele, as empresas ou fazem a triagem manual de longas listas de vulnerabilidades, um processo caro e lento, ou aplicam uma aceitação de riscos generalizada a vulnerabilidades não sinalizadas que podem ou não ser exploráveis.
VEX é relevante para TPRM porque, sem ele, as empresas ou fazem a triagem manual de longas listas de vulnerabilidades, um processo caro e lento, ou aplicam uma aceitação de riscos generalizada a vulnerabilidades não sinalizadas que podem ou não ser exploráveis.
- VEX, Vulnerability Exploitability eXchange: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias: documento VEX no formato OpenVEX ou CycloneDX VEX; justificativas para as classificações Não Afetado; lista de classificações Afetado com prazo de remediação.
- VPN versus acesso à rede de confiança zero
-
A diferença entre VPN e ZTNA é importante para TPRM porque a confirmação do acesso por VPN oferece garantia quanto ao transporte criptografado e à autenticação, sem tratar do escopo do acesso à rede que a VPN proporciona.
A diferença entre VPN e ZTNA é importante para TPRM porque a confirmação do acesso por VPN oferece garantia quanto ao transporte criptografado e à autenticação, sem tratar do escopo do acesso à rede que a VPN proporciona.
- VPN versus acesso à rede de confiança zero: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias: escopo de acesso da VPN, ou seja, faixas de rede versus requisitos reais; número de usuários nos grupos de VPN versus os requisitos de acesso legítimos; adoção ou roteiro de ZTNA para o acesso de fornecedores.
- Intercâmbio de explorabilidade de vulnerabilidades VEX
-
Declaração que informa, por vulnerabilidade e por produto, se ele é afetado, não afetado, corrigido ou está sob investigação, com uma justificativa.
Uma linha de VEX responde aos catorze chamados de clientes que uma única vulnerabilidade divulgada publicamente geraria de outra forma.
Ensinado em CYB-201 · Veja também: Lista de materiais de software, Gestão de vulnerabilidades
- Gestão de vulnerabilidades
-
O programa que identifica, prioriza, corrige e comprova o encerramento de fragilidades em todo o parque tecnológico.
A cobertura vem antes do volume, e a exposição antes da severidade: uma meta de sete dias é crível quando a fila tem uma dúzia de itens, não noventa.
Ensinado em CYB-220 · Veja também: Lista de materiais de software, Inteligência de ameaças
- SLAs de gestão de vulnerabilidades
-
Um SLA de remediação atribui uma janela a cada faixa de prioridade: sistemas expostos à internet com exploração conhecida, sete dias; todo o restante com correção disponível, trinta; sistemas aguardando desativação, acompanhados separadamente com uma data. As faixas são definidas pela exposição, pela explorabilidade e pelo valor do ativo, com a pontuação de severidade do scanner como um insumo, e não como a resposta.
Um SLA descumprido todos os meses ensina todos a ignorar SLAs. Uma empresa cujo scanner gerava noventa vulnerabilidades críticas por mês contra uma janela de sete dias descumpria o prazo de forma constante, o que tornava a métrica sem sentido. Repriorizar pela exposição à internet e pela exploração conhecida deixou cerca de uma dúzia de itens por mês na faixa de sete dias, o que era alcançável, e o SLA se tornou real.
W
- Mitos sobre a confiança em firewalls de aplicações web
-
A presença de WAF é um dos controles de segurança de aplicações mais citados nas respostas de fornecedores a questionários: é visível, é mensurável (bloqueios por dia, ataques mitigados) e oferece métricas de aparência impressionante que sugerem um engajamento ativo em segurança.
A presença de WAF é um dos controles de segurança de aplicações mais citados nas respostas de fornecedores a questionários: é visível, é mensurável (bloqueios por dia, ataques mitigados) e oferece métricas de aparência impressionante que sugerem um engajamento ativo em segurança.
- Mitos sobre a confiança em firewalls de aplicações web: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias verbais: confirmação do acompanhamento dos controles compensatórios, com as vulnerabilidades cobertas por WAF acompanhadas separadamente das corrigidas e com prazos de revisão definidos; confirmação do modo de bloqueio do WAF, com o escopo de cobertura da superfície da aplicação; processo de gestão de falsos positivos, confirmando que as regras não foram desativadas sistematicamente para reduzir o atrito operacional.
- O que DevSecOps realmente significa versus o que os fornecedores dizem que significa
-
DevSecOps: confirmado. Varreduras de segurança: em execução.
A lacuna de DevSecOps é relevante para TPRM porque confirmar que um fornecedor executa ferramentas de DevSecOps sem avaliar se essas ferramentas impõem algo oferece garantia de segurança para um teatro de segurança, e não para uma prática de segurança.
- O que DevSecOps realmente significa versus o que os fornecedores dizem que significa: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias: política de aplicação para falhas em varreduras de segurança, ou seja, o que bloqueia a implantação; mapa de cobertura das varreduras de segurança, com frameworks, ecossistemas e camadas de imagem; fluxo de remediação de achados com responsáveis e SLA.
- O que é SLSA e por que seus fornecedores deveriam se importar
-
Conformidade com SLSA: confirmada. Nível SLSA: 1.
SLSA é relevante para TPRM porque os ataques à cadeia de suprimentos de software, especificamente o comprometimento de pipelines de build e da distribuição de artefatos, estão entre os vetores de ataque de maior impacto e mais difíceis de detectar atualmente explorados.
- O que é SLSA e por que seus fornecedores deveriam se importar: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias: nível específico de SLSA, e não conformidade binária; atestação de proveniência de uma versão recente; método de verificação da atestação.
- Segurança de redes sem fio e risco de fornecedores
-
A segurança de redes sem fio é relevante para TPRM porque determina o perímetro físico da rede: a que distância um atacante precisa estar para acessar qualquer parte dela.
A segurança de redes sem fio é relevante para TPRM porque determina o perímetro físico da rede: a que distância um atacante precisa estar para acessar qualquer parte dela.
- Segurança de redes sem fio e risco de fornecedores: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena pedir, em vez de garantias verbais: método de autenticação da rede sem fio corporativa, 802.1X ou senha compartilhada; cronograma de rotação das credenciais de visitantes e data da última rotação; implementação de portal para visitantes, se aplicável.
Z
- Arquitetura de confiança zero, o que ela realmente significa
-
A arquitetura de confiança zero é relevante para TPRM porque fornecedores que afirmam ter confiança zero sem a dimensão de segmentação de rede têm uma rede plana que maximiza o potencial de movimentação lateral de qualquer atacante que comprometa qualquer usuário ou sistema interno.
A arquitetura de confiança zero é relevante para TPRM porque fornecedores que afirmam ter confiança zero sem a dimensão de segmentação de rede têm uma rede plana que maximiza o potencial de movimentação lateral de qualquer atacante que comprometa qualquer usuário ou sistema interno.
- Arquitetura de confiança zero, o que ela realmente significa: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias: descrição da segmentação de rede, ou seja, quais zonas estão isoladas de quais; implementação de ZTNA ou de controle de acesso à rede equivalente; verificação da postura do dispositivo no momento do acesso.
- Confiança zero para cadeias de suprimentos de software
-
A confiança zero para cadeias de suprimentos de software é relevante para TPRM porque as melhorias de segurança que a confiança zero proporciona em contextos de rede se aplicam igualmente à cadeia de suprimentos de software, e as empresas que investiram em arquitetura de rede de confiança zero enquanto mantêm suas cadeias de suprimentos de software baseadas em confiança implícita criaram uma assimetria em q
a confiança zero para cadeias de suprimentos de software é importante para TPRM porque as melhorias de segurança que a confiança zero proporciona em contextos de rede se aplicam igualmente à cadeia de suprimentos de software, e as empresas que investiram em arquitetura de rede de confiança zero enquanto mantinham suas cadeias de suprimentos de software sob confiança implícita criaram uma assimetria em qu
- Confiança zero para cadeias de suprimentos de software: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias: verificação da identidade do publicador além da presença no registro; minimização de credenciais por etapa nos agentes de build; descrição da arquitetura de cadeia de suprimentos de confiança zero.
- Modelo de maturidade de confiança zero para avaliação de TPRM
-
A avaliação de maturidade de confiança zero é relevante para TPRM porque o valor de segurança do programa de confiança zero de um fornecedor é determinado pela profundidade real de sua implementação nas cinco dimensões, e não pelo rótulo que ele lhe atribui.
A avaliação de maturidade de confiança zero é relevante para TPRM porque o valor de segurança do programa de confiança zero de um fornecedor é determinado pela profundidade real de sua implementação nas cinco dimensões, e não pelo rótulo que ele lhe atribui.
- Modelo de maturidade de confiança zero para avaliação de TPRM: as evidências
-
Ao questionar um fornecedor sobre isso, estes são os artefatos que vale a pena solicitar, em vez de garantias: evidências de cada estágio de maturidade declarado; estágio atual versus estágio-alvo por pilar; a um fornecedor que confirme ter confiança zero deve-se solicitar as classificações de maturidade por pilar. A confirmação de confiança zero descreve o rótulo. A maturidade por pilar, com evidências, descreve a profundidade da implementação. Ambas são necessárias para comparar os programas de confiança zero dos fornecedores.
Mantido pela associação. Cada termo aqui é um resumo; o curso indicado ao lado dele é onde a prática é ensinada.