Desenvolvimento Seguro, quem é que irá fazê-lo? — Parte 1
A polarização entre os profissionais de desenvolvimento e segurança começa cedo demais, isso causa grandes prejuízos para a segurança das aplicações.
Desde sempre …
No centro do problema da falta de recursos humanos para o desenvolvimento seguro, pode-se citar uma grande polarização que existe entre as comunidades de desenvolvimento de Software e Segurança. Este assunto, o qual já tratei brevemente neste artigo, é de longa data. Desde os primórdios da computação, os desenvolvedores não têm exercido protagonismo considerável em Segurança. Na década de 50, quando os primeiros computadores começaram a se proliferar entre os grandes centros de pesquisas e importantes universidades, os desenvolvedores tinham pouco ou nenhum contato com as grandes máquinas. Os programadores ficavam isolados em suas salas e preocupavam-se somente em refletir corretamente sua aplicação num conjunto de cartões perfurados que, ao término do desenvolvimento, eram levados até aqueles que administravam os computadores. Os cartões eram entregues, o programador ia embora e ficava aguardando sua aplicação ser executada para então obter seus resultados e realizar suas análises. Esses administradores dos primeiros computadores eram invejados pelos primeiros hackers e eram conhecidos como Priests (ou sacerdotes). Já os desenvolvedores eram conhecidos como meros Alcolytes (ou aprendizes). Os Priests, como responsáveis pelos computadores, foram os primeiros a estabelecerem as primeiras políticas de acesso para o uso dos servidores, que eram caríssimos e deveriam ser protegidos a todo custo. No meio disso tudo, os programadores continuavam a se preocupar com uma só coisa: desenvolver, afinal de contas já existiam os Priests para cuidar dos computadores.
Dessa forma, sendo responsáveis pela integridade dos computadores, os administradores de sistemas foram os primeiros a se preocuparem com questões de segurança. Juntamente com eles, os analistas de rede, os quais foram pressionados desde cedo pelos primeiros ataques em massa, decorrentes do período do Phreaking.
Este cenário continua claro até hoje. Quando analisamos de uma forma geral os profissionais que hoje atuam com segurança, verificamos que a maioria iniciou suas carreiras em uma dessas duas áreas: 1) administração de sistemas ou 2) administração de redes de computadores. Poucos são os entusiastas de segurança que vieram de áreas correlatas ao desenvolvimento de Software.
Durante a Universidade
Essa polarização ficou muito clara para mim já nos anos da faculdade. Sou formado em Ciência da Computação pela UNESP de São José do Rio Preto. Em nosso campus tínhamos uma característica diferente dos outros cursos de computação, nós tínhamos a opção de escolher uma entre 5 diferentes ênfases para a nossa formação, que eram: sistemas de computação, sistemas de informação, sistemas de automação, computação científica e linguagens e teoria da computação. As ênfases mais escolhidas pelos alunos eram a de sistemas de informação (SI) e sistemas de computação (SC).
A ênfase de SI era composta pelas matérias de Engenharia de Software, Banco de Dados, Organização e Recuperação da Informação, entre outras. Já a ênfase de SC compreendia matérias como: Redes de Computadores, Sistemas Operacionais, Programação Concorrente e etc. Assim, fica fácil de concluir que aqueles interessados em desenvolvimento e análise de sistemas partiam para ênfase de sistemas de informação, enquanto que aqueles mais interessados em redes, sistemas operacionais e segurança partiam para a ênfase de sistemas de computação. O interessante é que, por mais que você poderia escolher sua ênfase, ainda era obrigado a cumprir uma quantidade mínima de matérias de outras ênfases. Com isso, era visível o ‘horror’ que os alunos tinham, de uma forma geral, das matérias de outras ênfases. Para um aluno de SI era o fim do mundo ter que cursar redes. Em contrapartida, quando se tocava no assunto de Engenharia de Software para os alunos de SC, via-se o desespero em suas faces.
Resumindo, os programadores não se entendiam com as matérias de SC (que envolviam um ‘pouquinho’ de segurança). Já os alunos que gostavam de segurança e, por conseguinte, optavam por SC, tinham aversão às matérias de SI, que tratavam dos elementos fundamentais do projeto de sistemas. No meio disso tudo havia algumas exceções, por mais que eu tenha escolhido pela ênfase de SC, eu fiz praticamente todas as matérias de SI. Além de mim, lembro-me de alguns outros guerreiros, mas de uma forma geral não era a regra.
Assim, temos que a polarização dos profissionais começa cedo, já na faculdade. Isso ocorre de forma natural, de forma que não saberia explicar o porquê. Talvez tenha a ver com aptidões, como por exemplo a pessoa de exatas que não gosta muito de humanas e vice-versa. Mas enfim, somente um palpite, não tenho condições de opinar sobre isso.
Quando se trata de gostos e opiniões pessoais a gente não tem muito o que discutir. Mas, o que é problemático de verdade é que o atual sistema de educação em computação aprofunda ainda mais esta polarização. Quando se analisa a ementa dos cursos de Ciência da Computação e correlatos das grandes universidades, é quase que unanimidade não encontrar matérias que abordam assuntos de segurança. Quando existem, geralmente são matérias optativas que não atingem todos os alunos, dessa forma, atraindo somente aqueles que já naturalmente se interessam pelo assunto. Em meus quatro anos de graduação mais dois de mestrado, eu fiz uma única matéria de segurança (a melhor matéria que já fiz na vida, ministrada pelo Prof. Dr. Adriano Mauro Cansian). Mas como já adiantado, esta era uma matéria optativa na grade, de forma que somente aqueles já interessados em segurança participavam.
Assim, temos que nas poucas vezes que a segurança é tratada nos cursos de Computação, isso é feito por meio de matérias isoladas, um grande pecado para com a interdisciplinaridade em minha opinião. A segurança computacional permeia, sem exceção, todas as áreas da computação, do Hardware ao Software passando pelos mecanismos de comunicação. Dessa forma, é um grande erro isolar a segurança em matérias optativas. Este é um assunto muito bem tratado por Sarah Zatko em sua palestra: How to Prevent Security Afterthought Syndrome. Ela argumenta de que nada adianta somente formar especialistas se a grande maioria dos bugs são inseridos pelos profissionais de formação regular, que muito provavelmente nunca tiveram qualquer contato com segurança.
A segurança é interdisciplinar
Além dos claros benefícios para a formação de profissionais aptos para o desenvolvimento seguro, a inserção de segurança nas ementas pode contribuir muito para o enriquecimento das matérias mais tradicionais. Eu gostaria de clarear isso com alguns exemplos. Eu cursei Engenharia de Software durante a graduação e também no mestrado. Nessas duas experiências, a única vez que algum assunto relacionado a segurança foi tratado, foi em um seminário que apresentei à turma durante o mestrado, de resto, não me lembro de qualquer assunto de segurança ter sido ao menos citado. Será que então segurança não tem nada a ver com Engenharia de Software?
A verdade é que Segurança é um atributo dos sistemas tão importante como manutenibilidade, eficiência, corretude, entre outros. Então porque todos esses outros assuntos são tratados e Segurança não? Em Engenharia de Software estuda-se até técnicas de psicologia para a elicitação de requisitos, será que não cabe mesmo um pouco de segurança no meio disso tudo?
Uma das práticas mais importantes durante o ciclo de desenvolvimento seguro é a modelagem de ameaças, muito mais conhecida como Threat Modeling. Nessa modelagem, estuda-se um projeto inicial de sistema na busca por pontos vulneráveis que podem se converter em questões importantes de segurança nas fases posteriores de desenvolvimento. Devido a análise metódica e minuciosa que se é feito nessa fase, é possível descobrir uma série de decisões erradas de projeto antes que se tornem problemas instransponíveis. Isso leva as equipes de desenvolvimento a pensarem em soluções mais elegantes já no início dos projetos. Assim, essa é uma atividade que contribui em muito não só em termos de segurança, mas também num entendimento profundo sobre o projeto e no uso das melhores práticas de mercado nas várias partes do sistema. Será que uma atividade tão importante como o Threat Modeling não poderia fazer parte de um curso de Engenharia de Software?
Nós percebemos como esta questão é séria quando observamos que um dos livros-textos mais tradicionais de Engenharia de Software: Software Engineering de Ian Sommerville, cujo ano da primeira edição é 1982, só passou a tratar de assuntos de segurança de uma forma mais metódica a partir da 9 edição, no ano de 2011. No entanto, este fator também constitui uma esperança. Uma vez que este conteúdo foi adicionado, creio que pouco a pouco ele passará a se refletir nas aulas dos professores, um passo pequeno diante da problemática que vivemos, mas que não deixa de ser importante.
Além dessas questões com Engenharia de Software, também me pergunto: porque não estudar os problemas de corrupção de memória nas matérias de Arquitetura e Sistemas Operacionais? Este assunto seria bastante enriquecedor por trazer para estas matérias aspectos práticos e aplicáveis. Por exemplo, a teoria de memória virtual se tornou muito mais clara para mim após o estudo do layout dos processos em memória e as possibilidades de explorações deste padrão. Além disso, penso que um estudo sobre as técnicas de exploração e defesa, relacionadas aos ataques de Buffer Overflow, propiciaria importantes discussões sobre erros de design e a importância de se considerar a segurança nas fases iniciais do projeto de sistemas.
Portanto, a inserção de temas ligados à segurança computacional junto às matérias tradicionais do currículo de computação também contribuiria para um aprendizado mais profundo sobre fundamentos importantes da computação, propiciando uma formação muita mais sólida aos estudantes. Além disso, como resultado mais importante, conseguiríamos um nivelamento básico de segurança entre os profissionais de TI. Os mesmos que projetarão e manterão os futuros sistemas, sobre os quais estarão apoiadas nossas infraestruturas financeira, energética, industrial e tudo mais que sustenta a sociedade nos dias hoje.
