certunlp / ngen Goto Github PK

En los casos aparece la columna fecha de creación pero la fecha que aparece en ella es la de ocurrencia ingresada al crear el caso.

actualizar https://github.com/CERTUNLP/pyngen a la nueva veersion y actualizar con nuevas funciones

migrar los comentarios en incident comment y thread

algunas redes host estan agregadas a la BD por el uso q se le daba antes,
esto puede solucuonarse con el uso de observables o combinarse con el uso de los mismos.
aunq puede ser util agregar un host/32 con contactos fijos, en la BD actual hay mas ip host q ip de red

Cuando se ingresa al sistema no carga de una el contenido de la sección Métricas...luego de clickear en alguna otra opción si se vuelve a la sección en métricas desde el menú si carga

permitir el download de evidencias de eventos y casos en el front

los incidentes no van a referenciar a el id de las redes, deberian ir a buscar la red a partir de el address onthefly y asi evitar la dependencia
tambien permitiria agregar enriquecimientos a cada uno y dejarlos en la BD

Agregar campo nombre a la evidencia para que al crear o editar un evento y asociarle evidencia se pueda identificar fácilmente.

Hoy en día se muestra de la siguiente manera a la hora de editar un evento:

Cuando se crea un reporte, todos los campos son obligatorios, pero en la interfaz solo aparecen como obligatorios:

• taxonomía
• idioma
• problema

Se adjunta captura donde la verificación está en blanco y no se puede guardar

Por otro lado, estaría bueno que en vez de informar: "El reporte no se pudo crear."

Aparezca el listado de todos lo problemas que hay y uno no tenga que verificar a mano cual fue la respuesta del servidor.

Se toma como ejemplo el caso con nombre "caso2", que está cerrado:

Cuando se asocia intenta asociar un evento a ese caso usando un patch, la asociación no está permitida:

Ahora cuando se crea un evento, se puede asociar un caso que esta cerrado a un evento.
antes de crear un evento:

Después de crearse:


Lo mismo pasa cuando uno quiere editar un evento

Cuando se edita un evento, y se cambia el recurso afectado por un valor que no esta en la lista de artefactos, el backend responde con un error 500

cuando agrego el dominio "unlp.edu.info.ar" como recurso afectado, no se guarda como artefacto y el validador del backend lo toma como valido

Quitar fecha de ocurrencia de Casos del modelo de backend. Se concluyó que no es un campo necesario.

1. Al crear un caso me permite utilizar fechas posteriores a la actual en los tres campos correspondientes a fechas.
2. No guarda las fechas de atención y de resolución, tanto al crearlo como al editarlo.
3. En la fecha de creación el horario no aparece en GMT -3.

En taxonomia falta el ordenamiento por cantidad de eventos .
En Plantilla falta ordenar por fuente.

estuve investigando por paquetes de audit. Hay varios pero mucho no tienen compatibilidad con django 4 o nisiquiera con el 3

https://github.com/jazzband/django-auditlog es el que mas se parece a lo q necesita ngen. pero esta justo en medio de actualizaciones al 3 y al 4

django 4 salio hace muy poco asi q todavia no hay muchos paquetes testeados.

los eventos necesitan un estado o bool que permita mergear automaticamente solo si estan abiertos o son de la misma ventana de tiempo o feed

Hace falta un timer y healthcheck de sesión en backgruond para:

• Avisar al usuario que el tiempo de sesión esta venciendo
• Evitar que continue en la pagina con una sesión vencida

Se muestran datos no estando logeado en los Minified:

undefined por unknown.
los closed by o discardad by seran solo closed and discarded

enviar evidencias adjuntadas en los emails de los reportes con el nombre de la evidencia y los datos cronologicos de su evento o caso padre para que sea facil de asocial al momento de interpretar el reporte

se podiran usar bools para poder limitar la modificacion de ciertos edges y q siempre exista un camino valido en el grafo de estados

rdap deberia ser solo bajo demanda y no guardar ni siquiera el host, solo para buscar el contacto,
la funcion de las redes es tener una vision del la comunidad y sus contactos, lo q esta afuera y no es external no deberia ser guardado.
ver si se hace con cotex, pyngen o celery

Me permite ingresar fechas posteriores a la actual.

Crear una base elasticsearch mirror para hacer busquedas y demas.
https://django-elasticsearch-dsl-drf.readthedocs.io/en/latest/
https://github.com/barseghyanartur/django-elasticsearch-dsl-drf

unsolved and unattended se utilizan para abrir y cerrar incidentes automaticamente.

solved y attended son los tiempos minimos y se utilizan solo de forma informativa

investigar alguna manera de registrar eventos falsos positivos y relacionarlos al los Feeds que los reportan

En Reporte el ordenamiento por taxonomía no hace un correcto ordenamiento por el nombre de la taxonomía
Ordenamiento de forma ascendente:

Ordenamiento de forma descendente:

investigar la forma de enviar emails firmados y/o cifrados con PGP
ademas buscar django secret vaults o similares

Al agregar más de un artefacto a la lista de artefactos de evento (probado en editar evento, puede que falle tambien en caso, para creación y edición), se recibe un error 400 en el PUT

Esto se debe a que el frontend esta enviando la lista de artefactos concatenada con , en cada parte artifacts del multipart data:

-----------------------------199869655827211785973560009302
Content-Disposition: form-data; name="date"

