Um fornecedor de tecnologia financeira tinha uma política de senhas abrangente, aprovada pelo conselho, revisada regularmente e alinhada às recomendações da NIST SP 800-63B. A política especificava um comprimento mínimo de doze caracteres, requisitos de complexidade, proibição de senhas comuns e validade máxima de noventa dias para contas privilegiadas. Durante uma avaliação técnica de segurança, os avaliadores testaram a configuração real da plataforma de identidade em relação à política. Encontraram o seguinte: o Azure AD corporativo estava configurado com mínimo de oito caracteres, pois a configuração não havia sido atualizada quando a política foi revisada dois anos antes. A complexidade era imposta no Azure AD, mas não nos três sistemas de autenticação de aplicações legadas que ainda mantinham seus próprios repositórios de usuários. A rotação de noventa dias se aplicava às contas humanas no Azure AD, mas as contas de serviço do mesmo locatário não tinham nenhuma exigência de rotação configurada. As contas de serviço das aplicações legadas usavam senhas armazenadas em um documento compartilhado de credenciais que não era atualizado havia catorze meses. Cada uma dessas lacunas tinha uma causa comum: a política havia sido atualizada para refletir as boas práticas de segurança, mas as configurações técnicas que impunham a política não haviam sido atualizadas na mesma medida. A política descrevia o que deveria ser imposto. As configurações descreviam o que era imposto. Elas divergiam em todos os pontos medidos.
O que é, de fato, a lacuna entre política e aplicação?
Política versus aplicação é a lacuna entre os requisitos de segurança documentados (as normas, procedimentos e diretrizes que definem como os controles de segurança devem operar) e os mecanismos técnicos e operacionais que de fato implementam esses requisitos nos sistemas em funcionamento. As políticas são documentos normativos: especificam o que deve ser verdade. Configurações, parâmetros de sistema e procedimentos operacionais são mecanismos de implementação: determinam o que é verdade. Quando as políticas são atualizadas sem as atualizações correspondentes nos mecanismos de implementação, a política descreve um padrão de segurança aprimorado que o ambiente não impõe.
O atraso na atualização das políticas é a fonte mais comum de lacunas entre política e aplicação. As políticas são atualizadas por meio de processos de governança: ciclos de revisão, atualizações de estruturas, mudanças nas orientações regulatórias ou amadurecimento do programa de segurança. Esses processos produzem documentos de política atualizados que refletem com precisão requisitos de segurança aprimorados. As configurações técnicas que implementam esses requisitos (parâmetros de senha da plataforma de identidade, conjuntos de regras de firewall, configurações de criptografia, matrizes de controle de acesso) são atualizadas por processos de gestão de mudanças que exigem esforço de engenharia, testes e implantação. O processo de governança que produz documentos de política atualizados costuma ser mais rápido e consumir menos recursos do que o processo de engenharia que atualiza as configurações técnicas. A política avança para o novo padrão. A configuração fica para trás.
O problema das lacunas de cobertura agrava o atraso de atualização. Mesmo políticas aplicadas de forma consistente nos sistemas principais frequentemente têm lacunas de cobertura nos sistemas secundários: aplicações legadas com autenticação independente, sistemas adquiridos ainda não integrados ao padrão corporativo, ambientes de desenvolvimento operados com configurações diferentes das de produção e conjuntos de contas de serviço regidos por processos diferentes dos que regem as contas humanas. Uma política de senhas que se aplica ao provedor de identidade corporativo se aplica às contas gerenciadas por esse provedor. Ela não se aplica às contas em sistemas fora do escopo desse provedor, a menos que esses sistemas sejam explicitamente regidos por configurações correspondentes.
- Política atualizada sem atualização da configuração: padrão revisado da política não refletido nas configurações dos sistemas
- Lacunas de configuração em sistemas legados: a política se aplica aos sistemas principais, enquanto as aplicações legadas mantêm configurações separadas
- Divergência de política nas contas de serviço: a política das contas humanas não é aplicada ao conjunto de contas de serviço
- Nenhum mapeamento entre política e configuração: políticas não vinculadas explicitamente às configurações que as implementam
- Auditoria de configuração não realizada: configurações reais dos sistemas não comparadas com os requisitos da política
Por que isso importa
Política versus aplicação é importante para TPRM porque as 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 impõem. Um fornecedor com uma política de senhas robusta e configurações de senha fracas apresenta uma postura de segurança diferente da que a confirmação da política sugere. A segurança real é determinada pelo que a configuração impõe, não pelo que a política exige.
A dimensão regulatória é explícita e cada vez mais fiscalizada. Os reguladores que examinam fornecedores que atuam em setores regulados testarão a configuração em relação à política, perguntando não apenas “o que sua política exige”, mas “o que seu sistema realmente impõe, e vocês conseguem demonstrar que a configuração corresponde à exigência da política?”. Uma diferença entre as duas (doze caracteres na política, oito na configuração) é uma constatação que a força da política não atenua. O controle é a configuração, não o documento.
Onde a maioria das equipes erra
A falha mais recorrente é aceitar a documentação de políticas como evidência do padrão de segurança em vigor. As políticas descrevem requisitos. As configurações implementam requisitos. São artefatos diferentes, que exigem solicitações de evidência diferentes. Um documento de política de senhas confirma o que deveria ser imposto. Uma exportação de configuração ou um relatório de conformidade confirma o que é imposto.
- Aceitar documentação de políticas como evidência de implementação
- Auditoria de configuração não incluída na avaliação
- Cobertura dos sistemas legados não avaliada: configuração do sistema principal confirmada, sistemas legados não avaliados
- Configurações das contas de serviço não avaliadas separadamente
- Mapeamento entre política e configuração não revisado: nenhuma verificação de que as políticas estão vinculadas a configurações específicas que as implementam
Como é uma boa prática
Programas maduros de governança de políticas mantêm mapeamentos explícitos entre os requisitos da política e as configurações que os implementam, realizam auditorias regulares de configuração para verificar o alinhamento e têm processos de gestão de mudanças que conectam as atualizações de políticas às atualizações de configuração.
- Mapeamento entre política e configuração: documentação explícita de quais configurações implementam quais requisitos da política
- Periodicidade da auditoria de configuração: comparação regular das configurações reais com os requisitos da política
- A atualização da política aciona a revisão das configurações: mudanças na política geram tarefas de revisão e atualização das configurações
- Inventário das configurações dos sistemas legados: configurações de todos os sistemas sujeitos à política documentadas e auditadas periodicamente
- Avaliação da configuração das contas de serviço: configurações de senhas e credenciais das contas de serviço avaliadas separadamente das contas humanas
Ferramentas
Conformidade de configuração: AWS Config, Azure Policy, verificadores de benchmarks do CIS
As ferramentas de conformidade de configuração comparam continuamente as configurações dos sistemas implantados com os requisitos de política definidos, sinalizando as configurações que não atendem aos padrões da política. Os verificadores de benchmarks do CIS avaliam as configurações dos sistemas em relação aos padrões de proteção do Center for Internet Security. Para profissionais de TPRM, perguntar se o fornecedor usa ferramentas de conformidade de configuração para verificar continuamente se as configurações dos sistemas correspondem aos requisitos da política é uma pergunta específica sobre o alinhamento entre política e aplicação.
Conformidade automatizada: Drata, Vanta
As plataformas de conformidade automatizada coletam evidências de configuração junto com a documentação das políticas, oferecendo o pareamento entre requisitos da política e verificação da configuração que a avaliação manual não consegue manter continuamente. Para profissionais de TPRM, pedir aos fornecedores os resultados da plataforma de conformidade que confirmam a conformidade da configuração, junto com a documentação da política, fornece tanto o padrão da política quanto a evidência de sua implementação.
Desafios de governança
O desafio de governança em política versus aplicação é a disciplina de gestão de mudanças necessária para manter as configurações alinhadas às políticas à medida que ambas evoluem. As revisões de políticas são iniciadas por processos de governança. As mudanças de configuração exigem esforço de engenharia. Os dois processos seguem cronogramas diferentes, com responsáveis diferentes, e, sem uma conexão explícita entre eles, a política avança enquanto as configurações ficam para trás.
- Solicitar evidências de configuração junto com a documentação da política: os parâmetros reais do sistema, não o documento de requisitos
- Pergunte sobre a cobertura dos sistemas legados: quais sistemas estão no escopo da política e quais têm configurações independentes
- Pergunte separadamente sobre a configuração das contas de serviço: as configurações de contas humanas e de máquina podem ser diferentes
- Pergunte quando a política foi atualizada pela última vez e quando as configurações foram auditadas pela última vez: o intervalo entre as duas datas é o indicador de defasagem
- Solicitar os resultados das ferramentas de conformidade, e não documentos de política, para os controles técnicos
Se você faz parte de uma equipe pequena
Para o seu fornecedor de maior risco, peça a configuração real de senhas da principal plataforma de identidade dele: não o documento de política, mas a exportação da configuração ou a captura de tela que mostra o comprimento mínimo de senha, os requisitos de complexidade e as configurações de rotação atualmente impostos. Em seguida, faça a mesma pergunta sobre a configuração das contas de serviço. Compare as duas com o documento de política. As diferenças entre eles são as lacunas de aplicação que a avaliação da política não revelou.
- Solicitar a configuração real de senhas: comprimento mínimo, complexidade e rotação tal como impostos
- Perguntar separadamente sobre as configurações de senhas e credenciais das contas de serviço
- Comparar as configurações com os requisitos da política
- Perguntar sobre as configurações de senha dos sistemas legados
O que exigir
Pergunte diretamente:
“Vocês podem fornecer a configuração de senhas atualmente imposta em sua principal plataforma de identidade, especificamente o comprimento mínimo, os requisitos de complexidade e as configurações de rotação tal como configurados no sistema, e não como especificados em sua política?”
“Sua política de senhas se aplica às contas de serviço da mesma forma que às contas humanas, e qual é a configuração atual de senhas das contas de serviço, incluindo a frequência de rotação?”
O que esperar como evidência
- Configuração da plataforma de identidade que mostra os requisitos de senha efetivamente impostos
- Configuração de senhas das contas de serviço documentada separadamente
- Inventário das configurações de senha dos sistemas legados
- Documentação do mapeamento entre política e configuração
Um fornecedor que apresenta uma política de senhas robusta deve ser solicitado a mostrar a configuração que a impõe. A política é a exigência. A configuração é a realidade. Uma diferença entre uma política de doze caracteres e uma configuração de oito caracteres não se resolve pela força da política.
Como comprovar
- Registros de evidências de configuração dos principais controles técnicos
- Registros de avaliação das lacunas entre política e configuração
- Registros de auditoria de configuração
- Avaliação da configuração das contas de serviço
Principal conclusão
A política rege o padrão. A configuração rege o comportamento. Elas podem divergir, e frequentemente divergem quando os processos de governança atualizam as políticas mais rápido do que os processos de engenharia atualizam as configurações. A política de doze caracteres com uma configuração de oito caracteres não é uma falha da política: a política está correta. É um atraso de configuração que o processo de política não gerou um mecanismo para corrigir. A evidência de uma política robusta é evidência de uma exigência robusta. A evidência da configuração que a implementa é evidência do padrão efetivamente imposto. Solicite as duas. Aceite a documentação da política como a especificação. Solicite a evidência de configuração como a implementação.