Joven hacker sonriendo

Estilo

El objetivo del blog de FLUID es compartir opiniones y conocimientos sobre temas de seguridad de forma clara y fácil de entender.

Te invitamos a compartir tus conocimientos con nosotros y el mundo.

El público objetivo son personas que no tienen conocimientos técnicos avanzados. Se debe manejar un lenguaje sencillo pero que aporte conocimientos sobre temas de seguridad.

Temáticas

Los temas del blog están orientados únicamente a temas de seguridad y TI, aunque hay situaciones que aunque no son de seguridad pueden ser tratadas como tal:

  1. Cómo explicarle a un Gerente que debe invertir en la seguridad.

  2. Cómo utilizar un componente específico: Puedes explicar la forma segura de utilizarlo.

  3. Explicación de un concepto resolviendo un reto de seguridad.

También puedes consultar nuestra lista de temas.

Perfil del lector

lector
  • Rango de Edad: 20 – 60 años.

  • Escolaridad: Formación universitaria (Estudios superiores).

  • Cargo: Desde estudiantes hasta Gerentes de Tecnología.

  • Conocimientos: Variados con énfasis en temas de seguridad.

  • Intereses: Temas de tecnología y seguridad informática.

Criterios de aceptación

1. Título

El título del documento debe llamar la atención del lector. No debe exceder los 35 caracteres

  1. Convertir el tema del documento en algo divertido o curioso. Puede ser en modo de pregunta.

    Ejemplos:

    • Deseando la Cookie.

    • Seguridad de la Información ¿Gasto o inversión?

  2. Evitar a toda costa títulos genéricos.

    Ejemplos:

    • Inyección SQL.

    • Vulnerabilidad XSS.

  3. El título debe reflejar el contenido del documento, siempre evitar falsas expectativas.

    Ejemplo: Listas blancas; tu aliado en validación de datos, y hablar en el documento solo sobre inyecciones y no tocar el tema de las listas blancas o como se implementan.

2. Estructura

Todo documento debe tener:

  1. Primera sección: Una introducción que le transmita al lector qué puede esperar del documento que va a leer.

  2. Última sección: Una conclusión corta en donde se indique al lector el tema general.

  3. El documento debe tener una métrica de complejidad LIX inferior a 50, garantizando la lectura simple del texto.

3. Formato

Los documentos serán recibidos únicamente en formato AsciiDoc. Para mayor información consulta nuestra página de formatos, la guía de AsciiDoc, o su quick reference.

4. Límite de palabras

Los documentos tienen límites estrictos en su longitud :

  1. Para documentos tipo KB: Entre 400 y 800 palabras.

  2. Para documentos tipo Post: Entre 800 y 1600 palabras.

  3. Para documentos tipo Página: Entre 400 y 1600 palabras.

5. Saltos de línea semánticos

Los documentos deben incluir saltos de línea semánticos (SLB), para facilitar su posterior edición y llevar un registro ordenado de las modificaciones dentro del sistema de control de versiones (Gitlab). Para ello se definen las siguientes reglas:

  1. Mínimo de palabras antes de un SLB: 4.

  2. Máximo de caracteres antes de un SLB: 80.

  3. Se debe agregar un SLB luego de un punto y seguido (.).

  4. Se puede agregar un SLB después de un conector, dependiendo del contexto, siempre y cuando no incumpla las reglas anteriores.

Las excepciones a éstas reglas son:

  1. Hipervínculos.

  2. Códigos fuente.

Ejemplo:

slb
Figura 1. Ejemplo SLB.

Para mayor información sobre los SLB y cómo utilizarlos, puedes consultar las guías de semantic linefeeds, semantic linewrapping, o la documentación de AsciiDoc

6. Imágenes

  1. Todo documento debe incluir mínimo una imagen relacionada con el tema a tratar.

  2. Las imágenes que no sean propias deben incluir la referencia.

  3. Incluir una descripción de la imagen.

7. Vídeos

  1. Deben ser vídeos propios.

  2. Se deben enviar el medio para subirlo al canal de FLUID en Youtube

  3. El vídeo no puede ir solo, debe tener introducción y conclusión.

8. Fuente

A menos que el lenguaje obligue a lo contrario, el código fuente siempre debe:

  1. Estar en inglés (incluso los comentarios).

  2. Indentar utilizando 2 espacios en lugar de tabulaciones.

  3. Utilizar el estilo de llaves (brace style) stroustrup en su variante sin bloques de una línea (one liners). Ejemplo.

  4. Las líneas no deben superar los 80 caracteres de longitud.

  5. No debe contener comentarios de debug abandonados.

Los fragmentos de código fuente embebidos en documentos siempre deben:

  1. Estar enumerados. Para ello añadir el parámetro linenums al bloque de source.

  2. No debe tener más de 8 líneas.

  3. No está permitido repetir un fragmento que ya se haya usado en la guía.

  4. Añadir las líneas de código al post utilizando un bloque de código, no usar imágenes.

Ejemplo:

example.c
1
2
3
4
5
6
7
8
function cool(x){
  /*Please use SHORT comments in english when necessary.
  You must explain your code in the document*/
  int y;
  y = x + 1;
  return y;
  //And remember, do NOT exceed 8 lines ;)
}

9. Explicaciones de explotación

Para el caso de documentos enfocados en explotación, una vez explicado el procedimiento se recomienda incluir un gif corto demostrando el resultado de lo explicado. Agregar una descripción del gif.

gif
Figura 2. Ejemplo de descripción de explotación.

