Processo de Gestão de Vulnerabilidades e Automação para OffSec e AppSec Utilizando Atlassian Jira: Proposta e Tutorial

Proposta e tutorial de estruturação e customização do Jira para atender as necessidades de um cenário corporativo com times de AppSec e OffSec.

Sumário  

• Sumário
• Introdução
• Cenário
  • Versões do Ambiente
• 🌟 Criação inicial do ambiente
  • Criando projetos
  • Novos issue types: Vulnerability e Vulnerability Fix Review
  • Atribuindo issue types aos projetos (issue type schemes)
  • Novos status
  • Issue Linking customizado
• 🔀 Configurando workflows
  • Vulnerability
  • Vulnerability Fix Review
  • Atribuindo fluxos a projetos e respectivos issue types (Workflow schemes)
    • Vulnerability
    • Vulnerability Fix Review
  • Adicionando novos status às colunas dos boards dos projetos
    • Projetos Scrum
    • Projetos Kanban
• 📥 Criando campos custumizados
  • Vulnerability Detection Origin
  • Vulnerability Due Date
  • Ajustando contextos - Vulnerability (Detection Origin|Due Date)
  • Ajustando contextos - Sprint e Story Points
  • Adicionando os campos à tela de Vulnerability
  • Adaptando o Priority para atender severidades
• 🤖 Automatizando e comunicando processos
  • Determinando SLA de correção de acordo com a política de Gestão de Vulnerabilidades
  • Abertura de tarefa automática de validação de correção
  • Replicação de comentários
  • Triagem automática de vulnerabilidades após avaliação de correção
• 🚧 Controles de segurança
  • Criação de grupo de gerenciadores de vulnerabilidades
  • Controle de movimentação de status
  • Controle preventivo de edição indevida de campos
    • Instalação do Plugin-in Script Runner
    • Escrevendo script para ScriptRunner Behavior
  • Controle de edição de IssueType
    • Controle na visualização
    • Controle detectivo de movimentação da issue
• 😅 Considerações finais
• 📚 Referências

Introdução  

Parece chato, eu sei, mas a gestão eficiente de vulnerabilidades é fundamental para a manutenção da segurança em qualquer organização, especialmente em times de Cybersegurança que lidam com múltiplos processos e ferramentas. Neste tutorial, gostaria de explorar com vocês como estruturar e customizar o Jira para atender as necessidades de um cenário corporativo com três equipes de segurança: Gestão de Vulnerabilidades, Segurança de Aplicações (AppSec) e Segurança Ofensiva (OffSec). Além deste times, incluiremos como exemplo dois times de engenharia como responsáveis por correção de algumas vulnerabilidades: Site Reliability Engineering e Onboarding.

A grande vantagem do uso do Jira neste processo é que os itens reportados por segurança poderão se integrar completamente no dia a dia de engenharia, facilitando a aceitacão psicológica dos envolvidos sem mudar em nada sua rotina de organização das entregas nos projetos.

Nosso foco será na criação de um fluxo de controle que garanta que todas as vulnerabilidades identificadas por esses times sejam formalizadas, priorizadas e acompanhadas até sua correção, respeitando uma política de gestão de vulnerabilidades. O Jira será o coração dessa operação, com customizações específicas em tipos de issues, workflows e automações que asseguram a conformidade e a segurança do processo.

Este tutorial é ideal para profissionais que desejam implementar uma solução replicável tanto no Jira Cloud quanto no Jira Data Center, com práticas que permitem um controle robusto das vulnerabilidades, do apontamento à validação final.

Cenário  

Considerando a existência de um time de Cybersegurança, com times de Gestão de Vulnerabilidades, Segurança de Aplicações (AppSec) e Segurança Offensiva (OffSec), se faz necessário um processo de controle de todos os apontamentos gerados pelos seus processos e ferramementas.

Nesta cenário corporativo teremos algumas características:

1. Todas as vulnerabilidades são formalizadas no Atlassian Jira e direcionadas diretamente nos projetos dos times responsáveis pela correção;
2. Há uma política de gestão de vulnerabilidades que determina alguns controles:
   • Tempo limite de correção a dependender a criticidade da vulnerabilidade;
   • Nenhuma vulnerabilidade deve ser encerrada antes da validação de mitigação por parte do time de segurança.

Para atender o cenário proposto, será realizada diversas customizações no Jira, como issue types, status, workflows, campos e prioridades. Além disso, serão criadas automações para gerenciar todo o fluxo de atendimento e controles de segurança para evitar alterações indevidas nas informações das vulnerabilidades.

Todo cenário é plenamente replicável em qualquer ambiente com Jira Cloud ( ou até mesmo com o Jira Data Center).

