Soluções "cabeça de pudim" podem acabar com seu negócio

(domínio público: https://commons.wikimedia.org/wiki/File:Disorder_in_the_Court_title_1936.jpg)

Por trás de vários problemas de #TI há sempre alguma solução no estilo "Cabeça de Pudim"...

#segurança #negócios 

Soluções "Cabeça de Pudim" estão sempre à nossa volta, adotadas por pessoas de todos os níveis intelectuais, como resultado de pouca análise e observação. Querem resolver um problema de maneira imediata, sem pesar muito as consequências. 

No genial seriado: Os Três Patetas (The Three Stooges), o personagem Moe sempre chamava seus colegas de "Cabeça de Pudim", quando faziam alguma bobagem. Sinceramente, acredito que seja um adjetivo apropriado para quem implementa soluções simplistas, baseadas em "achismo" e sem muita preocupação com o futuro.

Senta que lá vem história...

Sim, estou parafraseando o Lito, do Canal "Aviões e Músicas", para contar algumas histórias que, tristemente, ocorreram na vida real. 

Em meu artigo sobre Complexidade Acidental, listei algumas soluções "Cabeça de Pudim" que encontrei pelo mundo afora, tomando cuidado para não identificar as pessoas e o contexto. No referido artigo, citei algumas categorias deste tipo de solução, como: 

• Parsing de XML por substring. Quando o programador lê e analisa um arquivo XML manualmente. E pode vir com um "plus", que é o uso de textos e números mágicos (para indicar posição e conteúdo). Já existem zilhões de soluções testadas para de-serializar um XML;
• Sincronização por file system: Quando é necessário processar transações de maneira assíncrona, e ficamos analisando o conteúdo de um diretório, buscando por arquivos de requisições. Esta solução tem uma prima mais nova, que é a "Sincronização por banco de dados". Já existem várias soluções de processamento de mensgens assíncronas, muito mais eficientes e testadas;
• Mamãe, criei meu primeiro servidor: Quando alguém cria um servidor Socket para processar requisições, ao invés de utilizar outros mecanismos existentes (Web, Web Services etc);

Bom, em um universo paralelo, em outra dimensão, em outra era, havia um problema de negócio que seria melhor resolvido através de comunicação segura via Internet. Pois bem, isso aconteceu em uma época que todos os mecanismos para isso já existiam, como: Certificação Digital, Web Services etc. 

O "Arquiteto" (aspas não acidentais) do Projeto resolveu que, para aumentar a segurança, deveriam adotar protocolos e soluções próprias, em vez de utilizarem qualquer coisa disponível no Mercado. Seu argumento era de uma lógica simplista, certamente falaciosa: "Se ninguém conhece, então ninguém saberá atacar". 

E assim foi... Ele criou um "protocolo" de nível de aplicação, e um "protocolo" de transporte sobre o TCP/IP. O tal "protocolo" incluía até conceitos de "firewall" próprios. Perdeu uns bons seis meses fazendo isso, mostrando estudos de caso e provas de conceito. Depois, para implementar, escolheu desenvolver um Servidor de rede utilizando C++, que utilizava API de comunicação Socket de baixo nível. 

Ele criou uma versão marombada, com esteroides, de um Web Service, que utilizava protocolos e portas próprios, e criou também uma biblioteca cliente, para que pudessem consumir o serviço. Ah, e a pérola era o esquema de criptografia dele, baseado em algoritmo próprio, adaptado do "Blowfish" (se não me falha a memória).

Orgulhosamente, ele apresentou sua solução "mágica" para um grupo de gerentes e havia até um diretor presente. Todos elogiaram muito a solução, porém, um "zé mané", sentado lá no fundo, fez uma pergunta matadora: "Quanto tempo demorou para criar esse software"? Várias pessoas, inclusive o Diretor, olharam com reprovação para o pobre-coitado, e o "Arquiteto" (lembra Matrix, não?) respondeu: "Cerca de 18 meses, mas isso não é nada perto da segurança que essa solução trará". 

O "zé mané", temendo por sua vida, continuou: "Já fizeram um teste de segurança, tipo um pentest?"  O "Arquiteto" disparou seu argumento lógico: "Nem precisa, pois não usamos soluções públicas aqui, até os protocolos foram reescritos". 

Mas o "zé mané" estava "com o diabo no corpo" e continuou: "Hmmmm. E qual será o custo de manutenção disto no futuro?" A essa altura, o "Arquiteto" perdeu a paciência e passou a não responder mais ao pobre-coitado lá no fundo. 

Bom, findada a reunião, ficou estabelecido que o referido software entraria no ar em 2 semanas. O "zé mané" incômodo da reunião, que vocês devem imaginar quem é procurou o Gerente e insistiu que deveria ser feito um teste de segurança do novo software antes dele entrar no ar, e que isso deveria ser feito por terceiros. É claro que o "Arquiteto" não gostou, pois considerou uma "traição", mas o Gerente insistiu, para minha surpresa, e contrataram um "hacker" para fazer o teste. 

Executaram o software, em uma rede isolada, em um servidor alocado especialmente para este teste. E passaram o acesso ao "hacker". Em menos de 2 dias, o testador reportou diversas vulnerabilidades e listou possíveis ataques, incluindo DOS (Denial Of Service). O "Arquiteto" negou a maioria das evidências e se comprometeu a resolver um ou dois problemas apontados. E o fez, em 1 semana. 

Bom, na verdade a história é beeeem mais comprida e interessante, mas vou ter que cortar aqui para não me alongar muito. O Gerente "comprou" as atualizações que o "Arquiteto" fez e resolveu colocar no ar, embora sob meus protestos. Minha preocupação era que havia mais riscos à segurança que foram negligenciados e que a solução, por ser proprietária, dificultava muito a manutenção. 

Houve ampla divulgação e colocaram o serviço no ar. Como esperado, houve diversas falhas, especialmente quando o tráfego aumentava. Não posso dizer se foram ataques, embora desconfie seriamente, mas havia falhas no software que não haviam sido detectadas, especialmente quando sob alta demanda. 

Depois de dias e mais dias, virando noites e fins de semana, o "Arquiteto" teve uma síncope e se afastou. E sobrou para o "zé mané" resolver. Ele simplesmente condenei o software, o que já havia feito desde o início. Então, pediram uma solução rápida. E ele fez, utilizando técnicas, métodos e ferramentas padrões de mercado. Se reuniu com a Equipe, estudaram o problema e meteram a mão na massa (sem a participação do "Arquiteto"). Em 1 semana o novo software estava funcionando sem apresentar os problemas. 

O "zé mané" era um gênio? É claro que não! Não precisa ser gênio algum para resolver um problema... Basta ouvir as pessoas, oxigenar suas ideias e usar os padrões de mercado. O fato de todos conhecerem aumenta a segurança, especialmente em soluções de criptografia, pois a força do algoritmo não pode estar escondida no código. 

Pois bem...

Temos ai o caso do Twitter, que pululando na mídia, cuja origem parece ter sido interna, embora sem necessariamente ser culpa dos funcionários. Usaram uma ferramenta interna para burlar a segurança e invadir as contas, segundo o artigo que eu linkei. 

Não estou afirmando que foi uma solução do tipo que eu estou apresentando aqui, mas, certamente, pode ter sido alguma falha em procedimentos de segurança, análise de comportamento etc. Sempre que um problema grave de engenharia social prospera, é porque algum controle falhou.

Na minha experiência (44+ anos) eu vi muitas e muitas soluções darem errado ou serem usadas fora de seu propósito original. E, muitas vezes, a causa raiz é a falta de oxigenação da ideia, provocada pela teimosia e insistência. 

O que é "falta de oxigenação"? Já viu água parada? Poluída? O oxigênio acaba, sendo combinado com elementos em decomposição e tudo vira uma lama fétida, altamente densa e tóxica. Assim se transformam as ideias quando lhes é negado o debate. 

Para evitar soluções "Cabeça de Pudim" é necessário ampliar a discussão de novas ideias e projetos, obtendo vários pontos de vista e observar o que o Mercado está utilizando. Um projeto que sobrevive ao diálogo franco e aberto, e à comparação com soluções de Mercado, certamente é algo em que vale a pena investir. 

Cleuton Sampaio, M.Sc.