• Artigo

Os arquivos da área de trabalhoSegurança X Conformidade

Wes Miller

Como um profissional de TI, você pode enfrentar objetivos que devem se complementar, mas muitas vezes, ao contrário, competem entre si. A segurança e a conformidade são dois objetivos organizacionais, nos quais a realização de um deve aprimorar o outro. Infelizmente, esse normalmente não é o caso. Minha intenção com esta coluna é fornecer a você

uma visão geral de por que estar seguro nem sempre significa estar em conformidade com as iniciativas exigidas de você, e por que estar em conformidade, muitas vezes, não significa estar seguro ou, pelo menos, não tão seguro como você deveria estar se a conformidade realmente se igualasse à segurança.

A segurança não é uma caixa de seleção

Recursos SDL

A conformidade geralmente envolve requisitos (pessoas, processo, infra-estrutura, tecnologia, e assim por diante) impostos em uma organização, indústria, empresa ou produto externo. Às vezes, a conformidade tem a ver com padrões promulgados de dentro da indústria (como o PCI-DSS ou Payment Card Industry Data Security Standards). Em termos ideais, essas são iniciativas que se alinham com a maneira com a qual sua organização já trabalha, pelo menos até um certo grau. À medida que a adoção de um padrão prolifera, você descobre que não pode ignorá-la; não se deseja fazer negócios. Eventualmente, você precisa mergulhar de cabeça e tirar o melhor proveito disso.

É o outro tipo de conformidade que normalmente é mais problemático. Estou me referindo a iniciativas estabelecidas pelo governo, como a HIPAA (Health Insurance Portability and Accountability Act) e a Sarbanes-Oxley, onde a implementação e o tempo raramente são uma questão de escolha.

O ponto chave para compreender sobre a conformidade a normas é que ela muitas vezes envolve uma abordagem "descendente". Em geral, há um modelo simplista que define a iniciativa, e você deve olhar seus produtos e processos para tentar descobrir como eles podem se integrar com o estranho modelo transmitido a você. Você precisa estar ciente não apenas da intenção da iniciativa de conformidade, mas, talvez mais importante, de quais podem ser as ramificações legais ou financeiras para que você não as siga ou para não ser mal-sucedido (se realmente elas existirem).

Embora possamos concordar com a intenção de várias iniciativas de conformidade, a implementação é muitas vezes difícil e pode não atender ao objetivo desejado. E, lamentavelmente, várias são ineficazes (isto é, não existem ramificações diretas legais ou financeiras que podem ser impostas para falha).

Posso dizer que, como um paciente médico, não posso descrever completamente o benefício líquido da HIPAA para mim. O que posso dizer é que significa que eu tenho muito mais papelada para resolver quando vou ao médico. As conseqüências indesejadas podem ser ainda piores. Já tentou obter informações médicas importantes de um médico ou agência para uma outra? Se não existir uma permissão por escrito, você não conseguirá, não importa qual seja a urgência das informações necessárias.

A questão é que, em vários sentidos, algumas iniciativas de conformidade se tornam iniciativas de caixa de seleção. Isto é, você está projetando ou modificando seu processo ou seu produto apenas para atender a iniciativa de conformidade. Como sempre pergunto para o meu filho de três anos: "isso é uma boa idéia?".

A segurança, por outro lado, é uma iniciativa ascendente — quando feita corretamente. Esteja você projetando um produto de software ou a arquitetura para a nova rede da sua organização, o conceito principal a lembrar é meça duas vezes, corte uma. Quando você está projetando a arquitetura do produto, por exemplo, da mesma forma que um bom passo inicial descreveria a comunicação, localização, versões e assim por diante, ele também deveria descrever os elementos de segurança que precisam ser criados no aplicativo desde o primeiro dia (e quais você deveria continuar investigando e refinando durante todo o desenvolvimento).

Se estiver trabalhando com um aplicativo ou uma arquitetura herdada (tenho certeza de que a maioria de vocês está), é igualmente crítico executar o tipo de revisão de segurança detalhada que freqüentemente menciono nesta coluna. Se você não entende como algo funciona, como pode possivelmente entender se isso está seguro ou não? Para obter mais informações sobre o SDL (ciclo de vida do desenvolvimento de segurança) da Microsoft®, consulte o quadro "Recursos SDL".

A visão global

Eu me lembro de quando comecei a estudar que a segurança não se iguala simplesmente a implementar a criptografia, ACLs (listas de controle de acesso) ou TLS ou PKI (infra-estrutura de chave pública). A segurança real é toda sobre compreender a visão global: entender por que essa versão desse protocolo foi abandonada ou até mesmo nunca foi suportada; por que essa nova estrutura interrompe ataques intermediários; como a sua implementação do produto v2 é muito mais segura do que o v1, mesmo se o v1 era mais muito mais rápido. E também é necessário que você entenda como todas as partes da sua infra-estrutura se encaixam.

