quarta-feira, 1 de março de 2017

Segurança da Informação: Vulnerabilidades do Negócio

28 de fevereiro de 2017
em Profissionais de TI

Link para o original
Um dos aspectos da inteligência humana que me fascina é o aprendizado. O ser humano é capaz de criar conceitos e concepções a partir de suas experiências e reflexões; e com isso passa a saber coisas que, momentos antes, não sabia. O ser humano cria conhecimento! Entretanto, a mente opera em diversos níveis, com maior ou menor grau de consciência sobre seus pensamentos e o saber também ocorre em diversos níveis de consciência.
Há um saber racional, intelectual e consciente, que conseguimos repetir e explicar, mas que curiosamente não é muito efetivo. Neste campo estão aquelas posturas que sabemos que são corretas mas que na prática temos muita dificuldade de realizar, pois, no fundo, não acreditamos nelas de verdade.
vulnerabilidades-seguranca-negocio
Por outro lado, existe um saber emocional, um tanto ilógico e inconsciente, mas muito efetivo porque reside em um nível muito mais profundo da mente. Este é o saber internalizado, onde estão gravados os conceitos em que acreditamos de verdade. O aprendizado real começa com a aquisição de um saber no nível consciente mas só se completa quando este saber é internalizado.
Pois um destes saberes, que está em pleno processo de internalização em minha mente, é algo que venho ouvindo e repetindo por toda minha carreira:
A Segurança da Informação tem que ficar próxima ao negócio, pois o que importa é proteger o negócio e não a tecnologia que o suporta.
Sinto que só recentemente estou começando a acreditar nisso de verdade e quero mostrar aqui uma aplicação prática desse conceito em um dos assuntos mais áridos em Segurança da Informação para quem não é da área: Análise de Vulnerabilidades.
A típica Análise de Vulnerabilidades começa com a escolha do escopo: uma coleção de ativos tecnológicos importantes, que normalmente compõem o ambiente produtivo da empresa, separando o que está exposto à internet do que não está.
Em seguida, com auxílio de alguma ferramenta, é feita uma varredura nesses ativos para identificar elementos desatualizados dos sistemas e configurações permissivas que de alguma maneira abram brechas para um acesso não-autorizado ou para uma paralisação de serviço não-autorizada.
O próximo passo, usualmente automatizado, é classificar todas as falhas de segurança encontradas em uma escala que varia entre três e cinco níveis de criticidade. No caso de uma análise mais elaborada, identifica-se ainda quais são vulnerabilidades comprovadamente exploráveis por ferramentas disponíveis na internet e quais são vulnerabilidades sem evidência de explorabilidade – Vale lembrar que ausência de evidência não significa evidência de ausência!
O último passo é priorizar a correção das vulnerabilidades, começando pelas exploráveis a partir da internet, gerar números para tudo isso, juntamente com uma série de gráficos com apontamentos de prioridade e metas de correção, para finalmente levar para o nível executivo e caprichar na retórica para ganhar patrocínio para o processo de remediação.
Esse método até funciona, mas funciona muito mal por que o que descrevi acima não protege o negócio e sim a tecnologia. Já na partida, escolhemos o escopo pensando em ativos tecnológicos importantes, sem sequer pensar em que processos de negócio rodam lá.
O nível executivo está preocupado com o negócio e não com a tecnologia; e não tem condições de conectar o risco tecnológico ao risco de negócio. Sem essa conexão, toda a retórica fica sem importância e o patrocínio para o projeto sucumbe diante da primeira disputa por recursos com um incidente em produção ou com um projeto de negócio que dê retorno financeiro à empresa.
O que apresento a seguir uma uma abordagem de fato centrada no negócio desde a definição de escopo. Os passos sugeridos são:
  1. Aproximar-se de alguns stakeholders do negócio. Esta é a pedra fundamental por que, assim como falta ao executivo conhecimento sobre a tecnologia, falta a você conhecimento sobre o negócio. Humildade é fundamental para construir pontes!
  2. Identificar, junto a estes stakeholders, os macroprocessos de negócio que são críticos e que rodam em sistemas ou em infraestrutura de tecnologia.
  3. Elencar, ainda com eles, riscos de negócio provenientes de desvios nestes processos críticos que poderiam ocorrer dentro dos sistemas. Exemplos seriam: “Fraudar pagamento para desviar dinheiro da empresa” ou “Paralisar uma planta produtiva por quarenta e oito horas” ou ainda “Disponibilizar para um concorrente o blueprint dos novos produtos que ainda estão sendo desenvolvidos”.
  4. Mapear em quais sistemas, bancos de dados, servidores e equipamentos de rede rodam os macroprocessos críticos identificados no passo [2] e com isso definir o escopo de sua análise de vulnerabilidades.
  5. Realizar a análise técnica e gerar a lista de vulnerabilidades tecnológicas classificadas e priorizadas.
  6. Construir a ligação entre os conceitos, isto é, conectar cada vulnerabilidade grave e/ou explorável com um dos riscos de negócio mapeados no passo [3], cruzando o ativo da vulnerabilidade com o ativo em que o macroprocesso de negócio roda e conciliando o tipo de exploração da vulnerabilidade com o risco de negócio do respectivo macroprocesso.
  7. Apresentar ao nível executivo os mesmos gráficos, metas e apontamentos de prioridade, trocando a descrição das vulnerabilidades pela descrição do risco de negócio que a exploração das vulnerabilidades poderia gerar.
