4.4 Operações de segurança

Visão geral e motivação

A prevenção é necessária, mas nunca basta. Adversários determinados, vulnerabilidades inéditas e o simples erro humano significam que algumas ameaças passarão pelas suas defesas. As operações de segurança são a disciplina de achá-las depressa, responder bem e devolver o que se aprende para defesas mais fortes. É a diferença entre um incidente contido em minutos e um que apodrece por meses antes de alguém notar.

Numa grande organização, as operações de segurança precisam funcionar em escala e em velocidade. Milhares de serviços geram oceanos de logs. Centenas de novas vulnerabilidades são divulgadas toda semana. A implantação nunca para. Operações manuais e artesanais simplesmente não acompanham. A resposta é embutir a segurança no pipeline de entrega (DevSecOps), automatizar a detecção e a resposta e construir a musculatura para tratar os incidentes com calma quando eles chegam. Para o governo, as operações de segurança também carregam obrigações estatutárias: prazos obrigatórios de relato de incidentes, divulgação coordenada de vulnerabilidades e um rigor forense capaz de resistir ao escrutínio legal.

Este capítulo cobre a integração da segurança ao pipeline, o gerenciamento de vulnerabilidades e de correções, a resposta a incidentes e a perícia forense, a detecção por SIEM e SOAR e a validação das defesas por red teaming, purple teaming e testes de intrusão.

Princípios fundamentais

Automatize a rotina. As máquinas tratam a varredura, a correlação e a resposta repetitiva para que os humanos se concentrem no julgamento.
Desloque a segurança para dentro do pipeline. Os testes e os portões vivem no CI/CD (integração contínua e entrega contínua), dando feedback rápido onde os engenheiros já trabalham.
Presuma a violação e prepare-se. Ensaie a resposta a incidentes antes de precisar. O incidente não é hora de improvisar.
Meça e reduza o tempo. O tempo médio de detecção e o tempo médio de resposta são as métricas que mais importam.
Aprendizado sem atribuição de culpa. Cada incidente e quase-acidente vira uma lição que endurece o sistema, não uma caça a alguém para punir.
Valide as defesas de modo adversarial. Testem a segurança do jeito que atacantes reais fariam e corrijam o que eles acharem.
A engenharia de detecção é um produto. Tratem as detecções como código: versionadas, testadas e continuamente melhoradas.

Recomendações

Embuta o DevSecOps no pipeline

Integrem testes automatizados de segurança diretamente à integração e à entrega contínuas para que o feedback chegue aos engenheiros em minutos:

O SAST (Static Application Security Testing) analisa o código-fonte em busca de padrões vulneráveis assim que é commitado.
O DAST (Dynamic Application Security Testing) sonda a aplicação em execução em busca de falhas exploráveis.
O SCA (Software Composition Analysis) sinaliza dependências sabidamente vulneráveis.
A varredura de IaC verifica a infraestrutura como código em busca de configurações inseguras antes de serem implantadas.
A varredura de segredos impede a entrada de credenciais no repositório.

Ajustem essas ferramentas sem piedade para controlar os falsos positivos. Um varredor que grita “lobo!” é ignorado. Definam portões baseados em risco: bloqueiem em achados de alta gravidade e alta confiança e acompanhem o resto sem parar a entrega. Vocês querem um sinal rápido e confiável, não uma parede de ruído.

Gerencie as vulnerabilidades e corrija de forma sistemática

Um fluxo constante de vulnerabilidades pede um processo sistemático e priorizado, não um pânico novo a cada manchete.

Mantenham um inventário exato de ativos para saber o que pode ser afetado por qualquer vulnerabilidade.
Priorizem a remediação pelo risco real: combinem gravidade, explorabilidade (está sendo explorada na natureza?), exposição e criticidade do ativo em vez de corrigir apenas pela pontuação bruta.
Definam e imponham SLAs de remediação (acordos de nível de serviço) por nível de gravidade e meçam a aderência.
Automatizem as correções onde puderem com segurança, em especial para infraestrutura e dependências.
Conduzam um programa de divulgação coordenada de vulnerabilidades, com um canal claro de recebimento e, onde apropriado, um bug bounty, para que pesquisadores externos relatem as falhas com responsabilidade em vez de despejá-las em público.

Prepare-se para a resposta a incidentes e conduza-a