Versões do Ambiente  

• Jira Cloud - buildNumber 100267.
  • Esta informação você pode obter através da URL https://seu-dominio.atlassian.net/rest/api/3/serverInfo
• ScripRunner - 1.1.131-AC.
  • Esta informação pode ser obtida em Apps -> Manage Your Apps.

🌟 Criação inicial do ambiente  

Criando projetos  

Conforme cenário proposto, criaremos 5 projetos nos seguintes modelos:

• Times de Segurança

  • VULN - Gestão de Vulnerabilidades (Modelo Kanban)

  • APPSEC - Desenvolvimento Seguro (Modelo Scrum)

  • OFFSEC - Segurança Ofensiva (Modelo Scrum)

• Times de Engenharia

  • SRE - Site Reliability Engineering (Modelo Scrum)
  • ONB - Onboarding, Cadastro, Login, Autenticação, Autorização e etc. (Modelo Scrum)

Em Projects, clique em Create Project.

Abaixo será exemplificada a criação em modelo Kanban e Scrum. Vamos utilizar os templates de Software Development e criar o projeto VULN em modelo Kanban.

Clique em Use Template

Escolha o tipo de projeto “Company-managed”, ele dá mais possibilidades de configurações, integrações e controles.

Por fim, nomearemos este projeto como “Vulnerability Management Team”, com a sigla “VULN”.

Clique em Next e a criação deste projeto estará pronta!

Em relação aos demais projetos, basta seguir o mesmo modelo (Software Development - Kanban|Scrum - Company Managed) alterando apenas para o modo Scrum, para que seja possível simular as interações das tarefas dentro de suas sprints.

Por fim, teremos os seguintes projetos configurados.

Novos issue types: Vulnerability e Vulnerability Fix Review  

Para seguir com nossa proposta, serão criados novos tipos de issues (tickets ou cards). Enquanto em tarefas normais do dia a dia são utilizados os tipos Story, Task, Sub-Tasks ou Épicos, criaremos as seguintes:

• Vulnerability - Vulnerabilidades de qualquer origem provenientes de ferramentas e processos de cybersegurança;
• Vulnerability Fix Review - Destinados a tarefas de reteste de vulnerabilidades de cybersegurança.

Em Settings→ Issues → Issue Types, podemos criar as issuetypes acima.

Crie ambas issue types com o typo 0, pois não serão sub-tarefas.

Após a criação das issuetypes, fique a vontade para alterar o ícone de cada uma delas.

• Vulnerability
• Vulnerabilty Fix Review

Ambas ficarão desta forma:

Atribuindo issue types aos projetos (issue type schemes)  

Em Settings → Issue Types → Issue Type schemes, será necessário atribuir os novos tipos aos projetos específicos. As seguintes atribuições deverão ser feitas:

• Projetos ONB (Onboarding) e SRE (Site Reliability Engineering)

  • Vulnerability

• Projetos VULN (Vulnerability Management), OFFSEC (Offensive Security) e APPSEC (Application Security)

  • Vulnerability Fix Review

Começaremos pelo projeto ONB. Clique em “…” e em Edit. Depois arraste a IssueType Vulnerability para a lista do projeto. Faça o mesmo para SRE.

Agora realize a mesma atividade para a issue type Vulnerability Fix Review para os projetos VULN, APPSEC, e OFFSEC.

Após concluir esta fase nossos projetos terão a seguintes configuração de opções de issue types.

Ao visitar os projetas e realizar a criação de novas tarefas, será possível visualizar a disponibilidades dos novos tipos para uso.

No projeto ONB (Onboarding) a issue type Vulnerability. O mesmo estará disponível em SRE (Site Reliability Engineering).

No projeto OFFSEC (Offensive Security) a issue type Vulnerability Fix Review. O mesmo estará disponível em APPSEC (Application Security) e VULN (Vulnerability Management).

Novos status  

Seguindo após a criação dos novos issue types e suas atribuições ao projetos, criaremos os status em que cada novo tipo transitará dentro do Jira.

• Vulnerability
  • To Do (Default Jira)
  • In Progress(Default Jira)
  • Validate Fix - Status de categoria “In Progress” que será utilizado pelo time responsável pela correção para que acione o time de segurança para validação da correção.
  • Done (Default Jira)
  • False Positive
• Vulnerability Fix Review
  • To Do (Default Jira)
  • In Progress (Default Jira)
  • ✅ Fix Confirmed - Status de categoria Done que será utilizado pelo time de segurança para confirmação da correção após análise. Este status acionará a automação para encerrar a vulnerabilidade.
  • ❌ Fix Not Confirmed - Status de categoria Done que será utilizado pelo time de segurança para informação que a vulnerabilidade não foi mitigada após análise. Este status acionará a automação para transacionar o status da vulnerabilidade novamente para In Progress.
  • 🥳 False Positive Confirmed - Status de categoria Done que será utilizado pelo time de segurança para confirmação de falso positivo após análise. Este status acionará a automação para encerrar a vulnerabilidade como Falso Positivo.

