NIST is developing a program to adapt the Cybersecurity Framework for AI-specific risks and opportunities. This guide translates that initiative into actionable steps for your SecOps team to manage AI-enabled tools and defend against AI-enabled threats.
Scope
This guide focuses on three operational domains where AI intersects with your security stack:
- Securing AI systems your organization deploys (model infrastructure, training data, inference endpoints)
- Defending against AI-enabled attacks (deepfake social engineering, automated vulnerability exploitation)
- Operating AI-powered security tools (SIEM anomaly detection, automated threat hunting, privacy assistants)
You'll need different controls for each domain. Treating "AI security" as a single project creates gaps.
Key Concepts and Definitions
AI Risk Management Framework (AI RMF): NIST's approach to managing AI-related risks across safety, transparency, and accountability. It complements but doesn't replace your existing cybersecurity controls.
Adversarial Machine Learning: Techniques that manipulate AI model behavior through poisoned training data, evasion attacks, or model extraction. NIST AI 100-2 provides the taxonomy.
Model Training Data Leakage: When AI systems inadvertently expose sensitive information embedded in training datasets through inference queries or model outputs.
Differential Privacy: A mathematical guarantee that limits what an adversary can learn about individuals in a dataset, even with full model access. NIST SP 800-226 (draft) provides evaluation guidelines.
Explainable AI: Systems that provide human-interpretable reasoning for their outputs. Critical for security tools where false positives carry operational costs.
Requirements Breakdown
Domain 1: Securing Your AI Systems
Data Asset Inventory
Your existing data classification doesn't account for training datasets or model weights as critical assets. Update your inventory to include:
- Training data sources and lineage
- Model artifacts and version history
- Inference endpoints and API access logs
Business units deploying AI create new data dependencies you don't yet track. Map these before an incident forces the exercise.
Software Development Practices
Generative AI and foundation models require adapted secure development controls:
- Version control for model weights, not just code
- Provenance tracking for training data sources
- Isolation of training environments from production networks
- Access controls on model registries
If you're treating model deployment like traditional software releases, you're missing model-specific attack surfaces.
Traditional Threat Modeling Still Applies
Your AI infrastructure runs on servers, containers, and networks. Standard controls apply:
- Network segmentation for training clusters
- Least-privilege access to GPU compute resources
- Logging and monitoring for model serving endpoints
- Patch management for ML framework dependencies
Don't let "AI" become an excuse to skip baseline hardening.
Domain 2: Defending Against AI-Enabled Attacks
Updated Threat Intelligence
AI lowers the skill floor for certain attacks:
- Voice deepfakes bypassing phone-based verification
- Automated vulnerability scanning with LLM-generated exploits
- Personalized phishing at scale using scraped social media data
Your annual security awareness training needs scenarios for these threats. Generic "don't click suspicious links" doesn't prepare users for AI-generated CEO voice calls requesting wire transfers.
Detection Challenges
AI-generated content is harder to flag with signature-based detection. Consider:
- Behavioral analysis over content filtering for phishing detection
- Multi-factor authentication that doesn't rely on voice verification alone
- Anomaly detection for unusual access patterns, not just malformed requests
Domain 3: Operating AI-Powered Security Tools
False Positive Management
AI-powered threat hunting can increase detection rates while simultaneously increasing false positives. Your team needs:
- Baseline metrics for alert accuracy before deploying AI tools
- Explainability features that show why the model flagged an event
- Human-in-the-loop workflows for high-stakes decisions (account lockouts, incident escalation)
A SIEM that generates 40% more alerts with 60% more false positives hasn't improved your security posture. It's created an alert fatigue problem.
Skill Requirements
NIST recently added Security of AI as a competency area. Your team needs:
- Understanding of how ML models make predictions (not deep math, but conceptual)
- Ability to interpret model confidence scores and uncertainty
- Skills to validate AI tool outputs against ground truth
If your analysts can't explain why the AI flagged something, they can't effectively triage it.
Implementation Guidance
Start with the Community Profile
NIST's National Cybersecurity Center of Excellence is developing an AI community profile that adapts the Cybersecurity Framework. This profile will map AI-specific risks to existing CSF categories (Identify, Protect, Detect, Respond, Recover).
Wait for this profile before creating your own mapping. Reinventing the wheel wastes cycles you could spend on implementation.
Coordinate Across Frameworks
The AI community profile will show how the Cybersecurity Framework, Privacy Framework, AI RMF, and NICE Framework intersect. You'll need:
- Privacy team involvement for data leakage risks
- HR involvement for workforce competency gaps
- Risk management involvement for AI RMF alignment
Siloed implementation creates control gaps at the boundaries.
Use Existing Tools
NIST provides reference implementations:
- Dioptra: Test platform for evaluating ML algorithm behavior under diverse conditions, including adversarial scenarios
- PETs Testbed: Capability for investigating privacy-enhancing technologies that protect ML models from privacy attacks
Use these to validate vendor claims about AI security features. "Our model is secure" isn't a control.
Common Pitfalls
Treating AI as Pure Innovation
AI systems are software systems. They inherit all the vulnerabilities of their underlying infrastructure. Skipping baseline controls because "it's AI" creates preventable incidents.
Assuming Explainability by Default
Many commercial AI security tools are black boxes. If the vendor can't explain how the model reaches decisions, you can't effectively tune it or validate its outputs.
Ignoring Privacy Implications
AI's ability to correlate across disparate datasets creates re-identification risks even with anonymized data. Your privacy team needs to assess these risks before deployment, not after a breach.
Underestimating Skill Gaps
Your current SecOps team may not have the competencies to operate AI-powered tools effectively. Budget for training or hiring.
Quick Reference Table
| Risk Category | Primary Control Domain | Key Standard/Guide |
|---|---|---|
| Model training data leakage | Data protection, access control | NIST SP 800-226 (draft) |
| Adversarial ML attacks | Threat modeling, testing | NIST AI 100-2 |
| Insecure AI development | Secure SDLC | NIST SP 218A |
| AI-enabled phishing | Awareness, authentication | Updated training scenarios |
| False positives from AI tools | Monitoring, tuning | Baseline metrics + explainability |
| Workforce skill gaps | Training, competency | NICE Framework (Security of AI) |
| Privacy violations | Data governance | Privacy Framework alignment |
Next Steps: Monitor NIST's AI cybersecurity program website for the community profile release. In the meantime, inventory your AI systems, assess your team's competency gaps, and establish baseline metrics for any AI-powered security tools you're already running.
Send questions to [email protected].
