◇ OpenCyber Academy
Técnico · Capítulo 8 · Português

Capítulo 8 — Segurança de IA e aprendizado de máquina: modos de falha

Ensino gratuito e aberto para quem deseja proteger pessoas e tecnologias. Não é preciso criar uma conta para estudar ou consultar as respostas.

Capítulo 8 — Segurança de IA e aprendizado de máquina: modos de falha

Mapa da aula

Aula 08 publicada. Mapa, exemplo, EX029.

flowchart TD
  N0["8.1 Modos de falha"]
  N1["8.2 Acidente ou ataque?"]
  N2["8.3 Efeito sobre o cliente"]
  N3["8.4 Primeiras respostas"]
  N4["Síntese"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Exemplo resolvido"]
  EX --> Q["Exercício EX029"]

Desenho lógico

flowchart LR
  N0["8.1 Modos de falha"]
  N1["8.2 Acidente ou ataque?"]
  N2["8.3 Efeito sobre o cliente"]
  N3["8.4 Primeiras respostas"]
  N4["Síntese"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX029"]

[8.1 Modos de falha]
    |
    v
[8.2 Acidente ou ataque?]
    |
    v
[8.3 Efeito sobre o cliente]
    |
    v
[8.4 Primeiras respostas]
    |
    v
[Síntese]
    |
    v
[Exemplo resolvido] --> [Exercício EX029]

Objetivos de aprendizagem

Você vai (1) reconhecer as principais formas pelas quais os serviços de IA falham ou são atacados; (2) distinguir falhas acidentais de ataques; (3) descrever o efeito de cada uma sobre os clientes; (4) ligar cada modo de falha a uma primeira resposta.

8.1 Modos de falha

Na Kestrel, cada modo tem um caso: injeção, o artigo editado das reinicializações; divulgação, o canário arquivado no lugar errado; agência, as reinicializações entre contas; deriva, o LineWatch.

8.2 Acidente ou ataque?

Os acidentes (um artigo desatualizado, uma atualização de modelo, deriva) costumam afetar muitos usuários de forma uniforme. Os ataques costumam se concentrar em certas contas, entradas ou horários e mostrar padrões deliberados, como variações repetidas. Verifique primeiro as versões e os registros de mudanças, depois os padrões. Os incidentes da Kestrel ilustram os dois lados. Os alertas perdidos do LineWatch afetaram de forma uniforme todos os equipamentos de um novo modelo de roteador e começaram com uma implantação de hardware: deriva. As respostas sobre restauração de fábrica afetaram todos que fizeram uma pergunta relacionada e começaram com a publicação de um artigo: um erro de conteúdo. As 900 denúncias de "não é spam" vieram de uma conta e visavam um único link curto: algo deliberado. As três contas com mais de 50 reinicializações pareciam abuso à primeira vista, mas o registro de mudanças mostrou o artigo editado, e o padrão acompanhava quem perguntasse sobre lentidão.

8.3 Efeito sobre o cliente

Descreva as falhas pelo que os clientes vivenciam: orientação errada, serviço perdido, dados expostos, dinheiro perdido. Isso ajuda a priorizar e a comunicar. As anotações de incidentes de Ana descrevem os efeitos assim. O artigo da restauração de fábrica fez os clientes perderem a configuração do roteador e terem de ligar para o suporte. A falha das reinicializações entre contas significava que um cliente podia cortar a internet de outro. O artigo arquivado no lugar errado expôs um procedimento exclusivo da equipe. O fim de semana das 40.000 mensagens dobrou a conta do fornecedor. Dito assim, o líder da equipe conseguiu classificá-los sem saber o que é um índice de recuperação, e o atendimento ao cliente soube o que dizer a quem ligava.

8.4 Primeiras respostas

Injeção que provoca ações: desativar ou restringir a ferramenta. Divulgação: interromper o caminho do vazamento, preservar as evidências. Desinformação: corrigir ou remover o documento de origem. Consumo: limitar a taxa. Envenenamento: congelar o treinamento, voltar a dados sabidamente bons. Extração: limitar a chave.

"""Lab E: evasion of a toy linear classifier (synthetic data, stdlib only).
Trains logistic regression on two synthetic clusters, then applies a
fast-gradient-sign (FGSM-style) perturbation of size eps to every test point
and reports clean vs adversarial accuracy. Teaching model only."""
import math, random
rng = random.Random(7)
def point(label):
    cx = 1.0 if label else -1.0
    return [rng.gauss(cx, 0.7), rng.gauss(cx, 0.7)], label
train = [point(i % 2) for i in range(400)]
test = [point(i % 2) for i in range(200)]
w, b = [0.0, 0.0], 0.0
sig = lambda z: 1 / (1 + math.exp(-z))
for epoch in range(200):
    gw, gb = [0.0, 0.0], 0.0
    for x, y in train:
        p = sig(w[0]*x[0] + w[1]*x[1] + b)
        gw[0] += (p - y)*x[0]; gw[1] += (p - y)*x[1]; gb += p - y
    w = [w[i] - 0.1*gw[i]/len(train) for i in range(2)]; b -= 0.1*gb/len(train)
def acc(data, eps):
    ok = 0
    for x, y in data:
        # gradient of the loss w.r.t. x is (p - y) * w; FGSM steps along its sign
        p = sig(w[0]*x[0] + w[1]*x[1] + b)
        xa = [x[i] + eps*math.copysign(1, (p - y)*w[i]) for i in range(2)]
        ok += (sig(w[0]*xa[0] + w[1]*xa[1] + b) >= 0.5) == bool(y)
    return ok / len(data)
print(f"weights w=({w[0]:.3f}, {w[1]:.3f}) b={b:.3f}")
for eps in (0.0, 0.25, 0.5, 0.75, 1.0):
    print(f"eps={eps:.2f} accuracy={acc(test, eps):.3f}")

Saída esperada:

weights w=(1.795, 1.756) b=-0.080
eps=0.00 accuracy=0.985
eps=0.25 accuracy=0.950
eps=0.50 accuracy=0.840
eps=0.75 accuracy=0.660
eps=1.00 accuracy=0.505

A Kestrel aplicou cada uma delas. Quando o artigo editado provocou reinicializações, o teto diário da ferramenta de reinicialização conteve o dano enquanto o artigo era revertido. O artigo exclusivo da equipe arquivado no lugar errado foi removido da coleção dos clientes, e os rastros foram exportados antes de qualquer outra mudança. O artigo da restauração de fábrica foi removido e seu responsável, avisado. A enxurrada do fim de semana foi enfrentada com um limite por conta. O envenenamento do feedback do SpamShield levou à pausa do treinamento até que o feedback em massa fosse revisado. Na API de parceiros do SpamShield, a resposta à extração é limitar a chave do parceiro responsável.

8.5 Exemplo resolvido (caso sintético da Kestrel)

O LineWatch para de alertar sobre uma classe de falhas de equipamentos. Ana verifica: não houve mudança de modelo; a telemetria de um novo modelo de roteador, introduzido no mês anterior, tem faixas de valores diferentes. Isso é deriva, não ataque. Primeira resposta: encaminhar os alertas do novo modelo para revisão manual; a equipe de dados retreina com novos exemplos. Duas verificações separaram a deriva de um ataque aqui. O histórico de versões não mostrou mudança no modelo nem nos limiares do LineWatch, e as falhas perdidas estavam distribuídas de forma uniforme entre todos os clientes que usavam o novo modelo de roteador, em vez de concentradas em contas específicas. O laboratório de evasão mostra a versão de ataque do mesmo sintoma: a acurácia caiu de 0,985 para 0,840 com eps 0,5 apenas porque cada entrada foi empurrada deliberadamente em direção à fronteira. A deriva desloca as entradas sem uma direção escolhida por alguém.

8.6 Erros e limites

Três erros são comuns: chamar toda falha de ataque; ignorar a deriva; e respostas que corrigem os sintomas, mas não as causas. Chamar a deriva do LineWatch de ataque teria mandado a equipe caçar um intruso enquanto os alertas continuavam quebrados. Ignorar a deriva teria deixado o novo modelo de roteador sem monitoramento até sua primeira interrupção real. Uma correção só do sintoma, como baixar o limiar de alerta do LineWatch para todos, teria inundado os operadores com alertas falsos nos modelos de roteador antigos, sem ensinar ao modelo as novas faixas de valores. A resposta escolhida, revisão manual para o novo modelo mais retreinamento, tratou a causa.

Exercícios

Síntese

Conhecer os modos de falha, distinguir acidentes de ataques e ter uma primeira resposta para cada um permite que os técnicos ajam com rapidez e acerto.

Continue estudando — capítulo 08 de 18

← Capítulo 07 (rascunho) · Índice de capítulos do curso · Capítulo 09 (rascunho) →