Em Settings → Issues → Issue Attributes → Statuses, criaremos todos os novos status customizados, lembrando que é necessário atribuir sua categoria adequada.

Abaixo o exemplo da criação do status “Validate Fix”.

Faça o mesmo para False Positive, ✅ Fix Confirmed, ❌ Fix Not Confirmed e 🥳 False Positive Confirmed.

Issue Linking customizado  

Durante a criação das tarefas de triagem, é interassante relacionar as tarefas (Vulnerability <-> Vulnerability Fix Review) adequadamente, para isso iremos adicionar uma nova categoria de relacionamento genérica que pode servir para validação de correção de vulnerabilidades, bugs, requisitos de arquitetura e etc.

Em Settings -> Issues -> Issue Features -> Issue Linking, clique um novo tipo da seguinte forma:

• Name: “Testers”

• Outward Link Description: “tests”

• Inward Link Description : “is tested by”

Este relacionamento adequado nos auxiliará mais a frente nas lógicas de nossas automações.

🔀 Configurando workflows  

Os fluxos de trânsito dos tickets também deverão ser customizados, visto que o Jira automaticamente adiciona os status padrão, como Backlog, To Do, In Progress, Done, etc. Os workflows seguirão exatamente a lista dos status criados no capítulo anterior.

Em Settings → Issues → Workflows, iniciaremos a construção dos fluxos, clique em Add Workflow → Create New.

Vulnerability  

Começaremos pele issue type “Vulnerability”. Como exemplo daremos o nome do workflow como “Vulnerability Issue Type Workflow”.

Adicione os status In Progress, Validate Fix, Done e False Positive. Habilite a opção em cada um dos status para que eles possam transitar livremente de qualquer outro status. Caso queira travar a sequência de status desejado é só manter a opção desabilitada.

Vulnerability Fix Review  

Faremos o mesmo para “Vulnerability Fix Review” com nome “Vulnerability Fix Review Issue Type Workflow”. Como pode ver, os status são ligeiramente diferentes da issue type Vulnerability.

Atribuindo fluxos a projetos e respectivos issue types (Workflow schemes)  

Vulnerability  

Em Settings-> Issues -> Workflows -> Workflow Schemes, nos projetos onde serão necessários atribuir a issue type Vulnerability, clique em Edit.

Depois clique em Add Workflow -> Add Existing.

Adicione o “Vulnerability Issue Type Workflow”.

E assinale o fluxo para a issue Vulnerability, e clique em Finish.

Após retornar scheme clique em Publish e depois em Associate. Automaticamente os possível items criados com este tipo neste projetos terão seus fluxos atualizados.

Ao visualizar o fluxo da Vulnerability no projeto atualizado, observará os novos status disponíveis.

Vulnerability Fix Review  

O mesmo processo exibido acima deste der feito para o fluxo de Vulnerability Fix Review para os projetos APPSEC, OFFSEC e VULN, onde receberão as tarefas de triagem por automação, assunto que será abordado mais a frente neste tutorial.

Ao fim, teremos a seguinte composição no esquema de workflows.

Adicionando novos status às colunas dos boards dos projetos  

Um comportamento que poderá ser visto, será ao mover as vulnerabilidades para o status “Validate Fix”, elas simplesmente “desaparecerem” dos boards dos projetos. Isso ocorre devido a necessidade de mapear o status de acordo com as colunas configuradas nos boards dos projetos.

Para resolver este problema, faça você mesmo ou instrua os responsáveis para realizar os ajustes demonstrados abaixo.

Projetos Scrum  

Caso o projeto seja do modelo Scrum, clique em Active Sprints, depois em Configure Board.

Em columns, mova os status False Positive para “Done”, e Validate Fix para “In Progress”.

Abaixo como deve ficar a configuração das colunas.

Projetos Kanban  

Para projetos Kanban, não é muito diferente, basta clicar em Kanban board e depois em Configure board.

E em seguida mover cada status não mapeado para sua coluna apropriada de acordo com sua natureza.

📥 Criando campos custumizados  

Ainda seguindo com as customizações necessárias, criaremos e configuraremos dois campos que nos ajudarão na categorização e aderência a uma possível política de SLA (Service Level Agreement) de correção de vulnerabilidades, sendo eles respectivamenter Vulnerability Detection Origin e Vulnerability Due Date. Além da criação dos campos, serão necessários ajustes para que fiquem totalmente disponíveis nos projetos.

