A espera

Na semana seguinte começou o curso de formação para os novos analistas do Banco Central. Era um curso que servia como uma introdução ao que é o Banco Central, ao que ele faz e também incluía apresentações sobre alguns processos de trabalho comuns a todos os funcionários do banco. Durante duas semanas ficamos reunidos com todos os novos contratados de diversas áreas. Esse período tinha também um papel social importante, porque permitia que a gente conhecesse pessoas que talvez não tivéssemos oportunidade de encontrar novamente quando o trabalho começasse de fato e cada um fosse para o seu departamento.

Depois do curso de formação houve um período de espera até que fosse feita a convocação formal dos novos analistas e pudéssemos começar oficialmente no órgão. O problema era que não havia uma definição de quanto tempo levaria entre o final do curso e a data de início. Ainda por cima, eu e a Gisele tínhamos passado no mesmo concurso, então estávamos sem emprego desde o começo do curso de formação. Como o banco acabou demorando mais do que o esperado para nos chamar, começamos a ter alguma preocupação com as nossas finanças. A parte boa foi que esse período de espera entre os dois empregos coincidiu com a Copa do Mundo de 2006. Isso acabou me permitindo assistir a quase todos os jogos da Copa, coisa difícil para quem está trabalhando.

Com a demora do Banco Central em nos chamar e com as férias escolares das crianças, começamos a pensar em alternativas. Acabamos decidindo passar um tempo na casa dos nossos pais. Ficar por lá saía mais barato do que viajar para qualquer outro lugar, funcionava como uma espécie de férias para as crianças e ao mesmo tempo ajudava a reduzir os nossos custos. Paralelamente, ativamos alguns contatos que ainda tínhamos em Belo Horizonte para ver se conseguíamos algum tipo de trabalho freelance. Acabamos conseguindo alguns trabalhos de treinamento e consultoria em um projeto da UFMG no qual a Gisele já tinha trabalhado quando moramos em Belo Horizonte. A minha parte foi ministrar um treinamento básico sobre desenvolvimento seguro e testes de segurança em sistemas web. Pelo que me lembro, tudo correu bem e ainda conseguimos ganhar algum dinheiro nesse período. O mais curioso foi que, durante o treinamento da equipe de testes, o pessoal ficou bastante empolgado com a possibilidade de encontrar problemas de segurança nos sistemas. Esse trabalho também acabou me dando a impressão de que havia muito pouco material sobre segurança no desenvolvimento de software, principalmente em português. Mais tarde eu acabei escrevendo algumas coisas sobre o assunto.

Depois de bastante espera, o Banco Central finalmente marcou a data de início dos novos analistas. Foi um grande alívio. Ainda assim teríamos que trabalhar um mês antes de receber o primeiro salário, mas já era reconfortante saber que voltaríamos a ter uma renda estável e suficiente para manter a família. Como eu tinha passado bem classificado no concurso e já conhecia algumas pessoas dentro do Banco Central, consegui ser alocado no time de segurança da informação dentro do departamento de TI. O time era responsável por duas grandes áreas: uma era a segurança de redes e administração de firewalls e a outra era segurança e administração da infraestrutura de e-mail do banco. Eu fui colocado na área de administração de firewalls. O Banco Central utilizava Check Point e eu não tinha muita experiência com essa plataforma, mas aprender a lidar com a interface gráfica da ferramenta não foi difícil, já que eu dominava bem os conceitos básicos de redes e segurança.

O time também era responsável por alguns projetos especiais que envolviam componentes de segurança da informação, como transmissão segura de arquivos, administração do antivírus de todos os computadores do banco, proteção de dados e avaliação de segurança dos sistemas desenvolvidos internamente. Logo que comecei a trabalhar ali, passei a conversar com os colegas sobre possíveis melhorias e um dos temas que discutimos foi a realização de testes de segurança nos sistemas web desenvolvidos dentro do banco. Naquele momento praticamente não existiam testes de segurança para os sistemas internos. Começamos então a experimentar algumas ferramentas de teste de aplicações web, como o Paros Proxy, e a fazer testes básicos nos sistemas. Um dos primeiros testes que fizemos foi de sequestro de sessão. Era relativamente fácil capturar os cookies de um usuário e utilizá-los para obter acesso indevido ao sistema. Aos poucos fomos aprendendo mais e evoluindo esse trabalho, até o ponto em que o banco acabou contratando uma empresa terceirizada para realizar testes de intrusão regulares nos sistemas.

