- A segurança de computadores é uma área em que produtos, conferências, livros e projetos de lei continuam aumentando, mas na raiz dos fracassos repetidos estão premissas básicas equivocadas como Default Permit e Enumerating Badness
- O problema central é uma estrutura que persegue sem fim “o que bloquear”, em vez de definir de forma restrita “o que permitir”; em firewalls, execução de código e resposta a worms, se não for adotado o Default Deny, cai-se em uma corrida armamentista com os atacantes
- Listar coisas ruins é ineficiente porque envolve rastrear mais de 75.000 vírus e de 200 a 700 novas ameaças por mês, enquanto gerenciar as cerca de 30 aplicações legítimas realmente necessárias por meio de Enumerating Goodness é mais eficiente
- A abordagem de encontrar vulnerabilidades e aplicar patches, a cultura de consumir hacking como algo legal e a estratégia de depender da educação do usuário acabam repetindo respostas posteriores ao incidente em vez de reduzir falhas de projeto
- Pode ser mais seguro esperar e validar novas tecnologias antes de adotá-las imediatamente, e profissionais de segurança devem priorizar projeto baseado em bom senso e uma postura cética acima de modismos
“Anti-boas ideias” que produzem falhas de segurança
- Na segurança de computadores, novos produtos, novas conferências, novos livros e novos projetos de lei continuam aparecendo, mas os problemas se repetem
- “Ideias estúpidas” são abordagens que ficam no lado oposto das boas ideias, e surgem quando se tenta fazer o impossível ou se ignora a realidade
- Essas abordagens às vezes nascem de mal-entendidos bem-intencionados, e às vezes de produtos bem embalados que só querem ganhar dinheiro rápido
- As seis ideias são organizadas na ordem em que aparecem com mais frequência, e evitar especialmente as três primeiras já colocaria alguém entre a minoria de excelentes profissionais de segurança
1. Default Permit: permitir por padrão
- Default Permit é a abordagem de permitir tudo o que não estiver explicitamente proibido, e isso fica mais fácil de ver em regras de firewall
- Os primeiros administradores de rede bloqueavam apenas telnet, rlogin e FTP de entrada, e permitiam todo o resto
- Cada vez que uma nova vulnerabilidade era descoberta, o administrador tinha de decidir se a bloquearia ou não, e precisava correr para alcançar o problema antes de ser invadido
- Isso deveria ter desaparecido com o surgimento dos worms nos anos 1990, mas muitas redes ainda têm uma estrutura de núcleo aberto sem segmentação
- O mesmo problema se repete na execução de código
- Se o usuário clica, por padrão qualquer coisa é executada, e a execução só é negada quando um antivírus ou bloqueador de spyware a interrompe
- Na prática, os aplicativos usados com frequência são cerca de 15, e os usados ocasionalmente ficam em torno de 20 a 30, mas mesmo assim o sistema operacional permite por padrão a execução de vírus ou spyware
- Um projeto de segurança de e-banking usou a abordagem oposta
- Em vez de o balanceador de carga enviar para um buraco negro apenas ataques conhecidos, ele mandava para um servidor bloqueado, que entregava uma imagem e uma página 404, todo tráfego que não correspondesse a uma lista de URLs corretas
- Não era um Default Permit que bloqueia só ataques conhecidos, mas uma forma de rejeitar requisições que saem da estrutura normal
- Se você está em uma corrida armamentista com os atacantes, isso é sinal de que caiu no Default Permit
- O conceito oposto, Default Deny, exige comprometimento, reflexão e entendimento na implementação, mas é uma abordagem melhor
2. Enumerating Badness: listar coisas ruins
- Enumerating Badness é a abordagem de listar tudo o que já se conhece como ruim para depois detectar ou bloquear
- No começo isso parecia possível porque havia poucos buracos de segurança conhecidos, mas por volta de 1992 as “coisas ruins” da internet já eram muito mais numerosas do que as “boas”
- Um produto típico de antivírus conhece mais de 75.000 vírus
- Considera-se que um computador pessoal tenha cerca de 30 aplicações legítimas instaladas
- Se você acompanhar essas 30 aplicações legítimas e impedir a execução do restante, pode reduzir ao mesmo tempo problemas com spyware, vírus, trojans de controle remoto e exploits de execução de código pré-instalados que quase nunca são usados
- Segundo algumas análises do setor, de 200 a 700 novas “coisas ruins” aparecem na internet todos os meses
- À objeção de que redes corporativas são complexas demais para identificar aplicações legítimas, o autor responde que, se o CTO nem sabe aproximadamente o que a tecnologia faz, então também não consegue planejar capacidade, recuperação de desastres nem segurança
- A análise de logs de produtos de firewall em 1994 começou buscando condições ruins, mas a segunda versão usou Artificial Ignorance
- Ela descarta logs que já se sabe não serem interessantes
- O que sobra é tratado como interessante
- Essa abordagem detectou condições operacionais e erros que talvez nem tivessem sido imaginados
- Antivírus, detecção de intrusão, prevenção de intrusão, segurança de aplicações e firewalls com inspeção profunda de pacotes muitas vezes dependem dessa abordagem
- Se um sistema precisa de atualizações regulares de assinaturas ou deixa passar um worm inédito, isso é sinal de Enumerating Badness
- A cura seria Enumerating Goodness, mas o autor considera que quase não existe suporte, no sistema operacional, para esse tipo de controle em nível de software
3. Penetrate and Patch: invadir e corrigir
- Penetrate and Patch é o ciclo de atacar firewalls, software, sites e afins a partir de fora para achar falhas, corrigi-las e então procurar as próximas
- Essa abordagem não cria um sistema melhor por projeto; ela apenas endurece um sistema por tentativa e erro
- Personal Observations on the Reliability of the Space Shuttle, de Richard Feynman, é uma leitura útil sobre como se deve alcançar confiabilidade em sistemas complexos
- A mensagem central está mais para “se um sistema não foi projetado para poder ser hackeado, então ele não deveria poder ser hackeado”
- A moda de divulgação de vulnerabilidades e atualizações de patch também se baseia nessa abordagem
- Pesquisadores de vulnerabilidades entendem que ajudam a comunidade ao encontrar falhas antes dos hackers e permitir sua correção
- Fornecedores entendem que fazem a coisa certa ao lançar patches antes que hackers e autores de worms explorem o problema
- Mas, se o código tivesse sido projetado desde o início para ser seguro e confiável, descobrir vulnerabilidades seria uma tarefa tediosa e pouco recompensadora
- Se o Internet Explorer teve de 2 a 3 bugs de segurança por mês durante 10 anos, é difícil dizer que Penetrate and Patch foi eficaz
- Algumas aplicações, como PostFix e Qmail, foram projetadas para modularizar e compartimentalizar privilégios e processamento, e por isso teriam um histórico muito pequeno de bugs de segurança
- Testes de intrusão sofrem da mesma limitação
- Redes com projeto fundamental ou práticas de segurança ruins continuam sendo hackeadas mesmo depois de vários testes de intrusão
- Em redes projetadas desde o início para permitir apenas certa direção, certo tráfego e servidores cuidadosamente configurados, testes de intrusão genéricos podem não fazer sentido
- Se você fica vulnerável ao “bug da semana” toda vez, está preso a Penetrate and Patch
- Software e sistemas devem ser secure by design e precisam ser projetados já considerando o tratamento de falhas
4. Hacking is Cool: a ideia de que hackear é legal
- Hacking is Cool é uma crítica à cultura que recompensa ou glamouriza hackers com stock options, livros, cursos e testes de intrusão caríssimos
- Donn Parker considerava que a computação remota eliminou, no crime, a necessidade de proximidade física, e que o anonimato e a ausência de contato com a vítima reduziram a barreira emocional para cometer crimes
- Hacking está mais próximo de um problema social do que de um problema técnico
- A internet oferece um novo espaço de atuação para pessoas com baixa sociabilidade
- Quando profissionais de segurança transformam hackers em heróis, acabam incentivando hacking de forma implícita
- A mídia às vezes retrata hackers como “whiz kids” ou “brilliant technologists”
- O fato de profissionais de segurança aprenderem técnicas de hacking também é tratado como parte dessa ideia
- Exploits e seu modo de uso envelhecem rapidamente assim que a falha correspondente recebe patch
- Isso faz a competência profissional depender da corrida armamentista de Penetrate and Patch
- Faz mais sentido aprender a projetar sistemas de segurança resistentes a hacking do que aprender a encontrar sistemas hackeáveis
- O autor prevê que “Hacking is Cool” desapareceria em 10 anos, mas não vê sinais de que o oposto, “Good Engineering is Cool”, vá substituí-la
5. Educating Users: educar usuários
- Educating Users é algo próximo de um Penetrate and Patch aplicado a pessoas
- A educação em si parece algo bom, mas, se funcionasse, já deveria ter mostrado resultado
- Vários estudos teriam mostrado que uma parcela significativa dos usuários entrega a senha em troca de um doce
- O worm Anna Kournikova é citado como caso que mostrou que quase metade da humanidade clica em qualquer coisa que pareça conter fotos nuas de uma mulher semicelebridade
- Se educação do usuário for a estratégia, talvez seja preciso “aplicar patch” nos usuários toda semana
- A verdadeira pergunta não é “é possível educar o usuário para ser mais seguro?”, mas “por que é preciso educar o usuário em primeiro lugar?”
- Por que usuários recebem anexos executáveis?
- Por que usuários esperariam um e-mail de um banco onde nem têm conta?
- O tratamento de anexos e phishing também é um problema de Default Permit
- Se todos os usuários podem receber anexos de e-mail, isso equivale a permitir por padrão tudo o que for enviado
- Uma abordagem melhor seria colocar todos os anexos em quarentena, apagar os executáveis e manter em um servidor intermediário apenas formatos de arquivo permitidos
- Usuários poderiam entrar com um navegador com suporte a SSL para buscar os arquivos, e a exigência de senha enfraqueceria imediatamente muitos mecanismos de propagação de worms
- Ferramentas gratuitas como MIMEDefang podem ser usadas para destacar anexos de e-mails recebidos, armazená-los em diretórios por usuário e substituir o anexo no e-mail pela URL correspondente
- Quando administrava uma pequena startup de segurança, o autor exigia que qualquer funcionário que quisesse usar Windows soubesse instalar e administrar a máquina por conta própria; caso contrário, não seria contratado
- A previsão é que, em 10 anos, usuários que ainda precisassem de treinamento sairiam do mercado de trabalho de alta tecnologia ou se treinariam sozinhos em casa para continuar competitivos
6. Action is Better Than Inaction: a crença de que agir é melhor do que não agir
- Executivos de TI se dividem entre “early adopters” e “pause and thinkers”, e o autor considera que os que construíram sistemas mission-critical bem-sucedidos e seguros estão mais próximos do segundo grupo
- Quando surge uma nova tecnologia, pode ser mais seguro esperar em vez de instalar imediatamente, observar os resultados de outros adotantes iniciais e só implantar quando já houver gente experiente
- Um alto executivo de TI planejou a adoção de rede sem fio na empresa como “esperar 2 anos e depois contratar alguém que já tenha implantado wireless com sucesso em uma empresa maior que a nossa”
- Nesse meio-tempo, a tecnologia se organiza melhor e o preço cai bastante
- A proposição central associada a isso é que “muitas vezes é mais fácil não fazer coisas estúpidas do que fazer coisas inteligentes”
- O conselho se estende a terceirização de segurança: adie por 1 ou 2 anos e ouça recomendações e opiniões das organizações que sobreviverem
- Em um caso de cliente que pretendia gastar muito dinheiro sem validação, sugeriu-se enviar um funcionário à conferência LISA para encontrar pessoas com experiência real de uso
- Esse funcionário pôde convidar usuários do produto para jantar e ouvir avaliações informais
- Segundo um gerente de TI, um jantar de 200 dólares evitou mais de 400 mil dólares em sofrimento técnico
- O verdadeiro “kung fu” profissional está em evitar fazer coisas estúpidas ao não fazer nada, e em conseguir que os chefes reconheçam o mérito dessa prevenção
Outras pequenas estupidezes
- “Nós não somos um alvo”
- Worms não são inteligentes o bastante para avaliar se um site ou uma rede doméstica é interessante
- “Se todo mundo usar determinado sistema operacional da moda para segurança, ficaremos seguros”
- Sistemas operacionais são complexos, portanto têm problemas de segurança, e administração de sistemas ainda não é um problema resolvido
- Mudar só para seguir a moda pode tornar mais difícil para administradores acumularem expertise ao longo do tempo
- “Temos boa segurança no host, então não precisamos de firewall”
- Se não dá para confiar no tecido da rede, toda aplicação que trafega pela rede é um alvo potencial
- O exemplo citado é o Domain Naming System
- “Temos um bom firewall, então não precisamos de segurança no host”
- Se o firewall permite que tráfego passe para os hosts que estão atrás dele, então também é preciso considerar a segurança nesses sistemas
- “Vamos colocar em produção agora e pensar em segurança depois”
- Se não há tempo para fazer direito agora, é preciso perguntar se haverá tempo para refazer depois que quebrar
- Alguns dias economizados no início podem virar anos de correções contínuas
- “Problemas ocasionais não podem ser evitados”
- O texto responde perguntando se alguém embarcaria em aviões comerciais se a indústria da aviação adotasse essa postura quando vidas estão em jogo
A postura exigida dos profissionais de segurança
- O autor considera que a segurança de computadores ficou obcecada demais com a “nova tecnologia da semana” e abandonou o bom senso
- O trabalho do profissional de segurança é questionar o senso comum e o estado atual das coisas, e, se necessário, enfrentá-los de frente
- O texto termina com a ideia de que, se o senso comum fosse realmente eficaz, a taxa de invasões bem-sucedidas deveria estar caindo
1 comentários
Opiniões do Hacker News
Lá vamos nós de novo com esse assunto: https://hn.algolia.com/?q=six+dumbest+ideas+in+computer+secu...
Há muitos pontos para destrinchar neste texto, mas o que sempre quero destacar é a posição implícita de Ranum sobre pesquisa de vulnerabilidades, à qual ele se opunha. No fim dos anos 90 e começo dos anos 2000, Marcus Ranum e Bruce Schneier eram intelectuais representativos da visão de que a divulgação de vulnerabilidades causava mais mal do que bem, e que esse trabalho deveria ser feito pelos fornecedores, não por pesquisadores externos. Essa perspectiva acabou não se sustentando; em 2002, ainda era possível colocar a pesquisa externa de vulnerabilidades com divulgação completa sob o rótulo de “hacking”, mas hoje isso não é nem um pouco o caso. As quatro grandes conferências acadêmicas de segurança, e até a literatura de criptografia, tratam de pesquisa ofensiva
Não sei se foi omitido, mas fiquei surpreso por não haver menção a senhas. Regras obrigatórias de composição, exceto tamanho mínimo, troca periódica e tentativas de “substituir senhas” me parecem essencialmente idiotas. Regras de composição levam a coisas como anotar em papel, reutilizar a mesma senha ou colocar um 1 no final; alternativas têm UX horrível ou confusa e, no fim, acabam voltando para senhas. Basta me deixar criar uma senha com pelo menos X caracteres escolhidos por mim, algo que eu consiga realmente lembrar mesmo sem celular ou computador, ou estando no exterior
suckmyDICK123!!. Mesmo assim, normalmente não são invadidos porque a taxa de tentativas de força bruta é insuficiente ou a conta é bloqueada após 5 falhas. Hoje em dia, a maioria das pessoas já sabe algo como “bots tentam senhas em velocidade sobre-humana”, e nenhuma política de senha impede escolhas ruins de senha. É um caso em que pessoas “responsáveis” desperdiçam um tempo enorme tentando resolver a realidade. Exceto por um ou dois serviços sensíveis, como bancos, dá vontade de usar a mesma senha em serviços que exigem contas à força, como 80 jogos que você experimentou por 1 minuto. Muitas vezes eles têm uma GUI separada que nem permite colar, e até dá para usar um gerenciador de senhas, mas não há grande motivo para se dar esse trabalhoHacking pode ser legal. Não no sentido de acessar dados e sistemas dos outros, mas é legal entender profundamente um sistema que eu possuo e descobrir como fazê-lo se comportar de forma inesperada a meu favor. Arrombar a fechadura do vizinho não tem graça, mas abrir a minha própria fechadura é legal; manipular um computador remoto para obter acesso indevido não tem graça, mas fazer meu próprio computador realizar algo que originalmente não era permitido é legal. A atitude de explorar as bordas do possível move o mundo para frente, e provavelmente poucas sociedades humanas bem-sucedidas celebraram permanecer dentro da caixa
Este texto tem muitos julgamentos muito ruins. Uma frase do tipo “projetei, implementei e configurei meu sistema cuidadosamente, então não preciso testá-lo” talvez seja a pior visão de segurança que já ouvi. A ideia de que “hacking é um problema social, não técnico” também se aproxima de segurança por obscuridade, e nem sempre é um problema social. Basta olhar para espionagem corporativa ou agentes estatais
O problema central geralmente é o infeliz trade-off entre usabilidade vs. segurança, e a maior parte do que foi citado aqui como ideias idiotas é resultado de sacrificar segurança para reduzir o incômodo do usuário médio. Por exemplo, permitir por padrão é péssimo para a segurança e é a causa de muitos problemas do Windows, mas os usuários detestam ter de permitir explicitamente cada novo programa. Mesmo quando a Microsoft adicionou janelas de confirmação, muita gente viu aquilo como um projeto ruim que tornava o software muito mais irritante. Foi assim que “permitir por padrão”, “enumerar coisas ruins” e “corrigir depois da invasão” viraram o padrão. Pessoalmente, acho que a própria senha é uma das ideias mais idiotas em segurança. A definição de uma boa senha é justamente algo difícil de lembrar, difícil de digitar em dispositivos sem um teclado decente e inconveniente para o usuário em quase todos os aspectos. Mas também não há uma alternativa realista. Links por e-mail comprometem tudo se o acesso ao e-mail for comprometido, e redefinição de senha geralmente é a mesma coisa. Dispositivos físicos de autenticação impedem o usuário de fazer login fora de casa ou exigem que ele carregue sempre um chaveiro/acessório, e quase todos os métodos exigem bons hábitos de segurança, mas 99,9% da população não se importa muito com isso
A afirmação de que “aprender vários exploits e como usá-los é gastar tempo aprendendo ferramentas e técnicas que ficarão obsoletas assim que forem corrigidas” está errada. Na prática, é aprender aspectos práticos junto com a teoria, e isso é muito útil
Eu tiraria “hackear é legal” desta lista e colocaria confiar no cliente. Recentemente houve mais tentativas de confiar no cliente. Exemplos disso são apps móveis exigindo prova de que o sistema operacional não foi modificado, ou a tentativa do Google de colocar um DRM parecido na web. Se o modelo de segurança de rede depende de confiar no software cliente, ele já está quebrado
Sobre “bloquear por padrão”, há a frase de que “não é muito mais difícil do que permitir por padrão e você dorme melhor à noite”; o responsável por segurança de TI pode até dormir melhor, mas o resto da empresa fica extremamente irritado porque não consegue fazer nada sem ir e voltar três vezes com o departamento de TI. E quanto mais irritadas as pessoas ficam, maior a chance de usarem gambiarras que destroem o conceito de segurança. Se você força troca mensal de senha, elas usam coisas como
password1,password2,password3. Uma boa segurança de TI não é simplesmente desconectar o cabo de rede; ela deve ser invisível e não intrusiva para o usuário, como mágicaTextos focados em segurança geralmente são escritos por pessoas que valorizam segurança ao extremo, e muitas vezes ignoram as dificuldades que uma abordagem puramente centrada em segurança impõe aos usuários de software seguro. Sempre vejo segurança como um controle deslizante entre segurança e conveniência. Um projeto totalmente seguro é tão inconveniente que quase não terá usuários, e um projeto totalmente conveniente também pode não ser seguro o suficiente e acabar chegando ao mesmo resultado. Ainda assim, o texto em geral vale a leitura, mas discordo fortemente da ideia de que seja burrice um especialista em segurança escrever exploits ou aprender a abusar de um determinado sistema. Aprendi muito mais sobre segurança estudando vulnerabilidades e exploits e implementando-os eu mesmo de forma white-hat do que estudando “projeto seguro”. É parecido com a ideia de que “para conhecer o sujeito, é preciso se tornar o sujeito”
Em grande parte, esta é uma lista péssima de 19 anos atrás. Dizer que “software e sistemas deveriam ser seguros desde a concepção e projetados já levando em conta o tratamento de falhas” significa que “em um mundo perfeito, tudo teria sido seguro desde o começo”. Isso nunca vai acontecer, então é preciso usar a técnica de descobrir e depois corrigir, que tem funcionado bem para empresas que de fato corrigem as vulnerabilidades descobertas e aprendem com os erros para melhorar práticas futuras de programação. Além disso, a maioria dos sistemas não é estática. Não se lança um sistema seguro uma vez para nunca mais atualizá-lo; a maioria dos aplicativos e sistemas é atualizada com frequência, e é aí que novas vulnerabilidades entram
scriptouonclick