A conformidade, por outro lado, significa pegar sua tecnologia e certificar-se de que a infra-estrutura que você criou atende a certos critérios. Algumas iniciativas, como a PCI-DSS ou NERC (North American Electric Reliability Council), são bem intencionadas e podem terminar promovendo a alteração de segurança real. Mas, ao final do dia, com uma seleção de aperitivos de "iniciativas de conformidade" que você precisa integrar com seus próprios projetos particulares e recursos finitos disponíveis, as iniciativas de segurança perdem terreno.

A segurança tem por muito tempo sido a filha adotiva do desenvolvimento de software. Com certeza, vários de vocês estiveram em uma organização onde a segurança era algo que "faremos mais tarde". Bem, iniciativas de conformidade chegaram agora para ficar porque esse costume — de que a segurança pode esperar — não funciona e nunca funcionou.

Bom o suficiente

Recentemente eu mudei de emprego. Estou trabalhando agora para um novo grupo aqui em Austin, no Texas, que está criando uma tecnologia de lista de exceções para aplicativos um tanto similar à tecnologia que criamos na Winternals com nosso produto Protection Manager. Algo sobre o qual acho muito interessante falar com os clientes é como eles consideram a segurança de suas atuais tecnologias — ou, mais especificamente, de que forma eles acreditam que o conjunto de tecnologias usado por eles está tornando segura sua infra-estrutura. Embora seja totalmente provável que a maior parte deles esteja segura e não esteja se dividindo com as vulnerabilidades de segurança, a avaliação que muitas vezes ouço e que me deixa com um pouco de medo é que um sistema é "seguro o suficiente".

As iniciativas de conformidade são engraçadas — você pode conseguir atendê-las ou não. A responsabilidade é sua. O custo de não atender a uma iniciativa é normalmente uma multa, uma penalidade ou a remoção de uma organização. Muitas vezes, isso não é suficiente para garantir que algo realmente mude.

No caso de uma iniciativa estabelecida federalmente, eu regularmente me deparo com a atitude "boa o suficiente para agradar ao auditor" ou a disposição de executá-la sem realmente estabelecer nenhuma estrutura de conformidade porque a legislação de apoio (como HIPAA) não consolida de modo adequado a aplicação — significando que custa muito menos continuar sem seguro e enfrentar qualquer conseqüência possível posteriormente.

A segurança muitas vezes atinge as mesmas barreiras, mas, na minha opinião, pelo menos ela é mais concreta. Se você, como desenvolvedor ou implementador, diz ativamente ao gerenciamento que deixar a seção x fora da especificação deixará o produto acentuadamente mais vulnerável a violações, você pode, pelo menos, depois que o produto for enviado ou sua implantação estiver concluída, dizer "eu avisei". Com as iniciativas de conformidade, minha experiência é que o cumprimento é freqüentemente apressado, com um orçamento o mais limitado possível. O objetivo é simplesmente atender o mínimo absoluto requerido pela iniciativa — portanto, talvez, atendendo a forma da iniciativa, mas dificilmente o conteúdo, na minha opinião.

Decidindo onde você está

Recursos de segurança e conformidade

Embora, para mim, possa ser idealista dizer que você deveria tornar o seu produto e a sua organização o mais seguros possíveis, a realidade é que a maioria das iniciativas de conformidade é realmente um compromisso que resulta de uma engenharia deficiente ou, mais freqüentemente, de complacência. Vivemos em um mundo onde "bom o suficiente" é, infelizmente, bom o suficiente. No mundo da segurança, no entanto, raramente "bom o suficiente" é inteligente. Nós, os profissionais de TI do mundo, podemos levar a sério as iniciativas de conformidade e tentar atendê-las no conteúdo e na implementação e, contudo, devemos nos certificar de que a infra-estrutura que estamos adotando não é meramente tão segura quanto ela poderia ser, mas sim tão segura quanto ela deve ser. Em outras palavras, estar em conformidade com a segurança real, não apenas para atender a iniciativa.

É importante dar um passo para trás e observar a tecnologia que você está criando, seja ela um fragmento de software comercial ou um conjunto de tecnologias que você procura integrar em um sistema maior. Não me canso de afirmar a importância de compreender as partes interconectáveis do sistema, como todas as partes trabalham juntas e as maiores ameaças que pairam sobre o seu sistema.

Dependendo da indústria na qual você trabalha, diferentes iniciativas de conformidade podem representar um papel no seu trabalho. Você pode se deparar com elas na sua vida diária ou apenas quando estiver projetando novas tecnologias ou projetos. Ou, pode ser o caso em que elas são apenas uma parte do seu trabalho durante revisões ou auditorias de conformidade especificamente designadas. Não importa. Não acredito que as iniciativas de conformidade devam ser ignoradas, mas eu o desafiaria a desafiar o status quo e, em vez de trabalhar apenas para atender as iniciativas de conformidade com as quais você está atarefado, executar uma revisão total de segurança para entender sua tecnologia por completo e modelá-la ao mesmo tempo que sua revisão de conformidade.