Vulnerability Detection Origin  

Em Settings → Fields → Custom fields, crie um novo campo chamado “Vulnerability Detection Origin” com o tipo Select List.

Modifique seu contexto para que ele apenas apareça na issue type Vulnerability.

Adicione quais serão as origens de detecção. Essas origens farão parte da regra de reteste. Dependendo do seu valor, será aberto o tipo específico de avaliação.

As opções criadas serão:

• Pentest - OffSec Team
• Adversary Simulation** - OffSec Team
• SAST (Checkmarx, Veracode, Snyk, etc) - AppSec Tem
• SCA (Checkmarx, Veracode, Snyk, etc) - AppSec Tem
• IaC Scanner (Checkmarx KICS, etc) - AppSec Tem
• DAST (Qualys, Tenable, Rapid7, BurpSuite Professional, etc) - AppSec Tem
• Infra Scanner (Qualys, Tenable, Rapid7, etc) - Vulnerability Mgmt Team
• 3SP Scanner (Third-Party Security Posture Manager, como Zanshin (Tenchi Security)) - Vulnerability Mgmt Team

Vulnerability Due Date  

Pelo fato do campo Due Date (Default) não estar disponível para nossas regras de proteção que abordaremos com ScriptRunner, criaremos um novo campo para a mesma natureza exclusiva para Vulnerabilidades. Sua utilidade será vista mais a frente.

Abaixo as características do campo:

• Tipo: Date Picker
• Nome: Vulnerability Due Date
• Screen: Vulnerbaility Issue Type Issue

Ajustando contextos - Vulnerability (Detection Origin|Due Date)  

Após a criação dos campos, é necessário delimitar em qual contexto eles estarão disponíveis. Busque pelos nossos campos criados, clique em “…” e depois em “Contexts and default value”. Abaixo o exemplo com o campo “Vulnerability Detection Origin”.

Logo após clique em Edit Context.

Selecione Vulnerability como o única issue type que receberá este campo customizado e deixe aplicado de forma global, se aplicando a todos os projetos do ambiente. Com tudo devidamente selecionado, clique em Modify.

Para o campo Vulnerability Due Date, basta replicar os mesmos passos acima.

Ajustando contextos - Sprint e Story Points  

Por se tratar de um ambiente em que trabalharemos também em modelo Scrum, podemos já deixar configurado o campo Story Points para todos os issue-types em todos os projetos. Esta configuração nem vem por default no Jira, por isso este ajuste deve ser feito.

O caminho para execução é o mesmo do anterior, e ficará da seguinte forma:

Adicionando os campos à tela de Vulnerability  

Após a criação do campo, em Settings → Screens → Screens, criaremos um screen chamado “Vulnerability Issue Type Screen”. Para que não seja necessário criar “do zero”, podemos fazer uma cópia de Default Screen.

Altere o nome do screen para “Vulnerability Issue Type Screen” e clique em Copy. Logo em seguida, clique em “…” -> Configure.

Adicione os campos Vulnerabilty Detection Origin, Sprint e Story Points (Caso trabalhe em modelo Scrum).

Depois em Settings → Screens → Screen Scheme, crie um esquema chamado “Vulnerability Screen Scheme” e atribua como Screen default o “Vulnerability Issue Type Screen” que criamos anteriormente.

E finalmente após configurar a tela (screen) e seu esquema. Precisamos atribui-los à issue type nos projetos necessários. Vá em Settings → Screens → Issue Type screen schemes, clique no scheme Default Issue Type Screen Scheme. Este passos garantirão que pode default todos os próximos projetos criadas terão este issue type e sua tela disponível.

Depois clique “Associate an issue type with a screen scheme“ e adicione o esquema de Vulnerability ao seu issue type.

Para que os projetos já criados tenham esta configuração, será necessária sua configuração manual, em nosso laboratório, faremos este passos em SRE e ONB.

Adaptando o Priority para atender severidades  

O Jira por default já possui uma categorização de prioridade, não totalmente aplicável para severidade. Dessa forma, temos duas opções:

1. Criar um novo campo chamado “Severity”;
2. Adaptar o campo Priority para atender ambas as demandas.

Sou extremamente favorável a seguir pela segunda opção, por simplificar o processo e deixar criar novos pontos de controle dentro do Jira. Mas isso dependerá muito do quão difundido as pioridades Highest e Lowest estão dentro de sua corporação. Caso o projeto de implementação do Jira esteja ainda no começo, a segunda opção é uma boa pedida, que será adotada neste laboratório.

Criaremos uma nova prioridade chamada “Critical”. Utilizaremos um novo ícone customizado.