Quando um incidente chega, um processo ensaiado vale mais que qualquer ferramenta.

Mantenham um plano de resposta a incidentes com papéis definidos (comandante do incidente, responsável pelas comunicações, investigadores), classificações de gravidade e caminhos de escalonamento.
Estabeleçam fases claras: preparação, detecção e análise, contenção, erradicação, recuperação e revisão pós-incidente.
Preservem as evidências adequadamente para a perícia forense: capturem logs, memória e imagens de disco com uma cadeia de custódia documentada para que os achados se sustentem juridicamente e a análise seja sólida.
Planejem de antemão as comunicações de violação: quem notifica clientes, reguladores e o público, em que prazo, com o envolvimento do jurídico e das relações públicas. Os relógios regulatórios (muitas vezes 72 horas ou menos) começam a correr na descoberta.
Conduzam exercícios de mesa regularmente para que a equipe conheça o plano antes de uma crise real e façam revisões pós-incidente sem atribuição de culpa que produzam melhorias concretas.

Opere a detecção com SIEM e SOAR e projete as detecções

Reúnam os seus sinais de segurança e ajam sobre eles em escala.

Usem um SIEM (Security Information and Event Management) para agregar e correlacionar logs e eventos de todo o parque, trazendo à tona padrões suspeitos.
Usem um SOAR (Security Orchestration, Automation, and Response) para automatizar a triagem e os manuais de resposta: enriquecer alertas, isolar hosts, desativar credenciais e abrir casos sem esperar um humano para as etapas de rotina.
Pratiquem a engenharia de detecção: tratem as regras de detecção como código versionado e testado, alinhado a um framework como o MITRE ATT&CK, meçam suas taxas de verdadeiros e falsos positivos e melhorem continuamente a cobertura das técnicas reais dos adversários.
Garantam um registro abrangente e resistente a adulteração em aplicações e infraestrutura. Vocês não conseguem detectar o que não registram.

Valide as defesas com red teaming, purple teaming e testes de intrusão

Testar as defesas do jeito que um atacante testaria é a única maneira de saber que elas de fato funcionam.

O teste de intrusão (pentest) fornece uma avaliação focada e pontual de sistemas específicos, muitas vezes por conformidade.
O red teaming simula um adversário realista perseguindo objetivos em todo o seu ambiente, testando a detecção e a resposta além da prevenção.
O purple teaming reúne atacantes (red) e defensores (blue) de forma colaborativa para que cada ataque simulado melhore imediatamente as detecções e os controles, transformando um exercício em capacidade duradoura.
Devolvam todos os achados à engenharia de detecção, à remediação e ao treinamento.

Compromissos: prós e contras

Decisão	Prós	Contras
Portões bloqueantes no pipeline	Impedem que problemas conhecidos sejam entregues	Atrito, os falsos positivos frustram as equipes
Varredura não bloqueante	Baixo atrito, entrega rápida	Os problemas podem ser entregues. Exige disciplina para corrigir
SOC interno	Contexto profundo, controle total	Caro, difícil de dotar de pessoal 24/7
Detecção/resposta gerenciada	Cobertura 24/7, especialização sob demanda	Menos contexto, dependência de fornecedor
Correção automatizada	Rápida, fecha janelas depressa	Risco de mudanças que quebram
Red teaming frequente	Validação realista, acha lacunas reais	Caro, consome muitos recursos
Programa de bug bounty	Descoberta distribuída, boa cobertura	Ônus de triagem, custo de pagamentos, ruído

A tensão central é velocidade versus garantia e cobertura versus custo. Os portões bloqueantes e a correção automatizada maximizam a garantia, mas acrescentam atrito e risco. As abordagens não bloqueantes andam mais depressa mas dependem de acompanhamento. A detecção 24 horas por dia é essencial em escala e cara de construir internamente, o que empurra muitas organizações para modelos híbridos. O caminho sustentável automatiza a rotina de alta confiança, guarda a atenção humana para o julgamento genuíno e continua ajustando o equilíbrio com resultados medidos e não com medo.

Perguntas para discutir com sua equipe