conexao
Com isso, você estará substituindo um discurso do tipo:
“Encontramos 3 vulnerabilidades graves que permitem adulterar o banco de dados do sistema de reembolso de despesas”
por algo como:
“Encontramos 3 maneiras diferentes de desviar dinheiro da empresa através de reembolsos de despesas fraudulentos que podem ser gerados e efetivados sem aprovação do gerente, explorando fragilidades no sistema”.
Parece ser uma mera mudança de discurso, mas não é. Trata-se de uma mudança de paradigma, que provoca uma mudança de linguagem. Nela, se abandona a linguagem técnica e se adota a linguagem de negócio, que afinal de contas, é a única que o nível executivo fala e entende.
Quando vivemos a experiência de pensar Segurança da Informação como Negócio e de falar de Segurança da Informação como Negócio, presenciamos um resultado tão fantasticamente diferente, que o sentimento de realização impulsiona a internalização desse conceito que é tão importante: Vulnerabilidades só importam quando são Vulnerabilidades de Negócio, porque Segurança da Informação só é relevante quando estabelece Segurança para o Negócio.
Publicado originalmente em Blog Ticiano Benetti

Cinco recomendações para a implementação de DevOps

Gerardo Dada * 
Publicada em 26 de fevereiro de 2017 às 09h42 em CIO.

Existem algumas maneiras de encarar o DevOps. Primeiro, como uma metodologia de desenvolvimento baseada na integração e na entrega contínuas, com o respaldo de um conjunto de ferramentas de gerenciamento de configurações, como Chef, Puppet, Salt e Ansible. 
Também podemos pensar no DevOps como um conjunto mais simples de princípios que orientam as práticas de desenvolvimento e de implantação (automatizar, monitorar e registrar tudo em log). Tudo com a meta de visualizar como cada alteração em um processo iterativo acelerado afeta o desempenho.
O desafio – além da complexidade envolvida na implementação dessas ferramentas, na criação de scripts e na transformação de todo o processo de desenvolvimento – é que o DevOps exige uma mudança de cultura e um novo conjunto de habilidades.
A principal pergunta é: por onde começar? Como as equipes podem começar a desfrutar dos benefícios do DevOps sem ter que esperar meses ou anos para que as novas habilidades, ferramentas e processos estejam prontos e a nova cultura tenha se arraigado?
Noções básicasTalvez, o melhor forma seja começar pelas noções básicas. A ideia central por trás do DevOps é a de que os desenvolvedores e as equipes de operações devem trabalhar juntos, colaborando, para fornecer que os desenvolvedores possam ter, em tempo real, as informações sobre como os aplicativos são executados, a fim de melhorar o desempenho enquanto estão sendo criados. Um aspecto essencial do estabelecimento de uma cultura de DevOps é proporcionar às equipes de desenvolvimento e operações  a visualização imediata do desempenho dos aplicativos. 
Equipes só trabalham bem juntas quando compartilham um propósito e têm um entendimento comum da realidade. No âmbito do desenvolvimento de aplicativos isso significa que, para que o DevOps tenha algum impacto, todos estejam de acordo quanto a uma única versão da verdade, o que proporciona um entendimento comum do que está funcionando e do que não está.
 Embora isso pareça simples, a realidade é que, com bastante frequência, as diferentes equipes que trabalham em aplicativos estão organizadas em silos, com cada uma delas executando seu próprio painel, tendo a perspectiva de uma parte específica da pilha de aplicativos. 
