O Saltador, o Consultor e os Levianos

Em 14 de Outubro de 2012, Felix Baumgartner, um paraquedista austríaco, concluiu o objetivo do projeto Red Bull Stratos e realizou um salto de 39 mil metros, sendo o salto mais alto de todos os tempos, partindo nada mais nada menos que da estratosfera no qual ele chegou através de um balão especialmente preparado para tal feito. E este não foi o único cuidado, pois para se conquistar tal feito, ele passou por uma preparação minunciosa, tomando assim vários cuidados como por exemplo empregando telemetrias adequada e altamente calibradas,  fazer Felix respirar oxigênio puro para eliminar o nitrogênio de seus sangue, que poderia se expandir em alturas elevadas e com isto ameaçar sua saúde.

O staff do projeto contava com especialistas altamente qualificados e  entre eles estava Joe Kittinger na categoria de consultor especial, detentor do recorde anterior que havia sido estabelecido em 1960. Vendo um documentário sobre o tal feito, houve algo que Joe comentou que me chamou muito a atenção:

“Teve muita gente falando sobre como as ondas de choque da barreira de som poderiam partí-lo ao meio” o que deixou Joe muito triste e frustrado, pois “aqueles que insistiam em afirmar estas coisas, não consultaram a equipe Stratos para saber os cuidados que eles estavam tomando, não eram especialistas no assunto e não possuíam nenhuma fundamentação e realizavam tais afirmações apenas porque eles podiam”.

Bom, Joe deveria estar mais acostumado com esta situação pois esta é um das constantes da humanidade.  Independente das motivações, *parece* que ser leviano é regra e não exceção. Além disto há a “recursividade dos sem noção“, onde sem argumentos racionais o imprudente critica o insensato que acredita e potencializa os delírios do leviano. E há quem afirme que o segredo do sucesso é saber conviver com tudo isto, convencer e ser articulado para sobreviver.

Mas sou muito solidário ao Joe, eu entendo totalmente o desconforto dele.

Num dos muitos contextos que posso citar, é muito comum vermos discussões em foruns e listas baseadas em artigos equivocados ou baseado em pesquisas de caráter duvidoso, algumas vezes as imprecisões logo vem a tona pela análise de seus integrantes, mas sempre há (quando não são maioria) os simpatizantes dos levianos por razões simples, tanto o autor quanto seus simpatizantes estão falando aquilo que eles desejam que seja verdade e não a realidade ou simplesmente são analistas imprudentes.

A algum tempo, me foi solicitado uma consultoria de  performance, security testing e verificação de SIMRAV compliace de um sistema, sendo-se que o SIMRAV tem um workflow, processos, protocolos  e mensageria padrão.  No primeiro contato com os desenvolvedores, me foi comentado que possivelmente eu não encontraria muita coisa, pois o Scrum Master do projeto havia orientado todo o processo de TDD (Test Driven Development), todos os módulos possuíam testes unitários, funcionais, de integração e que a arquitetura era excepcional, etc, etc, etc…  E quanto a capacidade de processamento ele realmente era impecável,  mas além de ter segurança tendendo a zero, ele havia falhas conceituais, que eu achei impressionante.

Quando fiz a introdução da apresentação do meu parecer, chegaram a me perguntar se eu tinha certeza do que eu estava falando,  chegaram a insinuar (na brincadeira) que eu estava sendo leviano e que tal apresentação era para conquistar mais horas de consultoria, da forma que foi feito confesso que me senti ofendido. Mas relevei, e já imaginando por isto, em minha apresentação dissequei alguns bits, datagramas, assim como fluxos incorretos e as páginas dos manuais que evidenciava as falhas. Nem preciso dizer que os diretores técnico e de produto, assim como os gerentes de produto, desenvolvimento e segurança  não ficaram nada felizes, mas ali não encontrei ninguém na equipe que dominasse de SIMRAV. E então fiquei pensando, como poderia? Para um sistema tão específico não possuir alguém que dominasse as regras de negócio? Na hora lembrei de uma das máximas do livro Code Complete do Steve McConnell:

“Testing by itself does not improve software quality. Test results are an indicator of quality, but in and of themselves, they don’t improve it. Trying to improve software quality by increasing the amount of testing is like trying to lose weight by weighing yourself more often. What you eat before you step onto the scale determines how much you will weigh, and the software development techniques you use determine how many errors testing will find. If you want to lose weight, don’t buy a new scale; change your diet. If you want to improve your software, don’t test more; develop better.”

