Entendendo os resultados desejados: como selecionamos o conjunto de recursos do Cloud Defense Free

Quando decidimos lançar uma versão gratuita do FireMon Cloud Defense, sabíamos que teríamos de equilibrar dois desafios fundamentais:

• Já sabíamos que a nossa plataforma conseguia escalar, mas conseguiríamos adaptá-la para escalar de forma economicamente viável e suportar grandes empresas a longo prazo? Escusado será dizer que não podíamos simplesmente lançá-la e esperar que as nossas faturas da AWS não nos levassem à insolvência.
• Com as limitações económicas, conseguiríamos disponibilizar um conjunto de funcionalidades que entregasse valor real aos utilizadores? Qual seria esse valor? Que problemas resolveria?

A realidade é que “gratuito” nunca é totalmente gratuito, uma vez que usar qualquer coisa exige tempo e esforço. Não encaramos o nível gratuito do Cloud Defense como migalhas que deixamos cair da ponta da mesa; sabemos que, se pedimos aos utilizadores que se registem, implementem e utilizem a plataforma, eles só o farão se os ajudarmos a fazer o seu trabalho.

(E o que ganhamos com isso? Bem, sabemos que uma certa percentagem passará para os nossos planos pagos, mas a plataforma gratuita ajudar-nos-á a obter feedback extremamente valioso sobre o que as pessoas querem do seu CSPM e como o utilizam, permitindo-nos testar novas ideias.)

Em publicações futuras falaremos da tecnologia com mais profundidade, mas hoje queremos percorrer o nosso processo de decisão sobre quais as funcionalidades a incluir no nível gratuito. Uma vez que encaramos esta versão da plataforma como um produto autónomo, decidimos usar a mesma abordagem metodológica que orienta grande parte da nossa estratégia.

Definir os resultados pretendidos

Aqui na FireMon somos grandes adeptos do modelo Jobs to be Done para a estratégia de produto. O nome é bastante revelador, mas o modelo orienta as decisões de produto ao centrar-se na tarefa que o cliente está a tentar realizar e nos resultados específicos que espera. Trata-se de uma simplificação grosseira do modelo JTBD, mas percebe-se a ideia. Em vez de se concentrar em funcionalidades, concentra-se nos resultados que um potencial cliente pretende ao utilizar um produto e usa isso para conceber as funcionalidades.

Depois de um processo aprofundado que incluiu investigação, experiência e entrevistas, chegámos a um conjunto preliminar de possíveis resultados pretendidos pelos profissionais de segurança na cloud:

• Melhorar o meu conhecimento e compreensão da nossa postura na cloud em toda a nossa presença cloud. (visibilidade)
• Minimizar a probabilidade de ser configurada uma má configuração na cloud em toda a nossa presença cloud. (prevenção)
• Reduzir as nossas exposições de segurança e conformidade na cloud (volume e tempo) em toda a nossa presença cloud, num ambiente descentralizado. (remediação)
• Melhorar a nossa capacidade de comunicar questões de segurança na cloud à gestão e aos reguladores.
• Reduzir o potencial de perda e abuso de acessos IAM às nossas implementações na cloud.
• Melhorar a nossa capacidade de prevenir, detetar e responder a ataques na cloud
• Manter a nossa segurança atualizada face às alterações nos serviços e plataformas cloud de vários fornecedores.
• Reduzir o atrito e a sobrecarga de segurança sobre as equipas de desenvolvimento e de cloud sem aumentar os nossos riscos de segurança.
• Reduzir o risco de uma violação de segurança quando implementamos com contentores.
• Reduzir o tempo que dedico a integrar a segurança na cloud no meu programa, com APIs e estruturas de dados padronizadas.

É evidente que há muitas formas de abordar cada um destes problemas, pelo que a questão para nós era: quais conseguiríamos disponibilizar dentro das restrições económicas de operar uma plataforma gratuita e alojada? É muito diferente de disponibilizar software open source que alguém tem de implementar e executar por conta própria. Queríamos construir algo tão rápido e fácil de utilizar como um produto comercial (bem, esperamos que mais rápido e mais fácil do que muitos dos produtos que já utilizou no passado).

Traduzir resultados em funcionalidades

Com essa lista, era altura de ver o que podíamos adaptar ou construir:

• Melhorar o meu conhecimento e compreensão da nossa postura na cloud em toda a nossa presença cloud. (visibilidade)

A postura não diz necessariamente respeito apenas à segurança; a postura é a forma como as coisas estão configuradas. Uma vez que fornecer apenas uma lista de más configurações não comunicaria a postura, sabíamos que teríamos de construir um inventário da cloud, à escala empresarial, dentro das nossas restrições de custos. A nossa plataforma já suportava um inventário em tempo real, mas não era economicamente viável escalá-lo para o nível gratuito.

Decidimos que conseguiríamos equilibrar os custos e ainda assim entregar valor com análises uma vez por dia e um histórico de inventário de 30 dias com registo de alterações. Repare que ainda não estamos a falar de más configurações de segurança, mas lá chegaremos. Depois de fazer alguma modelação de custos, percebemos que conseguíamos executar isto à escala empresarial (milhares de contas monitorizadas) dentro do nosso orçamento, pelo que cumpria ambos os requisitos: entregar valor e controlar custos.

Na verdade, isto exigiu um esforço de engenharia considerável, já que o produto comercial suportava sobretudo atualizações de inventário em tempo real, em vez de análises periódicas. No entanto, agrupámos essas atualizações com outras alterações que queríamos fazer e que melhoravam a eficiência global, pelo que se alinharam bem, tornando a decisão fácil.

