Ser demitido de um emprego focado em segurança da informação é um evento raro. Contudo, há algumas maneiras de acelerar um processo de demissão. Não falamos de pequenos deslizes, afinal, todo trabalho pressupõe uma série de falhas menores com o qual conseguimos conviver em nosso dia a dia dentro da companhia e até fazem parte da natureza complexa de algumas atividades.
Agora, a medida que a tecnologia fica mais abrangente, os responsáveis pela TI assumem o desafio de manter as coisas em ordem, as informações seguras, o risco mitigado. A pressão aumenta para que as defesas sejam fortes o suficiente para que hackers não consigam avançar sobre as organizações.
Confie em suas habilidades, siga diretrizes corporativas e se concentre no básico. Essa é a fórmula simples para ter uma carreira longa em segurança da informação. Ajude a organização a fortificar pontos de defesa e você se destacará. Agora, siga os erros abaixo e, possivelmente, terá a emoção de procurar um novo emprego.
Erro número um: destruir funcionalidades críticas de negócio
Todo profissional de segurança sabe intuitivamente que descarrilar uma funcionalidade crítica de negócios é um suicídio. Aliás, seria muito melhor deixar hackers entrarem na companhia do que interromper um sistema vital da organização. Ok, isso pode parecer contraditório, mas lembre-se: tornar o ambiente “mais seguro” não é a prioridade número 1 de uma empresa.
Mesmo depois de um ataque de hackers particularmente desagradável – com roubo de senhas, comprometimento da rede, acesso a dados – a alta administração possivelmente ficará mais preocupada com a interrupção de sistemas críticos do que se assegurarem que os invasores não estão mais lá.
De fato, há até um nome para essa estratégia: Assuma falha. Trata-se de uma abordagem na qual se reconhece a atividade maliciosa para sempre estar presente em seu ambiente e todos devem conduzir os negócios como de costume de qualquer maneira. É uma jogada arriscada, com a alta administração apostando que apesar de tudo o que acontece por causa dos hackers, o dano será menor do que o custo do que precisaria ser feito para garantir que o hacker se foi para sempre (se é que isso é mesmo possível). O jogo funciona na maioria das vezes – até que o atacante faz com que centenas de milhões de dólares em danos, o público descobre, e o ataque está diretamente ligada a um detalhe que deveria ter sido investigado, mas não foi.
Mas se você inesperadamente derrubar funcionalidade crítica de negócios por mais do que um ou dois dias devido a um novo processo de segurança, terá que enviar currículos o mais rápido possível.
Lições aprendidas: Saiba o que é fundamental para o negócio e não interrompa, a menos que não fazê-lo irá resultar em mais danos.
Erro número dois: tirar o acesso do CEO a qualquer coisa
CEOs são os reis e a empresa é seu reino. Independentemente de saber se eles realmente precisam de acesso a um recurso, se você, de alguma, remover isso do principal executivo de sua organização, é bem provável que sua cabeça esteja em risco. E, praticamente todo profissional de segurança da informação coleciona histórias curiosas sobre bloqueios a determinados sites que geraram reclamações acaloradas.
Lição aprendida: torne o acesso do CEO o mais fácil possível (mantendo o nível necessário de segurança).
Erro número três: ignorar um evento crítico segurança
O caso redente de violação de dados da Target ensinou alguma coisa: ignorar um evento crítico pode ser perigoso para o seu emprego. Como se vê, o software de segurança da companhia havia detectado a instalação de um Trojan. A equipe de segurança, contudo, considerou (incorretamente) a mensagem de log de eventos como um “falso positivo”. Em vez de alertar a gestão que a empresa estava sob ataque, todos permaneceram em silêncio enquanto o estrago era feito. A invasão desencadeou um prejuízo de centenas de milhões de dólares, forçou a demissão do CEO e do CIO, trouxe desconfiança de clientes.
Mas, qualquer um de nós pode atirar pedras? Quem nunca confiou que um log de erros poderia ser uma falha de leitura e fez “vista grossa”? Sistemas de armazenamento de eventos de monitoramento são medidos em terabytes e petabytes precisamente porque o registro disso é uma ciência inexata. Os logs são construídos para acumular falsos positivos no montante de um milhão de não-eventos para cada ataque real que fica registrado.
No caso da Target, o evento ignorado havia registrado que um novo executável estava sendo carregado e instalado. Alguém, analisando os logs, acreditou ser uma atualização prevista no sistema de ponto de venda. Assim, a empresa a ignorou um problema que acabou bastante sério.
Se o CEO e CIO se foram, você pode apostar que o empregado que disse a todos para ignorar o evento também “já era”.
Lição aprendida: Definir os eventos de segurança críticos que são mais propensos a indicar a atividade maliciosa e sempre pesquisá-los para a sua conclusão final quando eles ocorrem. Você não pode perseguir todo falso positivo em potencial, mas deve saber quais são os mais letais e mantê-los em seu radar.
Erro número quatro: brincar com dados confidenciais
Se o CEO é o rei da empresa, o administrador da rede é o rei da rede. Sabemos que muitos administradores de rede já olharam dados que não tinham permissão para ver. Alguns deles, além de espiarem informações que não tinham autorização, gabam-se de terem feito isso – assim como não deveriam ficar surpresos quando o departamento de recursos humanos, ao saber de tal atitude, pediu seu desligamento das companhias.
Lições aprendidas: Não acessar dados que não têm permissão válida para ver bem como ajudar os usuários a criptografarem informações pessoais.
Erro número cinco: invadir privacidades
Invadir a privacidade de uma pessoa é outra maneira infalível de colocar o emprego em risco, e não importa o quão pequeno ou inocente o incidente possa parecer.
Certa vez, um funcionário de um hospital soube que uma celebridade estava internada lá. Usando recursos de tecnologia, ele fez uma busca SQL e confirmou a informação. Ele não espalhou essa informação. Aliás, não contou para ninguém. Contudo, alguns dias depois, alguém do time de enfermagem vazou para a imprensa que uma celebridade estava internada. A gestão do hospital pediu uma auditoria de quem acessara os dados da celebridade. Com medo, nosso amigo resolveu ser honesto e confessar o que fizera, o que não evitou que fosse demitido.
Lição aprendida: a privacidade tornou-se um dos principais problemas de segurança da informação atualmente. Há alguns anos, era aceitável que administradores tivessem acesso a um determinado sistema e pudessem fazer consultas eventuais aos registros sem uma necessidade específica. Esses dias acabaram. Os sistemas atuais acompanham e mapeiam cada acesso e, se alguém vê coisas que não deveria, isso vai ficar registrado e a demissão é eminente.
Erro número seis: usar dados reais em um sistema de teste
Ao testar ou implementar novos sistemas, montes de dados de ensaios devem ser criados ou acumulados. Uma das maneiras mais simples de fazer isso é copiar um subconjunto de registros reais para o sistema de teste. Milhões de equipes de aplicativos tem feito isso por gerações. Agora, é preciso ter em mente que utilizar dados reais em sistemas de teste exigem as mesmas regras de segurança e privacidade do ambiente em produção.
No mundo da privacidade atual, é prudente criar dados falsos para executar teste. Afinal de contas, sistemas de teste raramente são tão bem protegidos quanto os sistemas em produção. Hackers sabem disso e é uma fraqueza que gostam de explorar.
Lição aprendida: ou criar dados falsos para seus sistemas de teste ou fortalecer esses sitemas de teste com regras rígidas de segurança aplicadas em ambientes de produção.
Erro número sete: banalizar a vulnerabilidade
Uma das piores coisas que você pode fazer para sua carreira é chorar com muita frequência. Todos os anos, alguns dos milhares de vulnerabilidades recém-descobertas tornam-se “um grande problema” para times de TI. Este ano tivemos o Heartbleed e o Shellshock, que mereceram atenção e devida correção.
Mas sempre haverá um número significativo de vulnerabilidades que os colegas e os meios de comunicação apontarão como um buraco crítico que irá inviabilizar a sua rede e sistemas. É preciso experiência e habilidade para reconhecer o que realmente precisa se preocupar. Se você correr em pânico com cada última “grande vulnerabilidade”, corre também o risco de ser visto como alguém que não conhece o seu trabalho, não sabe discernir as verdadeiras ameaças para o seu negócio e não deve ser levado a sério – mesmo quando o alarme coincide com uma vulnerabilidade que sua empresa deve efetivamente prestar atenção. Ser o “chorão” pode não causar demissão, mas impedir e trazer obstáculos para que cresça na carreira.
Lição aprendida: priorizar corretamente as vulnerabilidades e tenha cuidado para não minar sua credibilidade com os colegas com falsos alarmes.
Deixe um comentário