O que você tem a perder?

Ao final do dia, as penalidades para falhar ao atender uma iniciativa de conformidade podem parecer ambíguas. A falta de conformidade o expõe ao mesmo risco contra o qual foi adotada a proteção. As conseqüências podem parecer vagas ou distantes, mas são reais. Elas podem também não ser as suas conseqüências (individuais). Seja pragmático, mas sempre mantenha os piores cenários no fundo do coração.

Se você olhar o mesmo espaço, de uma perspectiva exclusivamente de segurança, a ameaça deve ser óbvia — e, mais importante, você deve poder identificar imediatamente o possível custo de deixar a vulnerabilidade aberta.

Muitas pessoas com as quais discuti sobre esse tópico enfatizaram o fato de que as iniciativas de conformidade são, às vezes, varridas para debaixo do tapete — uma vez que elas, muitas vezes, deixam margem a interpretações. Depois de ter conduzido uma revisão de segurança, no entanto, isso não deve ser verdadeiro sobre qualquer omissão de segurança. As ameaças imediatas da segurança ignorada devem ser claramente visíveis. Se não forem, convém reconsiderar quem você está envolvendo nas suas revisões de segurança. Você pode estar deixando escapar membros importantes da equipe que podem ajudar a encontrar os problemas reais na sua solução.

Seguindo a cauda

Na coluna focada em segurança do ano passado, discuti "Como evitar a perda dos seus dados" (technet.microsoft.com/magazine/cc162325). Um ano se passou, mais sistemas foram comprometidos, mais laptops não-criptografados foram perdidos e mais informações pessoais foram colocadas em mãos potencialmente questionáveis. É difícil dizer se algum progresso realmente foi feito. Por que ainda estamos no mesmo lugar? Os projetos freqüentemente atrasam, em um orçamento minúsculo, com recursos ridiculamente forçados demais, tentando entregar muitos recursos em um intervalo de tempo muito curto.

Esse tipo de ambiente, infelizmente, leva a uma situação onde o mínimo absoluto de trabalho se torna a norma. Isso certamente não é uma maneira de garantir que uma solução esteja segura ou em conformidade e também não é fatal a uma linha de tempo ou aos custos de um projeto.

Pessoalmente, acredito decididamente que:

  1. Você não deve criar uma solução se não está disposto a protegê-la.
  2. Sempre que você adicionar novos recursos, precisará projetar a segurança antes de começar.
  3. Se sua organização não está disposta a criar a segurança como uma etapa no seu processo de engenharia, você deve questionar quais são os objetivos gerais da sua empresa ou organização.

As organizações possuem cada vez mais dados pessoais de clientes ou parceiros por cuja segurança elas são responsáveis. Infelizmente, vivemos em um mundo onde, muitas vezes, a segurança não é o padrão e os funcionários não se sentem seguros questionando a dedicação da organização com a segurança.

A real falha de segurança (e não de conformidade) muitas vezes se torna o disparador que indica "é hora de proteger o sistema agora" e o "seguro contra roubo de identidade" se tornou uma tática de responsabilidade padrão para satisfazer clientes, estudantes, pacientes e funcionários, cujos dados pessoais, e um possível bem-estar financeiro, foram comprometidos.

Estamos todos sendo solicitados para fazer muitas coisas, muitas vezes por muito pouco e, normalmente, em um tempo muito curto. Mas é nossa responsabilidade que os profissionais de TI questionem por que a segurança não é o foco principal, por que muitas vezes o gerenciamento pensa na segurança apenas diante de iniciativas de conformidade ou, mais provavelmente, diante de falhas de segurança e suas ameaças legais reais ou potenciais (que poderiam potencialmente preocupar e, até mesmo, arriscar a organização).

Aceite o meu desafio

Mais do que qualquer coisa, eu o convido a desafiar o status quo. Se estiver sendo solicitado que você apenas atenda aos objetivos de conformidade — tente garantir que enquanto você o faça, não está simplesmente perdendo tempo atendendo ao conceito de segurança de outra pessoa. Esteja certo, mais exatamente, de que seu objetivo é proteger o sistema e, durante o caminho, definir uma parte suficiente do processo ou da sua infra-estrutura para atender a iniciativa de conformidade. Para obter mais informações sobre este tópico, consulte o quadro "Recursos de segurança e conformidade".

Em resumo, lembre-se de que a conformidade muitas vezes não é um caminho para a segurança. A segurança, no entanto, se implementada e instrumentada corretamente, pode freqüentemente ser um caminho para a conformidade.

Wes Miller é gerente sênior de produto técnico na CoreTrace (www.CoreTrace.com) em Austin, no Texas. Anteriormente, ele trabalhou na Winternals Software e como gerente de programa na Microsoft. Entre em contato com ele pelo email technet@getwired.com.

© 2008 Microsoft Corporation e CMP Media, LLC. Todos os direitos reservados; é proibida a reprodução parcial ou completa sem autorização..