Quais são os seus SLAs de remediação por gravidade, e o que de fato os impõe? Um fluxo constante de vulnerabilidades precisa de um processo sistemático e priorizado, não de um pânico novo a cada manchete, e os SLAs por nível de gravidade são como vocês mantêm o ritmo. Decidam seus relógios (por exemplo, críticas em dias, altas em semanas) e, igualmente importante, como medem a aderência e quem responde quando um prazo escorrega. Priorizem pelo risco real, combinando a gravidade com a explorabilidade na natureza, a exposição e a criticidade do ativo, em vez de corrigir apenas pela pontuação CVSS bruta. Levem o backlog atual de achados em aberto ordenado por idade e gravidade, porque as críticas sem correção além da janela são a evidência que importa. Se o SLA não tem imposição nem dono, é um desejo, e varrer sem remediar só constrói dívida de auditoria e uma falsa sensação de segurança.
Quando um incidente chega às 2 da manhã, quem é o comandante do incidente e com que rapidez o relógio regulatório começa? Um processo ensaiado vale mais que qualquer ferramenta, então vocês precisam de papéis nomeados (comandante do incidente, responsável pelas comunicações, investigadores), níveis de gravidade definidos e caminhos de escalonamento escritos antes da crise. Os relógios regulatórios muitas vezes correm 72 horas ou menos e começam na descoberta, então decidam de antemão quem notifica clientes, reguladores e o público e confirmem que o jurídico e as relações públicas estão no circuito. Preservar a evidência forense com uma cadeia de custódia documentada precisa acontecer antes de alguém reconstruir um host comprometido, ou vocês perdem a capacidade de entender ou provar o que ocorreu. Levem a data do último exercício de mesa, porque se foi há muito tempo ou nunca, o plano de vocês não foi testado. Para as equipes governamentais, os prazos estatutários de relato tornam isso obrigatório, então ensaiem o caminho de notificação, e não apenas a resposta técnica.
Quais ações de resposta de rotina vocês deixarão o SOAR tomar sem um humano no circuito? A automação é multiplicação de força que permite a uma equipe enxuta cobrir um grande parque, e a métrica que importa é o tempo médio de resposta, que manuais automatizados podem cortar de horas para minutos. Decidam quais ações de alta confiança (isolar um host, revogar uma credencial, abrir um caso) vocês confiam que rodem automaticamente e quais precisam antes de julgamento humano. O risco é um falso positivo disparar uma ação disruptiva, então liguem a automação à qualidade da detecção e ajustem sem piedade, porque um sistema que grita “lobo!” é desligado. Levem o volume atual de alertas e a taxa de falsos positivos, porque esses números dizem quais manuais são seguros de automatizar hoje. Se todo passo de resposta espera por um humano, vocês não acompanharão em escala, e o tempo de permanência, que conduz o custo da violação, continuará alto.
Quais achados do pipeline bloqueiam um lançamento, quais são apenas acompanhados e quem mantém a taxa de falsos positivos baixa o bastante para que os engenheiros ainda confiem no portão? Um varredor que grita “lobo!” é ignorado, e uma vez que os engenheiros perdem a fé num portão eles fazem lobby para removê-lo, então o valor do DevSecOps repousa na qualidade do sinal e não na cobertura bruta. A tensão é real: bloqueiem pouco e o código vulnerável é entregue, bloqueiem demais e vocês acrescentam atrito, desaceleram a entrega e queimam boa vontade. Levem as taxas de verdadeiros e falsos positivos de cada varredor (SAST, DAST, SCA, IaC e varredura de segredos), com que frequência as equipes ignoram ou suprimem um portão e a idade dos achados que vocês apenas acompanham sem corrigir. Para uma empresa ou órgão governamental que opera centenas de pipelines, definam a política de bloquear versus acompanhar de forma central e ajustem-na com dados, porque portões que diferem arbitrariamente de equipe para equipe criam tanto lacunas de auditoria quanto a sensação de que a segurança é caprichosa.
Quão confiantes vocês estão de que as suas detecções ainda cobrem as técnicas que um atacante real usaria, e quem é dono delas como código testado e versionado? As detecções decaem em silêncio à medida que o seu ambiente e os seus adversários evoluem, então um conjunto de regras que parecia abrangente no ano passado pode perder cobertura muito antes de um incidente finalmente revelar a lacuna. Tratar as detecções como código, versionado, testado e mapeado a um framework como o MITRE ATT&CK, é o que separa uma prática de engenharia de uma pilha de alertas obsoletos, e ainda assim ela disputa o mesmo escasso tempo de analista com a triagem ao vivo. Levem o mapa atual de cobertura do ATT&CK, a taxa medida de verdadeiros e falsos positivos das suas principais detecções e os resultados do último exercício de purple team, já que o teste colaborativo de red e blue é a maneira mais rápida de provar quais detecções de fato disparam. Em contextos corporativos e governamentais em que um framework pode ser exigido, liguem cada detecção a um dono nomeado e a uma cadência de revisão, porque a cobertura que ninguém mantém é cobertura que vocês só descobrem ter perdido depois da violação.
Vocês constroem detecção e resposta internamente, compram detecção e resposta gerenciada ou combinam as duas, e já precificaram o que custa uma cobertura genuína 24 horas por dia? O tempo de permanência conduz o custo da violação, então as horas descobertas (noites, fins de semana, feriados) são exatamente quando um intruso não detectado faz o maior dano, e ainda assim dotar de pessoal um centro de operações de segurança 24/7 internamente é caro e difícil de sustentar. A troca é contexto e controle versus custo e velocidade até a cobertura: uma equipe interna conhece o seu parque a fundo mas é lenta e cara de construir, enquanto um provedor gerenciado dá especialização instantânea 24 horas por dia ao preço de um contexto mais raso e de uma dependência de fornecedor. Levem as horas atuais de cobertura, o tempo médio de detecção e de resposta fora do horário comercial, o volume de alertas e uma leitura honesta de se vocês conseguem recrutar e reter os analistas de que um centro próprio precisa. Para governos e empresas reguladas, pesem a residência de dados, a habilitação do pessoal e as obrigações estatutárias de relato que o provedor precisa conseguir cumprir e confirmem que o contrato preserva o rigor forense e a cadeia de custódia que os processos legais exigem.

