Por Augusto Alves
Crimes digitais, vazamentos de dados e segurança da informação vem ganhando mais atenção nas notícias neste ano. Governos e empresas têm dedicado mais recursos para essas áreas. Entretanto, a maior parte da atenção é focada em medidas reativas – Como pegar os responsáveis? E menos em medidas preventivas – Como fazer nosso sistema seguro? A chave para um desenvolvimento seguro é a educação, se um sistema é feito sem considerar a sua segurança todo o investimento adicional em proteção pode ser inútil.
1 – Entendendo a programação segura (Intro)
Enquanto a maior parte da atenção vai para pegar os cibercriminosos e detectar ataques, vemos no geral uma menor atenção para determinar as causas desses ataques que podem ser: ingenuidade das pessoas e a exploração de um sistema com falhas. Prevenir um sistema com falhas é algo que nós programadores podemos controlar. Escrever um software seguro é talvez o método mais efetivo de prevenir a maioria dos crimes digitais que existem hoje. (Devanbu & Stubblebine, 2000).
A velocidade com a qual um sistema é desenvolvido para o mercado é incrível e leva para uma das principais causas de software inseguro. Compradores não podem distinguir entre um software inseguro de outro seguro. Desenvolvedores tendem a gastar recursos em funcionalidades adicionais do que gastarem com segurança. Afinal o software que apresenta o maior número de funcionalidades pelo menor preço é o mais provável de ganhar uma concorrência. Essa é a razão mais importante pela qual um software pode se tornar inseguro.
Mesmo que a segurança de um sistema fosse visível ao comprador ou fabricante, problemas de segurança ainda existiriam por conta da falta da capacidade de muitos de estimarem riscos. Nosso cérebro é otimizado para tomar decisões rápidas para sobreviver na savana, e não se adaptou para o moderno ambiente de TI. Tendemos a desprezar certos riscos e exagerar outros (Kahneman, 2002). Por conta disso, pode ser decidido não investir em certas medidas de segurança durante o desenvolvimento e compradores podem decidir que não precisam ser protegidos de certas ameaças.
1.1 Os jargões da segurança
Quando falamos de segurança, usamos termos como ameaças, risco e ataque. Eles podem parecer similares e às vezes são confundidos, mas existe uma pequena diferença entre esses termos:
Ataque – Uma tentativa de abusar de um sistema.
Exploração (exploit) – Um método de abusar de determinada vulnerabilidade.
Mitigação – Uma medida de reduzir o impacto de uma ameaça.
Patch – Uma medida para remover uma vulnerabilidade de um sistema.
Risco – A perda potencial, a probabilidade de uma vulnerabilidade ser explorada.
Ameaça – Um ataque ou atacante em potencial.
Vulnerabilidade – Uma fraqueza que pode ser explorada.
Fraqueza – Uma construção com falhas que pode reduzir a segurança.
Ameaça + Vulnerabilidade = Risco
Para fazer com que um software seja seguro, precisamos saber que a ameaça existe e como podemos nos proteger contra elas. Entretanto, é praticamente impossível criar uma lista completa de ameaças para um sistema em particular, por isso, nunca se pode garantir 100% de segurança. Felizmente muitas ameaças são conhecidas e sabemos como nos proteger contra elas.
1.2 STRIDE
Um método que ajuda bastante é aplicar o acrônimo STRIDE (Hernan, Lambert, Ostwald, & Shostack, 2006), que descreve os tipos possíveis de ataques. Durante o ciclo de desenvolvimento é importante considerar esses termos em qualquer interação com o usuário.
Spoofing – Fingir ser alguém ou algo que você não é.
Tampering – Modificar dados armazenados ou em trânsito.
Repudiation – Negar que você fez ou não fez algo.
Information Disclosure – Ver uma informação que você não está autorizado a ver.
Denial-of-Service – Tornar um sistema ou funcionalidade indisponível.
Elevation of Privilege – Fazer algo sem permissão.
1.3 Superfície de ataque
Uma das condições de sucesso de uma exploração feita por um atacante é acessar partes vulneráveis de um sistema. Essas partes são denominadas superfícies de ataque. Diferentes tipos de atacantes podem ter diferentes superfícies de ataque e também diferentes tipos de atacantes podem ter acesso à diferentes partes de uma superfície.
Uma prática para diminuir uma superfície de ataque consiste em reduzir o volume de código utilizado, reduzir e tratar pontos de entrada de dados para usuários não autorizados e desabilitar funcionalidades que são pouco requisitadas. Vale observar que reduzir uma superfície de ataque, diminui apenas a probabilidade de uma falha ser encontrada e não o dano causado por um atacante, caso alguma outra falha seja explorada.
1.4 Zonas de confiança
Para determinar uma superfície de ataque podemos dividir um sistema em “zonas de confiança”. Cada uma dessas zonas representa um certo grau de confiabilidade dentro de um sistema (Exemplo: partes onde existem interações com usuários são menos confiáveis). Essas zonas são separadas por limites de confiança, que por sua vez são ótimos candidatos para serem uma superfície de ataque.
REFERÊNCIAS
Devanbu, P. T, & Stubblebine (2000) . Software engineering for security: a roadmap. In Proceedings of the Conference on the Future of Software Engineering. ACM.
Kahnneman, D. (2002). Maps of bounded rationality: A perspective on intuitive judgement and choice. Nobel Prize Lecture. Disponível em: wisopsy.uni-koel.de/uploads/media/kahnemann_Nobelpreisrede_20.pdf
Hernan, S., Lambert, S., Ostwald, T., & Shostack, A. (2006). Threat modeling – Uncover security design flaws using the STRIDE acronym. MSDN Magazine, 68-75.
