Políticas de segurança que as pessoas conseguem pôr em prática

Uma política de segurança deve ajudar alguém a decidir o que fazer numa situação real. O seu valor depende de regras claras, de controlos disponíveis e de uma forma prática de os seguir. Um documento que promete controlos que os seus sistemas não conseguem impor gera confusão nos trabalhadores e evidências pouco fiáveis para os revisores.

Para um CTO, o desenvolvimento de políticas é, por isso, um exercício de implementação: definir o comportamento exigido, verificar as dependências técnicas, atribuir responsabilidades e testar se a regra funciona na prática.

Começar pela decisão que as pessoas precisam de tomar

Escolha uma atividade concreta, como a partilha externa de ficheiros, a concessão de acesso à produção ou a comunicação da perda de um dispositivo. Identifique a informação, os sistemas, as pessoas e as atividades abrangidos, incluindo, quando relevante, os prestadores externos e os fornecedores.

Substitua formulações vagas como «partilhar informação de forma segura» por requisitos que alguém consiga aplicar. Para a partilha externa, especifique as classes de informação permitidas, os canais aprovados, a autorização, o acesso dos destinatários e as exceções. Explique brevemente a razão: o acesso nominativo reduz a divulgação acidental e torna possível a remoção do acesso.

Mantenha três camadas distintas:

Ligue a política ao procedimento que o pessoal efetivamente utiliza. Isto evita reescrever a política sempre que a interface de uma ferramenta muda.

Percorrer um exemplo realista antes da aprovação

Pressupostos ilustrativos: uma equipa de projeto partilha ficheiros de conceção confidenciais com um consultor externo. A sua plataforma de colaboração suporta destinatários nominativos e a expiração dos acessos, mas a classificação é manual.

Uma regra exequível poderia exigir que o responsável pelo projeto autorizasse a divulgação, que o remetente utilizasse a plataforma aprovada e que o acesso expirasse no fim do trabalho. As ligações públicas não seriam permitidas para esta classe de informação.

Percorra o rascunho ao longo do fluxo de trabalho real:

• O remetente identifica a classificação do ficheiro com base no guia de classificação.
• O responsável pelo projeto confirma que o consultor precisa da informação.
• O remetente concede acesso à conta verificada do consultor e define a data de expiração acordada.
• O registo de aprovação identifica o ficheiro, o destinatário, a finalidade e a data de fim.
• O responsável pelo sistema verifica que o acesso expira ou é removido quando o trabalho termina.

As evidências incluiriam a autorização, a configuração da partilha e o registo de remoção do acesso. Se o consultor não conseguir autenticar-se, a resposta não é uma ligação pública informal: utilize o processo de exceção ou outro método de entrega aprovado.

Verificar se a organização consegue cumprir

Reveja o rascunho com as pessoas que o vão aplicar, incluindo o pessoal do service desk e os responsáveis pelos sistemas. Peça-lhes que executem o fluxo de trabalho, em vez de se limitarem a aprovar a redação.

Confirme que existem as ferramentas, o tempo, as competências, as permissões e o apoio necessários. Se a expiração não puder ser automatizada, decida se uma tarefa manual de remoção agendada é adequada. Caso contrário, altere o plano de implementação antes de declarar o controlo operacional.

Defina um processo de exceção com um aprovador, uma fundamentação, o âmbito afetado, salvaguardas, uma data de expiração e uma revisão. Mantenha as exceções visíveis para a gestão de riscos, sem fazer circular desnecessariamente pormenores sensíveis. Exceções repetidas podem indicar uma regra inadequada ou uma capacidade em falta, e não apenas incumprimento por parte dos trabalhadores.

Tornar a adoção parte da implementação

Publique as políticas onde os trabalhadores as possam encontrar durante o trabalho, e não apenas numa pasta de auditoria. Inclua ligações às políticas nos formulários de pedido relevantes e nos materiais de integração. Explique o que mudou e quem tem de agir.

Utilize instruções curtas baseadas em cenários: peça a um remetente que configure uma partilha externa ou pergunte a um trabalhador como comunicaria o desaparecimento de um portátil. Disponibilize um canal de comunicação que possam utilizar sem o dispositivo em falta. Os registos de tomada de conhecimento mostram que houve comunicação; não demonstram que alguém consegue executar o processo.

Ligar os requisitos às evidências operacionais

A ISO/IEC 27001 diz respeito a um sistema de gestão da segurança da informação com âmbito delimitado. Mapeie as políticas para os requisitos aplicáveis e para as decisões de tratamento de riscos dentro desse âmbito, em vez de importar todos os modelos como obrigatórios. Mantenha esses mapeamentos separados das instruções destinadas aos trabalhadores.

Para cada regra importante, identifique o seu responsável, o controlo de suporte, as evidências e o método de revisão. Na partilha de ficheiros, inspecione uma amostra de partilhas reais quanto à autorização, às restrições de destinatários e aos limites de acesso. Como recomendação prática, combine evidências de configuração com registos de transações: uma captura de ecrã das predefinições seguras, por si só, não prova que todas as partilhas seguiram o processo.

Manter as políticas alinhadas com sistemas em mudança

Conserve o responsável, a autoridade de aprovação, a versão, a data de entrada em vigor, o registo de comunicação e o histórico de revisões. Reveja-as a um intervalo planeado e sempre que os sistemas, os incidentes, os contratos ou as obrigações relevantes mudarem.

A IA pode ajudar a redigir a partir de requisitos aprovados e de procedimentos existentes. Reveja todas as afirmações sobre a implementação atual antes da publicação.

No Secani, ligue o material de origem das políticas a requisitos, controlos, responsáveis e evidências; transforme as lacunas em tarefas e conserve as decisões revistas. A revisão humana continua explícita, ajudando a política a manter-se ligada à implementação real.

Comece por um fluxo de trabalho de alta frequência. Teste-o com os seus utilizadores, resolva as capacidades em falta e recolha evidências operacionais antes de alargar o conjunto de políticas.