Perspectiva por setor

Startup. A velocidade e a sobrevivência vêm primeiro, então comprem segurança como subproduto das ferramentas que já rodam em vez de dotar de pessoal as operações. Liguem varredores gratuitos ao CI para bloquear vazamentos de segredos e dependências sabidamente vulneráveis na hora do commit, encaminhem os logs para um serviço gerenciado de baixo custo com um punhado de alertas de alto valor e escrevam um plano de incidente de uma página (para quem ligar, como rotacionar credenciais, tirar um snapshot antes de reconstruir) antes de precisarem dele. O seu recurso mais escasso é a atenção da engenharia, então automatizem a rotina e resistam a levantar um centro de operações de segurança que vocês não conseguem manter funcionando.

Pequena empresa. Sem especialista dedicado em segurança e com orçamento apertado, apoiem-se na detecção e resposta gerenciadas e nos recursos de segurança já embutidos nas suas plataformas. Tratem a correção e o inventário de ativos como os hábitos de maior alavancagem: saibam o que rodam, mantenham-no atual e imponham um prazo simples de remediação por gravidade. Prefiram fornecedores que tratam por vocês o monitoramento 24 horas, o recebimento de divulgação coordenada e a captura forense, e ensaiem a única coisa que não podem terceirizar, que é decidir quem declara um incidente e quem fala com os clientes.

Grande empresa. O desafio é a consistência entre muitas equipes e centenas de pipelines: uma política compartilhada de portões de bloquear versus acompanhar, SLAs de remediação impostos em toda a organização, uma plataforma de SIEM e SOAR com detecções medidas e um purple teaming que transforma cada exercício em nova cobertura. Gerenciem as operações de segurança como um portfólio, com painéis de tempo médio de detecção e de resposta, aderência aos SLAs e precisão das detecções, e decidam deliberadamente onde a profundidade interna vence a escala gerenciada. Orcem explicitamente o custo de supervisão humana da triagem e do ajuste, porque a automação desloca o esforço em vez de removê-lo.

Governo. As regras de contratação, a transparência e a responsabilização pública moldam toda escolha. Os prazos estatutários de relato de incidentes e a divulgação coordenada de vulnerabilidades são obrigações e não opções, então ensaiem o caminho de notificação à autoridade nacional com o mesmo cuidado da resposta técnica e preservem a evidência forense sob uma cadeia de custódia que resista ao escrutínio legal. Favoreçam contratos que mantenham portáveis a lógica de detecção e os dados, exijam que qualquer provedor gerenciado atenda às exigências de residência e de habilitação e esperem que as avaliações de red team e a varredura contínua alimentem um processo de autorização em que o público possa confiar.

