Notas prácticas: Numasec | El agente de IA para ciberseguridad
Guía paso a paso operativa de las notas prácticas: Numasec | El agente de IA para ciberseguridad: contratos, verificaciones y espacios para código integrable para los equipos que implementan este patrón.
Las notas siguientes reconstruyen un camino práctico para trabajar con “Numasec | El agente de IA para ciberseguridad”. Se da énfasis en los contratos, las verificaciones y los marcadores de posición para código, en lugar de en un enfoque motivacional. Al trabajar en la etapa de descripción general, anote primero el contrato: las entradas requeridas, la señal de éxito y qué ocurre en caso de fallo parcial. Esa lista de verificación ayuda a mantener honestas las futuras modificaciones del código. Documente tanto el camino óptimo como el de recuperación. Los intentos repetidos, los controles humanos y el manejo de mensajes no entregados forman parte del producto, no son mejoras posteriores.
¿Qué es Numasec?
La etapa “What Is Numasec” funciona mejor cuando se trata como una superficie medible. Capture una transcripción ejemplar, un caso de fallo y la nota de reversión antes de ampliar el alcance. Prefiera unidades pequeñas y verificables en lugar de scripts extensos. Cuando un paso falla, el fallo debe apuntar a una única responsabilidad y no a un proceso complicado. Mantenga el estado del gráfico simple y tipado; los bloques anidados ocultan qué nodo escribió qué campo y provocan interrupciones en la continuación del proceso.
Nmap → Network discovery
Nuclei → Vulnerability templates
SQLMap → SQL injection testing
FFUF → Content discovery
Nikto → Web-server checks
Trivy → Security scanning
🤖 AI Agent
│
┌──────────┼──────────┐
▼ ▼ ▼
Tools Runbooks Knowledge
│ │ │
└──────────┼──────────┘
▼
Operation
│
┌───────────┼───────────┐
▼ ▼ ▼
Findings Evidence Replay
│ │ │
└───────────┼───────────┘
▼
Report
Por qué los agentes de IA son interesantes para la ciberseguridad
Los agentes de IA funcionan mejor en esta etapa cuando se tratan como una superficie medible. Capture un registro exitoso, un caso de fallo y la nota de reversión antes de ampliar el alcance. Considere esta etapa como un contrato entre las entradas y las salidas validadas. Asigne nombres a los artefactos, defina verificaciones de éxito y rechace las completaciones parciales silenciosas. Mantenga el estado del grafo plano y tipado. Los bloques anidados ocultan qué nodo escribió qué campo y provocan interrupciones en la continuación posterior.
Target
Scope
Tools
Observations
Findings
Evidence
Risk
Remediation
Flujo de trabajo de seguridad de Numasec
La etapa de flujo de trabajo de seguridad de Numasec funciona mejor cuando se trata como una superficie medible. Capture una transcripción ideal, un caso de fallo y la nota de reversión antes de ampliar el alcance. Registre los tiempos y el costo de tokens o consultas junto con los resultados funcionales. Tener visibilidad del costo desde el principio evita facturas inesperadas cuando el proceso pasa de la fase de demostración a entornos compartidos. Mantenga el estado del gráfico simple y tipado; los bloques anidados ocultan qué nodo escribió qué campo y causan interrupciones en la continuación del proceso. La etapa de flujo de trabajo de seguridad de Numasec funciona mejor cuando se trata como una superficie medible. Capture una transcripción ideal, un caso de fallo y la nota de reversión antes de ampliar el alcance. Documente tanto el camino óptimo como el camino de recuperación juntos. Las reintentos, los controles humanos y el manejo de mensajes no entregados forman parte del producto, no son ajustes realizados posteriormente.
🎯 Target
↓
📋 Scope
↓
🧭 Security Posture
↓
📖 Runbook
↓
🛠️ Local Tools
↓
🔎 Observations
↓
🚨 Findings
↓
📸 Evidence
↓
🔁 Replay / Verification
↓
📊 Report
Reconocimiento de seguridad con IA
En la fase de reconocimiento de seguridad con IA, defina las entradas, el responsable de cada paso y los criterios de finalización antes de modificar el código. Los operadores deben poder volver a ejecutar el paso a partir de un punto de control conocido sin tener que adivinar el estado oculto. Prefiera unidades pequeñas y verificables en lugar de scripts extensos. Cuando un paso falla, el error debe indicar una única responsabilidad y no un proceso complicado. Incluya la aprobación humana en aquellas tareas que implican gastos o modificaciones en datos de producción. La configuración en tiempo de compilación no equivale a la completitud del proceso empresarial.
Domains
Subdomains
Technologies
Ports
Services
APIs
Authentication
Web applications
Cloud services
Raw Tool Output
↓
AI Interpretation
↓
Structured Observation
↓
Potential Finding
↓
Evidence
Trabajar con herramientas de seguridad existentes
En la etapa de Trabajo con seguridad existente, defina las entradas, el responsable del paso y los criterios de finalización antes de modificar el código. Los operadores deben poder volver a ejecutar el paso a partir de un punto de control conocido sin tener que adivinar el estado oculto. Considere esta etapa como un contrato entre las entradas y los resultados validados. Asigne nombres a los artefactos, defina verificaciones de éxito y rechace las completaciones parciales silenciosas. Autentíquese en la pasarela y vuelva a autorizarse en el plano de datos. Un token portador por sí solo no constituye un límite entre tenencias.
AI replaces security tools
AI
│
├── Nmap
├── FFUF
├── Nuclei
├── Nikto
├── SQLMap
├── Trivy
└── Other authorized tools
Agentes de seguridad y modos diferentes
Para los agentes de seguridad y las diferentes etapas, defina las entradas, el responsable de cada paso y los criterios de finalización antes de modificar el código. Los operadores deben poder volver a ejecutar el paso a partir de un punto de control conocido sin tener que adivinar el estado oculto. Registre los tiempos de ejecución y el costo de tokens o consultas junto con los resultados funcionales. La visibilidad temprana del costo evita facturas inesperadas cuando el proceso pasa de entornos de demostración a entornos compartidos. Incorpore la aprobación humana en aquellos casos que impliquen gastos o cambios en datos de producción. La configuración en tiempo de compilación no equivale a la completitud del proceso empresarial. Para los agentes de seguridad y las diferentes etapas, defina las entradas, el responsable de cada paso y los criterios de finalización antes de modificar el código. Los operadores deben poder volver a ejecutar el paso a partir de un punto de control conocido sin tener que adivinar el estado oculto. Documente tanto la ruta óptima como la ruta de recuperación. Las reintentos, los controles humanos y el manejo de mensajes no entregados forman parte del producto, no se añaden posteriormente.
...
Numasec
│
┌───────────┼───────────┐
▼ ▼ ▼
AppSec Pentest Research
│ │ │
▼ ▼ ▼
APIs Network CVEs
Web Systems Advisories
Guías de operación: Transformar el conocimiento en seguridad en flujos de trabajo
Al trabajar en la etapa de “Guías de operación: Transformar el conocimiento en seguridad”, anote primero los requisitos: entradas necesarias, señal de éxito y qué ocurre en caso de fallo parcial. Esa lista de verificación garantiza que los cambios posteriores en el código sean transparentes. Prefiera unidades pequeñas y verificables a scripts extensos. Cuando un paso falla, el fallo debe referirse a una sola responsabilidad y no a un proceso complicado. Haga puntos de control después de los pasos costosos. La función de reanudación no debe volver a facturar la misma llamada al LLM cuando un operador intenta nuevamente un nodo posterior.
Web Application Assessment
1. Identify target
2. Confirm scope
3. Inspect application
4. Identify technologies
5. Map endpoints
6. Analyze authentication
7. Review APIs
8. Identify potential vulnerabilities
9. Collect evidence
10. Validate findings
11. Generate report
Las conclusiones deben estar respaldadas por pruebas
Al trabajar en la fase de “Los hallazgos deben requerir evidencia”, anote primero el contrato: los datos necesarios, la señal de éxito y qué ocurre en caso de un fallo parcial. Esa lista de verificación mantiene honestas las futuras modificaciones del código. Trate esta fase como un contrato entre los datos de entrada y los resultados validados. Asigne nombres a los artefactos, defina las comprobaciones de éxito y evite completaciones parciales silenciosas. Haga una verificación después de los pasos costosos. El sistema de reanudación no debe volver a facturar la misma llamada al LLM cuando un operador intenta nuevamente un nodo posterior.
Interesting response
↓
"Potential vulnerability"
Observation
↓
Candidate
↓
Verification
↓
Evidence
↓
Confirmed Finding
Observación ≠ Vulnerabilidad
Al trabajar en la fase de Vulnerabilidad por Observación, anote primero el contrato: entradas requeridas, señal de éxito y qué ocurre en caso de fallo parcial. Esa lista de verificación mantiene honestas las futuras modificaciones del código. Registre los tiempos y el costo de tokens o consultas junto con los resultados funcionales. Tener visibilidad del costo desde el principio evita facturas inesperadas cuando el proceso pasa de la versión de demostración a entornos compartidos. Haga una verificación después de los pasos costosos. La reanudación no debe volver a facturar la misma llamada al LLM cuando un operador intenta nuevamente un nodo posterior. Al trabajar en la fase de Vulnerabilidad por Observación, anote primero el contrato: entradas requeridas, señal de éxito y qué ocurre en caso de fallo parcial. Esa lista de verificación mantiene honestas las futuras modificaciones del código. Documente tanto el camino óptimo como el camino de recuperación. Las reintentos, los controles humanos y el manejo de mensajes no entregados forman parte del producto, no son mejoras posteriores.
Potential vulnerability
Candidate
Observed
Verified
Rejected
Stale
Recopilación de pruebas
La etapa de recopilación de pruebas funciona mejor cuando se trata como una superficie medible. Capture una transcripción clave, un caso de fallo y la nota de reversión antes de ampliar el alcance. Prefiera unidades pequeñas y verificables en lugar de scripts extensos. Cuando un paso falla, el fallo debe apuntar a una sola responsabilidad y no a un proceso complicado. Mantenga el estado del grafo simple y tipado. Los bloques anidados ocultan qué nodo escribió qué campo y provocan interrupciones en la continuación del proceso.
HTTP Requests
HTTP Responses
Screenshots
Tool Output
Logs
Hashes
Configuration
Reproduction Steps
Downloads/
Screenshots/
Terminal History/
Notes/
Browser Tabs/
Finding #001
│
├── Observation
├── Request
├── Response
├── Screenshot
├── Reproduction
└── Remediation
Reproducción y verificación
La etapa de Reproducción y Verificación funciona mejor cuando se trata como una superficie medible. Capture un registro ideal, un caso de fallo y la nota de reversión antes de ampliar el alcance. Trate esta etapa como un contrato entre las entradas y las salidas validadas. Asigne nombres a los artefactos, defina verificaciones de éxito y rechace completaciones parciales silenciosas. Mantenga el estado del grafo plano y tipado. Los bloques anidados ocultan qué nodo escribió qué campo y provocan interrupciones en la continuación después de las interrupciones.
Initial Observation
↓
Hypothesis
↓
Controlled Test
↓
Evidence
↓
Replay
↓
Verified Finding
De las pruebas a los informes
La etapa de De pruebas a informes funciona mejor cuando se trata como una superficie medible. Capture una transcripción de referencia, un caso de fallo y la nota de reversión antes de ampliar el alcance. Registre los tiempos y el costo de tokens o consultas junto con los resultados funcionales. Tener visibilidad del costo desde el principio evita facturas inesperadas cuando el proceso pasa de la demostración a entornos compartidos. Mantenga el estado de los gráficos simple y tipado. Los bloques anidados ocultan qué nodo escribió qué campo y causan interrupciones en la continuación del proceso. La etapa de De pruebas a informes funciona mejor cuando se trata como una superficie medible. Capture una transcripción de referencia, un caso de fallo y la nota de reversión antes de ampliar el alcance. Documente tanto el camino óptimo como el camino de recuperación. Las reintentos, los controles humanos y el manejo de mensajes no entregados forman parte del producto, no son ajustes realizados posteriormente.
Executive Summary
Technical Findings
Severity
Evidence
Impact
Remediation
References
Terminal
+
Screenshots
+
Notes
+
Browser
+
Scanner Output
Comenzando
En la fase de inicio, defina las entradas, el responsable del paso y los criterios de finalización antes de modificar el código. Los operadores deben poder volver a ejecutar el paso a partir de un punto de control conocido sin tener que adivinar el estado oculto. Prefiera unidades pequeñas y verificables en lugar de scripts extensos. Cuando un paso falla, el error debe indicar una única responsabilidad y no un proceso complicado. Incluya la aprobación humana en aquellos casos en los que se gastan fondos o se modifican datos de producción. La configuración en tiempo de compilación no equivale a la completitud del proceso empresarial.
npm install -g numasec
numasec
Your Machine
│
▼
Local Web Application
│
▼
Numasec
│
▼
AppSec Runbook
│
▼
Findings + Evidence
El concepto /doctor
En la fase del concepto del médico, defina las entradas, el responsable de cada paso y los criterios de finalización antes de modificar el código. Los operadores deben poder volver a ejecutar el paso a partir de un punto de control conocido, sin tener que adivinar el estado oculto. Considere esta fase como un contrato entre las entradas y los resultados validados. Asigne nombres a los artefactos, defina verificaciones de éxito y rechace las completaciones parciales silenciosas. Incluya la aprobación humana en aquellos casos que impliquen gastos o cambios en los datos de producción. La conexión en tiempo de compilación no equivale a la completitud del proceso empresarial.
Installed tools
Missing tools
Broken tools
Incorrect versions
Unavailable dependencies
El alcance es crucial
En la fase en la que el alcance es crítico, se deben definir las entradas, el responsable de la tarea y los criterios de finalización antes de modificar el código. Los operadores deben poder volver a ejecutar la tarea a partir de un punto de control conocido, sin tener que adivinar el estado oculto. Se deben registrar los tiempos de ejecución y el costo de tokens o consultas junto con los resultados funcionales. Tener visibilidad del costo desde el principio evita facturas inesperadas cuando la tarea pasa de un entorno de demostración a entornos compartidos. Se debe incluir la aprobación humana en aquellos casos en los que se gastan fondos o se modifican datos de producción. La configuración en tiempo de compilación no equivale a la completitud del proceso empresarial. En la fase en la que el alcance es crítico, se deben definir las entradas, el responsable de la tarea y los criterios de finalización antes de modificar el código. Los operadores deben poder volver a ejecutar la tarea a partir de un punto de control conocido, sin tener que adivinar el estado oculto. Se deben documentar tanto la ruta óptima como la ruta de recuperación. Las intentonas repetidas, los controles humanos y el manejo de mensajes no entregados forman parte del producto, y no son algo que se añada posteriormente.
AUTHORIZED TARGET
↓
DEFINED SCOPE
↓
ALLOWED TESTS
↓
CONTROLLED EXECUTION
Allowed:
example-lab.local
Not allowed:
production.example.com
third-party.example.net
unrelated infrastructure
La automatización de la seguridad necesita marcos de referencia
Al trabajar en la etapa de marcos de referencia para las necesidades de automatización de la seguridad, primero anote el contrato: los datos requeridos, la señal de éxito y qué ocurre en caso de un fallo parcial. Esa lista de verificación mantiene honestas las futuras modificaciones del código. Prefiera unidades pequeñas y verificables en lugar de scripts extensos. Cuando un paso falla, el fallo debe apuntar a una única responsabilidad y no a un proceso complicado. Haga una verificación después de los pasos costosos. La función de reanudación no debe volver a facturar la misma llamada al LLM cuando un operador intenta nuevamente un nodo posterior.
Ambito
Al trabajar en la etapa de Alcance, anote primero el contrato: los datos de entrada requeridos, la señal de éxito y qué ocurre en caso de fallo parcial. Esa lista de verificación mantiene honestas las futuras modificaciones del código. Trate esta etapa como un contrato entre los datos de entrada y los resultados validados. Asigne nombres a los artefactos, defina las comprobaciones de éxito y rechace las completaciones parciales silenciosas. Haga una verificación después de los pasos costosos. La función de reanudación no debe volver a facturar la misma llamada al LLM cuando un operador intenta nuevamente un nodo posterior.
Permisos
Al trabajar en la etapa de Permisos, anote primero el contrato: los datos requeridos, la señal de éxito y qué ocurre en caso de fallo parcial. Esa lista de verificación garantiza que los cambios posteriores en el código sean transparentes. Registre los tiempos de ejecución y el costo del token o la consulta junto con los resultados funcionales. Tener visibilidad temprana del costo evita facturas inesperadas cuando el proceso pasa de la versión de demostración a entornos compartidos. Haga una verificación después de los pasos costosos. La función de reanudación no debe volver a facturar la misma llamada al LLM cuando un operador intenta nuevamente un nodo posterior. Al trabajar en la etapa de Permisos, anote primero el contrato: los datos requeridos, la señal de éxito y qué ocurre en caso de fallo parcial. Esa lista de verificación garantiza que los cambios posteriores en el código sean transparentes. Documente tanto la ruta óptima como la ruta de recuperación. Las reintentos, los controles humanos y el manejo de mensajes no entregados forman parte del producto, no son mejoras adicionales realizadas posteriormente.
Evidencia
La etapa de Pruebas funciona mejor cuando se trata como una superficie medible. Capture un registro ideal, un caso de fallo y la nota de reversión antes de ampliar el alcance. Prefiera unidades pequeñas y verificables en lugar de scripts extensos. Cuando un paso falla, el fallo debe apuntar a una sola responsabilidad y no a un proceso complicado. Mantenga el estado del grafo plano y tipado. Los bloques anidados ocultan qué nodo escribió qué campo y dificultan la reanudación después de interrupciones.
Registro
La etapa de Registro funciona mejor cuando se trata como una superficie medible. Capture un registro ideal, un caso de fallo y la nota de reversión antes de ampliar el alcance. Trate esta etapa como un contrato entre las entradas y las salidas validadas. Asigne nombres a los artefactos, defina comprobaciones de éxito y rechace completaciones parciales silenciosas. Mantenga el estado del grafo plano y tipado. Los bloques anidados ocultan qué nodo escribió qué campo y dificultan la reanudación después de interrupciones.
Supervisión humana
La etapa de Supervisión humana funciona mejor cuando se trata como una superficie medible. Capture un registro ideal, un caso de fallo y la nota de reversión antes de ampliar el alcance. Registre los tiempos y el costo de tokens o consultas junto con los resultados funcionales. La visibilidad temprana del costo evita facturas inesperadas cuando el proceso pasa de la versión de demostración a entornos compartidos. Mantenga el estado del gráfico simple y tipado. Los bloques anidados ocultan qué nodo escribió qué campo e interrumpen la continuación después de las interrupciones. La etapa de Supervisión humana funciona mejor cuando se trata como una superficie medible. Capture un registro ideal, un caso de fallo y la nota de reversión antes de ampliar el alcance. Documente tanto el camino óptimo como el camino de recuperación. Las reintentos, los controles humanos y el manejo de mensajes no entregados forman parte del producto, no son mejoras posteriores.
Entornos seguros
En la etapa de Entornos Seguros, defina las entradas, el responsable de cada paso y los criterios de finalización antes de modificar el código. Los operadores deben poder volver a ejecutar el paso a partir de un punto de control conocido, sin tener que adivinar el estado oculto. Prefiera unidades pequeñas y verificables en lugar de scripts extensos. Cuando un paso falla, el error debe indicar una única responsabilidad y no un proceso complicado. Incluya la aprobación humana en aquellas tareas que implican gastos o modificaciones en datos de producción. La configuración en tiempo de compilación no equivale a una solución completa para los negocios.
Numasec vs Flujos de trabajo de seguridad tradicionales
Para la etapa Numasec vs Seguridad Tradicional, defina las entradas, el responsable de la fase y los criterios de finalización antes de modificar el código. Los operadores deben poder volver a ejecutar la fase a partir de un punto de control conocido sin tener que adivinar el estado oculto. Trate esta etapa como un contrato entre las entradas y los resultados validados. Asigne nombres a los artefactos, defina verificaciones de éxito y rechace las completaciones parciales silenciosas. Incluya la aprobación humana en aquellos casos que impliquen gastos o cambios en datos de producción. La conexión en tiempo de compilación no equivale a la completitud del proceso empresarial.
Terminal
+
Browser
+
Burp
+
Nmap
+
Scanner
+
Notes
+
Screenshots
+
Report
🤖 AI Agent
│
┌─────────────┼─────────────┐
▼ ▼ ▼
Terminal Browser Tools
│ │ │
└─────────────┼─────────────┘
▼
Operation
│
┌────────┴────────┐
▼ ▼
Findings Evidence
│ │
└────────┬────────┘
▼
Report
Por qué este enfoque es interesante
En la fase de “¿Por qué este enfoque?”, defina las entradas, el responsable del paso y los criterios de finalización antes de modificar el código. Los operadores deben poder volver a ejecutar el paso a partir de un punto de control conocido sin tener que adivinar el estado oculto. Registre los tiempos de ejecución y el costo en tokens o consultas junto con los resultados funcionales. La visibilidad temprana de los costos evita facturas inesperadas cuando el proceso pasa de entornos de demostración a entornos compartidos. Incorpore la aprobación humana en aquellos casos en que se gastan fondos o se modifican datos de producción. La configuración en tiempo de compilación no equivale a la completitud del proceso empresarial. En la fase de “¿Por qué este enfoque?”, defina las entradas, el responsable del paso y los criterios de finalización antes de modificar el código. Los operadores deben poder volver a ejecutar el paso a partir de un punto de control conocido sin tener que adivinar el estado oculto. Documente tanto la ruta óptima como la ruta de recuperación. Las intentonas repetidas, los controles humanos y el manejo de mensajes no entregados forman parte del producto, no son ajustes realizados posteriormente.
Ejemplo de flujo de trabajo autorizado
Al trabajar en la etapa del Ejemplo de flujo de trabajo autorizado, anote primero el contrato: los datos necesarios, la señal de éxito y qué ocurre en caso de fallo parcial. Esa lista de verificación mantiene honestas las futuras modificaciones del código. Prefiera unidades pequeñas y probables sobre scripts extensos. Cuando un paso falla, el fallo debe apuntar a una sola responsabilidad en lugar de a un proceso complicado. Haga una verificación después de los pasos costosos. La función de reanudación no debe volver a facturar la misma llamada al LLM cuando un operador intenta nuevamente un nodo posterior.
1️⃣ Define scope
↓
2️⃣ Start Numasec
↓
3️⃣ Check local tools
↓
4️⃣ Select AppSec posture
↓
5️⃣ Start appropriate runbook
↓
6️⃣ Discover application surface
↓
7️⃣ Analyze observations
↓
8️⃣ Validate interesting behavior
↓
9️⃣ Capture evidence
↓
🔟 Generate report
Arquitectura
Al trabajar en la etapa de arquitectura, primero escribe el contrato: los datos de entrada requeridos, la señal de éxito y qué ocurre en caso de un fallo parcial. Esa lista de verificación mantiene honestas las futuras modificaciones del código. Considera esta etapa como un contrato entre los datos de entrada y los resultados validados. Nombra los artefactos, define las verificaciones de éxito y rechaza las completaciones parciales silenciosas. Haz una verificación después de los pasos costosos. La función de reanudación no debe volver a facturar la misma llamada al LLM cuando un operador intenta nuevamente un nodo posterior.
👨💻 Operator
│
▼
Terminal Console
│
▼
AI Security
Agent
│
┌───────────────┼────────────────┐
▼ ▼ ▼
Tools Runbooks Knowledge
│ │ │
└───────────────┼────────────────┘
▼
Cyber Operation
│
┌──────────────┼──────────────┐
▼ ▼ ▼
Findings Evidence Replay
│ │ │
└──────────────┼──────────────┘
▼
Reports
Conocimientos de seguridad
CVE
Advisories
Package Versions
Methodologies
Tool Documentation
Vulnerability Intelligence
Software:
ExampleServer 1.2.0
CVE:
Potentially affected↓
Is the vulnerable component actually enabled?↓
Is the vulnerable configuration present?↓
Can the issue be reproduced?↓
Confirmed / Not Applicable
La IA no reemplaza al profesional de seguridad
Repetition
Organization
Research
Command assistance
Data interpretation
Documentation
Workflow management
Scope
Risk
Business Impact
Exploitability
Evidence
Authorization
Remediation
Human
+
AI
+
Security Tools
+
Evidence
=
Better Security Workflow
AI = Automatic Hacker
El futuro de la seguridad impulsada por IA
🤖 AI Security Agent
│
┌───────────────┼────────────────┐
▼ ▼ ▼
Reconnaissance Analysis Validation
│ │ │
└───────────────┼────────────────┘
▼
Evidence
│
▼
Findings
│
▼
Remediation
│
▼
Report
Lista de verificación para el aprendizaje práctico
Local Lab
↓
CTF
↓
Authorized Test Environment
↓
Scoped Bug Bounty
↓
Professional Assessment