Por isso, um grande primeiro passo rumo ao DevOps é trabalhar no sentido de proporcionar uma única versão da verdade para essas equipes – uma estrutura comum em que todos os membros da equipe possam compreender o que acontece nos aplicativos, sistemas de banco de dados, sistema operacional, hipervisor, servidor de host e armazenamento. Só assim é possível eliminar a troca de acusações, determinando com clareza onde estão os problemas, afastando a a ambiguidade, focando na ação.
Como implementarCom isso em mente, apresentamos cinco recomendações para implementar uma cultura DevOps em sua organização:
 1.  Proporcione aos desenvolvedores uma visualização direta do monitoramento dos servidores de produção, preparo e teste. Até que o desenvolvedor veja o comportamento efetivo do código, ele não terá como saber como o aplicativo se comportará de fato.
2.  Torne as equipes autossuficientes com relação às observações sobre desempenho, eliminando gatekeepers e silos de informações. Quando os desenvolvedores têm informações diretas sobre o desempenho, a interação deles com o pessoal de operações são mais construtivas e eles não precisam implorar por informações.
3.  Torne o desempenho um requisito explícito logo de saída. Por muito tempo, o desempenho foi considerado algo secundário, com que se deve lidar apenas quando as especificações funcionais tiverem sido atendidas. Tornar requisitos de desempenho uma parte essencial do processo de design, com testes e avaliações de desempenho logo no início do ciclo de desenvolvimento, garante que eles não tenham que ser acrescentados posteriormente.
4.  Estabeleça métricas compartilhadas, de modo que o desenvolvimento, a produção e a gerência tenham uma base para comparação dos resultados, avaliação do progresso e rastreamento do impacto das alterações. Quando os engenheiros de software e de sistema têm uma base comum para discussão e avaliação do progresso, estão em melhor posição para  trabalhar por uma meta comum.
5.  Concentre o foco na experiência do usuário final, seja este um cliente externo ou o responsável por um aplicativo em uma unidades de negócio. Quando a TI se volta para o serviço, o nível de serviço proporcionado ao cliente torna-se a única métrica realmente importante para avaliação do departamento de TI. Com a meta comum de proporcionar um serviço responsivo e previsível para aplicativos  dirigidos ao usuário final, tanto a produção quanto o desenvolvimento podem colaborar para o seu cumprimento.
devops625cio
Mas isso não é tudoHá mais duas considerações importantes. Primeiro, somente as ferramentas de monitoramento não são suficientes. O monitoramento baseado em integridade fornece o status ativo/inativo para dezenas ou centenas de componentes, em geral com foco em indicadores de status verde, amarelo ou vermelho. Eles são úteis para identificar quando algo não funciona, mas são muito limitados para identificar a causa raiz dos problemas apontados e a correlação entre os componentes. Um sistema pode ser totalmente ineficiente e, mesmo assim, o painel de monitoramento mostrar apenas luzes verdes, já que nada em especial está avariado. Por isso, é importante olhar para um sistema com uma visão de desempenho, para compreender os tempos de espera e os congestionamentos.
Segundo, muitas equipes DevOps tentam monitorar tudo. O resultado são logs de mais de um gigabyte que exigem ferramentas avançadas e muito tempo de análise. Embora os gráficos produzidos possam ser muito interessantes, sua utilidade é limitada à capacidade de produzir informações. Um terabyte de dados de log é algo inútil, a menos que possa especificar o que há de errado com o sistema.
ConclusãoPara resumir, as equipes de desenvolvimento e de operações podem trabalhar melhor em conjunto quando: 
1 - Compartilham uma mesma visão do sistema, que fornece visibilidade de todas as camadas da pilha e das dependências entre elas;
2 - Estão voltadas para o desempenho e seu foco se concentra em localizar congestionamentos e informações que resultem em ação;
Mesmo sem a complexidade de um sistema completo de gerenciamento de configurações, partir das metas corretas e contar com um ferramental de desempenho eficaz pode deixar você um passo mais próximo do nirvana do DevOps, o que significa aplicativos mais rápidos e inovação acelerada.

(*) Gerardo Dada é vice-presidente de marketing de produtos da SolarWinds
- See more at: http://cio.com.br/gestao/2017/02/26/cinco-recomendacoes-para-a-implementacao-de-devops/#sthash.iKcfKXSm.dpuf