Depois em Priority Schemes, vamos alterar a configuração Default. Removeremos a prioridade Highest e substituiremos por Critical, e removeremos a prioridade Lowest, ficará da seguinte forma:

Caso hajam issues com as prioridades removidas, podemos apontar para as prioridades remanescentes, como Critical e Low.

🤖 Automatizando e comunicando processos  

Determinando SLA de correção de acordo com a política de Gestão de Vulnerabilidades  

Para os responsáveis pela correção das vulnerabilidades, é importante saberem como devem priorizar cada uma delas. Para isso precisamos seguir a política de tempo de correção de acordo com as severidades de cada uma delas.

Usando como exemplo uma política que siga os SLAs de correção de vulnerabilidade, podemos começar a desenhar uma automação para automaticamente preencher o campo “Vulnerability Due Date”:

• 🟣 Critical - 15 dias
• 🔴 High - 30 dias
• 🟡 Medium - 60 dias
• 🔵 Low - 90 dias

Com estas informações em mãos, clique em Create Rule.

Lógica da regra:

• Nome: Configuração do SLA de correção (Vulnerability Due Date)
• Trigger: Quando uma issue é criada
• Condições:
• Se for do tipo “Vulnerability” e Priority igual a “Critical”
• Ações:
• Preencher o campo “Vulnerability Issue Date” com {{now.plusBusinessDays(15)}} (Date de home + 15 dias úteis)

Copie a regra a partir do IF e crie mais 3 regras para High, Medium e Low, preenchendo o campo da Vulnerability Issue Date da seguinte forma:

• {{now.plusBusinessDays(30)}} - High
• {{now.plusBusinessDays(60)}} - Medium
• {{now.plusBusinessDays(90)}} - Low

Após a criação das vulnerabilidades, podemos observar que automaticamente os campos são preenchidos com as datas limite de correção.

No vídeo abaixo, demonstro o campo Vulnerability Issue Date sendo automaticamente preenchido.

Abertura automática de tarefa de validação de correção  

Em Settings-> System -> Automation -> Global Automation, crieremos nossas automações para triagem e comunicações automáticas. Serão estas tarefas responsáveis pela encerramento ou não as vulnerabilidades, pois os responsáveis pela correção estarão restritos a um controle de movimentação de status.

A primeira automação necessária é a abetura do ticket “Vulnerability Fix Validation” aos respectivos times responsáveis.

Clique em Create Rule.

Lógica da regra:

• Nome: Abertura de tarefa de reteste

• Trigger: Quando a issue é transacionada para status “Validate Fix”.

• Condições:

  • Se for do tipo “Vulnerability”;
  • Se o campo Vulnerability Detection Origin for algum dos escolhidos (Caso haja times distintos de atuação);

• Ações:

  • Cria um tarefa do tipo “Vulnerability Fix Review” no projeto do time de revisão (Vulnerability Management, Offensive Security ou Application Security)

    • Summary: “Vulnerability Fix Review: {{issue.key}}”

    • Description: “Atividade de revisão de correção de vulnerabilidades originadas de processos ou soluções de Offensive Security.

      Colaborador solicitante: {{initiator.displayName}} ({{initiator.emailAddress}}).

    • Linked Issues: Tests -> Trigger Issue.

    • Sprint: Active Sprint (Projeto do time responsável pela triagem).

    • Story Points: 1 (Considerando a lógica de dimensionamento de esforço por Fibonacci).

    • Assignee: Issue Reporter .

    • Priority: Copy Priority from Current issue.

  • Adiciona um comentário alertando o usuário sobre sua ação indevida.

    Olá!
    Uma tarefa de revisão de correção de vulnerabilidade foi criada para o time "Offensive Security", responsável pelas soluções de análise de código. O ticket desta tarefa é  {{createdIssue.key}}.
    Caso tenha dúvidas, você pode nos encontrar no canal do Slack #si-help-vulnerabilities.
    Conheça mais sobre o time acessando nosso Confluence: https://ebit.atlassian.net/wiki/spaces/SI.

  • Envia uma mensagem por slack para o canal do time a ser alertando via webhook:

    Estimada equipe, foi atribuída a vocês uma nova tarefa de revisão de correção referente à vulnerabilidade  {{triggerIssue.key}}.
    
    Aqui estão os detalhes pertinentes.
    Id da tarefa: {{createdIssue.key}}
    URL da tarefa: {{createdIssue.url}}
    URL da vulnerabilidade: {{triggerIssue.url}}
    Colaborador solicitante: {{initiator.displayName}} ({{initiator.emailAddress}})
    
    Com os melhores cumprimentos,
    
    Alfred

