Prompt Engineering: criando prompts seguros para segurança da informação

Prompt engineering para segurança da informação - Apresentação

Apresentando o curso e o escopo

Bom dia, boa tarde, boa noite, pessoal, independentemente do horário em que vocês estiverem assistindo a este vídeo. Eu me chamo Michelle Araujo Mesquita, sou instrutora da Alura, e vou dar seguimento ao curso de Prompt Engineering: criar prompts seguros para segurança da informação (segurança da informação) voltado para Inteligência Artificial.

Neste curso, nosso escopo será:

• Montar e revisar algumas composições de prompts (instruções).
• Entender como a IA opera na realização das instruções.
• Aprender a aprimorar a criação de novas instruções de acordo com as necessidades do seu escopo de tarefa e do mercado de trabalho em que vocês estão inseridos, seja em marketing, ciência de dados, engenharia de dados ou outras áreas.
• Focar na criação de instruções seguras para fazer bom uso da IA.

Estamos na apresentação do curso neste momento. Nós vamos utilizar os modelos de linguagem com uma comunicação assertiva. Vamos abordar instruções genéricas e específicas, discutir por que, em muitos casos, os resultados podem ser medianos durante a execução, e trabalhar a engenharia de prompt (Prompt Engineering) baseada na qualidade. Nós vamos explicar a importância de uma instrução bem estruturada em contraste com uma mal estruturada, bem como suas consequências, com foco total em segurança da informação. Exploraremos fortemente essa parte de segurança; pessoas de cursos de segurança cibernética, ou de outras áreas com interesse em aprender mais sobre o uso da IA e segurança da informação, também serão contempladas.

No primeiro slide (apresentação), nós vamos explicar como os modelos de linguagem fazem a leitura das instruções. E o primeiro tópico a nos questionar é: por que o mesmo pedido gera resultados diferentes?

A IA é um sistema probabilístico; trabalha com probabilidades. Se formos vagas ou excessivamente genéricas, abrimos uma janela de contexto para a IA gerar múltiplas soluções. Em outras palavras, abrimos espaço para ela “pensar”. Pensemos como em um cérebro humano: se dissermos “execute tal tarefa” de forma genérica, surgem diversas maneiras possíveis de executar. Por exemplo, ao solicitar “escreva seu nome”, é possível fazê-lo com lápis, caneta, pena e tinta, entre outras formas. Com a IA funciona de maneira semelhante.

Também vamos apresentar os elementos de uma instrução eficaz. Estudaremos a janela de contexto, a especificação clara do objetivo, as funcionalidades, e o que a IA pode ou não pode fazer dentro do escopo de execução. Isso nos levará a um melhor formato ao ajustar o contexto, a estrutura e as restrições. Há um momento apropriado para realizar cada ajuste: nem sempre alteramos o contexto, nem sempre aplicamos o mesmo formato, e nem sempre impomos restrições o tempo todo. Há estudos indicando que, quanto mais negações impomos à IA, pior tende a ser a qualidade de execução da instrução. Precisamos, portanto, de equilíbrio: quando aplicar cada forma e como empregar esse conhecimento.

Além disso, vamos apresentar os erros mais comuns de pessoas iniciantes em engenharia de prompt e no uso prático da IA.

Explicando por que resultados variam

Por que instruções diferentes geram resultados diferentes? Não é mágica; é matemática. A IA não pensa como uma mente humana. Ela identifica padrões — padrões de execução. Suponhamos que, na sua janela de contexto, repetidamente realizamos um deploy (implantação) da mesma forma. Esse padrão de execução será identificado pelo modelo. Se quisermos que ele identifique outro padrão, é possível especificá-lo, e existem maneiras eficientes de fazer isso.

Instruções ambíguas forçam o modelo a “adivinhar”. Se trouxermos muita ambiguidade no enunciado, induziremos o modelo a decidir por conta própria como executar. Instruções específicas reduzem interpretações equivocadas. Por exemplo: ao solicitar a edição de um vídeo com cortes nos minutos 2, 3 e 4, precisamos especificar exatamente que os cortes são nesses minutos. Caso peçamos “três cortes ao longo do vídeo” sem dizer onde, e não definamos se há ou não transições, abrimos espaço para interpretações que podem se afastar do objetivo.