Exemplos

Startup. Uma startup sem centro de operações de segurança liga varredores gratuitos ao seu pipeline de CI para que vazamentos de segredos e dependências sabidamente vulneráveis sejam pegos na hora do commit, bloqueando apenas em achados de alta confiança para que os dois engenheiros não se afoguem em ruído. Escreve um plano de incidente de uma página antes de precisar: para quem ligar, como rotacionar credenciais e tirar um snapshot de um host comprometido antes de reconstruí-lo para aprender o que aconteceu. Encaminha os logs para um serviço gerenciado de baixo custo e define alguns alertas sobre os eventos que realmente sinalizariam uma violação, de modo que um problema aparece em horas e não nos meses que leva para notá-lo por acaso.

Grande empresa. Uma empresa de software como serviço roda SAST, SCA, IaC e varredura de segredos em todo pipeline, bloqueando apenas em achados de alta gravidade e alta confiança e acompanhando o resto num painel com SLAs de remediação. Um SIEM alimenta uma plataforma SOAR que isola hosts e revoga credenciais automaticamente em alertas de alta confiança, cortando o tempo médio de resposta de horas para minutos. Exercícios trimestrais de purple team contra técnicas do MITRE ATT&CK geram diretamente novas regras de detecção, fechando continuamente as lacunas de cobertura.

Governo. Uma agência federal opera um centro de operações de segurança (SOC) com relato obrigatório de incidentes a uma autoridade cibernética nacional dentro de prazos estatutários. Conduz um programa de divulgação coordenada de vulnerabilidades com um canal público de recebimento, como exige a política, e preserva a evidência forense sob procedimentos estritos de cadeia de custódia adequados a processos legais. As avaliações anuais de red team e a varredura contínua de vulnerabilidades alimentam a autorização contínua da agência e seus SLAs de remediação baseados em risco.

Justificativa de negócio: motivações, ROI e TCO

Quase tudo no argumento a favor das operações de segurança se resume ao tempo de permanência: quanto mais tempo um atacante passa sem ser detectado, mais cara a violação. Estudos mostram consistentemente que os incidentes contidos depressa custam dramaticamente menos que os que se arrastam por meses. O custo total de propriedade inclui ferramentas (SIEM, SOAR, varredores), pessoal ou serviços gerenciados para detecção e resposta e o tempo para construir e ensaiar os processos de incidentes. Contra isso está o custo de não investir: uma violação descoberta tarde, espalhando-se pelos sistemas, atraindo multas regulatórias, notificações obrigatórias, litígios e dano de reputação, tudo agravado pelo caos de uma resposta não ensaiada.

O ROI vem de detecção e resposta mais rápidas, de automação que permite a uma equipe enxuta cobrir um grande parque e de melhorias de prevenção devolvidas por cada incidente e exercício. O DevSecOps em particular se paga ao pegar problemas no pipeline, onde são baratos, e não em produção, onde são caros e públicos. Ao defender o caso junto à liderança, ponham números no seu tempo médio atual de detecção e de resposta, mostrem como eles se ligam ao tempo de permanência e ao custo e enquadrem a automação como multiplicação de força que evita crescer o quadro de pessoal em marcha com o parque. Para o governo, enfatizem que as obrigações estatutárias de relato e de divulgação tornam obrigatórias as operações maduras.

Antipadrões e armadilhas

Fadiga de alertas. Tantos alertas que os analistas se desligam e perdem o verdadeiro.
Varrer sem remediar. Gerar achados que ninguém corrige, criando uma falsa sensação de segurança e dívida de auditoria.
Nenhum plano de incidente. Improvisar durante uma crise, desperdiçando minutos críticos e tratando mal as evidências.
Destruir evidências. Reconstruir um host comprometido antes de capturar a perícia, perdendo a capacidade de entender ou provar o que aconteceu.
Cultura de culpa nas revisões. Punir os respondentes para que o próximo incidente seja escondido ou tratado de modo defensivo.
Pentest só por conformidade. Um único teste anual para satisfazer um auditor, com os achados ignorados até o ano seguinte.
Portões bloqueantes com muitos falsos positivos. Corroer a confiança até os engenheiros exigirem que os portões sejam removidos por completo.
Detecções de configurar e esquecer. Regras que decaem à medida que o ambiente e os adversários evoluem, perdendo cobertura em silêncio.

