ISO 27001 Guest WiFi: Um Guia de Conformidade

ISO 27001 Guest WiFi: Um Guia de Conformidade Purple Technical Briefing Podcast — Guião do Episódio Duração aproximada: 10 minutos | Voz: Inglês do Reino Unido, tom de consultor sénior --- SEGMENTO 1: INTRODUÇÃO E CONTEXTO (aprox. 1 minuto) Bem-vindo ao Purple Technical Briefing. Sou o vosso anfitrião para o episódio de hoje, e vamos mergulhar num tema que se situa na intersecção das operações de rede e da governação da segurança da informação: Guest WiFi e conformidade com a norma ISO 27001. Se é um gestor de TI, um arquiteto de rede ou um auditor líder ISO 27001 num grupo hoteleiro, numa cadeia de retalho, num estádio ou numa organização do setor público, este episódio foi feito para si. Não vamos abordar a ISO 27001 do zero - já conhece a norma. O que vamos fazer é dar-lhe um mapa preciso e prático de como a sua implementação de Guest WiFi se enquadra no seu Sistema de Gestão de Segurança da Informação, quais os controlos aplicáveis, o que a sua avaliação de risco precisa de documentar e, crucialmente, que evidências precisa de apresentar quando o auditor entrar pela porta. O Guest WiFi é uma daquelas áreas que as organizações subestimam constantemente do ponto de vista da conformidade. Parece um serviço básico - ligar alguns pontos de acesso, partilhar uma palavra-passe, e já está. Mas, do ponto de vista de um SGSI, trata-se de um ativo de informação ativo que toca a fronteira da sua rede, as suas relações com fornecedores, as suas obrigações de proteção de dados e a sua exposição legal. Vamos analisar isto detalhadamente. --- SEGMENTO 2: ANÁLISE TÉCNICA DETALHADA (aprox. 5 minutos) Vamos começar com o mapeamento de controlos. A norma ISO 27001:2022 reestruturou os seus controlos do Anexo A, e vários deles aplicam-se diretamente ao Guest WiFi. O grupo mais crítico situa-se na secção de Controlos Tecnológicos - que é a cláusula 8 do Anexo A. O Controlo A.8.22 - Segregação de Redes - é o seu requisito fundamental. Este controlo exige que os grupos de serviços de informação, utilizadores e sistemas sejam segregados nas redes. Para o Guest WiFi, isto traduz-se diretamente na monitorização de isolamento de VLAN. A sua rede de convidados deve ser 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 descobrir que o tráfego de convidados consegue aceder a partilhas de ficheiros internas ou interfaces de gestão, isso constitui uma não conformidade clara em relação ao A.8.22. O Controlo A.8.20 - Segurança de Redes - exige que as redes sejam geridas e controladas para proteger a informação em sistemas e aplicações. Para o Guest WiFi, isto significa regras de firewall documentadas, listas de controlo de acesso e uma política de segurança de rede que aborde explicitamente o segmento de convidados. Precisa de ser capaz de mostrar ao auditor um diagrama de rede atualizado com a VLAN de convidados claramente identificada, bem como o conjunto de regras de firewall que governa o que esse segmento pode e não pode aceder.O Controlo A.8.21 - Segurança dos Serviços de Rede - aborda os fornecedores de serviços de rede terceiros. A maioria das organizações que disponibiliza WiFi para convidados utiliza um fornecedor de serviços geridos, uma plataforma de Captive Portal baseada na nuvem ou uma solução fornecida por um ISP. Cada uma destas opções representa uma relação com fornecedores que necessita de ser gerida. Precisa de acordos de nível de serviço que incluam requisitos de segurança, bem como de provas de revisões periódicas aos fornecedores. É aqui que as atestações SOC 2 Tipo II dos fornecedores se tornam genuinamente úteis - voltaremos a este ponto. O Controlo A.8.15 - Registo de Eventos (Logging) - exige que os registos de eventos sejam produzidos, armazenados, protegidos e analisados. No caso do WiFi para convidados, isto significa registar eventos de ligação, tentativas de autenticação e dados de sessão. No entanto, existe aqui uma tensão com o GDPR e os princípios de minimização de dados, particularmente no Reino Unido e na UE. Precisa de registar o suficiente para cumprir as suas obrigações de monitorização de segurança, mas não tanto que acabe por reter dados pessoais para além do estritamente necessário. A sua política de registo de eventos deve abordar explicitamente o âmbito do WiFi para convidados, definir períodos de retenção e documentar a base legal para quaisquer dados pessoais recolhidos. O Controlo A.8.23 - Filtragem Web - exige que o acesso a sites externos seja gerido para proteger os sistemas contra infeções por malware e para impedir o acesso a recursos web não autorizados. Para o WiFi para convidados, isto significa tipicamente implementar uma filtragem baseada em DNS ou um proxy web na nuvem que bloqueie domínios maliciosos conhecidos, infraestruturas de comando e controlo e, dependendo do seu setor, categorias de conteúdo inadequado. Um operador hoteleiro que serve um público familiar tem obrigações de filtragem diferentes das de um centro de conferências que serve delegados empresariais, mas ambos necessitam de uma política documentada e de provas de que a filtragem está ativa e é revista. Passando para os Controlos Organizacionais - Anexo A, cláusula 5 - dois controlos são particularmente relevantes. O Controlo A.5.14 - Transferência de Informação - rege as regras, procedimentos e controlos para a transferência de informação. Se os convidados utilizarem a sua rede para transferir ficheiros, aceder a serviços na nuvem ou realizar negócios, precisa de uma Política de Utilização Aceitável que lhes seja apresentada no momento da autenticação - normalmente através do Captive Portal - e aceite antes de o acesso ser concedido. Esse evento de aceitação precisa de ser registado como prova. O Controlo A.5.31 - Requisitos Legais, Estatutários, Regulamentares e Contratuais - exige que identifique e documente todas as obrigações legais e regulamentares relevantes. Para o WiFi para convidados, isto inclui o GDPR ou o UK GDPR caso recolha dados pessoais no momento da autenticação, o Investigatory Powers Act se estiver no Reino Unido e for obrigado a reter dados de comunicações, e regulamentos específicos do setor, como o PCI-DSS, se a sua rede de convidados estiver no âmbito dos dados de titulares de cartões. Agora, a avaliação de risco. A ISO 27001 é uma norma baseada no risco, o que significa que não pode simplesmente implementar controlos e dar o trabalho por concluído. Precisa de documentar uma avaliação de risco formal para o ativo de guest WiFi. Essa avaliação deve identificar ameaças - acesso não autorizado a sistemas internos, propagação de malware a partir de dispositivos de convidados, interceção de dados no meio sem fios, negação de serviço e danos reputacionais decorrentes da utilização indevida da sua rede. Para cada ameaça, avalia a probabilidade e o impacto, determina o seu tratamento de risco - seja ele mitigar, aceitar, transferir ou evitar - e documenta o risco residual. A Declaração de Aplicabilidade deve referenciar a avaliação de risco do guest WiFi como a justificação para incluir ou excluir controlos específicos do Anexo A. Vamos falar sobre o WPA3 e as normas de autenticação. As gerações de hardware WiFi IEEE 802.11ax e 802.11be suportam WPA3, que fornece Simultaneous Authentication of Equals - SAE - substituindo o handshake de Pre-Shared Key mais antigo. Para uma rede de convidados onde utiliza uma frase de passe partilhada, o WPA3-Personal com SAE fornece forward secrecy, o que significa que, mesmo que a frase de passe seja comprometida, o tráfego histórico das sessões não pode ser desencriptado. Para implementações empresariais onde deseja autenticação por utilizador, o WPA3-Enterprise com IEEE 802.1X e EAP-TLS fornece autenticação baseada em certificados que mapeia diretamente para os controlos de gestão de identidade da ISO 27001. A escolha entre estes dois modelos depende da sua população de utilizadores e da sua tolerância à complexidade operacional. Agora, as atestações SOC 2 de fornecedores. Se estiver a utilizar uma plataforma de guest WiFi gerida na nuvem - e a maioria das organizações está - o relatório SOC 2 Type II desse fornecedor é uma peça crítica de evidência de garantia de fornecedores. Um relatório SOC 2 Type II abrange os Trust Services Criteria: 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. Quando está a construir o seu ficheiro de garantia de fornecedores ISO 27001, o relatório SOC 2 Type II do fornecedor, combinado com um questionário de segurança de fornecedores preenchido e um acordo de processamento de dados, fornece-lhe um pacote de evidências defensável para o controlo A.8.21. A Purple, por exemplo, possui um alinhamento SOC 2 que apoia diretamente este requisito de SGSI a jusante - o que significa que pode referenciar a atestação deles nas suas próprias evidências de auditoria em vez de realizar uma avaliação de segurança totalmente personalizada da plataforma. --- SEGMENTO 3: RECOMENDAÇÕES DE IMPLEMENTAÇÃO E ERROS COMUNS (aprox. 2 minutos) Deixe-me apresentar-lhe as quatro decisões de implementação que a maioria das organizações erra. Primeiro: desvio de âmbito na avaliação de riscos. As organizações ou definem o âmbito do WiFi de convidados de forma demasiado estreita — tratando-o como fora do âmbito por ser apenas para visitantes — ou de forma demasiado ampla, tentando aplicar todos os controlos possíveis independentes da relevância. A abordagem correta é defini-lo como um ativo de informação que está no âmbito do SGSI, realizar uma avaliação de riscos proporcional e documentar a justificação da seleção de controlos na Declaração de Aplicabilidade. Segundo: segmentação de rede inadequada. Tenho visto VLANs de convidados que são tecnicamente separadas, mas partilham uma zona de firewall com sistemas internos, ou onde a interface de gestão do controlador sem fios é acessível a partir do segmento de convidados. A segmentação precisa de ser verificada com um teste de intrusão ou, no mínimo, com uma revisão de acessos à rede, e essa verificação precisa de ser documentada como evidência de auditoria. Terceiro: ignorar o Captive Portal como um mecanismo de controlo de acessos. O Captive Portal não é apenas um exercício de imagem de marca. É o ponto onde apresenta a sua Política de Utilização Aceitável, obtém consentimento para o processamento de dados e cria o registo de autenticação que serve de evidência para múltiplos controlos ISO 27001. Se o seu Captive Portal não estiver a registar eventos de aceitação com carimbos de data/hora e identificadores de sessão, tem uma lacuna que um auditor irá encontrar. Quarto: tratar a garantia de fornecedores como um exercício único. Os relatórios SOC 2 expiram. Os contratos de ISP mudam. Os termos de serviço das plataformas de nuvem são atualizados. O seu programa de garantia de fornecedores precisa de incluir uma revisão anual das certificações de segurança dos fornecedores, e essa revisão precisa de 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. Relativamente à questão dos tempos limites de sessão (session timeouts): a norma ISO 27001 não prescreve valores específicos de tempo limite, mas a sua avaliação de riscos deve documentar a justificação para qualquer valor que escolher. Um tempo limite de sessão de oito horas é comum na hotelaria, mas um centro de conferências que realize um evento de um dia pode definir um tempo limite mais curto para garantir que as credenciais não são partilhadas 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 configurar e impor políticas de tempo limite de sessão de forma centralizada, sendo o estado da configuração exportável como evidência de auditoria. - SEGMENTO 4: PERGUNTAS E RESPOSTAS RÁPIDAS (aprox. 1 minuto) Vou responder rapidamente às perguntas que recebo com mais frequência de gestores de TI que se preparam para a certificação ISO 27001. O WiFi de convidados tem de estar no âmbito do nosso SGSI? Se processar, armazenar ou transmitir informações que entrem no âmbito do seu SGSI, sim. Se os convidados se autenticarem utilizando quaisquer dados pessoais, ou se a rede se ligar a quaisquer sistemas que estejam no âmbito, deve ser incluído. Podemos excluir o WiFi de convidados da Declaração de Aplicabilidade? Pode excluir controlos, mas deve documentar a justificação. Excluir o A.8.22 Segregação de Redes para uma implementação de WiFi de convidados exigiria um argumento muito convincente que o auditor dificilmente aceitaria. Qual é o pacote mínimo de evidências viável para uma auditoria de WiFi de convidados? Diagrama de rede que mostre a segregação de VLAN, regras de firewall, configuração do Captive Portal com o texto da política de utilização aceitável, amostra de registo de autenticação, entrada na avaliação de riscos e relatório SOC 2 do fornecedor ou documento de garantia equivalente. Como é que o GDPR interage com o ISO 27001 para o WiFi de convidados? O GDPR é um requisito legal que alimenta o controlo A.5.31. O seu aviso de privacidade, o acordo de processamento de dados com o fornecedor da plataforma de WiFi e a política de retenção de dados são itens de evidência do ISO 27001, bem como artefactos de conformidade com o GDPR. Servem um duplo propósito. - SEGMENTO 5: RESUMO E PRÓXIMOS PASSOS (aprox. 1 minuto) Para resumir: o WiFi de convidados não é uma preocupação periférica para o seu SGSI - é uma fronteira de rede ativa com exposição a riscos reais e um conjunto claro de controlos ISO 27001:2022 aplicáveis. Os controlos mais importantes são o A.8.22 para segregação de redes, o A.8.20 para gestão da segurança da rede, o A.8.21 para garantia de fornecedores, o A.8.15 para registo de eventos, o A.8.23 para filtragem web, o A.5.14 para utilização aceitável e o A.5.31 para conformidade legal. Os seus próximos passos imediatos: primeiro, confirme que o WiFi de convidados está explicitamente incluído na declaração de âmbito do seu SGSI. Segundo, adicione uma entrada de WiFi de convidados ao seu registo de riscos com ameaças, probabilidade, impacto e decisões de tratamento documentadas. Terceiro, construa o seu pacote de evidências - diagrama de rede, regras de firewall, configuração do Captive Portal, política de registo de eventos e relatório SOC 2 do fornecedor. Quarto, agende uma revisão anual de garantia de fornecedores para o seu provedor de plataforma de WiFi. Se está a implementar ou a atualizar a sua infraestrutura de WiFi de convidados, a plataforma da Purple é desenvolvida a pensar nestes requisitos de conformidade - alinhada com o SOC 2, com gestão de políticas centralizada e evidências de configuração exportáveis que alimentam diretamente a documentação do seu SGSI. Agradecemos por se juntar ao Purple Technical Briefing. Para aceder ao guia escrito completo, diagramas de arquitetura e exemplos práticos, visite o centro de recursos da Purple. Até à próxima.