Antes de falarmos sobre o risco para o software menciono abaixo a definição de risco segundo a ISO 31000 – Gestão de Risco – Princípios e Diretrizes
Risco é o efeito da incerteza nos objetivos.
NOTA 1 – Um efeito é um desvio em relação ao esperado – positivo e/ou negativo.
NOTA 2 – Os objetivos podem ter diferentes aspectos (tais como metas financeiras, de saúde e segurança e ambientais) e podem aplicar–se em diferentes níveis (tais como estratégico, em toda a organização, de projeto, de produto e de processo).
NOTA 3 – O risco é muitas vezes caracterizado pela referência aos eventos potenciais e às consequências, ou uma combinação destes.
NOTA 4 – O risco é muitas vezes expresso em termos de uma combinação de consequências de um evento (incluindo mudanças nas circunstâncias) e a probabilidade de ocorrência associada.
NOTA 5 – A incerteza é o estado, mesmo que parcial, da deficiência das informações relacionadas a um evento, sua compreensão, conhecimento, sua consequência ou sua probabilidade.
Risco para um software são possíveis falhas existentes nos códigos que possam ser exploradas por hackers ou pessoas mal intencionadas como o objetivo de causar danos e possíveis fraudes para a organização possibilitando perdas financeiras e de imagem.
Como estratégia códigos fontes devem ser auditados com o objetivo de remover funcionalidades obsoletas e desnecessárias. Essas auditorias devem ser realizadas de maneira sistemática de modo a mitigar o risco.
É importante ressaltar que as proteções dessas informações existentes devem se basear em padrões normativos e de Segurança (ISO/IEC-15408 – Information technology – Security techniques – Evaluation criteria for IT security , ISO/IEC-27002 – Information Technology – Security Techniques – Code of practice for Information security controls, PCI Payment Card Industry – Data Security Standard) de maneira a garantir a Segurança implementando conjuntos de funcionalidades seguras, executando testes funcionais, verificando e protegendo códigos fontes de forma controlada, restringir somente a pessoas autorizadas com a finalidade de prevenir o uso não autorizado e assim mantendo a integridade, disponibilidade e confidencialidade, estabelecendo processos para identificar as vulnerabilidades, classificando e tratando os riscos, instalando patches de segurança e demais controles.
A Open Web Application Security Project (OWASP), iniciada em 9 de setembro de 2001, é uma entidade sem fins lucrativos e de reconhecimento internacional. Esta contribui para a melhoria da segurança de softwares aplicativos reunindo informações importantes que permitem avaliar riscos de segurança e combater formas de ataques através da internet.
Como forma de contruir, a OWA elencou 10 riscos (OWASP TOP 10 – 2017) considerados como mais graves para uma ampla gama de organizações, no entanto citaremos apenas 2 apresentando casos ocorridos e sugerindo contramedidas como forma de mitigar esses riscos. São eles:
A4- Quebra do controle de acesso
Em abril de 2013 o hacker Nir Goldshlager certamente entrou para a história da Facebook, de modo positivo. Em uma postagem em seu blog pessoal, o mesmo confirmou ter encontrado e explorado uma falha no sistema de autorizações da rede social, o que permitiu a ele ter acesso a todas as opções de qualquer perfil cadastrado.
É notório falhas e brechas de segurança existentes no sistema de autorização da rede social citada, falha essa que possibilitava o acesso as informações de perfis existentes.
Como contramedida testes de funcionalidades de segurança devem ser executados durante os desenvolvimentos dos sistemas. Outra proteção sugerida seria a criptografia dos códigos fontes. Se essa opção for utilizada o acesso lógico deve ser gerenciado separadamente sendo independente de mecanismos de controle de acesso e autenticação do sistema operacional nativo.
A6-Exposição de dados sensíveis
Em maio de 2014 uma brecha de segurança atingindo o eBay. Aparentemente, o ataque comprometeu uma base de dados com senhas criptografadas e informações financeiras.
Esse ataque só foi possível porque os criminosos conseguiram credenciais de acessos com alguns funcionários da própria empresa. Uma situação parecida também aconteceu com o Spotify.
Não se pode afirmar que houve o envolvimento dos colaboradores da empresa, entretanto é perceptível que a base de dados foi obtida através desses. Uma das hipóteses seria o ataque utilizando Engenharia Social ou até mesmo envolvimento interno como já mencionado. Independente, entende-se que houve Incidente de Segurança.
Nesse caso a contramedida sugerida seriam proteções adequadas das credencias dos colaboradores incluindo forte controle de acesso, limitando as informações com base somente na “necessidade de divulgação”, realizando conscientização interna, treinamentos bem como o controle e monitoramento de logs de acesso sendo posteriormente auditáveis.
Concluo que em ambos os casos são perceptíveis falhas no controle de acesso expondo dados sensíveis. Funções dos sistemas de aplicações deveriam ser protegidas e restritas de forma rigorosa, sendo assim todo cuidado é pouco!