O mesmo pedido, três versões:

• Pedido ruim: “Me ajude com esse log (registro).” O que é esse registro? Qual é o contexto? É um registro de execuções de quê? Trata-se de um fluxo de dados (pipeline — fluxo de processamento)? É um registro de auditoria? Sem contexto, o modelo tenderá a responder de forma genérica.
• Pedido mediano: “Analise este log (registro) de firewall (barreira de proteção de rede) e diga se há algo suspeito.” Ao colarmos o registro junto da instrução, reduzimos a probabilidade de erro e de respostas inesperadas.
• Pedido bom: “Você é um analista de SOC (Centro de Operações de Segurança) nível 2. Analise o registro abaixo, identifique anomalias, classifique a severidade e sugira próximos passos. Responda em tabelas em Markdown (formatação de marcação leve).” Aqui, definimos o papel, o objetivo, o que identificar, como classificar e o formato de resposta. Em outras palavras, estruturamos claramente a janela de contexto e acrescentamos um requisito de saída.

Apresentando a anatomia de uma instrução eficaz

Qual é a anatomia de uma instrução eficaz?

Comecemos pelos elementos essenciais de um bom prompt (instrução) para estruturar o trabalho com IA.

• Instrução: utilizar um verbo de ação preciso para orientar a tarefa. Caso queiram, podem anotar em papel e caneta; este material também estará disponível ao longo do curso, em cada sessão das aulas.

• Contexto: a IA trabalha com contexto. Há um campo de estudo chamado engenharia de contexto. Precisamos especificar quem é, para quem é, qual cenário, para qual finalidade e qual a situação. É fundamental fornecer contexto à IA, independentemente da tarefa.

• Padrão esperado: mostrar um exemplo do resultado desejado. Por exemplo, ao realizar um recorte de vídeo, se já houver um vídeo de referência que inspirou o resultado, devemos enviá-lo para a IA, para aumentar a assertividade do resultado.

• Formato de saída: definir claramente como queremos a resposta. Podemos solicitar um log (registro) de auditoria em *.md, em um documento de texto ou na própria janela da IA. Como não sabemos qual seria o padrão por omissão, precisamos especificar o formato de saída.

• Restrições e tom: explicitar o “não” para a IA, o tom de resposta, como deve se comportar (especialmente se estivermos desenvolvendo um bot (robô)), o que não deve executar. Exemplo: estamos criando uma IA vinculada ao WhatsApp para consultar dados de um BI (inteligência de negócios) com níveis de auditoria e segurança. Se um número não pertence à empresa, essa pessoa não pode acessar dados. No prompt, estruturamos que a IA não deve informar dados a não colaboradores da empresa. Há muitos cenários possíveis, mas este exemplifica de forma clara.

Contextualizando o que e quanto colocar

Contexto — o que colocar e quanto colocar

• Mantemos o equilíbrio: “pouco contexto = chute; contexto demais = ruído”. Com pouco contexto, abrimos espaço para ambiguidades. Exemplo: “execute este log (registro)” gera: qual log (registro)? De quê? Por outro lado, contexto em excesso pode gerar ruído, pois a IA pode tentar ser assertiva demais e, ainda assim, não chegar ao resultado esperado. O equilíbrio é a base.

• Regra prática: “passe o contexto que você daria a um colega competente que não conhece seu ambiente”. Ou seja, explique como se fosse para uma pessoa que não sabe o que está acontecendo ali. Aplicamos isso no dia a dia e o entendimento fica mais claro.

• Dúvidas durante a aula: vocês podem retomar o vídeo, assistir em 1,75x ou mais devagar, voltar quantas vezes desejarem e consultar o material abaixo.

Selecionando e omitindo informações do contexto

O que colocar e o que omitir no contexto

