A surpreendente verdade sobre a transformação digital: Ignorando a segurança

Este é o terceiro blog de uma série sobre os desafios decorrentes da transformação digital.

• A surpreendente verdade sobre a transformação digital
• A surpreendente verdade sobre a transformação digital: Caos na Nuvem

Ignorando a segurança.

Não será nenhuma surpresa para muitos veteranos de TI saber que, quando o desempenho do aplicativo se torna um problema, a segurança geralmente é o primeiro serviço a ser descartado. Firewall caindo diante de um ataque? Desligue isso. Serviços sobrecarregados pela demanda repentina? Desligue-os.

Por vinte anos, temos sistematicamente descartado a segurança quando o desempenho do aplicativo se torna problemático.

Portanto, não é nenhuma surpresa que, diante do desempenho do pipeline, a segurança seja frequentemente ignorada.

Nove em cada dez executivos admitem se sentir pressionados a lançar aplicativos no mercado com mais rapidez e frequência graças à transformação digital.

É irrelevante se os executivos transmitem essa pressão de forma explícita ou implícita aos responsáveis; desenvolvedores e operações muitas vezes se sentem pressionados quando se trata de lançar aplicativos em tempo recorde.

E talvez por isso, eles admitem ter ignorado a segurança. Quase metade (44%) em uma pesquisa da IBM/Arxan com desenvolvedores de dispositivos móveis e IoT fez isso, e é provável que desenvolvedores de outros setores admitam o mesmo.

Afinal, segurança é algo difícil. Há muita superfície de ataque por aí – e nenhuma camada fica intocada. Da rede à plataforma e ao aplicativo, há mais maneiras de se infiltrar em aplicativos e extrair dados do que camadas na rede.

Mas se olharmos para as maiores violações dos últimos tempos, veremos um padrão emergir que pode ajudar todos a concentrar seu tempo limitado no maior risco.

Todos nós ouvimos sobre a violação da Equifax. Conhecemos os detalhes sórdidos e, como muitas outras organizações, eles foram pegos por uma vulnerabilidade publicada executada contra uma estrutura de terceiros não corrigida por meio de uma plataforma web. A descoberta foi provavelmente, mas não verificada, obtida por meio de um bot/script automatizado que procurava alvos prováveis. Provavelmente porque a maioria significativa da atividade de bots atualmente não é tráfego de ataque, mas missões de reconhecimento de sondagem.

Acontece que já faz muito tempo que alguém não consegue entrar via SSH ou por meio de uma vulnerabilidade de rede. Os invasores de hoje estão atrás de aplicativos e credenciais e estão usando bots para encontrar vulnerabilidades lucrativas – e realizar o ataque.

Os três principais riscos de segurança contra os quais você precisa proteger seus aplicativos são:

• Dez melhores da OWASP. SQLi, XSS, injeção de comando, injeção No-SQLi, travessia de caminho e recurso previsível
• CVEs. Apache, Apache Struts, Bash, Elasticsearch, IIS, JBoss, JSP, Java, Joomla, MySQL, Node.js, PHP, PHPMyAdmin, Perl, Ruby On Rails e WordPress.
• Robôs. Scanners de vulnerabilidades, web scrapers, ferramentas DDoS e ferramentas de spam de fóruns.

É aqui que a padronização da plataforma e da política de segurança se encontram com a arquitetura por aplicativo para fornecer efetivamente uma maneira de remediar o risco antes que ele se torne uma ameaça existencial. Padronizar em uma plataforma significa a capacidade de padronizar políticas. Usando essa combinação, os profissionais de segurança podem criar uma política de segurança básica e padrão que pode ser implantada automaticamente em cada aplicativo, protegendo-o imediatamente contra as ameaças mais recentes. Como é por aplicativo, proteções específicas do aplicativo podem ser adicionadas para fornecer proteção adicional, mas, no mínimo, você estará mais confiante sabendo que os vetores de ataque mais prováveis estão cobertos.

O outro benefício em uma arquitetura por aplicativo é que os aplicativos normalmente não são protegidos por algo como um WAF (sim, eu sei, por que isso aconteceria? Mas acredite em mim, eles podem ser protegidos no curto prazo injetando uma nova instância com as políticas apropriadas no pipeline do aplicativo pelo tempo que for necessário. Então, quando esse CVE for publicado — e será — os profissionais de segurança poderão implementar imediatamente uma política de mitigação e injetá-la no caminho de cada aplicativo vulnerável antes que ele possa ser explorado.

A resposta para os desenvolvedores que ignoram a segurança devido às pressões para entregar resultados na transformação digital é padronizar. Padronize uma plataforma de segurança de aplicativos comum para que você possa aproveitar sua capacidade de padronizar políticas e colocá-las no pipeline como um profissional.

Fique ligado no próximo post desta série, no qual veremos como você pode lidar com a Deseconomia de Escala decorrente da tendência da transformação digital de criar mais aplicativos do que operações.