2024-04-08T11:41
-----------------------------199869655827211785973560009302
Content-Disposition: form-data; name="priority"

http://localhost:8000/api/administration/priority/1/
-----------------------------199869655827211785973560009302
Content-Disposition: form-data; name="tlp"

http://localhost:8000/api/administration/tlp/1/
-----------------------------199869655827211785973560009302
Content-Disposition: form-data; name="taxonomy"

http://localhost:8000/api/taxonomy/117/
-----------------------------199869655827211785973560009302
Content-Disposition: form-data; name="artifacts"

http://localhost:8000/api/artifact/1/,http://localhost:8000/api/artifact/9/
-----------------------------199869655827211785973560009302
Content-Disposition: form-data; name="feed"

http://localhost:8000/api/administration/feed/1/
-----------------------------199869655827211785973560009302
Content-Disposition: form-data; name="address_value"

1.1.1.9
-----------------------------199869655827211785973560009302
Content-Disposition: form-data; name="case"


-----------------------------199869655827211785973560009302
Content-Disposition: form-data; name="todos"


-----------------------------199869655827211785973560009302
Content-Disposition: form-data; name="comments"


-----------------------------199869655827211785973560009302
Content-Disposition: form-data; name="notes"

TEST1
-----------------------------199869655827211785973560009302
Content-Disposition: form-data; name="reporter"

http://localhost:8000/api/user/1/
-----------------------------199869655827211785973560009302
Content-Disposition: form-data; name="tasks"


-----------------------------199869655827211785973560009302
Content-Disposition: form-data; name="evidence"

[object Object]
-----------------------------199869655827211785973560009302
Content-Disposition: form-data; name="evidence"

[object Object]
-----------------------------199869655827211785973560009302
Content-Disposition: form-data; name="artifacts"

http://localhost:8000/api/artifact/1/,http://localhost:8000/api/artifact/9/
-----------------------------199869655827211785973560009302--

como se ve ahí hay mas de un Content-Disposition: form-data; name="artifacts" con http://localhost:8000/api/artifact/1/,http://localhost:8000/api/artifact/9/

cuando debería ser separado en dos:

-----------------------------199869655827211785973560009302
Content-Disposition: form-data; name="artifacts"

http://localhost:8000/api/artifact/9/
-----------------------------199869655827211785973560009302
Content-Disposition: form-data; name="artifacts"

http://localhost:8000/api/artifact/1/

el objeto Feed es solo un label.
deberia tener un usuario asignado ya que actualmente se crean usuarios para cada feed y no queda bien

UUIDs para casos y eventos. seria una identificacion indirecta .
hay q evaluar el envio de los mismos en los reportes

Cuando se agrega un nuevo elemento a la lista de evidencias, o cuando se manda una lista de evidencias vacía no se reflejan los cambios en el backend.
Ejemplo de eliminación de todas las evidencias:

Al crear un evento me permite poner una fecha posterior a la actual.

Si busco algún tipo de reporte no solo no lo busca si no que además se traba y me inhabilita. Tengo que recargar la página para que vuelva a funcionar.

path: /reports

ver que hay en ngen 1 de este tema e investigar sobre playbooks/task list/ todo list en django 4

investigando cortex para el enriquecimiento de observables.
como almacenar los resultados
como parsear

Al agregar un evento se puede modificar el usuario que reporta, esto no deberia ser modificable en front, solo mostrar el usuario actual sin poder modificarse.
En backend deberia pisar el valor, cual sea que se envie, con el usuario actualmente logueado.

agrgar la posibilidad de enviar reportes/anuncios a la comunidad entera o parcial.
y renotificar casos a partir de cierta cantidad de dias de inactividad (configurable)

En Redes el ordenamiento por entidad está invertido, el ordenamiento ascendente ordena de manera descendente y viceversa para el descendente
Cuando la consulta al backend se realiza de forma ascendente se ve ordenado descendente:

Agregar ordenamiento por fecha de creación de Casos.

hacer templates de casos y eventos con las misma funcion de las deciciones en ngenPHP

1. En Eventos:

1.a. Orden predeterminado: por fecha descendente.

2. En Casos:

2.a. Orden predeterminado: por fecha descendente.

3. En Entidades:

3.a. Ordenar por nombre.
3.b. Orden predeterminado: por nombre ascendente.

4. En Redes:

4.a. Ordenar por entidad.
4.b. Orden predeterminado: por entidad ascendente.

5. En Contactos:

5.a. Ordenar por nombre.
5.b. Orden predeterminado: por nombre ascendente.

6. En Reporte:

6.a. Ordenar por taxonomía.
6.b. Orden predeterminado: por taxonomía ascendente.

7. En Fuentes:

7.a. Orden predeterminado: por nombre ascendente.

8. En Prioridades:

8.a. Orden predeterminado: por nombre ascendente.

9. En Taxonomía:

9.a. Ordenar por cantidad de eventos también.
9.b. Orden predeterminado: por nombre ascendente.

10. En Plantilla:

10.a. Ordenar por taxonomía o fuente.

hasta ahora s utiliza un campo padre y se pasan algunos elementos de los hijos al padre para poder verlos en los listados etc.
pero puede q esto deje intancias hijas vacias u obsoletass.

• se puede usar un campo virtual para listar los campos de los hijos en el padre como evidencias o los eventos en los casos.
• Usar M2M en esas relaciones
• buscar la manera de serializarlos en la vista detail del padre