• O que colocar:

  • Papel/função: por exemplo, se a IA deve atuar como analista de dados, analista de SOC ou analista de segurança.
  • Ambiente: se estivermos em nuvem da AWS, é importante declarar para a IA “onde mexer”, até porque muitas IAs já contam com integrações nativas.
  • Objetivo final: declarar a finalidade para orientar a execução rumo ao resultado esperado.

• O que omitir:

  • Nunca compartilhar senhas, tokens (unidades de texto), IPs, chaves de API. Não se compartilha isso no chat (bate-papo) com a IA nem em prompts. É a velha máxima: o arquivo .env nunca vai para o GitHub. Tratem esse princípio como inegociável. Inserir dados sensíveis pode gerar dor de cabeça e, dependendo do ambiente, até multas e outras consequências severas.

• Histórico irrelevante:

  • Se a execução necessária está no final do prompt, precisamos organizar bem o conteúdo. Exemplo: ao construir uma IA para análise de dados, se a quinta execução (no final do prompt) é a função solicitada, mas colocamos um histórico irrelevante antes, pode haver “desgaste” na janela de contexto e queda de assertividade.
  • Hipóteses e expectativas: explicitem o resultado esperado e suas premissas, para a IA mapear e formar uma janela de contexto condizente, aumentando as chances de bons resultados.

• Reforço sobre privacidade:

  • Nunca incluir dados sensíveis em LLMs (modelos de linguagem de grande porte) públicos. Sempre anonimizar.

Ajustando parâmetros de geração

Parâmetros de geração

• Temperatura:

  • Varia de LLM para LLM; não é um padrão rígido. É uma análise média de comportamento:
    • 0 a 0,3: mais determinístico — adequado para código, extração e classificação.
    • 0,4 a 0,7: mais explicativo.
    • 0,8 a 1,2: mais criativo — ideação e cenários.
    • Acima de 1,2: tende ao caótico; raramente útil em produção.

• Máximo de tokens (unidades de texto):

  • Diferentes IAs limitam a quantidade de tokens de maneiras diversas; considerem essas restrições ao estruturar o prompt e as saídas.

• top-p:

  • Também contamos com o parâmetro top-p (amostragem por núcleo), ou “núcleo”. Como explicar isso de forma clara?

Há uma limitação de candidatos por probabilidade acumulada. De forma simplificada, é como se fosse um usuário por vez, uma janela por vez; essa é a maneira como a IA opera no seu back-end (camada de serviços).

Evitando erros comuns

Os cinco erros mais comuns são:

• Pedidos genéricos demais. Já mencionamos e reforçamos: procurem sempre trazer um bom contexto para a IA.
• Não especificar o formato de saída e as expectativas. Especifiquem claramente como desejam a resposta e quais critérios esperam que sejam atendidos.
• Confiar cegamente na resposta. A IA é uma ferramenta probabilística; é necessário avaliar criticamente as saídas.
• Colar o resultado diretamente na linha de produção sem validação. Evitem transferir integralmente a saída para o fluxo produtivo sem checagens.
• Colocar todo o ciclo em uma única instrução (prompt (instrução)) e não iterar. Uma única instrução muito longa pode criar uma janela de contexto grande e gerar alucinações. Separamos as instruções para reduzir esse risco. Pode surgir a dúvida: “Isso vai gastar muitos tokens (unidades de contagem)?” Sim, faz parte da ferramenta e do seu uso. Precisamos usar bem a IA para obter bons resultados. A engenharia de instruções é inerentemente iterativa: nós testamos, ajustamos, manipulamos, criamos e recriamos continuamente.

Esses são os cinco tópicos mais importantes que recomendamos internalizar.

Praticando em laboratório e autoavaliando

Deixaremos um laboratório para reescrever algumas instruções (prompts (instruções)). Esse laboratório estará no material abaixo para que possam realizar. Em caso de dúvidas, voltem à aula, pois o material estará todo bem explicado.

Realizem uma avaliação e recapitulação pessoal. Façam uma autoavaliação:

• A reescrita é mais útil no contexto real?
• O formato veio como desejado?
• A resposta está específica ou genérica?
• O processo reduziu perguntas de follow-up (acompanhamento)?

Eu aguardo vocês na segunda aula, para a nossa próxima aula do curso. Um abraço.

Técnicas fundamentais de prompting - Técnicas de prompt

Apresentando técnicas fundamentais de prompting

Aula 2 — Técnicas fundamentais de prompting

Hoje vamos aprofundar técnicas fundamentais de prompting. Vamos implementar cinco técnicas de prompting, identificar essas técnicas e como combiná-las. No contexto de IA, conseguimos combinar algumas técnicas que melhoram o resultado do uso da IA.

Apresentando zero-shot prompting

Vamos para a primeira técnica: Zero-Shot Prompting (Sem Exemplos). O que isso significa? Pedir algo sem exemplos; o modelo utiliza apenas o que aprendeu durante seu treinamento.

Para entendermos melhor, consideramos dois aspectos:

• Quando funciona bem: tarefas comuns e bem definidas; quando buscamos uma resposta razoável, sem necessidade de perfeição; em um brainstorm (tempestade de ideias) rápido. Em resumo, tarefas de execução fácil e rápida, nas quais a resposta não precisa ter qualidade extremamente alta. Por exemplo: selecionar uma pasta, excluir uma pasta, gerar um texto curto de resposta — algo que não exija tanta qualidade na expectativa de resultado.
• Quando não funciona: quando necessitamos de um formato de saída muito específico; quando há nuances de domínio; quando precisamos de consistência entre execuções. Quando aumentamos a nossa janela de contexto, a janela de execução e a complexidade ao executar determinadas tarefas utilizando IA, essa técnica deixa de ser a mais adequada.

A próxima técnica envolverá um pouco desse exemplo, e ficará claro o porquê.

Vamos ao cenário: um achado de pentest (teste de intrusão) — o upload (envio) de um arquivo .php sem validação. É a única informação que queremos: encontramos um arquivo em um pentest e estamos fazendo o upload daquele arquivo. O nosso prompt (instrução) deve classificar a severidade como crítico, alto, médio, baixo ou informativo. Somente isso: o modelo fará uma breve análise e identificará a severidade de acordo com parâmetros de risco. Isso nos leva à próxima técnica.

Apresentando few-shot prompting

Vamos passar para o próximo slide para entendermos: Few-Shot Prompting (Poucos Exemplos). Começamos a oferecer alguns exemplos antes da entrada e também da saída da tarefa real. Podemos inserir exemplos ao longo de toda a interação: no primeiro prompt (instrução), durante a conversa ou após uma saída inesperada. Assim, passamos a calibrar a IA e alinhar a nossa janela de contexto.

Como é a estrutura do prompt (instrução)? Alerta, classificação e justificativa. O que queremos dizer com isso? É importante que o modelo reconheça a estrutura e os exemplos que estão na janela de contexto.

• Exemplo 1: múltiplas falhas de login, ataque de brute force (força bruta) — classificação alta.
• Exemplo 2: domínio recém-registrado, um C2 (comando e controle) suspeito — classificação média.
• Tarefa real: um comando PowerShell com Base64. Qual é a classificação e a justificativa?

Percebemos como funciona essa estruturação de contexto mais claro. Fornecemos de dois a cinco exemplos para que o modelo apresente uma resposta mais equilibrada.

Boas práticas com Few-Shot Prompting (Poucos Exemplos):

• Incluir casos negativos e ambíguos, reduzindo a ambiguidade da resposta.
• Ser consistente no formato: precisamos manter a consistência no que pedimos e em como pedimos.
• Evitar ambiguidade nos pedidos. Não precisamos ser 100% diretos, mas devemos ser objetivos e manter uma linha de raciocínio junto com a IA.
• Fornecer de três a cinco exemplos. Se quisermos dar mais exemplos porque a documentação do nosso contexto é extensa, perfeito — é um conhecimento rico e dependerá de caso a caso.

Aplicando chain of thought