Modelo de maturidade

Nível 1: Iniciar. As operações de segurança são ad hoc e reativas. O teste de segurança é manual e raro, e não há registro central nem SIEM. Não existe plano de incidente, então a resposta é improvisada no momento. A correção só acontece quando uma manchete a força, e as defesas nunca são testadas de modo adversarial.

Nível 2: Desenvolver. Aparecem práticas básicas mas inconsistentes entre as equipes. Alguns pipelines rodam varredores e outros não rodam nenhum, e o registro central existe em manchas. Um plano básico de incidente é documentado mas raramente ensaiado, a correção segue prazos frouxos e um pentest anual satisfaz a conformidade sem mudar muito. A cobertura e o rigor dependem de qual equipe vocês consultam.

Nível 3: Padronizar. As práticas são documentadas e impostas em toda a organização. A varredura DevSecOps completa com portões baseados em risco é aplicada de forma consistente, um SIEM correlaciona eventos e os primeiros manuais de SOAR rodam. A resposta a incidentes é ensaiada com exercícios de mesa e revisões sem atribuição de culpa, os SLAs de remediação por gravidade são impostos com donos nomeados e a divulgação coordenada de vulnerabilidades e o red teaming regular são a norma e não a exceção.

Nível 4: Gerenciar. As operações são medidas e controladas em relação a linhas de base. O tempo médio de detecção e de resposta, a aderência aos SLAs por nível de gravidade, a cobertura de varreduras, as taxas de verdadeiros e falsos positivos das detecções e o tempo de permanência são acompanhados em painéis e revisados numa cadência. As detecções carregam precisão e revocação medidas, mapeadas ao MITRE ATT&CK, as decisões de automação são condicionadas a dados de falsos positivos e não à esperança, e uma métrica que passa da sua linha de base dispara uma resposta definida em vez de passar despercebida.

Nível 5: Orquestrar. As operações de segurança são continuamente melhoradas, integradas em toda a organização e adaptativas. A engenharia de detecção, o purple teaming, a remediação e a revisão de incidentes alimentam um único ciclo que se adapta às novas técnicas dos adversários à medida que surgem. Manuais automatizados tratam a rotina em todo o parque para que os humanos se concentrem no julgamento, a segurança é planejada junto com a entrega e o risco, e cada incidente e exercício endurece mensuravelmente o sistema enquanto as métricas centrais continuam tendendo para baixo.

Ideias para discussão

Quais achados do pipeline devem bloquear um lançamento, e quais devem apenas ser acompanhados?
Construir um SOC interno, usar detecção e resposta gerenciadas ou combinar as duas, e por quê?
Como vocês impedem que as regras de detecção decaiam à medida que o seu ambiente evolui?
Com que agressividade a correção deve ser automatizada, dado o risco de mudanças que quebram?
Como é uma revisão pós-incidente genuinamente sem atribuição de culpa na sua cultura?
Como vocês medem se o red teaming e o purple teaming estão de fato melhorando as suas defesas?

Principais conclusões

A prevenção eventualmente falha. As operações existem para detectar e responder depressa.
Embutam SAST, DAST, SCA, IaC e varredura de segredos no pipeline, com portões baseados em risco.
Priorizem a correção pela explorabilidade real e pela criticidade do ativo, sob SLAs impostos.
Ensaiem a resposta a incidentes, preservem a evidência forense e planejem de antemão as comunicações de violação.
Usem SIEM e SOAR para correlacionar e automatizar. Tratem as detecções como código projetado e testado.
Validem as defesas com pentest, red teaming e purple teaming colaborativo.
O tempo de permanência conduz o custo da violação, então o tempo médio de detecção e de resposta são as métricas que importam.

Referências e leitura complementar

National Institute of Standards and Technology, SP 800-61: Computer Security Incident Handling Guide
National Institute of Standards and Technology, SP 800-40: Guide to Enterprise Patch Management
MITRE, ATT&CK Framework
Anton Chuvakin and others, Logging and Log Management / SIEM literature
Jim Bird, DevOpsSec: Securing Software through Continuous Delivery
Richard Bejtlich, The Practice of Network Security Monitoring
FIRST, Coordinated Vulnerability Disclosure guidance and CVSS specification