O que o #LOB deve saber sobre a segurança dos aplicativos que sua empresa gerencia?

by Dezembro 28, 2017

Cinco perguntas a serem feitas durante o jogo de golfe, poquer ou reunião do Conselho de Administração

@Scavanna: no final, você precisa apenas de uma resposta curta do estilo: “O risco é ACEITÁVEL. Vamos avançar”.

Obviamente, a resposta curta não é simples, e conseguir diminui-la a este nível é um desafio que envolve várias áreas da tecnologia.

Mas eu me pergunto: o que acontece quando não se busca alcançar esse objetivo? Quero dizer, o negócio espera saber o risco que enfrenta, o risco que assume ou as ações disponíveis para mitigar isso em níveis aceitáveis e, embora seja verdade que não é possível ter toda a informação, também é verdade que “poder e não fazer” tem um sabor amargo.

Por outro lado, quanto mais informação disponível, mais nos pedem para poder responder a essas perguntas. E quanto mais incidentes de segurança ocorrem em um mercado/ indústria, mais exigirão que vejamos essa parte da equação: o risco.

Todo negócio tem um custo projetado, um ganho esperado e um risco. Sem uma dessas variáveis, a equação não é credível.

  • Quando o impacto em uma linha de negócios também afeta os outros, pois afeta a imagem da empresa, mais pressão haverá sobre fazer bem as coisas.
  • Quando o impacto também afeta os dados dos clientes e pode levar a uma demanda.

Mas o LOB não precisa saber o que está acontecendo na cozinha, certo? Não, isso não é verdade.

O negócio tem mais e mais a ver com a tecnologia. A tecnologia está cada vez mais no coração de qualquer negócio.

Isso é transformação digital. E o LOB não pode saber sobre o que se trata (em uma linguagem que se possa entender e com um nível de agregação-detalhe específico próprio de sua função).

Continuarei a insistir que existe um problema de comunicação entre diferentes áreas com diferentes funções. É necessário resolvê-lo, não importa por onde você comece com a solução.

Se você faz parte do LOB, então estou confiante de que isso será útil.

@SrLOB: – Ok, sério, me dê algo útil, porque o que eu costumo encontrar tem essa forma:

Como as diferentes áreas respondem à pergunta: “Isso é seguro?”

  • @SrDevManager: – É muito complexo para explicar, mas acredite que funcionará, também é responsabilidade da segurança proteger os sistemas.
  • @SrSecManager: – Não tenho dinheiro e o Desenvolvimento ignora-me, eles não sabem incluir segurança no desenvolvimento.
  • @SrTechManager: – Para quando você disse que queria?
  • @SemiSrLOB: – Poderíamos contratar uma Software Factory para desenvolvê-lo para nós.
  • @SemiSrSecAnalist: – Eu poderia executar alguns pen-tests com umas ferramentas de código aberto.
  • @CIO: – Se não há evidências de que seja um problema, não desviarei o orçamento pela paranoia das pessoas de segurança. Se estão tão preocupadas, a empresa que pague.
  • @SrSecManager: Não iremos ter suporte para um aplicativo com vulnerabilidades, a menos que a empresa aceite o risco. Os sistemas de proteção podem nos proteger contra ataques externos e podemos incluí-lo no próximo serviço de auditoria externa.

@SrLOB: Mas qual é o risco? É real? Quanto custa para corrigi-lo? Por que eles não me disseram antes? Será possível que tudo seja tão complicado nessa empresa?

@Scavanna: Tudo bem, está bem. Respire, respire novamente.

Se você entendeu algo do que leu até agora, estamos indo bem. Avance um pouco mais.

Eu acredito que, ao fazer as perguntas certas (desconfortáveis talvez, mas corretas), você poderá avançar para uma posição em que possa defender.

Cinco perguntas simples, que deveriam ter respostas claras:

  1. Temos uma política de segurança integrada ao ciclo de desenvolvimento que deva cumprir com os aplicativos em produção (independentemente de quem os desenvolve)?
  2. Quando e onde é o controle da conformidade com essa política, análise de vulnerabilidade dos aplicativos, a infraestrutura onde eles correm e os processos administrativos? (Desenvolvimento, Teste, Produção)
  3. Quem é responsável e quem paga a análise de vulnerabilidades de aplicativos, da infraestrutura? (Quanto custa, como o custo é distribuído?)
  4. Quem é responsável e quem paga pela correção de uma vulnerabilidade encontrada em um aplicativo (independentemente de quem o desenvolve). Isto inclui Software Factory?
  5. Se entramos em produção com um aplicativo que tenha vulnerabilidades, qual é o risco que estamos assumindo, como podemos mitigar isso?

Não se enrole sobre possíveis ataques e potenciais atacantes, basta saber que se você colocar um aplicativo na internet, tentarão atacá-lo desde o primeiro momento, desde a primeira hora, para ser preciso. 

Com isso em mente, obtenha respostas para essas cinco perguntas.

E se eles não podem responder de forma satisfatória, então pode ser hora de tomar outras decisões:

@SrLOB: Veja, mas quase tudo é dinheiro?

@Scavanna: Quase. O principal motivo pelo qual não se fazem as análises de vulnerabilidade nos aplicativos de uma empresa gira ao redor da falta de responsáveis ou falta de orçamento e isso já é um círculo vicioso. O último responsável é a Administração da Empresa, e ela deveria contemplar os custos para que as coisas saiam bem.

Na prática, esse é o orçamento para a segurança, mas também para o Desenvolvimento.

Quanto custa à sua empresa 10 pessoas por um ano para criar e desenvolver um aplicativo de negócios (Design, Desenvolvedores, Gerentes de Projetos, Testes, Produção, etc.)?

A integração da análise de vulnerabilidade do PC do desenvolvedor para a produção com o Veracode pode custar menos de 3%. E, acredite em mim quando sigo que resolver as vulnerabilidades nos estágios iniciais do desenvolvimento irá poupar muito mais do que o investimento indicado. Na verdade, isso irá poupar-lhe muitas dores de cabeça.

Conclusão: Estou sendo claro?

Mas se não for o caso, convido você a fazer um teste. Vamos fazer uma análise de vulnerabilidade do seu aplicativo.

Santiago CavannaEscrito por Santiago Cavanna
Ciberseguridad e API de administración de soluciones Cuenta director CA Technologies
LinkedIn: @santiagocavanna
Twitter:  @SCavanna