Agora, a próxima técnica: Chain of Thoughts (Cadeia de Raciocínio). Vamos pedir ao modelo que pense passo a passo antes de responder. Isso força um raciocínio em vez de um chute.

O que queremos dizer com isso? A IA não pensa da forma humana; não tem sentimentos. Contudo, temos maneiras de ativar um raciocínio estruturado. Ao solicitar passos, pedir reformulação do contexto e validação da resposta, geramos uma “janela de pensamento”. Sem essa técnica, tendemos a obter respostas excessivamente diretas: o básico é muito direto, a saída é muito direta, e acabamos sem contexto gerado por trás, sem a devida atenção ao detalhamento da resposta.

Com essa técnica aplicada, orientamos o modelo a explicitar:

• O que cada parte faz.
• Quais são os indicadores de risco.
• Qual é o contexto legítimo possível.
• Qual é o veredito final.

Podemos utilizar essas instruções explicitamente para levar a IA a raciocinar com mais contexto.

Quando usar:

• Logs complexos com múltiplos eventos. Por exemplo, ao refatorar um pipeline (fluxo de processamento) de dados no qual múltiplos eventos de log apresentaram erro.
• Classificação com múltiplos fatores.
• Investigação forense ou triagem de informações e dados.
• Quando precisamos entender o raciocínio do modelo.

Quando não usar:

• Tarefas simples e diretas.
• Quando apenas o output (saída) final importa.

Atribuindo papéis ao modelo

Vamos trabalhar com uma formulação mais simples e genérica: estamos falando de Role Prompting (atribuição de papel). Atribuímos um papel ao modelo para mudar o estilo, a profundidade e o foco da resposta. Pode surgir a pergunta: “O que é isso? O que queremos dizer com isso? Está confuso? Estamos misturando engenharia de contexto com engenharia de prompt (instrução)?” O ponto central é: o mesmo pedido pode ser feito com papéis diferentes, e isso altera significativamente a resposta.

Vamos analisar com calma três variações do mesmo pedido:

• Nossa versão A: Você é um Pentester Sênior, com 15 anos de experiência em Red Team (equipe de ataque) em instituições financeiras. Explique como abordaria um teste em uma API REST que autentica via JWT.
• Nossa versão B: Você é um instrutor de segurança de aplicações, ensinando para um time de pessoas desenvolvedoras júnior. Explique como abordaria um teste de uma API REST que autentica via JWT.
• Próxima versão: Você é um auditor de conformidade, revisando se a aplicação está aderente ao OWASP ASVS Nível 2. Como avaliaria essa autenticação JWT?

Estamos pedindo essencialmente a mesma coisa, porém definindo formas diferentes de solicitar. Com frequência, isso evidencia níveis de senioridade — alguém júnior, pleno ou sênior — e também ajuda a identificar a janela de contexto e quem está utilizando a IA.

Componentes de um bom Role Prompting

• Papel específico: Como discutimos na aula anterior, definimos algo como “Você é analista de dados”, “Você é analista de segurança”, “Você é engenheira ou engenheiro de dados”, “Você é cientista de dados”.
• Senioridade: Pode parecer estranho atribuir senioridade a uma IA, mas quando fazemos isso, comunicamos um nível maior de responsabilidade pela tarefa, gerando um senso de importância na execução.
• Contexto de atuação: Podemos atribuir janelas de contexto já existentes e erros já conhecidos no domínio do problema.
• Audiência da resposta: Exemplos incluem “time não técnico”. Ou seja, definimos explicitamente para quem a resposta é destinada. Se conseguirmos incorporar a audiência no papel, melhor.

Atenção: Role Prompting (atribuição de papel) não é jailbreak (burlar restrições). Devemos evitar papéis antiéticos. Não se trata de “quebrar as restrições”. É fundamental ter cuidado: o mau uso da IA pode trazer consequências.

Apresentando o encadeamento de prompts

Próximo tópico: Prompt Chaining

Trata-se de quebrar uma tarefa complexa em prompts menores encadeados, em que a saída de um é a entrada do próximo. Se a tarefa for muito extensa, podemos dividi-la em etapas. Isso é muito presente em cenários de multi-agent (multiagentes). Por exemplo, em um mesmo ecossistema, podemos ter:

• uma IA para leitura,
• uma IA para validação,
• uma IA para auditoria de segurança,
• e uma IA para codificação.

Tudo faz parte do mesmo ecossistema, mas está dividido em cadeias e em espaços distintos de execução. Essa é a lógica: separamos o prompt em janelas diferentes, o que torna o processo mais assertivo.

Essa abordagem costuma se basear em agentes ou em workflows (fluxos de trabalho) reais. Ao produzir saídas intermediárias e inspecionáveis, conseguimos prever determinados riscos. Com foco único por etapa, delimitamos cada fase com um objetivo claro, o que impede a IA de criar novas janelas de pensamento fora do escopo. Erros não comprometem o todo e também não contaminam as próximas etapas. Havíamos esquecido de mencionar “contaminam”, mas o ponto é manter o isolamento entre janelas de contexto (1, 2, 3) para evitar propagação de falhas. Dessa forma, a própria execução pode conter uma janela de auditoria.

Exemplos incluem extração, enriquecimento, classificação e comunicação. Em vez de um único prompt, podemos quebrar em quatro etapas:

• separar a extração,
• o enriquecimento,
• a classificação,
• e a comunicação.

A tendência é obter resultados mais previsíveis e alinhados às expectativas.

Combinando técnicas

Podemos combinar essas estratégias: começar o prompt com Role Prompting (atribuição de papel), intermediar com Few-Shot (poucos exemplos) e finalizar com Prompt Chaining (encadeamento de prompts). Isso não garante o “prompt perfeito”, mas costuma elevar bastante a qualidade do prompt e da resposta.

Propondo atividades de laboratório

Laboratório e exercícios

O laboratório agora ficará responsável por cenários de escolha e alguns exercícios. Queremos provocar em você a prática de construir prompts e executar essas janelas:

• Escrever prompts de Zero-Shot (sem exemplos).
• Reescrever em Few-Shot (poucos exemplos), com 3 exemplos.
• Adicionar Prompt Chaining (encadeamento) ao prompt que foi construído em Zero-Shot e Few-Shot, para observar o resultado no Playground de vocês.
• Adicionar Role Prompting (atribuição de papel).
• Quebrar em 3 prompts encadeados.
• Produzir 5 versões diferentes desses exercícios.

Por que 5 versões? Quanto mais praticamos, mais entendemos e começamos a arquitetar, em nosso pensamento, como a IA funciona dentro de janelas de contexto, além de observarmos novos contextos sendo gerados.

Eu aguardo vocês na próxima aula para fazermos os próximos passos. Um abraço para vocês.

Prompt engineering para Blue Team e SOC - Prompts para Blue Team

Contextualizando a aula de segurança e operações

Seguindo para a nossa Aula 3 de prompt (instrução), hoje vamos abordar uma parte específica voltada para segurança da informação. Vamos trabalhar com o tópico Blue Team (equipe azul) e SOC (Centro de Operações de Segurança). A nomenclatura pode variar; neste curso, costumamos utilizar SOC por hábito.

Dentro do contexto desta aula, vamos trazer pontos muito importantes, com atenção especial a um deles, mesmo que o apresentemos por último. Vamos utilizar as técnicas da Aula 2 e da Aula 3, pois seguimos uma linha encadeada. Temos percebido que, ao longo do curso, retomamos continuamente as mesmas informações.

Para iniciar, vamos definir o primeiro escopo da aula, entendendo como funciona e como vamos trazer eficácia para nossos prompts (instruções).

Estruturando prompts para análise e triagem

Análise de logs

• Nossa primeira janela é a análise de logs (registros), assumindo o papel de uma pessoa analista.
• Podemos solicitar um resumo em 3, 4 ou 5 linhas, incluindo:
  • Relatórios e próximas ações.
  • Correlação de fontes para a IA.
  • Eventos em cadeia que vêm acontecendo com frequência.
  • Lacunas de visibilidade.
  • Uma hipótese mais provável sobre o erro identificado.