Após a criação da primeira regra, copie o IF para criar as demais para APPSEC e VULN.

Mais dois “else-ifs” deverão ser criados para atender aos outros escopos de triagem, APPSEC e VULN.

No vídeo abaixo, demonstro a abertura automática da issue Vulnerability Fix Review após os responsáveis mudarem o status da vulnerabilidade para Validate Fix.

Replicação de comentários  

Para uma boa experiência de quem interaje com este tipo de processo, é importantes a clareza das informações providas e o follow-up contínuo. Assim criaremos uma automação para que qualquer comentário adicionado durante o processo de triagem seja automaticamente replicado na vulnerabilidade.

Lógica da regra:

• Nome: Replicação de comentários

• Trigger: Quando qualquer comentário é feito em qualquer momento.

• Condições:

  • Se for do tipo “Vulnerability Fix Review”.

• Ações:

• Para cada Linked Issues do tipo “Tests” (Caso mantenha o relacionamento de Teste)

  • Adiciona um comentário informando o usuário:

    Abaixo o último comentário da triagem. Para visualizar os anexos é necessário visitar a tarefa de validação {{triggerIssue.key}}.

    {{comment.created}} {{comment.author.displayName}} | {{comment.author.emailAddress}} | {{comment.body}}

No vídeo abaixo, demonstro a replicação automática de comentários inseridos em Vulnerability Fix Review na issue de Vulnerability.

Triagem automática de vulnerabilidades após avaliação de correção  

Por fim, a automação que finaliza (ou não) ou processo de gestão de vulnerabilidades, onde a correção é confirmada pelo time que reportou a vulnerabilidade e encerra automaticamente o seu fluxo.

Clique em Create Rule.

Lógica da regra:

• Nome: Triagem automática de vulnerabilidades após avaliação de correção

• Trigger: Quando a issue é transacionada para alguns dos status ✅ Fix Confirmed, 🥳 False Positive Confirmed ou ❌ Fix Not Confirmed.

• Condições:

  • Se for do tipo “Vulnerability Fix Review”;
  • Se o status transacionado for ✅ Fix Confirmed;

• Ações:

  • Para cada Linked Issues do tipo “Tests” (Caso mantenha o relacionamento de Teste)

  • Condições

    • Se for do tipo “Vulnerability”

      • Transaciona para Done

      • Edita o campo Resolution para Done (Vulnerability)

      • Adicione um comentário:

        ✅ A correção desta vulnerabilidade foi validada, e as evidências na íntegra podem ser visualizadas em {{triggerIssue.key}}.

        • Adiciona um comentário

• Edita o campo Resolution para Done (Vulnerability Fix Revirew)

Feita a primeira parte da regra, copie o primeiro IF duas vezes, customize a seguintes regras com as seguintes mudanças:

• Se status 🥳 False Positive Confirmed ;

• Para cada Linked Issues do tipo “Tests” (Caso mantenha o relacionamento de Teste)

  • Transacione o status de Vulnerbaility para False Positive;

    • Adicione um comentário:

    ✅ A condição de falso positivo desta vulnerabilidade foi validada, mais informações podem ser visualizadas em {{triggerIssue.key}}.
    
    Gratos,
    Security Team

• Se status ❌ Fix Not Confirmed;

• Para cada Linked Issues do tipo “Tests” (Caso mantenha o relacionamento de Teste)

  • Transacione o status de Vulnerbaility para In Progress;

  • Adicione um comentário:

    ❌ Infelizmente a correção desta vulnerabilidade não foi validada. evidências na íntegra podem ser visualizadas em {{triggerIssue.key}}.
    
    Esta vulnerabilidade foi transacionada para o status de "In Progress" para que possam continuar o trabalho de correção.
    
    Caso ache necessário, pode nos procurar diretamente pelo Slack através do canal #si-help-vulnerabilities ou entrar em contato diretamente com o avaliador.
    
    Após a correção, mova novamente o ticket para "Waiting Validation" para que uma nova tarefa de reteste seja aberta para avaliação.
    
    Gratos,
    Security Team

    

No vídeo abaixo, demonstro a triagem automática de acordo com o resultado apontado em Vulnerability Fix Review na issue de Vulnerability.

🚧 Controles de segurança  

Com todo o nosso cenário construído vem algumas perguntas relacionadas a comportamentos indevidos de alguns usuários mais “espertinhos”:

• Como detectar e impedir alterações indevidas de campos?
• Como detectar e impedir movimentações de status sem avaliação de segurança?
• Como detectar e impedir alteração de issue type?

Para a maioria das peguntas o Jira possui controles nativos, parte delas precisaremos de plugins 💸, e em outro nosso controle será apenas detectivo. Nos próximos tópicos abordaremos cada um deles.