E neste caso, para desenvolver melhor, era necessário de um especialista nas regras de negócio. Pois técnicas eles possuíam de sobra. E o mais surpreendente foi ouvir do diretor que num outro sistema eles haviam cometido a mesma falha.

Acidentes acontecem, ninguém é perfeito, todos estão propensos ao erro e o alvo de minha crítica é ao cerne de cada uma das iniciativas. É a insistência e a recorrência que classifica o indivíduo.

Namastê!

A lenda dos notórios App Testers do IBM Black Team

Ao participar do seminário de testes de software “Test Day 2012”  me chamou muito a atenção coisas que não vi,e uma única palestra que comentou algo sobre o tratamento de aspectos de segurança em testes de software, e  conversando com um colega que lá estava que me comentou que ele já não dava conta de fazer o trabalho dele, quanto mais ter que cuidar de segurança e que isto ele deixava para os especialistas em Security Testing  feito eu, que este não era o campo dele. Confesso que na hora lembrei muito da lendária história do IBM Black Team, que fiquei conhecendo  pela primeira vez no livro Peopleware – Productive Projects and Teams - de Tom DeMarco e Timothy Lister.

Este time, tem uma história muito peculiar, muito lendária pois há poucos registros históricos sobre eles. Mas mesmos assim, eles tem gerado admiração por aqueles que ouvem falar sobre eles. Principalmente porque em sua época muitos desenvolvedores aspiravam participar do time e o que acontece hoje é o contrário, muitos testers tem como sonho se “qualificar” para se tornar desenvolvedor, o que por um certo lado é uma grande distorção senão um grande desequilíbrio da força.

Tratando Falhas Conhecidas em Código – Juliet Test Case

Apoiando o  desenvolvimento de software seguro e de qualidade, muito se fala da OWASP, porém ela é muito focada em Web Applications e nem só de Web vive a indústria de desenvolvimento de software.

Há algumas  iniciativas interessantes, como o da SEI  (Software Engineering Institute),  SafeCode, mas uma que vem me chamando muito a atenção são as do  NSA’s Center for Assured Software (CAS) via o  NIST que mantém o projeto SAMATE (Software Assurance Metrics And Tool Evaluation) Reference Dataset (SRD).

A fim de resolver a crescente falta de qualidade dos softwares utilizados no governo dos EUA, o CAS  foi criado em 2005 com a missão de melhorar a segurança de software empregado por eles. E o CAS tenta cumprir esta missão, entre outras coisas, ajudando as organizações nos processos de implantação de ferramentas para tratar de garantia de todo o ciclo de vida de desenvolvimento de software.

Malware Bypasses Process Monitoring & Colonização Marciana

Computer security rings (Note that Ring 1 is not shown) (Photo credit: Wikipedia)

Em alguns produtos de segurança o domínio dos “anéis” do sistema operacional é fundamental e para alguns malwares, conquistar o poder do “anel” é torná-lo quase invencível.

Tá, anel pode ser um termo muito sinistro para você, no fundo para mim também, por isto que prefiro utilizar o termo “ring”. Há um tipo de malware (considerado advanced) que costuma render bastante trabalho que são os Rootkits; principalmente aqueles que sabem explorar o poder destes rings, OS Internals, processors internals ou até instruction sets bugadas e ou desconhecidas como  Likhachev Nikolay encontrou em alguns rootkits (e trojans) em 2007 e revelou no paper “Remote Code Execution through Intel CPU Bugs“.

Rootkits podem ser de Ring 3 (User Land), de Ring 0 (Kernel Land),  Ring -1  (Hypervisor), Ring -2 (SMM) e até de Ring -3, estando em iminência os de EFI  que tem sucesso apenas em firmwares que não empregam algumas boas práticas de segurança, mas em tempos onde malwares já estão utilizando ataques desconhecidos de colisão de hash para forjar certificados digitais, muitos princípios começam a entrar em xeque.