• Ao fornecer todas essas informações para a inteligência artificial, buscamos um resultado alinhado a este segmento.

Modelos de prompt e aplicação do conteúdo da Aula 2

• Persona: pessoa analista de SOC (Centro de Operações de Segurança), analista de dados ou analista de segurança (security).
• Saída esperada: resumo, relatórios, suspeitas, próximas ações.
• Formato de saída: definimos claramente como a resposta deve ser estruturada.
• Prompt (instrução) negativo: o que não queremos que o modelo faça (por exemplo, não inventar erros, eventos ou gerar relatórios falsos).

Correlação de fontes

• Podemos estruturar um modelo com foco em correlação de fontes, trazendo-as para o contexto da IA:
  • Firewall (barreira de proteção de rede), EDR (Endpoint Detection and Response), DNS (Domain Name System) ou, às vezes, uma consulta específica.
• Objetivos:
  • Identificar a cadeia de ataque.
  • Mapear lacunas de visibilidade (por exemplo, janelas de exposição ou portas abertas).
  • Propor uma hipótese mais provável para o problema.
• Ao juntar a identificação com a hipótese mais provável, a IA consegue modelar a linha de cadeia de vulnerabilidades com base no contexto fornecido.

Triagem de alertas

• Também podemos criar prompts (instruções) específicos para triagem de alertas. Estruturamos o contexto considerando:
  • Persona, setor, stack (pilha tecnológica), horário de operação e histórico relevante de incidentes.
• Formato de resposta esperado:
  • Classificação, nível de confiança e justificativa.
  • Ações imediatas.
  • Perguntas pendentes.
• Nível de confiança: alta, média ou baixa.
• Justificativa: em 2, 3, 4 ou 5 linhas.
• Há uma grande variedade de possibilidades de trabalho, sempre com uso consciente da IA.

Construindo playbooks de resposta a incidentes

Playbooks de resposta a incidentes

• Vamos ao próximo tópico: playbooks (guias de resposta) a incidentes. Vamos destacar um ponto para esclarecer o que queremos abordar:
  • As LLMs (Modelos de Linguagem de Grande Porte) geram primeiras versões e identificam lacunas em playbooks existentes.
• O que isso significa?
  • As primeiras versões de um prompt (instrução) ou de uma análise tendem a se ancorar em playbooks já existentes, isto é, em janelas já estabelecidas.
  • Isso pode envolver um playbook (guia de resposta), uma janela, uma execução ou a leitura de log (registro).
  • O modelo tende a analisar primeiro o que está internalizado para, depois, buscar referências externas.
• Há como contornar esse comportamento? Sim. Podemos especificar no nosso prompt (instrução) negativo que o modelo não deve priorizar esse caminho, para que não perca tempo nem gaste tokens (unidades de texto processadas pelo modelo) utilizando essa técnica.

Exemplo de como gerar um playbook (manual de procedimentos) do zero a partir da criação de um prompt (instrução).

No topo do prompt, colocamos a nossa persona (perfil). Neste caso, definimos uma liderança técnica de CSIRT e Red Team, indicando uma senioridade mais alta e deixando claro o papel técnico.

Cenário: DNS (Domain Name System), tunneling (túnel de rede) e exfiltração.

Ambiente: um SaaS (software como serviço) B2B e B2C, com 200 pessoas colaboradoras, em nuvem AWS (Amazon Web Services) e ambiente local, seja onde for.

Estrutura: se já houver um padrão documentado de toda a estrutura (obviamente sem dados sensíveis), isso fornece um ótimo contexto. Devemos dividir por:

• ação;
• responsável;
• ferramenta;
• tempo estimado;
• resposta esperada;
• resposta não esperada.

Esse encadeamento de etapas torna o prompt muito mais assertivo dentro desse segmento.

Revisando e auditando playbooks

Revisão: aplicamos a mesma lógica, trazendo um nível de ambiguidade mais limitado. Ao longo do tempo, vamos afunilar as informações para evitar a introdução de novos contextos desnecessários, a depender do tema.