• Minimizar a probabilidade de ser configurada uma má configuração na cloud em toda a nossa presença cloud. (prevenção)

Prevenir más configurações na cloud é um problema muito mais difícil do que detetá-las. Bloqueia-se no pipeline de CI/CD se estiverem a usar Infrastructure as Code? E as alterações manuais? Como gerir os fluxos de trabalho sem acrescentar demasiado atrito ou partir coisas?

Sabíamos que, de momento, não conseguiríamos implementar uma prevenção completa num produto gratuito. A nossa plataforma atual trata disto através de automação, cuja execução em escala seria demasiado dispendiosa para ser gratuita. No entanto, temos algumas ideias que poderão funcionar e que estão agora no nosso backlog de desenvolvimento.

• Reduzir as nossas exposições de segurança e conformidade na cloud (volume e tempo) em toda a nossa presença cloud, num ambiente descentralizado. (remediação)

Isto tem sido o essencial do Cloud Defense desde as primeiras versões do produto. Embora a remediação automatizada não funcionasse no nosso nível gratuito (novamente, equilibrando custo e complexidade), não havia razão para não executar o nosso conjunto completo de verificações de segurança.

Mas receber uma longa lista de potenciais problemas de segurança não ajuda necessariamente a remediá-los. Outra das capacidades centrais do nosso produto é a integração profunda com ChatOps. De origem, suportávamos Slack e Teams, mas o Teams exigiria mais suporte porque… bem… é o Teams. Por isso, decidimos ativar plenamente as nossas notificações granulares do Slack (por conta ou projeto), já que não representavam um custo material para nós e traziam muito valor aos utilizadores.

• Melhorar a nossa capacidade de comunicar questões de segurança na cloud à gestão e aos reguladores.

Os nossos custos internos para produzir um relatório de conformidade são negligenciáveis, mesmo em ambientes de grande dimensão. No caso da conformidade, avaliações uma vez por dia tendem a satisfazer largamente este resultado pretendido. Tivemos de investir algum esforço de desenvolvimento adicional para suportar melhores relatórios em PDF em implementações maiores (por exemplo, centenas de contas), mas isso era algo de que precisávamos de qualquer forma para os nossos clientes comerciais.

• Manter a nossa segurança atualizada face às alterações nos serviços e plataformas cloud de vários fornecedores.

Como os nossos produtos gratuito e comercial utilizam a mesma biblioteca de verificações, que atualizamos constantemente, isto ficou disponível de origem. O nosso esforço inicial de engenharia centrou-se na otimização de custos para a AWS, pelo que decidimos lançar sem suporte para Azure ou GCP no início. O Azure está quase pronto, pelo que os utilizadores acabarão por ter suporte multicloud completo de forma gratuita.

• Reduzir o potencial de perda e abuso de acessos IAM às nossas implementações na cloud.

Temos uma funcionalidade notável chamada Authorization Control que melhora materialmente a segurança IAM, mas as contas simplesmente não permitiam incluí-la no produto gratuito.

• Melhorar a nossa capacidade de prevenir, detetar e responder a ataques na cloud

O nosso produto comercial suporta deteção de ameaças em tempo real, mas esta foi outra funcionalidade cujas contas simplesmente não permitiam o suporte numa plataforma gratuita, devido ao elevado volume de atividade que temos de monitorizar em tempo real.

• Reduzir o atrito e a sobrecarga de segurança sobre as equipas de desenvolvimento e de cloud sem aumentar os nossos riscos de segurança.
• Reduzir o risco de uma violação de segurança quando implementamos com contentores.
• Reduzir o tempo que dedico a integrar a segurança na cloud no meu programa, com APIs e estruturas de dados padronizadas.

Todos estes resultados acrescentavam custos e/ou complexidade que não considerámos poder abordar adequadamente no produto gratuito, fosse por custos de infraestrutura, de suporte ou de desenvolvimento.

Definir o conjunto de funcionalidades

Os resultados pretendidos, combinados com a nossa análise de custos, ajudaram-nos a decidir que funcionalidades incluir:

• Análises uma vez por dia
• Inventário de recursos com um histórico de 30 dias
• O conjunto completo de verificações de segurança
• Relatórios de conformidade fundamentais
• Integração com Slack
• AWS por agora, Azure e GCP à medida que atualizarmos a plataforma

Nem sempre foram decisões fáceis. Por exemplo, mesmo um inventário de 30 dias acarreta custos, mas não considerámos que disponibilizar apenas relatórios de más configurações respondesse adequadamente às necessidades de visibilidade de um utilizador. Decidimos também que limitar as nossas verificações de segurança ou exigir que alguém passasse para o produto comercial para obter relatórios de conformidade resultaria igualmente num produto que não proporcionaria um resultado suficiente.

Este conjunto responde aos resultados pretendidos essenciais de visibilidade de segurança e aos resultados de comunicação, melhorando o reporte e reduzindo os prazos de remediação. E sabemos que aqui existe valor, pois estes são os resultados pretendidos que levaram à criação das primeiras ferramentas OSS de segurança na cloud e que estiveram na origem de todo o mercado de Cloud Security Posture Management.

A estrutura JTBD nos ajudou muito a manter o foco na melhoria dos resultados para o cliente, em vez de simplesmente destacar alguns recursos que, juntos, não realmente ajudam ninguém. Acreditamos que o resultado final é uma plataforma gratuita que entrega valor real e, ao mesmo tempo, é tão eficiente em custos que podemos mantê-la a longo prazo.

Confira e diga-nos o que acha. O FireMon Cloud Defense é um trabalho em andamento e uma excelente maneira de aprimorarmos nossa capacidade de ajudar os profissionais de segurança em nuvem a realizar seu trabalho.