Baixe o app para aproveitar ainda mais
Prévia do material em texto
Pós Graduação FUMEC – Gestão de Segurança da Informação As seis idéias mais idiotas sobre segurança de computadores por Marcus J. Ranum , expert em arquitetura e implementação de sistemas de segurança e inventor do firewall Gauntlet Tradução para o português do documento de Marcus J. Ranum , por CJr. O original (em inglês) pode ser encontrado http://www.ranum.com/security/computer_security/editorials/dumb/. Última alteração em 03 de novembro de 2005. Há muita inovação acontecendo na área de segurança – estamos inundados por uma forte correnteza de novos produtos e parece que isso tudo funciona maravilhosamente bem. A cada poucos meses, sou convidado para uma nova conferência sobre segurança de computadores, ou pedem para que eu escreva o prefácio de um novo livro. E, graças ao fato de este ser um tópico de interesse público e um “tema seguro” para políticos discorrerem, podemos esperar uma enxurrada de legislação sobre o assunto. Resumindo: segurança de computadores é definitivamente um “assunto quente”. Mas por que estamos gastando todo esse tempo e dinheiro e ainda temos problemas com isso? Deixe-me apresentar a você as seis idéias mais idiotas sobre segurança de computadores. O que são elas? Elas são as anti-boas idéias. Elas são as idiotices que fazem o seu turbo-firewall baseado em ASIC, de última geração e que custou US$100.000,00 ser transparente para os hackers. De onde vêm as anti- boas idéias? Elas vêm de tentativas canhestras de fazer o impossível (o que equivale a tentar ignorar a realidade). Freqüentemente estas tentativas idiotas são esforços sinceros de pessoas bem intencionadas ou de empresas que simplesmente não entendem toda a situação. Algumas vezes os responsáveis são aqueles bandos de empreendedores “espertos” que tentam ganhar dinheiro rápido com uma porcaria de produto bem marquetado. Em todos os casos, estas idéias imbecis são as razões fundamentais pelas quais todo aquele dinheiro que você gastou em segurança da informação vai ser desperdiçado, a menos que você de alguma maneira consiga evitá-las. 1 - Permitido por padrão Essa idéia idiota costuma aparecer em várias formas; é incrivelmente persistente e difícil de erradicar. Por que? Porque ela é tão atraente. Sistemas baseados em “Permitido por padrão” são as calorias sem vitaminas da segurança de computadores: saborosas, mas engordativas. A manifestação mais reconhecível dessa idéia idiota aparece em regras de firewall. Nos primórdios da segurança de computadores, os gerentes de rede configuravam uma conexão à Internet e decidiam torná- la segura desligando o telnet, conexões de rlogin e telnet vindas da Internet. Tudo o mais era permitido, daí o nome “Permitido por padrão”. Este procedimento iniciava uma briga sem fim entre o administrador da rede e os hackers. Suponha que apareça uma nova vulnerabilidade em um serviço que não está bloqueado – agora o administrador precisa decidir se a bloqueia ou não (tomara que ele o faça antes de ser hackeado). Muitas empresas adotaram a política do “permitido por padrão” no começo da década de 90, e se convenceram de que ela era boa porque “os hackers nunca vão se importar em nos invadir”. O advento dos vermes (worms) nessa década deveria ter sepultado essa política para sempre, mas não foi assim. Na verdade, ainda hoje muitas redes são construídas em torno da idéia de um núcleo aberto sem segmentação. Isso é “permitido por padrão”. Um outro lugar em que aparece o “permitido por padrão” é na maneira como tratamos a execução de programas em nossos sistemas. O padrão é permitir que qualquer coisa sobre a qual você clique em sua máquina seja executada, a menos que essa execução seja proibida por algo como um antivírus ou um Pós Graduação FUMEC – Gestão de Segurança da Informação bloqueador de spyware. Se você pensar sobre isso uns poucos segundos, vai entender o quão idiota é essa idéia. Em meu computador, costumo executar por volta de 15 aplicações regularmente. Provavelmente, existem umas outras 20 ou 30 instaladas, que eu uso a cada poucos meses. Ainda não consigo entender como os sistemas operacionais são tão idiotas que permitem que qualquer vírus ou spyware seja executado sem ao menos me perguntar. Isso é “permitido por padrão”. Há alguns anos atrás, trabalhei analisando os procedimentos de segurança de um website, como parte de um projeto de segurança de E-banking. Esse website tinha um balanceador de carga e era capaz de redirecionar o tráfego dependendo da URL acessada. Meu cliente queria usar o balanceador para evitar vermes e hackers redirecionando os ataques para um endereço “black-hole”. Redirecionar os ataques significaria adotar uma política de “permitido por padrão” (isto é: se não é um ataque conhecido, deixe passar). Ao invés disso, orientei-o a adotar o enfoque oposto. O balanceador foi configurado para redirecionar qualquer tráfego que não tivesse correspondente em uma lista de URLs permitidas para um servidor que tinha apenas imagens e páginas de não encontrado (404), e que tinha uma configuração especialmente “trancada”. Como era de se esperar, esse site tem resistido bem ao teste do tempo. Um sintoma claro de que um caso de “permitido por padrão” está em andamento é quando você se vê em uma briga interminável com hackers. Isto significa que você mesmo se pôs em uma situação onde o que você não sabe pode atingi-lo, e você vai se dar mal se continuar brincando de “conserta/estraga”. O oposto do “permitido por padrão” é o “proibido por padrão” e essa é realmente uma boa idéia. Implementar uma política de “proibido por padrão” demanda dedicação, esforço intelectual e compreensão, o que explica porque ela é tão pouco realizada. É mais difícil do que usar “permitido por padrão”, mas você vai dormir muito melhor à noite. 2 - Enumerando maldades N.T.: O título original desta seção é "Enumerating badness". O termo “badness” tem, nesse caso, a conotação inteligentemente irônica que M.J. Ranum tenta imprimir a todo o texto, e transmite uma grande abrangência (software realmente maldoso, somente mal feito ou mal projetado, falhas em sistemas operacionais e por aí vai). Optei então pela tradução mais literal de “maldades”. O mesmo vale para o termo “goodness”, que comtempla tanto o software inócuo quanto o bem pensado/projetado/implementado. Nos primórdios da segurança de computadores, havia apenas um número relativamente pequeno de vulnerabilidades, todas bem conhecidas. Isto tinha muito a ver com a adoção em massa do “permitido por padrão” porque, quando existiam apenas 15 maneiras bem conhecidas de se invadir uma rede, era possível pensar e examinar caso a caso esses 15 tipos de ataque e bloqueá-los. Os responsáveis pela segurança criaram então o hábito de “Enumerar Maldades” – fazer uma lista de todas as maldades existentes. Uma vez que você listasse todas elas, podia se organizar para detectá-las ou bloqueá-las. Pós Graduação FUMEC – Gestão de Segurança da Informação Figura 1: "A escalada da maldade" Por que “Enumerar Maldades” é uma idéia idiota? É idiota porque, por volta de 1992, o número de maldades na Internet começou a superar de muito o número de bondades. Para cada software inócuo e legítimo havia dezenas, centenas de malwares, vermes, exploits ou vírus. Examine um antivírus típico e você vai ver que ele tem cadastrados mais de 75000 vírus que podem invadir sua máquina. Compare esse número com os 30 softwares que tenho instalados em minha máquina, e você vai ver que parece idiota tentar controlar 75000 malwares quando até o programa mais simples consegue controlar os 30 softwares legítimos. Na verdade, se eu simplesmente permitisse que só esses 30 programas fossem executados em minha máquina (e portanto não deixasse mais nada ser executado), eu teria simultaneamente resolvido todos os problemas abaixo: • Spyware • Vírus • Cavalos de tróia • Exploits que envolvem a execução de código pré-instalado que você não usa regularmenteGraças a todo o apelo de marketing criado em torno da descoberta e anúncio de vulnerabilidades, existem (de acordo com alguns analistas da indústria) entre 200 e 700 novas maldades aparecem na Internet todo mês. “Enumerar maldades” não apenas é uma idéia idiota, ela se torna pior durante os poucos minutos do seu tempo que fiz você gastar lendo este artigo. Mas quando eu discuto esse conceito com o executivo típico de TI, ele ou ela dizem algo do tipo “Está certo, mas nossa rede empresarial é realmente complexa. Saber todas as aplicações que usamos seria impossível! O que você diz soa razoável até que você pense nisso e veja o quão absurdo é!”. Ao que eu respondo “Como você pode se denominar um CTO se não tem idéia sobre o que a tecnologia que você usa está fazendo?” Um CTO não tem que saber cada detalhe sobre todas as aplicações que são executadas na rede, mas se ele não tem nem mesmo uma vaga idéia sobre o que está acontecendo é impossível fazer um planejamento de capacidade, de recuperação de desastres, de segurança, ou virtualmente de qualquer coisa que seja de responsabilidade de um CTO. Em 1994 escrevi um firewall que precisava fazer algumas análises dos logs do sistema que alertariam o administrador no caso de alguma condição inesperada acontecer. A primeira versão usava “enumeração de maldades” (eu também era idiota), mas a segunda versão já implementava o que eu denominei “Ignorância Artificial” – um processo através do qual você descarta as entradas do log que sabe não serem interessantes. Se ainda sobrou algo depois de jogar fora tudo o que você sabe que não é interessante, então o resto tem que ser interessante. Este método funcionava surpreendentemente bem, e detectou um bom número de erros e condições operacionais interessantes que eu simplesmente nunca teria procurado encontrar. “Enumerar maldades” é a idéia por trás de um imenso número de produtos e sistemas de segurança, de antivírus a sistemas de detecção de intrusos, prevenção de intrusões, segurança de aplicações e firewalls de inspeção em profundidade de pacotes. O que esses programas e dispositivos fazem é assumir a responsabilidade de avaliar o que é legítimo. Ao invés de você mesmo usar seu tempo para fazer isso, é mais fácil pagar US$29,95 por ano para alguém que vai tentar manter uma lista exaustiva de todos os males do mundo. Exceto se, infelizmente, o seu expert em maldades vai ganhar US$ 29,95 por ano pela lista de vírus, outros US$ 29,95 por ano pela lista de spywares e você vai comprar um firewall pessoal que controla as aplicações de rede. A partir do momento em que você estiver pagando outras pessoas para enumerar todos os malwares que podem vir a ter contato com seu sistema, você mais que dobrou os custos com seu sistema operacional “quase sem custo”. Um sintoma claro de que um caso de “Enumerando Maldades” está em curso é você ter um sistema ou software que necessita de atualizações regulares, ou um sistema que deixa passar um novo worm que não existia até o momento. A cura para “Enumerar Maldades” é, é claro, “Enumerar Bondades”. De maneira Pós Graduação FUMEC – Gestão de Segurança da Informação surpreendente, não existe virtualmente nenhum suporte de software nos sistemas operacionais para realizar este controle. Eu tentei usar o “Controle de Execução de Programas” do Windows XP, mas ele é orientado para “Enumerar Maldades” e é, ele próprio, uma implementação idiota de uma idéia idiota. Pensando bem, “Enumerar Maldades” é um caso especial de “Permitido por Padrão” – nossa idéia idiota número 1. Mas acontece tanto que acaba merecendo ser uma classe separada. 3 - Invadir e corrigir Há um provérbio que diz: “Você não pode fazer uma bolsa de seda a partir de uma orelha de porco.” Isso é bastante verdadeiro, a menos que você use tanta seda para remendar a orelha do porco que ela acabe completamente substituída. Infelizmente, quando um software com bugs é consertado, esse conserto é quase sempre realizado adicionando-se código novo, ao invés da remoção dos velhos bits da orelha do porco. “Invadir e corrigir” é uma idéia que é melhor expressada em BASIC: 10 GOSUB PROCURAR_POR_BURACOS 20 IF BURACO_ENCONTRADO = FALSE THEN GOTO 50 30 GOSUB CONSERTA_BURACO 40 GOTO 10 50 GOSUB PARABENS 60 GOSUB SER_EVENTUALMENTE_HACKEADO 70 GOTO 10 Em outras palavras, você ataca seu firewall/software/website/qualquer coisa de fora para dentro, identifica uma falha, conserta a falha e volta a procurar. Um de meus colegas programadores chama esse processo de “polir cocô” porque, na opinião dele, isso não faz seu código menos fedorento a longo prazo, mas os gestores apreciam sua aparência melhorada e brilhante no curto prazo. Em outras palavras, o problema com “Invadir e Corrigir” é que ele não faz o seu código/implementação/sistema melhor por design, mas simplesmente fortalecido por tentativa e erro. O relatório de Richard Feynnman, “Observações Pessoais sobre a Confiabilidade do Ônibus Espacial” era leitura obrigatória para os engenheiros de software que eu contratava. Ele contém considerações profundas sobre expectativa de confiabilidade e como ela é obtida em sistemas complexos. Resumidamente, o significado para os programadores é: “Seu sistema não será hackeado a menos que ele seja percebido como possível de ser hackeado.” “Invadir e Corrigir” acontece em todos os lugares, e é a idéia idiota primária por trás desse frenesi de descoberta de vulnerabilidades e atualizações de segurança, que vem se arrastando pelos últimos 10 anos. A premissa dos “caçadores de vulnerabilidades” é de que eles estão ajudando a comunidade a encontrar buracos nos softwares e consertando-os antes que os hackers os encontrem e os explorem. A premissa dos fornecedores é que eles estão fazendo a coisa certa ao empurrar as atualizações para consertar os bugs antes que os hackers e os criadores de vermes possam agir para aproveitá-los. Neste cenário, ambas as partes estão sendo idiotas porque se os fornecedores estivessem escrevendo código que fosse concebido para ser seguro e confiável, então a descoberta de vulnerabilidades seria uma tarefa tediosa que não valeria a pena! Deixe-me explicar de maneira diferente: se “Invadir e Corrigir” fosse uma idéia efetiva, já não haveria bugs de segurança no Internet Explorer . Há quanto tempo isso acontece? Dois ou três meses ou dez anos? Se você avaliar as aplicações mais usadas da Internet, vai ver que existem várias delas que apresentam vulnerabilidades de segurança constantemente. Existem também umas poucas, como o PostFix e o Qmail, que foram desenhadas para ser compartimentalizadas em si mesmas, com permissões e processamento modularizados e que – nenhuma surpresa aqui – tem históricos de pouquíssimos bugs. A mesma lógica se aplica a “testes de invasão”. Eu conheço redes que foram “testadas por invasão” n vezes Pós Graduação FUMEC – Gestão de Segurança da Informação e ainda assim são continuamente hackeadas em pedaços. Isso acontece porque seu design (ou suas práticas de segurança) são tão fundamentalmente falhos que nenhuma quantidade de polimento de cocô vai manter os hackers de fora. Eles somente mantêm os auditores e os gerentes longe do pescoço do administrador de rede. Eu também conheço outras redes que são, literalmente, imunes a “testes de invasão”, porque foram desenhadas desde o começo para serem permeáveis somente em determinadas direções, para somente determinados tipos de tráfego, tráfego esse que é destinado a servidores cuidadosamente configurados executando software cuidadosamente securitizado. Executar um “teste de invasão” para encontrar bugs no Apache é completamente sem sentido quando esse servidor está executando um programa C customizado em uma partição segura (trancada) de um sistema operacional embutido. “Invadir e corrigir” é sem sentido porque você sabe que ou vai encontrar uma fila sem fim de bugs ou não vai achar nada compreensível. Ações sem sentido são idiotas. Umsintoma claro de que você tem um caso de “Invadir e corrigir” em andamento é quando descobre que seu sistema é sempre vulnerável ao “bug da semana”. Isto significa que você mesmo se colocou em uma situação na qual a cada vez que os hackers inventam uma nova arma, ela funciona contra você. Isso não soa idiota? Seu software e seus sistemas deveriam ser seguros por design e desenhados com tolerância a falhas sempre em mente. 4 - Hacking é Cool Uma das melhores maneiras de se livrar de baratas em sua cozinha é espalhar migalhas de pão debaixo do forno, certo? Errado! Essa é uma idéia idiota. Uma das melhores maneiras de desencorajar a prática do hacking na Internet é dar ações preferenciais aos hackers, comprar os livros que eles escrevem sobre seus como explorar as falhas de segurança, tomar aulas de “kung fu hacker extremo” e pagar a eles dezenas de milhares de dólares para que eles façam “testes de invasão” em nossos sistemas, certo? Errado! “Hacking é Cool” é uma idéia realmente idiota. Quando eu ainda estava aprendendo a andar, Donn Parker pesquisava os aspectos comportamentais do hacking e da segurança de computadores. Ele fala sobre isso melhor do que eu jamais conseguiria: “A computação remota liberta os criminosos do pré-requisito histórico de terem de se aproximar de seus crimes. Anonimato e libertação do confronto pessoal com a vítima aumentam a facilidade emocional de se cometer um crime, ou seja, a vítima era somente um computador, não uma pessoa ou empresa de verdade. Pessoas tímidas podem se tornar criminosos. A proliferação de sistemas e modos de uso idênticos e a automação dos negócios não só tornaram possível como melhoraram o custo econômico de automatizar crimes e construir ferramentas e scripts criminosos de grande eficiência.” Escondida nesta observação de Parker está a consciência de que o hacking é um problema social . Não é, de maneira nenhuma, um problema tecnológico. “Pessoas tímidas podem se tornar criminosos”. A Internet proporcionou todo um novo espaço para a manifestação da personalidade mal socializada. A quarta coisa mais idiota que os praticantes de segurança da informação podem fazer é encorajar implicitamente os hackers entronizando-os. A mídia interfere diretamente nisso, retratando hackers como “jovens magos” e “tecnólogos brilhantes” – é claro que se você é um repórter da CNN, qualquer um que consiga instalar o Linux provavelmente é qualificado como um “tecnólogo brilhante”. Acho interessante comparar as reações sociais a hackers (“jovens magos”) com as provocadas pelos spammers (“vigaristas vulgares”). Comove-me ver que os spammers, phishers e outros scammers adotam os próprios hackers e suas técnicas – isto vai fazer mais para reverter o ponto de vista da sociedade do que qualquer outra coisa que pudéssemos fazer. Se você é um praticante de segurança, ensinar a você mesmo como hackear também faz parte do princípio idiota de “Hacking é Cool”. Pense sobre isso por alguns minutos: ensinar a você mesmo um punhado de exploits e como usá-los significa que você está investindo o seu tempo em aprender várias técnicas e ferramentas que vão ser inúteis assim que alguém tapar o buraco específico que elas atacam. Significa que Pós Graduação FUMEC – Gestão de Segurança da Informação você fez parte do seu conhecimento profissional dependente do princípio de “Invadir e Corrigir” e que vai participar da briga sem fim com os hackers se quiser manter esse conhecimento atualizado. Não seria mais sensato aprender como desenhar sistemas de segurança que fossem à prova de hackers do que aprender como identificar quais sistemas de segurança são idiotas? Minha previsão é que a idiotice “Hacking é Cool” será uma idéia morta daqui a 10 anos. Gosto de fantasiar que ela será substituída pela sua idéia oposta “Boa Engenharia é Cool”, mas até agora não há sinais de que isso vai mesmo acontecer. 5 - Educar Usuários O princípio “Invadir e Corrigir” pode ser aplicado aos seres humanos da mesma maneira que o aplicamos antes ao software, sob a forma de educação de usuários. Vista superficialmente, a idéia de “Educar Usuários” não parece idiota: educação é sempre boa. Vendo por outro lado, essa idéia é como “Invadir e Corrigir”: se tivesse que funcionar, já teria funcionado . Existem numerosos estudos interessantes que indicam que um percentual significativo de usuários vai trocar sua senha por um doce, e o worm Anna Kournikova mostrou-nos que aproximadamente metade da humanidade vai clicar em qualquer coisa que alegue conter figuras de mulheres semi-famosas nuas. Se “Educar Usuários” é a estratégia em que você está planejando embarcar, prepare-se para “atualizar o software” de seus usuários toda semana. Isso é idiota. A questão real não é “podemos educar nossos usuários para serem mais eficientes em segurança?” e sim “por que precisamos educar nossos usuários em qualquer coisa?” Em certo sentido, este é outro caso especial de “Permitido por padrão” – porque os usuários baixam anexos executáveis? Porque usuários aceitam receber e-mails de bancos nos quais não possuem contas? Muitos dos problemas que podem ser solucionados através da educação de usuários são auto-solucionáveis no decorrer do tempo. Quando uma nova geração de trabalhadores alcançar o mercado, eles virão com um ceticismo sadio sobre phishing e engenharia social pré-instalado. Lidar com coisas como anexos e phishing é outro caso de “Permitido por padrão” – nossa idéia idiota favorita. Afinal de contas, se você permite que todos os seus usuários recebam anexos em seu e-mail, você está “Permitindo por Padrão” que qualquer coisa seja enviada a eles. Uma idéia melhor seria simplesmente colocar todos os anexos em quarentena assim que eles chegam ao servidor, apagar todos os executáveis imediatamente e armazenar os poucos tipos de arquivos que você quiser permitir em um servidor separado, ao qual os usuários podem conectar-se usando um navegador com SSL habilitado e baixá-los (solicitar uma senha obrigatória vai impedir um bocado de mecanismos de propagação de worms de imediato). Existem ferramentas grátis como o MIMEDefang que podem ser facilmente configuradas para retirar anexos de e-mails, salvá-los para um diretório específico do usuário e substituir o anexo por uma URL para o arquivo retirado. Porquê educar seus usuários para lidar com o problema se você pode enfiar uma estaca direto no coração dele? Quando eu era o CEO de uma pequena startup que trabalhava com segurança de computadores nós não tínhamos um administrador de sistemas Windows. Todos os funcionários que queriam executar o Windows tinham de saber instalá-lo e gerenciá-lo eles mesmos , ou não seriam nem contratados. Minha previsão é que daqui a 10 anos os usuários que precisarem de treinamento ou estarão totalmente fora da força de trabalho de alta tecnologia ou farão sua própria qualificação em casa para permanecerem competitivos. Meu palpite é que essa qualificação vai incluir o conhecimento necessário para saber que não se deve abrir anexos esquisitos de remetentes desconhecidos. 6 - Ação é Melhor que Inação Executivos de TI parecem ser divididos em duas categorias: os “pioneiros” e os “paro e penso”. Durante minha carreira, tenho notado que dramaticamente poucos “pioneiros” constroem sistemas de missão Pós Graduação FUMEC – Gestão de Segurança da Informação crítica seguros com sucesso. Isto é porque, de alguma maneira, eles acreditam que “Ação é Melhor que Inação”, ou seja: se apareceu uma nova tecnologia da moda , o melhor é instalá-la agora mesmo ao invés de esperar, pensar no assunto, acompanhar o que está acontecendo com outros pioneiros e então utilizá-la uma vez que esteja estudada e já tenha sua primeira geração de usuários experientes. Eu conheço um executivo sênior de TI – um dos “paro e penso” – cujo plano para a migração de sua rede corporativa para wireless era “esperar 2 anos e contratar um cara que tenha feito com sucesso uma migração wirelesspara uma empresa maior do que a nossa.” Nesse prazo, não somente a tecnologia estará mais estudada mas será também muito, muito mais barata. Que estratégia fantasticamente brilhante! Há um corolário importante para a idéia idiota “Ação é Melhor que Inação”: “Geralmente é mais fácil não fazer alguma coisa idiota do que fazer algo inteligente.” Na realidade, Sun Tzu não escreveu isso em seu livro a “Arte da Guerra”, mas se você disser a executivos de TI que ele o fez, eles vão levá-lo muito mais a sério quando você aconselhá-los a tomar uma atitude mais judiciosa e profunda sobre a adoção da nova tecnologia da moda. Tenho aconselhado a muitos dos meus clientes “espere um ano ou dois antes de terceirizar suas demandas de segurança e então peça as recomendações e opiniões dos sobreviventes calejados e ensangüentados – se houver algum.” É possível reconhecer a idéia idiota “Ação é Melhor que Inação” espalhada por redes corporativas, e ela tende a se correlacionar com os gerentes seniores de TI, que tomam suas decisões de compra lendo pesquisas do Gartner e catálogos de fornecedores. Se você está subordinado a um desses gerentes, espero sinceramente que tenha apreciado este artigo, porque você está provavelmente muito mais familiarizado com a idiotice do que eu. Uma técnica de kung-fu gerencial extremamente útil e que deve ser lembrada se você estiver lidando contra um “pioneiro” é recorrer aos seus colegas. Há muitos anos, tive um cliente que estava se preparando para gastar uma montanha de dinheiro com uma tecnologia sem antes testá-la operacionalmente. Sugeri imediatamente ao executivo de TI responsável pelo processo que enviasse um de seus profissionais a uma conferência importante (no caso a LISA), onde ele teria a chance de encontrar-se com algum participante que tivesse tido experiência prática na tecnologia em questão. Propus que, nessa conferência, ele colocasse uma mensagem num quadro de avisos, dizendo: "Você tem experiência prática com a tecnologia xyz da empresa pdq.com? Se tem, estou autorizado a levá-lo para jantar no 'Ruth´s Cris' se você prometer repassar as informações técnicas de como foi essa experiência. Manterei sigilo. Contate fulano, etc.". Esse executivo confessou depois que um jantar de US$ 200,00 tinha poupado à empresa mais de gastar mais que US$ 400.000,00 em um infernal trauma tecnológico. É realmente mais fácil não fazer algo idiota do que fazer alguma coisa inteligente. O truque é que quando você evitar fazer algo idiota, esteja certo de fazer com que seus superiores compreendam que você evitou passar por uma região de areia movediça especialmente traiçoeira, e que deve receber os bônus por ter sido inteligente. Essa não é a mais elevada forma do kung-fu profissional: receber bônus por não ter feito nada?! Idiotices menores As idéias a seguir não merecem o status de “mais idiotas”, mas são bastante ruins e merecem ser mencionadas: • "Não somos um alvo" - sim, vocês são. Worms não são espertos o bastante para perceber que o seu site ou rede corporativa não são interessantes. • "Todo mundo estaria seguro se instalasse o <tipo_de_segurança_da_moda_neste_mês>" - não, não estariam. Sistemas operacionais tem problemas de segurança porque são complexos e sua administração é um problema ainda sem solução. Até que alguém resolva o problema da administração de sistemas, mudar para a tecnologia do mês vai somente piorar as coisas, já que se Pós Graduação FUMEC – Gestão de Segurança da Informação torna mais difícil para os seus administradores de sistemas atingir níveis mais altos de expertise (que dependem do tempo de uso da tecnologia). • "Não precisamos de um firewall porque temos segurança nas estações" - não, vocês não tem. Se sua rede é insegura, cada uma das aplicações que passa pela rede é um alvo de ataques em potencial. 3 palavras: Domain Naming System. • "Vamos colocar isso em produção, depois implementamos sua segurança" - não, vocês não vão. A pergunta que você deve fazer a si mesmo é: "Se não tenho tempo para corrigir isso agora, vou ter tempo quando o problema já tiver acontecido?" Às vezes, construir um sistema que está constantemente precisando de reparos significa que você vai gastar anos investindo em polir cocô porque não quis gastar alguns dias fazendo o trabalho direito na hora certa. • "Não podemos impedir problemas ocasionais." - sim, vocês podem. Você viajaria de avião se pensasse que a indústria aeronáutica pensa dessa maneira sobre a sua vida? Acho que não. Adeus e boa sorte Tentei manter a leveza deste texto, mas minha mensagem é séria. Segurança de computadores é uma área que tem amado demasiadamente a “tecnologia da semana” e esqueceu-se do senso comum. Seu trabalho como praticante de segurança é perguntar – senão desafiar – o entendimento convencional e o status quo. Afinal de contas, se o entendimento convencional estivesse funcionando, a taxa de sistemas sendo comprometidos estaria baixando, não é? mjr. Morrisdale , PA 01/09/2005 (Um grande obrigado a Abe Singer e Tina Bird for por fornecer algumas das idéias idiotas descritas, e a Paul Robertson e Fred Avolio pela atuação como testadores) Perguntas 1) Descreva com suas palavras 3 idéias que você considera importante neste texto. 2) Você concorda com as colocações do autor? Por quê? 3) A partir deste texto, descreva 3 mudanças que precisam ocorrer no mercado mundial de tecnologia para melhorar a segurança em TI. 4) O que você, como futuro analista de sistemas, pode fazer para melhorar a segurança de TI? 5) Descreva qual seria seu comportamento baseado no texto acima em um ambiente com múltiplos sistemas operacionais e aplicações?
Compartilhar