A TI do Banco Central tinha muitas características herdadas da época dos mainframes. Apesar do alto custo desse tipo de infraestrutura, havia também aspectos interessantes em termos de maturidade operacional e segurança que vinham dessa tradição. Um exemplo era o sistema de autenticação e controle de acesso. Era um sistema bastante elaborado que permitia um controle muito granular sobre os acessos que cada funcionário tinha em cada sistema. Do ponto de vista de desenvolvimento ele era praticamente plug and play. O desenvolvedor precisava apenas utilizar as bibliotecas corretas e definir os perfis de acesso dentro do sistema. O trabalho principal era decidir quais funcionalidades deveriam estar associadas a cada perfil, não implementar os mecanismos de segurança propriamente ditos.

Nessa época o Banco Central também começou a fornecer laptops para alguns funcionários, principalmente para aqueles que trabalhavam fora da sede do banco. Áreas como fiscalização, por exemplo, visitavam instituições financeiras presencialmente e para esse tipo de trabalho os laptops eram bastante úteis. Ao mesmo tempo havia uma preocupação com a segurança dos dados armazenados nesses equipamentos. Esse tema acabou se tornando um projeto para o time de segurança. Eu já tinha experiência com um software de criptografia de disco chamado TrueCrypt e sempre gostei da ferramenta. Sugeri que avaliássemos o uso do TrueCrypt e fizemos alguns testes. A conclusão foi que o software funcionava bem, mas não possuía algumas funcionalidades importantes para um ambiente corporativo como o do Banco Central. Como o software era de código aberto, meu chefe me pediu para avaliar se seria possível adaptá-lo às nossas necessidades.

Eu consegui fazer alguns ajustes e incluir algumas funcionalidades adicionais. O problema é que essas modificações eram muito específicas para o ambiente do Banco Central e dificilmente seriam aceitas pelos mantenedores do projeto. Isso significaria manter uma versão própria do software, um fork dedicado apenas ao nosso uso, o que implicaria um esforço de manutenção considerável ao longo do tempo. Ao mesmo tempo o Windows começou a incluir o BitLocker, que era totalmente integrado ao sistema operacional e à infraestrutura de Active Directory. Fizemos uma nova avaliação e acabamos decidindo usar o BitLocker. Esse episódio acabou sendo uma boa lição, porque nem sempre vale a pena modificar um software de código aberto só porque é tecnicamente possível. Existe um custo de manutenção que precisa ser levado em conta.

Enquanto eu trabalhava na área de segurança, a Gisele estava no time responsável pelos processos de desenvolvimento de software do Banco Central. Como eu sempre tive interesse em segurança no desenvolvimento de software, achei que poderíamos fazer algum projeto em colaboração. Naquela época eu estava estudando métodos de taint analysis em software. A ideia é verificar se os dados recebidos de fontes externas foram devidamente validados antes de serem utilizados pelo sistema, seja para armazenamento em banco de dados ou para exibição ao usuário. O Banco Central utilizava Java e eu tinha encontrado uma ferramenta que realizava taint analysis em código Java e que me pareceu bastante interessante. Conversei com a Gisele e acabamos montando um projeto para implantar esse tipo de análise no processo de desenvolvimento do banco.

Fizemos a implantação acreditando que seria um grande sucesso, mas a reação dos desenvolvedores foi bastante negativa. A ferramenta tinha tendência a gerar muito ruído, apontando muitos problemas que nem sempre eram realmente relevantes. Além disso o processo que definimos exigia que os desenvolvedores justificassem cada alerta gerado pela ferramenta, o que criava uma carga de trabalho adicional considerável. Com o aumento das reclamações e com a dificuldade de ajustar a ferramenta para reduzir os falsos positivos, acabamos abandonando a iniciativa. Nossa colaboração nesse projeto acabou fracassando e, olhando em retrospecto, talvez um dos motivos tenha sido justamente a nossa proximidade. Tivemos confiança demais um no outro e acabamos não fazendo a avaliação crítica que o projeto exigia. Implementamos tudo muito rapidamente e sem testes suficientes, o que acabou contribuindo para os problemas que apareceram depois.

Depois desses projetos vieram outros, alguns até mais importantes, mas essa já é uma estória para um próximo capítulo.