Segurança à vista

E mesmo assim, eu ainda conheci pessoas que descobriram um meio de subverter os recursos de proteção. Isso sempre me intrigou. Quando as pessoas saem de casa, elas trancam as portas; e quando retornam, precisam destrancá-las. Em geral, aprendemos que precisamos proteger nossos lares e nossos bens e tomar parte ativamente dessa tarefa.
Por que deveria ser diferente quando se trata da segurança de uma empresa? O que há de errado com uma caixa de diálogo que aparece nos perguntando se uma mensagem de e-mail deve ser criptografada quando é destinada a um domínio externo? Por que o sistema não deveria perguntar qual chave precisa ser utilizada para abrir uma mensagem, uma sessão ou um arquivo protegido?
É claro que a interface com o usuário deveria ser, pelo menos, tão boa quanto no mundo real. As chaves, por exemplo, deveriam ser mostradas com diferentes ícones, que os usuários pudessem definir por eles mesmos.
Historicamente, as interfaces de segurança sempre têm sido algo de causar orgulho ao “demônio do Inferno de Dante”. E isso apenas vem encorajando os usuários a se oporem a nossos esforços. Quando criamos controles de proteção de fácil utilização, geralmente removemos toda a segurança prática de nossos sistemas. Nesse caso, esses controles não são de fácil uso apenas para os clientes internos, eles são igualmente simples para os invasores em potencial. Certamente existem diferenças entre a segurança em ambientes de computação e a de nossas casas: provavelmente não deixaremos nossas chaves de acesso trancadas dentro de nossos computadores como algumas pessoas descuidadas fazem com as chaves de seus carros (a menos que elas estejam em um token USB). No entanto, as lições estão aí para serem aprendidas, ou para apenas tomarmos ciência.
A primeira lição: a segurança deve ser tangível quase a ponto de ser incômoda, precisa interagir diretamente com o usuário. O pequeno cadeado da SSL (Secure Sockets Layer) nos navegadores é sutil demais. Eu sempre penso em quantos usuários nem sequer notam que ele está aberto quando fornecem uma senha ou um número de cartão de crédito. A maioria de nós cresceu acostumado a ter parafusos maciços para a segurança de nossas casas ou a utilizar seguro para nossos carros. E embora os desktops sejam menores do que carros e casas, precisamos saber o que está e o que não está protegido.
A segunda lição: o sistema de segurança deve poder ser testado. Além disso, os usuários devem estar habituados a testar seu ambiente a qualquer momento. Quando saímos de nossas casas, verificamos se está tudo fechado. Em nossos desktops, conhecemos alguma evidência de que realmente temos um túnel de IPsec (segurança por IP) e de que ele está mesmo sendo utilizado? E embora o estejamos usando, sabemos o que não está passando por ele? Tenho observado clientes de correio POP com erros de configuração, nos quais a conexão POP é externa ao túnel e a SMTP está dentro. Fique atento.
Última lição: o usuário deve estar muito ciente de garantir a segurança do que precisa de proteção e saber o que não precisa. Conseguir isso exige muitos esforços no sentido de fornecer orientação. Precisamos desenvolver uma abordagem para educar nossos usuários sobre a importância da verdadeira segurança e de suas interações com ela.
Durante anos, a segurança tem sido muitas vezes relegada ao segundo plano em nossos projetos de sistemas. Nossa tendência é a de pedir desculpas aos usuários por expô-los aos recursos de proteção. Eles não precisam estar à nossa vista, mas também não devem ficar escondidos sob um escudo de ignorância e indiferença.