Nossa persona nesta etapa é uma pessoa auditora de segurança e operações. Aqui não definimos o escopo de senioridade, mas especificamos claramente as responsabilidades técnicas.

Itens de revisão:

• Lacunas: passos importantes ausentes. Se estivermos auditando algo, precisamos identificar o que falta, o que já foi gerado e quais são os próximos passos.
• Pontos sem responsável definido: muitas vezes não há definição de responsável; tarefas, subtarefas, análises ou logs (registros) podem ter ficado pendentes ou executados de forma incorreta. A IA precisa desse contexto.
• Referências e documentações: manter sempre listadas e atualizadas.

Estruturando relatórios de incidentes

Geração de relatórios de incidentes: sugerimos uma estrutura obrigatória:

• Resumo executivo: evitar jargões e gírias; manter um tom o mais profissional possível.
• Timeline (linha do tempo): quando o incidente foi detectado/ocorreu, por que acreditamos que está ocorrendo e, se já ocorreu, em qual escopo.
• Análise técnica e causa raiz.
• Governança de acesso: não conceder à IA acesso à nuvem de forma autônoma. Sempre manter supervisão humana. A janela de incidentes, por exemplo, frequentemente leva uma pessoa analista de IA ou de segurança a pedir: “IA, faça uma análise na minha nuvem”. Não devemos permitir que a IA opere 100% de forma autônoma para gerar esses relatórios. Manter supervisão humana é um ponto de atenção.
• Impacto, ações tomadas e recomendações, acompanhadas dos respectivos relatórios.

Regras do template (modelo):

• Linguagem acessível para públicos não técnicos (ajustar conforme o público). Se estivermos dialogando com outros times, por exemplo, de marketing (marketing), especialmente em casos de vazamento de informações, não devemos usar termos excessivamente técnicos.
• Lacunas marcadas como “A confirmar”: em segurança, todo relatório costuma conter uma seção “A confirmar” para orientar a próxima janela de execução. Exemplo: relatório no qual uma empresa requisita uma chave de API (interface de programação de aplicações) de um determinado sistema, é reprovada e tenta obter, além da chave, a ampliação de escopo (estrutura física e sistemas). Sempre haverá uma aba “A confirmar”.
• Tom sem dramatização: a IA tende a dramatizar; manter tom técnico e profissional é essencial.
• Entradas e saídas: explicitar os insumos do relatório e as hipóteses consideradas. É importante torná-los visíveis.

Pesquisa e contextualização:

• Trazer uma contextualização profunda do ambiente e do domínio em que estamos atuando.
• Se a IA precisar executar pesquisa, web scraping (coleta de dados na web) ou atividades similares, especificar isso de forma explícita e clara, indicando se será com API (interface de programação de aplicações), IPs (endereços IP) e IDs (identificadores).
• Lembrando: manter esse escopo isolado. Nunca fornecer dados sensíveis para a IA.

Apresentando o próximo laboratório

Próximo laboratório: Agora vamos apresentar o próximo laboratório. Vamos solicitar que vocês desenvolvam um workflow (fluxo de trabalho) de triagem simplificado com LLM (Large Language Model). Vamos aplicar todos os escopos apresentados na aula de hoje e aprofundar um pouco mais o tema.

Eu aguardo vocês na próxima aula. Um abraço.

Sobre o curso Prompt Engineering: criando prompts seguros para segurança da informação

O curso Prompt Engineering: criando prompts seguros para segurança da informação possui 69 minutos de vídeos, em um total de 30 atividades. Gostou? Conheça nossos outros cursos de IA para segurança em Cibersegurança, ou leia nossos artigos de Cibersegurança.

Matricule-se e comece a estudar com a gente hoje! Conheça outros tópicos abordados durante o curso:

• Prompt engineering para segurança da informação
• Técnicas fundamentais de prompting
• Prompt engineering para Blue Team e SOC
• Prompting para red team e pentest
• Prompting para GRC e conformidade
• Biblioteca de prompts