Categories: NOTÍCIAS EM GERAL

A maioria dos requisitos de conformidade são completamente absurdos

O fato é que os requisitos de conformidade costumam ser mal escritos, vagos e confusos. Na minha opinião, a confusão em torno da conformidade vem da redação, então não é surpresa que as empresas estejam lutando, especialmente quando precisam cumprir vários requisitos simultaneamente.

A escrita ruim está sufocando os regulamentos de conformidade

Tome a ISO 27001 como exemplo. Seu objetivo é aprimorar a gestão da segurança da informação de uma empresa e seu processo tem seis partes, que incluem comandos como “conduzir uma avaliação de risco”, “definir uma política de segurança” e “gerenciar os riscos identificados”. Os requisitos para cada um desses comandos são extremamente vagos e desnecessariamente subjetivos.

Lei Sarbanes-Oxley (SOX), que cobre todos os negócios nos Estados Unidos, não é melhor. A seção 404 diz vagamente que todas as organizações de capital aberto devem demonstrar “due diligence” na divulgação de informações financeiras, mas não explica o que “due diligence” significa.

Gramm-Leach-Bliley Act (GLBA) exige que as instituições financeiras dos EUA expliquem as práticas de compartilhamento de informações a seus clientes. Ele afirma que as organizações financeiras precisam “desenvolver um plano de segurança da informação por escrito”, mas não oferece nenhum conselho sobre como fazer isso.

Mesmo Lexcel (um credenciamento que indica qualidade em relação aos padrões de gestão de prática jurídica) no Reino Unido, que é escrito por advogados para advogados, não é claro: “As clínicas devem ter uma política de gestão da informação com procedimentos para a proteção e segurança das informações ativos.”

Para uma profissão que se orgulha de ser capaz de manter a clareza absoluta, estou surpreso que a Lexcel permita esse tipo de subjetividade em seus requisitos de conformidade.

Não é fácil escrever para um público tão amplo

Olha, eu entendo. É um trabalho bastante complicado escrever requisitos de conformidade. Ele precisa ser aplicável a todas as organizações em um determinado campo, cada uma das quais terá suas diferenças na forma como conduzem os negócios e como configuraram sua infraestrutura tecnológica.

Além disso, os escritores estão trabalhando contra o relógio com os requisitos de conformidade. Os regulamentos de TI estão mudando em um ritmo tão rápido que os requisitos que eles escrevem hoje podem estar desatualizados amanhã.

No entanto, acho que aqueles que escrevem requisitos devem tomar o padrão de segurança de dados do setor de cartões de pagamento (PCI DSS) como exemplo. O PCI DSS se aplica a todas as organizações que armazenam dados do titular do cartão e os requisitos são claros, atualizados regularmente, e você pode encontrar tudo o que precisa em um só lugar.

A forma como a conformidade com PCI DSS é estruturada (em termos de requisitos, procedimentos de teste e orientação) é muito mais clara do que qualquer outra coisa que já vi. Ele contém muito pouco espaço para a subjetividade e você sabe exatamente onde está.

GDPR também é muito bem escrito e detalhado. Os muitos artigos referentes à proteção de dados são específicos, compreensíveis e implementáveis.

Por exemplo, quando se trata de acesso a dados, esta frase é perfeitamente clara: “O acesso não autorizado também inclui destruição acidental ou ilegal, perda, alteração ou divulgação não autorizada de dados pessoais transmitidos, armazenados ou processados ​​de outra forma” (Artigos 4, 5, 23 e 32).

Também é muito claro quando se trata de processos de auditoria: “Você precisa manter um registro das atividades de processamento de dados, incluindo informações sobre ‘destinatários a quem os dados pessoais foram ou serão divulgados’, ou seja, quem tem acesso aos dados” (Artigos 5, 28, 30, 39, 47).

Portanto, enquanto você se depara com muitos requisitos de conformidade, você precisa ter uma boa estratégia em vigor. No entanto, pode ficar complexo quando você está tentando cumprir várias ordens. Se posso dar uma dica, é para encontrar as semelhanças entre todos eles, antes de chegar a uma solução.

Você precisa fazer o básico certo

Na minha opinião, a natureza confusa da conformidade apenas gera o bombardeio implacável de material de marketing de fornecedores sobre “como você pode ser compatível com X” ou as “cinco principais coisas que você precisa saber sobre Y”.

Você tem que entender que no centro de qualquer mandato de conformidade está o desejo de manter os dados protegidos seguros, permitindo o acesso apenas àqueles que precisam deles por motivos comerciais. É por isso que tudo que você precisa fazer com relação à conformidade é começar com o básico: armazenamento de dados, auditoria de arquivos e gerenciamento de acesso. Faça tudo certo e você estará no caminho certo para demonstrar sua disposição em obedecer.

Fonte: https://www.helpnetsecurity.com/2020/09/09/most-compliance-requirements-are-completely-absurd/

Ninja

Na cena de cybersecurity a mais de 25 anos, Ninja trabalha como evangelizador de segurança da informação no Brasil. Preocupado com a conscientização de segurança cibernética, a ideia inicial é conseguir expor um pouco para o publico Brasileiro do que acontece no mundo.

Recent Posts

Campanha de phishing com IA compromete centenas de organizações via Railway

Pesquisadores da Huntress identificaram uma campanha massiva de phishing que usa infraestrutura da Railway e…

1 dia ago

Mazda expõe dados de funcionários e parceiros após falha em sistema logístico

A Mazda informou que um acesso externo não autorizado a um sistema ligado à gestão…

1 dia ago

Falha crítica no telnetd do GNU InetUtils permite RCE como root sem autenticação

A CVE-2026-32746, com CVSS 9.8, afeta o telnetd do GNU InetUtils até a versão 2.7…

6 dias ago

GlassWorm ressurge e compromete mais de 430 repositórios, pacotes e extensões em nova ofensiva supply chain

A campanha GlassWorm voltou com escala muito maior e já atingiu 433 componentes em GitHub,…

6 dias ago

Falsos instaladores do OpenClaw ganham destaque no Bing AI e espalham malware

Como o golpe funcionava- O atacante publicou um projeto “parecido com legítimo” no GitHub, usando…

3 semanas ago

Falha crítica no better-auth permite criação não autenticada de API keys e risco de takeover

Falha crítica no better-auth permite criar API keys sem autenticação para usuários arbitrários, com risco…

1 mês ago