10. No se permiten

  1. Fragmentos de código fuente que no sean evidencias propias.

  2. Imágenes sin la referencia original.

  3. Explicaciones técnicas que no incluyan temas de seguridad:

    Ejemplo: Introducción a un lenguaje de programación sin incluir cómo programar seguro en el.

11. Metadatos

Los metadatos son variables que se incluyen al inicio del documento las cuales influyen en el renderizado final y en cómo los indexa el motor de búsqueda. Puede encontrar más información de las variables en AsciiDoc pulsando aquí.. A continuación se presenta una tabla con los metadatos obligatorios en un documento:

Tabla 1. Lista de metadatos presentes en un documento.

Metadato

Página

KB

Post

Descripción

:slug:

Si

Si

Si

Enlace donde se encontrará disponible el documento una vez aceptado. El slug debe ser el nombre en minúscula del artículo, sin espacios, preposiciones, conjunciones o conectores y separado por guiones "-".

:description:

Si

Si

Si

Resumen en 250 a 300 caracteres de la idea principal del documento. Esta descripción aparecerá en los resultados de los motores de búsqueda.

:keywords:

Si

Si

Si

Palabras clave del documento a través de las cuales puede ser encontrado por un motor de búsqueda. El documento debe incluir 6 keywords.

:translate:

Si

Si

Si

Atributo que indica si se encuentra disponible una versión traducida del documento dentro de la página de FLUID. En caso afirmativo se debe incluir el slug del documento traducido.

:subtitle:

Si

Si

Si

Subtitulo corto que indique concretamente la finalidad del documento. No debe exceder los 55 caracteres.

:defends:

No

Si

No

Metadato único de artículos en Knowledge Base. El único valor aceptado es yes.

:date:

No

No

Si

Fecha en la que se realizó el documento.

:category:

No

No

Si

Categoría a la que pertenece el documento. Ejemplo: Opinión de seguridad, Buenas Prácticas, etc.

:tags:

No

No

Si

Similar al metadato :keywords: palabras destacables para indexar el documento internamente.

:image:

No

No

Si

Imagen que aparecerá en la vista previa del artículo. Esta imagen deberá tener unas dimensiones de 600 x 200 px y no debe superar los 300 Kb de peso.

:alt:

No

No

Si

Descripción de la imagen de la vista previa.

:author:

No

No

Si

Nombre del autor que aparecerá en la parte superior del documento. Poner únicamente un nombre y un apellido.

:writer:

No

No

Si

Nombre y extensión de la imagen que te representa como autor. La única extensión permitida es PNG.

:name:

No

No

Si

Nombre que aparecerá bajo la imagen del autor. Puede ser tu nombre completo o tu nickname.

:about1:

No

No

Si

Información primaria del autor: formación académica, experiencia, cargo (si aplica).

:about2:

No

No

Si

Información adicional del autor: gustos, intereses, enlaces a blog personal o perfiles.

12. Información Adicional

  1. Si se usan acrónimos se debe incluir entre paréntesis su significado.

  2. Incluir las referencias cuando utilicen fragmentos de fuentes externas.

  3. Los párrafos deben ser originales, no utilizar textos de otras páginas a menos que sean frases puntuales.

  4. Las palabras extranjeras y palabras reservadas utilizadas por fuera de bloques de código deben ir en monospace.

  5. Agregar la línea link: antes de incluir un enlace.

  6. Al incluir una referencia, utilizar como anchor_ID la letra "r", seguida del número de la referencia. utilizar superíndice para citarla.

Ejemplo:

I'm talking about some topic
and now I need to cite a reference <<r# ,^[#]^>>

== References

. [[r#]] link:https://my-url[Fancy name for url].
  1. Para más información sobre AsciiDoc, consulta nuestra página de formatos permitidos y ejemplos.

Autores

Si quieres compartir tus conocimientos y opiniones de seguridad con la comunidad y no haces parte del talento de FLUID puedes ser autor invitado, escribe tu post en el editor que te guste y envíanos todo lo necesario para publicarlo y no olvides enviar con él un párrafo contándonos un poco sobre ti y una imagen que te represente, ya que al final del post se incluirá el perfil del invitado.

invitado
  1. Nombre y Apellido del autor

  2. Descripción Corta mínimo: 15 palabras – máximo 30 . Puede incluir: A que te dedicas, años de experiencia, certificaciones, gustos.

  3. Opcional: enlace a blog personal – githublinkedin

Solicitudes

  1. Si eres parte del equipo de FLUID envía tu documento a través de un Merge Request en formato AsciiDoc cumpliendo todas las reglas anteriormente mencionadas.

  2. Si no eres parte del equipo de FLUID solo debes enviar a communications@fluidattacks.com tu documento, adjuntando todos los archivos necesarios para crear el post. Una vez enviado el documento entrará en proceso de evaluación para definir si es publicado.

Términos y condiciones

  1. FLUID se reserva el derecho de admisión de los documentos enviados.

  2. La revisión es de forma no de fondo, FLUID no evalúa si está de acuerdo o no con la opinión del autor solo revisa que cumpla con las normas descritas anteriormente.

  3. Una vez completado el borrador se debe solicitar la revisión del documento a través del Merge Request para entrar a evaluar el contenido.

Si el documento es aceptado y se decide publicar en el blog el autor cede los derechos patrimoniales del mismo a FLUID; de ser necesario se realizarán cambios de forma sin solicitar permisos al autor del mismo.


Estado de los servicios - Términos de Uso