Para muitos o desenvolvimento de rootkits é uma arte negra, até porque há várias técnicas relacionadas a eles que não são muito simples mesmo. Por isto outro dia fiquei admirado com um  post  no blog de uma  empresa  de segurança que tem produtos anti-malware, mostrando como realizar by-pass via kernel rootkit  (ring 0) de um dos pilares da monitoração real-time por endpoint protections no Windows.  Obviamente, esta empresa não é afetada por tal técnica, visto que seus engines de captura são de  in-network e o conteúdo do tal post era direcionado para bypass de kernel mode driver callback, enfim outra categoria de AVs.

O post pareceu-me mais FUD (Fear, Uncertainty and Doubt) e uma peça de marketing, e isto levou-me a fazer uma série de questionamentos e  deixou-me muito pensativo.

Mistérios do SMS – bits, bytes, mitos e modelos mentais

Ainda sobre mitos

Call flow for the Mobile Terminated short message service (Photo credit: Wikipedia)

Quando eu atuava com desenvolvimento de soluções para  Telematics Security, certa vez, conversando com um engenheiro de suporte que me apresentaram como o papa dos SMS (Short Message Service) de uma representante local de um fabricante de módulos de comunicação GSM, perguntei a ele o quanto o  módulo dele era compliance com o  padrão 3GPP TS 23.040 (Technical Realization of the Short Message Service) e a resposta dele foi que não tinha nada a ver uma coisa com a outra, que o manual do produto deveria ser seguido sempre.  Eu repeti a questão de uma outra forma e  a resposta foi similar! Aquela resposta não fazia sentido algum, até poucos meses antes eu havia testado um módulo de comunicação de um outro fabricante e encontrei problemas de aderência que reportei ao fabricante;  ele comentou que era um problema conhecido e que em breve isto seria corrigido, de verdade levou 3 anos para isto ocorrer, mas tudo bem. Porém preferi  ignorar a resposta deste engenheiro brasileiro e preferi falar sobre outros assuntos, que de verdade estavam mais ligados a nossa pauta.

Noutro momento, perguntei para um engenheiro de suporte de um outro fornecedor, como eu ativava o MUX do módulo para operar com canais simultâneos de GPRS e SMS, o mesmo falou que isto não era possível; bom olhando o manual do módulo dele em alguns minutos vi referências ao MUX e pedi exatamente o manual no qual aquela linha daquela página do manual estava se referindo, ele me perguntou para que eu queria aquele documento? Pois tudo o que eu precisava estava no manual no qual eu estava lendo. Com o tempo fui descobrir que entre application notes, datasheets e manuais, o produto dele tinha cerca de 9 documentos e só aquele manual era insuficiente.

Mitos e Verdade – O Dossiê Farewell e Stuxnet

Uma das históricas clássicas de ações para-militares cibernéticas da década de 80 é o famoso caso da explosão do gasoduto  Trans-Siberiano em junho de 1982, que segundo duas fontes foi uma sabotagem do sistema SCADA perpetuado pela CIA. Quando comentei esta história com meu amigo DQ, na mesma hora ele questionou-me: será que não é mais uma lenda urbana sobre a CIA? E então respondi a ele que ao que parece não, pois há duas fontes consideradas seguras sobre o acontecido, o Dossiê Farewel e um livro de Thoma C. Reed, um ex-Secretário da Força Área dos EUA, o “At the Abyss – An Insider´s History of the Cold War, de 2005.

EB – Projeto MK-ULTRA & Neurohacking

Texto publicado originalmente em 27/05/2009 na coluna Ensaios de Borda do Fringe Lab, dentro do contexto da coluna de mashup de ficção, história, realidade e conjecturas especulatórias:

Desde o primeiro capítulo de Fringe, temos ouvido que o Dr.Bishop teve financiamento do DARPA para realizar as mais estranhas pesquisas entre as décadas de 60 e 90, tendo atendido os militares das mais diversas formas, em muitos casos realizando pesquisas utilizando mescalina, LSD (a preferida do Dr.Bishop e parece que também muito apreciada por Dr.Bell) além de outras drogas experimentais (cortexiphan) utilizando cobaias humanas (sem seu consentimento) e seus objetivos estavam relacionadas a controle mental, seja para transferência de memórias e amplificação de ESP (Percepção Extra-Sensorial) em crianças entre outas modalidades de experiências químicas e físicas, tendo outrora utilizado DNI (Direct Neural Interfaces) e tanque de isolação sensorial. Porém o mais curioso é que neste parágrafo os principais elementos de ficção são: Fringe, Dr.Bishop e o Dr.Bell.