Criação de grupo de gerenciadores de vulnerabilidades  

Para que possamos adicionar parte dos controles necessários, precisamos criar um grupo com as pessoas que poderão realizar as ações que abordaremos mais adiante, como controle de movimentação de status e edição de campos da vulnerabilidade.

Em Settings → User Management → Groups, crie um grupo onde estarão os usuários que poderão ter controle sobre as vulnerabilidades, chamaremos de “Vulnerability Managers”. Adicione os usuários que poderão ter total controle sobre cada vulnerabilidade.

Controle de movimentação de status  

Em Settings -> Issues -> Workflows -> Workflows, edite o Vulnerability Issue Type Workflow.

Altere o editor do workflow para o novo editor e clique em Rule.

Clique em Restrict transition, e depois em Restrict who can move an issue.

Crie uma regra que para a transição de qualquer status para Done, apenas os usuários administradores do Jira e o grupo Vulnerability Managers tenham permissão para tal transição.

Faça o mesmo para o status False Positive e atualize o workflow. Logo após a configuração haverá as seguintes sinalizações de regra nos status Done e False Positive.

Feito isso, usuários comuns não poderão mais dar como corrigidas as vulnerabilidades, com exceção do time de segurança, administradores do Jira e plugins de automação.

Controle preventivo de edição indevida de campos  

Para impedir que usuários não autorizados possam alterar campos importantes para categorização e identificação das vulnerabilidades, será necessário a utilização do plugin ScriptRunner, disponível no marketplace da Atlassian.

Instalação do Plugin-in Script Runner  

O plugin ScriptRunner é gratis para ambientes com até 10 usuários. Nele há diversos recursos para várias situações de administração.

https://marketplace.atlassian.com/apps/6820/scriptrunner-for-jira

Simulando uma empresa de porte maior com 1000 usuário do Jira, o valor atual serial de US$ 8500, que na minha opinião, é um valor acessível para quem quer realizar um bom trabalho de gestão de vulnerabilidades, além disso, por ser um plugin multi proposta, pulverizando esse valor com todas as áreas, é totalmente acessível e justificável por poder ser aproveitado por todos os times de engenharia.

Escrevendo script para ScriptRunner Behavior  

Para garantir a integridade de informações importantes, daremos como escopo os seguintes campos:

• Summary
• Description
• Priority
• Vulnerability Due Date
• Vulnerabily Detection Origin

Antes de escrevermos nosso Behavior no ScriptRunner, precisamos obter o id dos nossos campos customizados Vulnerability Due Date e Vulnerability Detection Origin, para obter esta informação de forma simples basta voltar novamente em Settings-> Fields -> Custom Fields, procure pelo nome do campo e clique em Edit Details. Na URL, poderemos observar o ID do campo Vulnerability Detection Origin , no nosso caso o número será 10037. Seguindo o padrão do Jira todo nome de campo customizado é composto da seguinte forma customfield_{ID}. Sendo assim, o nome do nosso campo será customfield_10037.

Fazendo o mesmo para o campo Vulnerability Due Date, teremos o campo customfield_10038.

Com estas informações em mãos podemos começar a escrever nosso script. Diversos exemplos para cada um dos módulos do ScriptRunner podem ser obtidos e sua biblioteca e no canal do YouTube.

Vá em Setting -> Apps -> ScriptRunner -> Behaviors, depois clique em Create Behavior.

Preencha os seguintes campos:

• Behavior Name: “Protect Fields - Vulnerability”
• Enable Behavior: True
• Projects: “All Projects”
• Issue Types: “Vulnerability "

Depois clique em Add Script.

Na linha Run the script, selecione “On load” e “On change” e aplicável em “Issue view”. Essas configuração irão proteger os campos no carregamento e em qualquer rotina de alteração, e aplicável na visualização na tarefa, ou seja, uma vez criado, apenas o grupo “Vulnerability Managers” poderá alterar os campos.

No campo do script, cole o seguinte código em JavaScript:

// Atribuindo às variáveis o escopo de proteção.
const priorityField = getFieldById("priority");
const issueTypeField = getFieldById("issuetype");
const summaryField = getFieldById("summary");  
const descriptionField = getFieldById("description");  
const detectionoriginField = getFieldById("customfield_10037");  //Vulnerability Detection Origin ID
const vulnduedateField = getFieldById("customfield_10038");  //Vulnerability Due Date ID


// Selecionando o grupo que poderá alterar o escopo
const group = "Vulnerability Managers";

