Este símbolo representa sua causa?

16 06 2013


guy-fawkes

Hoje em dia este é um ícone muito conhecido, sendo muito comum ver alguns ativistas protestando por direitos democráticos, pela paz, pelos direitos humanos, pelo combate a corrupção, contra o sistema e por um mundo melhor entre outras causas utilizando esta “máscara” em manifestações, esta que representa do rosto de Guy Fawkes.

Muitos se espelham na ficção no qual ela foi iconizada pelo V, personagem de HQ  de ficção científica e fantasia da década de 80 e 90 de Alan Moore,  sendo o símbolo de um  assassino justiceiro violento que queria dar um golpe de estado, ficando mais conhecido pelo filme de James McTeigue de 2006, estrelado por Natalie Portman e pelo Hugo Weaving. Que foi considerado por alguns como a adaptação mais detestável para o cinema de um HQ, mas acho que há casos piores.

 Na vida real, na Inglaterra, esta é considerada a face da traição, que representa um ícone histórico que é cultuado todos os anos  na noite de Guy Fawkes por seu fracasso.

Fawkes, foi um militar especialista em explosivos, que participou da tentativa de um golpe de estado, a Conspiração (ou Revolta) da Pólvora, via um regicídio contra o rei protestante Jaime I  e todo o parlamento da Grã-Bretanha em 1605.  Mas a conspiração falhou, os membros foram presos, torturados e executados. Houve jesuíta que participou do golpe que foi afogado, decapitado e esquartejado só para dar exemplo. No dia 5 de novembro, tradicionalmente, ocorre uma festa popular nas ruas da Grã-Bretanha onde, semelhante ao malhar o Judas que ocorre no Brasil, o alvo é um boneco de Fawkes que depois é queimado numa fogueira e então soltam fogos de artifícios, sendo o  personagem mais lembrado deste evento histórico,  que acabou sendo traído por seu gênio e morreu sem ter alcançado seus objetivos, felizmente, pois todos os indícios indicam que o novo regime teria sido péssimo para o Reino Unido.

Minha grande curiosidade:  este símbolo realmente te representa?

Leia o resto deste post »





O Saltador, o Consultor e os Levianos

5 01 2013

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

18 11 2012

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.

Leia o resto deste post »





Tratando Falhas Conhecidas em Código – Juliet Test Case

14 11 2012

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.

Leia o resto deste post »





Malware Bypasses Process Monitoring & Colonização Marciana

24 06 2012
Computer security rings (Note that Ring 1 is n...

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.

Leia o resto deste post »





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

10 06 2012

Ainda sobre mitos

Call flow for the Mobile Terminated short mess...

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.

Leia o resto deste post »





Mitos e Verdade – O Dossiê Farewell e Stuxnet

9 06 2012

siberia_img

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.

Leia o resto deste post »