ISO 27001 Guest WiFi: Um Guia de Conformidade

ISO 27001 Guest WiFi: Um Guia de Conformidade Podcast Purple Technical Briefing — Roteiro do Episódio Duração aproximada: 10 minutos | Voz: Inglês britânico, tom de consultor sênior --- SEGMENTO 1: INTRODUÇÃO E CONTEXTO (aprox. 1 minuto) Bem-vindo ao Purple Technical Briefing. Sou o seu anfitrião no episódio de hoje, e vamos mergulhar em um tema que está na interseção entre operações de rede e governança de segurança da informação: guest WiFi e conformidade com a ISO 27001. Se você é um gerente de TI, um arquiteto de rede ou um auditor líder da ISO 27001 em um grupo hoteleiro, uma rede de varejo, um estádio ou uma organização do setor público, este episódio foi feito para você. Não vamos cobrir a ISO 27001 do zero — você já conhece a norma. O que faremos é fornecer um mapa preciso e prático de como a sua implantação de guest WiFi se encaixa no seu Sistema de Gestão de Segurança da Informação (SGSI), quais controles se aplicam, o que a sua avaliação de risco precisa documentar e, crucialmente, quais evidências você precisa apresentar quando o auditor chegar. O guest WiFi é uma daquelas áreas que as organizações subestimam constantemente do ponto de vista de conformidade. Parece um serviço básico — basta conectar alguns pontos de acesso, fornecer uma senha e pronto. Mas do ponto de vista do SGSI, trata-se de um ativo de informação ativo que afeta o limite da sua rede, os relacionamentos com seus fornecedores, as suas obrigações de proteção de dados e a sua exposição jurídica. Vamos analisar isso detalhadamente. --- SEGMENTO 2: ANÁLISE TÉCNICA DETALHADA (aprox. 5 minutos) Vamos começar com o mapeamento de controles. A ISO 27001:2022 reestruturou seus controles do Anexo A, e vários deles se aplicam diretamente ao guest WiFi. O grupo mais crítico está na seção de Controles Tecnológicos — que é a cláusula 8 do Anexo A. O Controle A.8.22 — Segregação de Redes — é o seu requisito fundamental. Este controle exige que grupos de serviços de informação, usuários e sistemas sejam segregados em redes. Para o guest WiFi, isso se traduz diretamente em isolamento de VLAN. A sua rede de convidados deve estar lógica e, quando apropriado, fisicamente separada da sua rede corporativa, do seu ambiente de processamento de pagamentos e de quaisquer segmentos de IoT ou tecnologia operacional. Se um auditor constatar que o tráfego de convidados pode alcançar compartilhamentos de arquivos internos ou interfaces de gerenciamento, isso constitui uma não conformidade clara em relação ao controle A.8.22. O Controle A.8.20 — Segurança de Redes — exige que as redes sejam gerenciadas e controladas para proteger as informações em sistemas e aplicativos. Para o guest WiFi, isso significa regras de firewall documentadas, listas de controle de acesso e uma política de segurança de rede que aborde explicitamente o segmento de convidados. Você precisa ser capaz de mostrar ao auditor um diagrama de rede atualizado com a VLAN de convidados claramente identificada e o conjunto de regras de firewall que determina o que esse segmento pode ou não acessar. O Controle A.8.21 — Segurança dos Serviços de Rede — aborda provedores de serviços de rede terceirizados. A maioria das organizações que operam WiFi para convidados utiliza um provedor de serviços gerenciados, uma plataforma de Captive Portal baseada em nuvem ou uma solução fornecida por um ISP. Cada uma dessas é uma relação com fornecedores que precisa ser governada. Você precisa de acordos de nível de serviço que incluam requisitos de segurança e de evidências de revisões periódicas de fornecedores. É aqui que as atestações SOC 2 Tipo II de fornecedores tornam-se genuinamente úteis — voltaremos a isso. O Controle A.8.15 — Registro de Eventos (Logging) — exige que os logs de eventos sejam produzidos, armazenados, protegidos e analisados. Para o WiFi para convidados, isso significa registrar eventos de conexão, tentativas de autenticação e dados de sessão. No entanto, há uma tensão aqui com a GDPR e os princípios de minimização de dados, particularmente no Reino Unido e na UE. Você precisa registrar o suficiente para satisfazer suas obrigações de monitoramento de segurança, mas não tanto que acabe retendo dados pessoais além do necessário. Sua política de registro deve abordar explicitamente o escopo do WiFi para convidados, definir períodos de retenção e documentar a base jurídica para quaisquer dados pessoais capturados. O Controle A.8.23 — Filtragem Web — exige que o acesso a sites externos seja gerenciado para proteger os sistemas contra infecções por malware e para evitar o acesso a recursos web não autorizados. Para o WiFi para convidados, isso normalmente significa implantar filtragem baseada em DNS ou um proxy web em nuvem que bloqueie domínios maliciosos conhecidos, infraestrutura de comando e controle e, dependendo do seu setor, categorias de conteúdo inadequado. Um operador de hotel que atende a um público familiar tem obrigações de filtragem diferentes de um centro de conferências que atende a delegados corporativos, mas ambos precisam de uma política documentada e de evidências de que a filtragem está ativa e sendo revisada. Mudando para os Controles Organizacionais — Anexo A, cláusula 5 — dois controles são particularmente relevantes. O Controle A.5.14 — Transferência de Informações — governa as regras, procedimentos e controles para a transferência de informações. Se os convidados estiverem usando sua rede para transferir arquivos, acessar serviços em nuvem ou realizar negócios, você precisa de uma Política de Uso Aceitável que seja apresentada a eles no momento da autenticação — normalmente por meio do Captive Portal — e aceita antes que o acesso seja concedido. Esse evento de aceitação precisa ser registrado como evidência. O Controle A.5.31 — Requisitos Legais, Estatutários, Regulatórios e Contratuais — exige que você identifique e documente todas as obrigações legais e regulatórias relevantes. Para o WiFi para convidados, isso inclui a GDPR ou a GDPR do Reino Unido se você estiver capturando dados pessoais na autenticação, o Investigatory Powers Act se você estiver no Reino Unido e puder ser obrigado a reter dados de comunicações, e regulamentações específicas do setor, como o PCI DSS, se a sua rede de convidados estiver no escopo de dados de titulares de cartões. Agora, a avaliação de riscos. A ISO 27001 é uma norma baseada em riscos, o que significa que você não pode simplesmente implementar controles e dar o trabalho por encerrado. Você precisa documentar uma avaliação de riscos formal para o ativo de WiFi de visitantes. Essa avaliação deve identificar ameaças — acesso não autorizado a sistemas internos, propagação de malware a partir de dispositivos de visitantes, interceptação de dados no meio sem fio, negação de serviço e danos à reputação decorrentes do uso indevido da sua rede. Para cada ameaça, você avalia a probabilidade e o impacto, determina o tratamento do risco — seja mitigar, aceitar, transferir ou evitar — e documenta o risco residual. A Declaração de Aplicabilidade deve fazer referência à avaliação de riscos do WiFi de visitantes como justificativa para a inclusão ou exclusão de controles específicos do Anexo A. Vamos falar sobre o WPA3 e os padrões de autenticação. As gerações de hardware WiFi IEEE 802.11ax e 802.11be suportam o WPA3, que oferece a Autenticação Simultânea de Iguais — SAE — substituindo o antigo handshake de Chave Pré-Compartilhada. Para uma rede de visitantes onde você usa uma senha compartilhada, o WPA3-Personal com SAE oferece sigilo de encaminhamento (forward secrecy), o que significa que mesmo se a senha for comprometida, o tráfego de sessões históricas não poderá ser descriptografado. Para implantações corporativas onde você deseja autenticação por usuário, o WPA3-Enterprise com IEEE 802.1X e EAP-TLS oferece autenticação baseada em certificados que se mapeia diretamente aos controles de gestão de identidade da ISO 27001. A escolha entre esses dois modelos depende da sua base de usuários e da sua tolerância à complexidade operacional. Agora, as atestações SOC 2 de fornecedores. Se você utiliza uma plataforma de WiFi de visitantes gerenciada na nuvem — e a maioria das organizações utiliza —, o relatório SOC 2 Tipo II desse fornecedor é uma peça crítica de evidência para a garantia de seus fornecedores. Um relatório SOC 2 Tipo II cobre os Critérios de Serviços de Confiança: Segurança, Disponibilidade, Integridade de Processamento, Confidencialidade e Privacidade, ao longo de um período de auditoria que normalmente varia de seis a doze meses. Ao construir seu arquivo de garantia de fornecedores da ISO 27001, o relatório SOC 2 Tipo II do fornecedor, combinado com um questionário de segurança do fornecedor preenchido e um acordo de processamento de dados, fornece um pacote de evidências defensável para o controle A.8.21. A Purple, por exemplo, possui alinhamento com o SOC 2 que apoia diretamente esse requisito de SGSI posterior — o que significa que você pode fazer referência à atestação deles em suas próprias evidências de auditoria, em vez de realizar uma avaliação de segurança completa e personalizada da plataforma. --- SEGMENTO 3: RECOMENDAÇÕES DE IMPLEMENTAÇÃO E ERROS COMUNS (aprox. 2 minutos) Deixe-me apresentar as quatro decisões de implementação que a maioria das organizações erra. Primeiro: desvio de escopo na avaliação de riscos. As organizações costumam definir o escopo do WiFi de visitantes de forma muito estreita — tratando-o como fora de escopo por ser apenas para visitantes — ou muito ampla, tentando aplicar todos os controles possíveis, independentemente da relevância. A abordagem correta é defini-lo como um ativo de informação que está no escopo do SGSI, realizar uma avaliação de risco proporcional e documentar a justificativa para a seleção de controles na Declaração de Aplicabilidade. Segundo: segmentação de rede inadequada. Já vi VLANs de visitantes que são tecnicamente separadas, mas compartilham uma zona de firewall com sistemas internos, ou onde a interface de gerenciamento do controlador sem fio é acessível a partir do segmento de visitantes. A segmentação precisa ser verificada com um teste de intrusão ou, no mínimo, uma revisão de acesso à rede, e essa verificação deve ser documentada como evidência de auditoria. Terceiro: ignorar o Captive Portal como um mecanismo de controle de acesso. O Captive Portal não é apenas um exercício de branding. É o ponto onde você apresenta sua Política de Uso Aceitável, obtém o consentimento para o processamento de dados e cria o log de autenticação que serve como evidência para múltiplos controles da ISO 27001. Se o seu Captive Portal não estiver registrando eventos de aceitação com carimbos de data/hora e identificadores de sessão, você tem uma lacuna que um auditor irá encontrar. Quarto: tratar a garantia de fornecedores como um exercício de uma única vez. Relatórios SOC 2 expiram. Contratos de provedores de internet mudam. Os termos de serviço de plataformas em nuvem são atualizados. Seu programa de garantia de fornecedores precisa incluir uma revisão anual das atestações de segurança dos provedores, e essa revisão precisa ser documentada. Defina um lembrete no calendário para quando o período do relatório SOC 2 de cada fornecedor terminar e solicite o relatório atualizado proativamente. Sobre a questão do tempo limite de sessão: a ISO 27001 não prescreve valores específicos de tempo limite, mas sua avaliação de risco deve documentar a justificativa para qualquer valor que você escolher. Um tempo limite de sessão de oito horas é comum no setor de hospitalidade, mas um centro de convenções que realiza um evento de um único dia pode definir um tempo limite menor para garantir que as credenciais não sejam compartilhadas entre os participantes. O princípio fundamental é que a política de tempo limite seja documentada, justificada pelo risco e implementada de forma consistente. A plataforma da Purple, por exemplo, permite que você configure e aplique políticas de tempo limite de sessão centralizadamente, com o estado da configuração exportável como evidência de auditoria. --- SEGMENTO 4: PERGUNTAS E RESPOSTAS RÁPIDAS (aprox. 1 minuto) Deixe-me passar pelas perguntas que recebo com mais frequência de gerentes de TI que estão se preparando para a certificação ISO 27001. O WiFi de visitantes precisa estar no escopo do nosso SGSI? Se ele processa, armazena ou transmite informações que se enquadram no escopo do seu SGSI, sim. Se os visitantes se autenticarem usando quaisquer dados pessoais, ou se a rede se conectar a quaisquer sistemas que estejam no escopo, ele deve ser incluído.Podemos excluir o guest WiFi da Declaração de Aplicabilidade? Você pode excluir controles, mas deve documentar a justificativa. Excluir o controle A.8.22 Segregação de Redes para uma implantação de guest WiFi exigiria um argumento muito convincente que o auditor dificilmente aceitaria. Qual é o pacote de evidências mínimo viável para uma auditoria de guest WiFi? Diagrama de rede mostrando a segregação de VLANs, conjunto de regras de firewall, configuração de Captive Portal com texto de política de uso aceitável, amostra de log de autenticação, entrada de avaliação de risco e relatório SOC 2 do fornecedor ou documento de garantia equivalente. Como o GDPR interage com a ISO 27001 para o guest WiFi? O GDPR é um requisito legal que alimenta o controle A.5.31. Seu aviso de privacidade, o contrato de processamento de dados com o fornecedor da sua plataforma de WiFi e a política de retenção de dados são itens de evidência da ISO 27001, bem como artefatos de conformidade com o GDPR. Eles cumprem dupla função. --- SEGMENTO 5: RESUMO E PRÓXIMOS PASSOS (aprox. 1 minuto) Para resumir tudo: o guest WiFi não é uma preocupação periférica para o seu SGSI — é uma fronteira de rede ativa com exposição real a riscos e um conjunto claro de controles ISO 27001:2022 aplicáveis. Os controles mais importantes são o A.8.22 para segregação de redes, A.8.20 para gerenciamento de segurança de rede, A.8.21 para garantia de fornecedores, A.8.15 para registro de logs, A.8.23 para filtragem web, A.5.14 para uso aceitável e A.5.31 para conformidade legal. Seus próximos passos imediatos: primeiro, confirme se o guest WiFi está explicitamente incluído na declaração de escopo do seu SGSI. Segundo, adicione uma entrada de guest WiFi ao seu registro de riscos com ameaças documentadas, probabilidade, impacto e decisões de tratamento. Terceiro, crie seu pacote de evidências — diagrama de rede, regras de firewall, configuração de Captive Portal, política de logs e relatório SOC 2 do fornecedor. Quarto, agende uma revisão anual de garantia de fornecedores para o provedor da sua plataforma de WiFi. Se você estiver implantando ou atualizando sua infraestrutura de guest WiFi, a plataforma da Purple foi desenvolvida com esses requisitos de conformidade em mente — alinhada ao SOC 2, com gerenciamento centralizado de políticas e evidências de configuração exportáveis que alimentam diretamente a documentação do seu SGSI. Obrigado por participar do Briefing Técnico da Purple. Para acessar o guia escrito completo, diagramas de arquitetura e exemplos práticos, visite a central de recursos da Purple. Até a próxima.