// Obtendo Informações do usuário para identificar se está dentro do grupo Vulnerability Managers
const user = await makeRequest("/rest/api/2/myself");
const { accountId } = user.body;
const getUserGroups = await makeRequest(`/rest/api/2/user/groups?accountId=${accountId}`);
const groupNames = getUserGroups.body.map(({ name }) => name);

// Configurando a proteção somente leitura
if (!groupNames.includes(group)) {
  issueTypeField.setReadOnly(true);
  priorityField.setReadOnly(true);
  summaryField.setReadOnly(true);  
  descriptionField.setReadOnly(true);
  detectionoriginField.setReadOnly(true);  
  vulnduedateField.setReadOnly(true); 
}

Abaixo demonstro o resultado após criar uma vulnerabilidade com um usuário do grupo “Vulnerability Managers” e tentar alterar os campos com um outro usuário comum.

Infelizmente este Behavior não consegue aplicar a proteção à mudança de issue type, o que implica na próxima configuração sugerida.

Controle de edição de IssueType  

Há duas possíveis formas de alterar a issue type, na visualização ou em sua movimentação de projeto, abordaremos os dois cenários.

Controle na visualização  

Em Settings -> Screens -> Screens, na screen Vulnerability Issue Type Screen, remova o campo Issue Type da lista.

Com a remoção no screen, ao tentar clicar no ícone da type não é mais possível realizar sua alteração para outro tipo.

Esta é uma configuração global e estática, o que se aplicará a todos os usuários, sejam eles administrativos ou não.

Controle detectivo de movimentação da issue  

Um controle necessário é impedir que o responsável simplesmente movimente a issue para outro projeto afim de despistar ou alterar indicadores de vulnerabilidades.

Ainda há uma brecha onde é possível alterar a issue type de Vulnerability para qualquer outro através da sua movimentação para outro projeto, como pdoe ser visto na imagem abaixo.

Como não há qualquer referência global que possamos aplicar uma regra de movimentação de forma granular (Vulnerability) por Permission Schemes ou pelo próprio ScriptRunner, abordaremos um controle detectivo no lugar de um preventivo.

Criaremos uma automação para comunicar os times responsáveis pelos processos que originam as issues quando uma houver a movimentação indevidas deles.

Em Settings-> System -> Automation -> Global Automation, clique em Create Rule.

Lógica da regra:

• Trigger: Quando a issue é movimentada de qualquer projeto para outro projeto qualquer.

• Condições

  • Se for do tipo “Vulnerability”;
  • Se o campo Vulnerability Detection Origin for algum dos escolhidos (Caso haja times distintos de atuação);
  • Usuário que tomou ação não faz parte do grupo “Vulnerability Managers”.

• Ações

  • Adiciona um comentário alertando o usuário sobre sua ação indevida.

    Olá {{initiator.displayName}} ({{initiator.emailAddress}}). 
    
    A issue type Vulnerabilidade só deveria ser movimentada ou alterada pelo time de Segurança. Caso de fato ela deva ser direcionada para outro time, solicite ao time pelo canal #si-vulnerability-management no Slack.
    
    Gratos,
    
    Information Security Team.

  • Envia uma mensagem por slack para o canal do time a ser alertando via webhook:

    Uma vulnerabilidade originada do time de Application Security foi movida indevidamente.
    
    ID da Vulnerability: {{triggerIssue.Key}}
    Executor da ação: {{initiator.displayName}} ({{initiator.emailAddress}})

Como no exemplo, caso haja times distintos de atuação, adicione IFs para tomar ação de acordo com o campo “Vulnerability Detection Origin”.

😅 Considerações finais  

Se você sobreviveu até aqui, parabéns! Eu também não sei como tive paciência…lol.

Mas olha só, com as personalizações no Jira apresentadas neste tutorial, sua organização estará preparada para implementar uma gestão de vulnerabilidades eficiente e centralizada. Ao formalizar as vulnerabilidades nos projetos certos, aplicar prazos de correção com base na criticidade e garantir que as vulnerabilidades só sejam encerradas após a validação do time de segurança, sua operação ganhará em controle, conformidade e eficácia.

Além disso, as automações e as proteções criadas impedirão alterações indevidas, proporcionando uma camada adicional de segurança e integridade no processo. Este modelo pode ser facilmente adaptado para atender qualquer equipe de Cybersegurança que utilize o Jira, independentemente do tamanho ou da complexidade do ambiente.

📚 Referências  

• https://tiagotavares.io/blog/gestao-de-vulnerabilidades-com-greenbone-openvas/#por-qu%C3%AA-gerir-vulnerabilidades-e-como-fazer-isso
• https://confluence.atlassian.com/jirakb
• https://community.atlassian.com/
• https://library.adaptavist.com/
• https://www.youtube.com/@scriptrunnerhq

👾