O dia 0 foi o dia 1 de desenvolvimento
Um estudo recente da Universidade de Columbia descobriu que estamos atolados em mais de 70 decisões por dia. Isso se você contar apenas as decisões importantes, já que uma pesquisa anterior da Universidade Cornell determinou que tomamos mais de 200 decisões apenas relacionadas à alimentação em um determinado dia.
Muitas das decisões que tomamos em um dia são inconsequentes a longo prazo. O impacto é mínimo e a maioria não pode ser categorizada como "boa" ou "ruim". Elas são apenas a escolha que fizemos. Mas algumas escolhas têm consequências significativas. Algumas são intencionais e feitas com premeditação. Outras não são intencionais e só se tornam óbvias quando olhamos para trás.
Algumas consequências não intencionais que parecem óbvias em retrospectiva estão relacionadas à segurança de nossos aplicativos.
ESCOLHAS: PLATAFORMAS, FRAMEWORKS e COMPONENTES
Desde o primeiro dia de desenvolvimento, escolhas estão sendo feitas. Muitas dessas escolhas giram em torno de plataformas e estruturas, bibliotecas e componentes de terceiros. Muitas dessas escolhas são feitas durante o desenvolvimento. Estima-se hoje que 80-90% de um aplicativo seja composto por componentes de código aberto/de terceiros . Cada uma das escolhas que levam à inclusão de um componente de código aberto/de terceiros tem consequências potenciais, principalmente no que diz respeito à segurança do aplicativo. A análise da Black Duck Software afirma uma média de 105 componentes de código aberto por oferta de software comercial.
Essas consequências, à primeira vista, não são tão assustadoras. Afinal, uma pesquisa da Contrast Security descobriu que bibliotecas de software representam apenas 7% das vulnerabilidades. A Black Duck encontrou uma média de 22,5 vulnerabilidades de código aberto por aplicativo. Quarenta por cento (40%) dessas vulnerabilidades foram classificadas como "graves". Ainda assim, isso é mínimo considerando que os 10-20% restantes de um aplicativo (código personalizado) são responsáveis pela maioria das vulnerabilidades nos aplicativos.
Infelizmente, a maior parte das vulnerabilidades não são divulgadas por meio de CVEs e os códigos de exploração de exemplo são disponibilizados facilmente aos invasores. Os criminosos não precisam se esforçar tanto para encontrar alvos em um ambiente onde os mesmos componentes e bibliotecas são frequentemente usados por milhares e milhares de aplicativos da web. Atualmente, o builtwith.com — que monitora o uso de tecnologia para criar aplicativos e sites — conta com quase 40.000 sites ativos que dependem do Apache Struts. A maioria de nós está ciente da exploração bem-sucedida de vulnerabilidades publicadas no Apache Struts 2, o que causou um leve pânico na Internet. Pânicos semelhantes foram causados por divulgações de vulnerabilidades graves envolvendo outras bibliotecas de código aberto e de terceiros muito utilizadas, como o OpenSSL.
Mas não é apenas a escolha de incluir bibliotecas ou componentes de terceiros ou criar aplicativos em estruturas de código aberto que é potencialmente problemática. Outras escolhas que fazemos durante o desenvolvimento também podem ter sérias repercussões, principalmente quando levam a práticas de desenvolvimento inseguras.
ESCOLHAS: NEGOCIAÇÃO DE SEGURANÇA POR VELOCIDADE
Nunca é uma surpresa ouvir que segurança foi trocada por velocidade. Sempre foi assim. Uma pesquisa da McAfee de 2014 com 504 profissionais de segurança descobriu que "cerca de um terço das organizações pesquisadas cujos operadores admitiram que tentam aumentar o desempenho da rede desabilitando rotineiramente os recursos de segurança do firewall".
O desenvolvimento, ao que parece, não é diferente. O foco deles não está na velocidade de execução, mas na velocidade do pipeline. Para atender às demandas por lançamentos mais rápidos de aplicativos e atualizações no mercado, muitos admitem ignorar completamente a segurança durante o desenvolvimento. Uma pesquisa de 2017 da Arxan | IBM com desenvolvedores de dispositivos móveis e IoT descobriu que 26% dos entrevistados não testam aplicativos móveis para problemas de segurança, e quase metade (48%) não testa aplicativos de IoT. A pressão para entregar foi citada por 69% como o motivo pelo qual a segurança é frequentemente ignorada.
Uma pesquisa com os participantes do nosso evento para clientes, Agility , neste verão, reforçou que isso é realidade. Mais da metade - 62% - admitiu ter trocado segurança por velocidade em sua organização.
E depois há as escolhas feitas sobre como as organizações abordam as vulnerabilidades descobertas. A análise da Black Duck revelou que 10% dos aplicativos escaneados em 2018 ainda estavam vulneráveis à vulnerabilidade Heartbleed de 2014. Um estudo da ServiceNow conduzido pela Ponemon descobriu que 57% das vítimas de violação relataram que poderiam ter evitado a violação instalando um patch disponível.
AS ESCOLHAS TÊM CONSEQUÊNCIAS
Do primeiro dia de desenvolvimento até a pós-implantação, as escolhas que fazemos em relação à segurança de toda a pilha de aplicativos são importantes. Essas escolhas não são comparáveis a comer um hambúrguer ou uma salada no almoço; são decisões cujas ramificações podem repercutir não apenas na TI e nos negócios, mas também nos clientes que confiam que os provedores de aplicativos levam a segurança a sério.
Poucos de nós podemos afirmar que nunca recebemos uma carta "Caro usuário do aplicativo" informando que nossos dados foram expostos. Isso não é uma licença para ser negligente com a segurança; pelo contrário, todos nós devemos nos esforçar para fazer melhor pelos nossos clientes na proteção de informações pessoais e privadas.
A melhor maneira de fazer isso é reconhecer que cada escolha desde o primeiro dia de desenvolvimento é uma oportunidade de melhorar a segurança dos aplicativos que desenvolvemos. Escolha consciente e sabiamente.