SecOps ou DevSecOps – que bicho

é este ? pra que serve?

12/08/2019 mindsecblog Artigos, Notícias 2

SecOps ou DevSecOps – que bicho é este ? pra que serve? É uma abordagem de
gerenciamento que conecta equipes de segurança e operações.

O SecOps, também chamado de DevSecOps, é uma abordagem de gerenciamento que

conecta equipes de segurança e operações, semelhante a como o DevOps unifica
desenvolvedores de software e profissionais de operações.

A premissa por trás do SecOps é garantir que as equipes de segurança e operações

compartilhem a responsabilidade, os processos, as ferramentas e as informações para
garantir que a organização não precise sacrificar a segurança para obter mais tempo de
atividade e melhor desempenho.

Manter as duas equipes envolvidas no processo fornece maior visibilidade sobre quais
mudanças são necessárias e qual pode ser o impacto dessas mudanças em outras partes
do negócio.

A integração de Segurança no ciclo de Desenvolvimento é importante para reduzir o

retrabalho e diminuir falhas devido a requerimentos de segurança não seguidos.

Seu objetivo é aumentar a segurança da informação, agilidade de TI e agilidade de

desenvolvimento. No entanto, as empresas tem enfrentado vários desafios, incluindo o
tempo necessário e as diferenças culturais entre as funções de segurança, TI e DevOps.

O processo de mesclar segurança com operações envolve várias etapas!

O processo de adicionar Sec ao DevOps não é fácil, envolve várias etapas e requer um
compromisso com mudanças culturais dentro da empresa: todos precisam assumir a
responsabilidade pela segurança, estar na mesma página sobre seus deveres e trabalhar
juntos durante os processos de desenvolvimento e entrega.

Ele também requer o desempenho da análise de segurança do aplicativo em todas as

etapas do ciclo de vida da entrega de software, uma dose considerável de automação e a
implementação das ferramentas certas.

“O departamento de segurança é frequentemente visto nas organizações como um bloqueador de

inovação porque os requisitos e processos que eles acrescentam diminuem o ritmo dos lançamentos
de código.  Se a segurança quer trabalhar melhor com as equipes de DevOps, precisa adotar
abordagens que melhorem a segurança e, ao mesmo tempo, capacitem a inovação”, diz Andrew
Peterson, CEO da Signal Sciences, empresa de segurança de aplicativos web .

As equipes de segurança devem seguir três princípios para reunir as tribos SecOps e
DevOps:

 Construir uma ponte entre as culturas de segurança e engenharia

 Criar laços de feedback adequados que capacitam as equipes de desenvolvimento
a atingir a velocidade de entrega desejada
 Insistir em que tudo, inclusive a infraestrutura, seja tratado como código, ou
componentes, para ser gerenciado e testado de forma eficaz em uma base
contínua.

“A busca desses três princípios é um esforço contínuo, e as ferramentas e processos que permitem
que as equipes de segurança alcancem com sucesso esses objetivos serão aquelas que se mostrarem
mais efetivas”, observa ele.

O processo de mesclar segurança com operações envolve várias etapas. A primeira fase
do processo é consolidar as prioridades e os processos de tomada de decisão. Em
seguida, os canais de comunicação, as ferramentas de software e as autorizações para a
informação precisam ser compartilhadas para dar a cada membro da equipe uma visão
holística e uniforme do desenvolvimento. Por fim, todos os processos de desenvolvimento
precisam ser atualizados para incorporar a segurança em cada estágio.

A diferença mais importante entre as metodologias SecOps e de gerenciamentos

alternativos é que a segurança está incluída na responsabilidade de todos os membros da
equipe e em todos os aspectos da organização.

Por exemplo, um agente de atendimento ao cliente pode perceber uma notificação por e-
mail suspeita ou um engenheiro pode relatar uma tentativa de injeção de SQL.

Como as equipes de segurança da informação desempenham um papel mais crucial nas

organizações, a SecOps é importante para garantir que a lacuna entre a segurança e as
operações não cause problemas em toda a empresa. A colaboração das equipes de
segurança com as equipes de operações ajuda as organizações a reduzir as ineficiências
do processo, tornar-se mais seguras no geral e compartilhar a responsabilidade.

Objetivos do SecOps
Os objetivos de uma abordagem bem-sucedida de SecOps giram em torno da introdução
de aspectos de segurança mais cedo ou em todos os estágios do ciclo de
desenvolvimento.
A ênfase é colocada na alta administração para se comprometer a fazer melhorias de
segurança, a fim de implementar um roteiro mais holístico. Os objetivos também podem
incluir colaboração entre equipes e revisão inter-funcional de riscos operacionais.

O SecOps pode ser uma mudança cultural para algumas organizações que exige que
questões maiores sejam abordadas antes que as metas possam ser alcançadas.

Nessa situação, os objetivos podem incluir a redefinição de funções e prioridades de

trabalho, delineando os riscos de negócios associados a incidentes de segurança e
concordando com as principais funções de negócios.

Benefícios

A implementação de uma abordagem SecOps está associada aos seguintes benefícios:

• Maior retorno do investimento (ROI).

• Melhor produtividade.
• Uso mais eficiente de recursos compartilhados.
• Menos interrupções de aplicativos ou serviços.
• Auditoria de segurança mais simplificada
• Maior visibilidade das vulnerabilidades de segurança em toda a organização.
• A adoção mais fácil de tecnologias que exigem medidas avançadas de segurança, como
serviços em nuvem.
• Gerenciamento e resposta a incidentes mais fortes
• patch mais eficaz
• Menos conformidade

DevSecOps
Um termo relacionado ao SecOps é DevSecOps, um processo que envolve as práticas de
segurança entre desenvolvimento e operações. Embora o termo DevSecOps seja
relativamente novo, a ideia de abordar a segurança em cada estágio do ciclo de vida do
software existe há anos. O DevSecOps geralmente se concentra em uma abordagem Ágil
para o desenvolvimento, que visa a velocidade e a eficiência. As equipes estão
trabalhando juntas para garantir que a segurança se mantenha no mesmo nível do
desenvolvimento e das operações.

Ano passado publicamos aqui no Blog dois artigos sobre o assunto Segurança e DevOps –
Conceito Novo para uma Necessidade Antiga e

DevSecOps: Desenvolvimento rápido sem sacrificar a segurança, onde colocamos que a

integração de Segurança no ciclo de Desenvolvimento é importante para reduzir o
retrabalho e diminuir falhas devido a requerimentos de segurança não seguidos e que a
integração correta de pessoal e tecnologia de segurança, incluindo certificados digitais,
pode melhorar as métricas organizacionais, evitar atrasos caros e melhorar a experiência
do usuário final.

Como explicamos nestes artigos, a Segurança da Informação é sempre vista “uma pedra
no sapato” quando é chamada somente ao final do ciclo de Desenvolvimento e necessita
barra ou cobrar algum tipo de controle que não tenha sido implementado.

Usualmente quando um processo estruturado não acontece a Segurança é chamada ao

final para liberar “regras de firewall” ou “criar usuários” e então descobre-se que o produto
não implementa questões importantes de segurança e o desenvolvedor precisa voltar para
a “prancheta” ou o produto entra em produção com deficiências importantes e coloca a
organização exposta a riscos desnecessários.

Uma boa integração de Segurança com Desenvolvimento, aqui dê-se o nome que quiser, 
DevOps ou outro, mapeia as fases do desenvolvimento e define-se os entregáveis de
ambas as áreas para que se tenha as orientações e avaliações de segurança necessárias
ao mesmo tempo que se tem as informações e implementações realizadas nos produtos.

A algum tempo atrás, em 2007, bem antes de falarmos de DevOps, tive o prazer de liderar
uma equipe excelente de profissionais de segurança em um banco, onde definimos o que
chamamos na época de ASTI que representava um indíce de “Aderência à Segurança de TI”.
Para criar o ASTI, mapeamos cada fase da metodologia de desenvolvimento e definimos
os entregáveis em cada uma delas.

Passamos a reportar mensalmente, nos comitês de TI e no book mensal da área, a

aderência média de cada superintendência de desenvolvimento (o banco tinha várias, uma
para cada área de negócio). Mas claro que antes comunicamos a todos o que iríamos
fazer nos reunindo e explicando a cada uma das áreas individualmente.

No início causamos certo desconforto pois ninguém queria ver um número ruim na sua
área, com o passar dos meses as equipes de Dev entenderam o propósito e “compraram”
ideia, pois viram o benefício de ter a área de segurança envolvida desde o início no ciclo
de desenvolvimento ajudando a definir os caminhos necessários para um desenvolvimento
seguro e aderentes as normas do banco e não sendo mais a “pedra no sapato” na hora de
subir para produção.

Um ano depois conseguimos fazer com que um percentual do indíce de qualidade do geral
do projeto fosse relativo a avaliação ASTI.  Sucesso!!!!  Estava implementado o melhor
processo de integração de segurança e desenvolvimento do qual tive oportunidade de
participar e ver implementado. Claro que tive alguns problema com o ajuste de workload da
área, mas isto a gente sempre resolve de alguma forma, e ali não foi diferente, a equipe
era realmente boa.

Pelo que sei o sistema funcionou e evoluiu ainda mais até a venda do banco em 2016,
quase 10 anos depois.

Portanto, seja qual for a forma de integração de segurança ao processo de

desenvolvimento e de novos projetos de infraestrutura que use, seja qual for a metodologia
“da moda” que adote, ou que desenvolva a sua própria metodologia, afirmo, sem medo
que errar, que um bom processo de integração de segurança no ciclo de desenvolvimento
de projetos, desde a geração da demanda até a pós implementação, o processo agrega e
muito na robustez do ambiente e reduz o tempo de “go-live” e custo de cada solução
(devido ao não retrabalho). De quebra o CSO poderá dormi mais tranquilo !