Preguntas frecuentes

La Fundación LibreKAT trabaja en la seguridad de la información abierta, controlable y verificable. La fundación apoya proyectos, el intercambio de conocimientos y la colaboración en torno a la seguridad digital.

No se trata sólo de software. LibreKAT también quiere contribuir a mejores prácticas laborales, más transparencia y una comunidad en la que las personas puedan mejorar juntas la seguridad digital.

Lea más en Acerca de la Fundación LibreKAT.

La seguridad digital es demasiado importante como para depender completamente de sistemas cerrados, procesos incontrolables o promesas vagas. Las organizaciones deben poder comprender, controlar y mejorar cómo funciona su seguridad.

LibreKAT existe para promover eso. La fundación fomenta la tecnología abierta, el intercambio de conocimientos y la colaboración entre personas que desean aumentar la resiliencia digital.

Lea también ¿Cuáles son los objetivos de la Fundación LibreKAT? y Acerca de la Fundación LibreKAT.

No. LibreKAT es una fundación y no tiene ningún objetivo de lucro. La fundación puede colaborar con empresas, gobiernos, investigadores, voluntarios y organizaciones sociales.

El objetivo principal de la colaboración es contribuir a una seguridad digital abierta, sostenible y verificable.

Lea más en Acerca de la Fundación LibreKAT.

Libre se refiere a la libertad. No sólo el uso gratuito, sino sobre todo la libertad de estudiar, controlar, adaptar y compartir tecnología.

Esto es importante para la seguridad de la información. Si desea confiar en un sistema o método, debe poder ver cómo funciona y cómo se toman las decisiones.

Eso se relaciona con el valores fundamentales de la Fundación LibreKAT.

La Fundación LibreKAT quiere mejorar la seguridad digital fomentando la seguridad de la información abierta, controlable y verificable.

En términos concretos, esto incluye:

• desarrollo y uso de software y hardware de código abierto para infraestructuras digitales seguras;
• transparencia y reproducibilidad en los procesos de seguridad;
• investigación, formación y actividades sobre resiliencia digital;
• conexión entre ciudadanos, empresas, gobierno y organizaciones sociales.

Lea más en Acerca de la Fundación LibreKAT y en página de inicio de la Fundación LibreKAT.

LibreKAT es la base. OpenKAT es un producto de análisis de vulnerabilidades de código abierto.

Los nombres son similares, pero no significan lo mismo. La fundación puede soportar OpenKAT y OpenKAT encaja con la misión de LibreKAT, pero OpenKAT no es la fundación en sí.

Lea más sobre Fundación LibreKAT y OpenKAT.

El código abierto hace posible el control. Las personas pueden ver cómo funciona el software, encontrar errores, sugerir mejoras y reducir la dependencia de un único proveedor.

El código abierto no es una garantía automática de seguridad. Es una condición importante para la transparencia, la cooperación y la restaurabilidad.

Lea más sobre los principios en Acerca de la Fundación LibreKAT.

Los proyectos importantes en este sitio son OpenKAT, MIAUW y OciDeck.

OpenKAT ayuda a visibilizar las vulnerabilidades y los riesgos digitales. MIAUW ayuda a que la investigación sobre seguridad de la información sea verificable y digna de auditoría. OciDeck ayuda con presentaciones estructuradas, informes e intercambio seguro de información.

Lea más sobre OpenKAT, MIAUW y OciDeck.

LibreKAT es para todos los que quieran hacer que la seguridad digital sea abierta, verificable y más explicable.

Piense en profesionales de la seguridad, desarrolladores, administradores, auditores, investigadores, gobiernos, empresas, instituciones educativas, organizaciones sociales y ciudadanos involucrados.

Lea más en Acerca de la Fundación LibreKAT.

Sí. Puedes participar de varias maneras: contribuyendo con código, mejorando la documentación, probando, traduciendo, haciendo preguntas, compartiendo experiencias o ayudando con reuniones y actividades comunitarias.

No es necesario saberlo todo técnicamente para hacer una contribución valiosa. También son importantes las buenas preguntas, la experiencia práctica y las explicaciones claras.

Contáctenos al Contacto.

Esto es posible si la colaboración se ajusta a los objetivos de la fundación. LibreKAT busca colaboración que contribuya a una seguridad digital abierta, sostenible y verificable.

Algunos ejemplos son el intercambio de conocimientos, la investigación, el desarrollo de código abierto, la documentación, la formación o las aplicaciones prácticas de los proyectos.

Consulte también Partners y Contacto.

Los valores importantes son la seguridad, la libertad, la apertura, la soberanía, la integridad, el intercambio de conocimientos, la cooperación, la humanidad y la continuidad.

En lenguaje sencillo: LibreKAT quiere que la seguridad digital sea verificable, justa, sostenible y utilizable para las personas y organizaciones que dependen de ella.

Lea también el artículo Acerca de nuestros valores fundamentales.

Utilice pagina de contacto si tiene alguna pregunta, desea contribuir o discutir la colaboración.

Intenta describir brevemente de qué se trata tu pregunta: fundación, MIAUW, OpenKAT, OciDeck, colaboración, prensa o un aporte técnico. Entonces quedará más claro y más rápidamente quién puede responder.

Una cultura justa es una cultura organizacional en la que las personas pueden informar problemas de seguridad, errores y casi incidentes sin buscar automáticamente a quién culpar. La organización utiliza la información para comprender lo sucedido y mejorar las personas, la tecnología, los métodos de trabajo y la organización.

Eso no significa que todos los comportamientos sean aceptables. Una Cultura Justa deja claro de antemano dónde se encuentran los límites y evalúa el comportamiento de forma cuidadosa, coherente y en contexto. Las normas de aviación europeas definen esto como una cultura en la que los empleados no son castigados por acciones consistentes con su formación y experiencia, mientras que no se toleran negligencias graves ni violaciones intencionadas. Ver Reglamento (UE) 376/2014.

La elaboración moderna proviene de la ciencia de la seguridad que rodea a organizaciones complejas y de alto riesgo. El psicólogo James Reason describió Just Culture en 1997 como parte de una cultura de seguridad informada, además de una cultura de presentación de informes, una cultura de aprendizaje y una cultura flexible.

La aviación en particular puso este principio en práctica. Los accidentes y los cuasi accidentes sólo pueden investigarse cuando los pilotos, los controladores de tránsito aéreo, los técnicos y otros se atreven a compartir información. Por lo tanto, las organizaciones de aviación desarrollaron sistemas de notificación que no castigan automáticamente los errores comunes, pero sí establecen límites para el comportamiento intencional o imprudente. SKYbrary describe este desarrollo; La Unión Europea estableció el principio en Reglas para la notificación de sucesos en la aviación civil. en 2014.

Posteriormente, la Cultura Justa también se ha aplicado en la atención sanitaria, los ferrocarriles, la energía y otros sectores donde es importante aprender de las señales débiles. Por lo tanto, no se trata de un procedimiento aeronáutico que se copia uno a uno, sino de un principio más amplio para afrontar errores y riesgos de forma justa y orientada al aprendizaje.

No. Una Cultura Justa evita que una denuncia honesta, un simple error o una infracción involuntaria conduzcan automáticamente a un castigo. Puede ser necesario asesoramiento, apoyo adicional o un método de trabajo adaptado; Se trata de medidas para garantizar un trabajo seguro, no de castigos automáticos.

En casos de mala conducta intencional, sabotaje, imprudencia deliberada o desprecio grave de un riesgo claro, puede ser apropiado tomar medidas contra una persona. En primer lugar, esto requiere una investigación honesta de los hechos, circunstancias, capacitación, recursos disponibles y decisiones previas comparables. Just Culture tampoco otorga inmunidad legal: la ley aplicable sigue aplicándose. Este saldo se puede encontrar en Artículo 16 del Reglamento (UE) 376/2014.

No. Un modelo completo de “sin culpas” puede dejar fuera de escena la responsabilidad y el comportamiento inaceptable. La Cultura Justa busca un límite justo entre el comportamiento del que la organización debe aprender y el comportamiento del que debe dirigirse a una persona.

La primera pregunta no es “¿a quién podemos castigar?”, sino “¿qué pasó, por qué esta acción parecía lógica en ese momento y qué circunstancias influyeron?”. Sólo entonces surge la pregunta de si el comportamiento se encontraba dentro de los límites previamente conocidos y aplicados de manera consistente.

No. Los empleados siguen siendo responsables de actuar con cuidado, informar y cooperar en las investigaciones. Los gerentes son responsables de objetivos realistas, recursos suficientes, límites claros y reparación de problemas estructurales.

La rendición de cuentas significa que las opciones y circunstancias pueden discutirse y controlarse. Asignar culpas es un juicio sobre la culpabilidad. Una Cultura Justa separa a ambos, de modo que la responsabilidad no desaparezca sino que se distribuya de manera más justa.

El error humano no es intencional. El comportamiento riesgoso puede surgir porque alguien subestima un riesgo, un hábito inseguro se ha vuelto normal o los objetivos entran en conflicto entre sí. La conducta imprudente implica un desprecio consciente y grave de un riesgo evidente. Las acciones intencionalmente dañinas forman otra categoría más.

Estas palabras no son resultados automáticos. Una investigación cuidadosa analiza la capacitación, la información disponible, la carga de trabajo, el diseño técnico, los procedimientos, las señales previas y cómo actuaron otros en la misma situación. La gravedad del daño por sí sola no prueba que la conducta haya sido imprudente.

Los empleados deben informar errores, riesgos y cuasi incidentes de manera oportuna, expresar incertidumbre, cooperar en investigaciones y compartir conocimientos relevantes. Se espera que los gerentes escuchen sin emitir juicios prematuros, protejan a los periodistas, investiguen los hechos y el contexto y proporcionen comentarios sobre lo que sucede con un informe.

La organización debería reparar las causas estructurales, tratar casos comparables por igual y dejar claro de antemano qué comportamiento es inaceptable. Ocultar, tomar represalias, juzgar únicamente el resultado o permitir que continúen los riesgos conocidos no encaja con una Cultura Justa.

La seguridad de la información depende de señales tempranas. Piense en un enlace de phishing abierto, un acceso configurado incorrectamente, un archivo casi filtrado, una solución de emergencia insegura o una vulnerabilidad que alguien descubre accidentalmente. El miedo al castigo o al daño a la reputación puede llevar a que dicha información se comunique demasiado tarde o no se comunique en absoluto.

Una cultura justa reduce ese umbral y permite una investigación y recuperación más rápidas. Esto no reemplaza las medidas de seguridad, la respuesta a incidentes, las obligaciones de informar o las acciones contra el abuso. Garantiza que la organización reciba información más confiable para utilizar esos instrumentos de manera específica.

Las personas trabajan dentro de objetivos, herramientas, procedimientos, presiones de tiempo y limitaciones técnicas. Si varias personas pueden cometer el mismo error, dirigirse a la última persona sola no es una solución completa. Las mismas condiciones pueden causar el problema nuevamente.

Por lo tanto, una Cultura Justa también examina el diseño del sistema, los derechos de acceso, la capacitación, la carga de trabajo, la supervisión, los objetivos conflictivos y las señales previas. Esto no excluye la responsabilidad individual. Impide que una acción humana visible oculte a la vista causas más profundas.

Una prueba de penetración puede afectar el comportamiento de empleados, administradores o proveedores. MIAUW requiere que un hallazgo esté fundamentado con evidencia, alcance y contexto. Por lo tanto, un informe debe describir hechos y consecuencias observables y no atribuir intenciones o culpabilidad personal sin una investigación.

Just Culture ayuda a utilizar el resultado para la recuperación: ¿qué condiciones técnicas u organizativas hicieron posible el problema, qué medida reduce la recurrencia y quién es el propietario de esa medida? Si la acción individual parece apropiada, se requiere un proceso separado y justo; la puntuación de una prueba de intrusión por sí sola no es prueba de ello.

Primero describa qué sucedió de manera demostrable, cuándo, dentro de qué alcance y con qué consecuencias. Luego registre las circunstancias relevantes, como la información disponible, las instrucciones, la carga de trabajo, los derechos de acceso y la seguridad técnica. Deje en claro qué es un hecho, una afirmación y una suposición no confirmada.

Utilice un nombre sólo cuando la identificación sea necesaria y proporcionada. Frases como “una cuenta pudo realizar la acción” suelen ser más informativas que “el empleado X causó el incidente”. Cuando corresponda, brinde a los involucrados la oportunidad de corregir inexactitudes fácticas o contexto faltante.

La responsabilidad individual puede ser necesaria en caso de conducta perjudicial intencionada, sabotaje deliberado, engaño o olvido grave y culpable de un riesgo evidente. Incluso entonces, el fallo debe basarse en hechos, escuchando a ambas partes, reglas conocibles y una respuesta proporcionada.

El efecto de una acción no es suficiente para establecer la culpabilidad. Un pequeño error puede causar accidentalmente daños importantes, mientras que un comportamiento imprudente a veces termina sin daños. Por lo tanto, una cultura justa evalúa el comportamiento y el contexto, no sólo la suerte o la mala suerte en el resultado.

Una Cultura Justa bien aplicada puede aumentar la disposición a informar errores, riesgos y cuasi incidentes. Esto permite a una organización comprender antes las señales débiles, reconocer patrones recurrentes y centrar las medidas en las causas en lugar de solo en la última persona de la cadena.

Otros posibles beneficios incluyen una mayor confianza, mejores conversaciones sobre seguridad, apoyo a los empleados comprometidos y una mejora continua de los procesos. Estos efectos no surgen únicamente de la etiqueta. Un reciente revisión del alcance de 36 intervenciones sanitarias encontró estos resultados, pero también enfatiza que todavía es difícil determinar exactamente qué componentes causan qué efecto. La Cultura Justa es, por tanto, un método de trabajo que apoya el aprendizaje, no una garantía de menos incidentes.

Observe la calidad y distribución de los informes, el tiempo para recibir comentarios, el porcentaje de medidas de mejora completadas, la recurrencia de eventos similares y la imparcialidad percibida de la investigación. Los empleados deben saber dónde están los límites y confiar en que casos similares serán tratados de manera similar.

Un número cada vez mayor de informes puede ser inicialmente una buena señal: la información que antes estaba oculta se vuelve visible. Por lo tanto, el mero recuento de los informes resulta insuficiente. Compruebe también si la organización aprende de ello, apoya a los periodistas, aborda las causas estructurales y motiva las decisiones de forma imitable.

No. La Cultura Justa se desarrolló fuertemente en la aviación y luego se aplicó en la atención médica, entre otros lugares, porque los errores pueden tener consecuencias importantes y la notificación temprana es vital. El núcleo (poder informar de forma segura, evaluar el comportamiento de manera honesta y en contexto y mejorar el sistema) también es útil en la seguridad de la información, el desarrollo de software, los servicios públicos y otras organizaciones en las que las personas trabajan con sistemas complejos.

La elaboración debe adaptarse a la organización. Una pequeña fundación tiene funciones, riesgos y obligaciones legales diferentes a los de una aerolínea. Por lo tanto, adopte los principios, pero cree usted mismo rutas de denuncia, poderes, límites de comportamiento y garantías claras. La reciente [revisión del alcance de la cultura justa en la atención sanitaria] (https://pubmed.ncbi.nlm.nih.gov/41612347/) también muestra que las intervenciones estudiadas varían y que la evidencia sobre una implementación exitosa aún es limitada.

La seguridad psicológica significa que las personas de un equipo se atreven a correr riesgos interpersonales: hacer una pregunta, expresar dudas, admitir un error o dar una opinión diferente. Just Culture es más específico sobre lo que luego hace la organización con un informe o evento: cómo investiga, evalúa el comportamiento, protege a los reporteros, distribuye la responsabilidad e implementa mejoras.

Los conceptos se refuerzan entre sí, pero no son lo mismo. Un equipo agradable sin una evaluación clara y coherente todavía no es Cultura Justa. Por el contrario, un buen documento político no funciona si la gente no se atreve a hablar en la práctica. Las investigaciones sobre seguridad psicológica mencionan como condiciones importantes el liderazgo inclusivo, el apoyo y la orientación al aprendizaje. Véase esta revisión sistemática.

Los gerentes establecen expectativas claras, responden con calma a las malas noticias y se aseguran de que los informes se investiguen de forma independiente y experta. Primero preguntan qué sucedió y qué circunstancias influyeron antes de sacar conclusiones sobre las personas. También liberan tiempo, personal y presupuesto para medidas de mejora y brindan retroalimentación sobre lo que se ha hecho con los informes.

También deben poder investigarse sus propias acciones. Si sólo se aborda a los empleados ejecutivos y las opciones sobre la carga de trabajo, los recursos o las metas poco claras quedan fuera de escena, la cultura no es justa. La Guía AHRQ para la investigación de incidentes basada en sistemas enfatiza tanto el apoyo del liderazgo como la investigación de hechos en lugar de la búsqueda de culpas.

Los empleados informan errores relevantes, cuasi incidentes, condiciones inseguras y dudas de la manera más oportuna y objetiva posible. Participan en investigaciones, también comparten información que puede resultar incómoda y ayudan a realizar mejoras útiles para la práctica diaria. Se acercan a sus colegas con respeto y piden ayuda cuando el conocimiento, el tiempo o los recursos son insuficientes.

La Cultura Justa no exige perfección ni heroísmo. Un empleado sigue siendo responsable de actuar con cuidado dentro de su función, pero la organización sigue siendo responsable de un sistema viable, una formación adecuada y condiciones realistas. Por lo tanto, la responsabilidad se comparte, no se transfiere.

En primer lugar, se protegen las personas y los sistemas y se confirma la recepción del informe. Luego, una persona autorizada determina quién manejará el informe, qué información se necesita y qué confidencialidad se puede brindar. La investigación reconstruye el evento, involucra a las personas relevantes y analiza factores técnicos, humanos y organizativos.

A continuación se registran los resultados y las medidas, los implicados reciben la información adecuada y se controla si las medidas se han aplicado realmente y funcionan. Un informe sin seguimiento visible daña la confianza. La investigación sobre los sistemas de notificación de incidentes advierte que la recopilación por sí sola es insuficiente; son precisamente las acciones de mejora y un ciclo cerrado de aprendizaje los que determinan el valor. Véase esta revisión sistemática.

La investigación comienza con un cronograma y hechos verificables, no con un presunto culpable. Los investigadores hablan respetuosamente con los involucrados, prueban varias declaraciones y examinan procedimientos, capacitación, herramientas, carga de trabajo, comunicación, opciones de diseño y señales previas. Lo que sigue siendo incierto también queda registrado.

Cualquiera que esté personalmente involucrado o tenga un conflicto de intereses no debe decidir el resultado por sí solo. Las personas involucradas deben poder explicar los hechos relevantes y hacer que se corrijan las inexactitudes fácticas. La medida elegida debe ser adecuada a la conducta y las circunstancias y los casos comparables deben ser tratados de manera similar. Mientras tanto, pueden ser necesarias medidas de seguridad urgentes, pero no deben presentarse como un castigo encubierto.

La organización determina de antemano quién evalúa el comportamiento, según qué criterios y con qué posibilidad de contradicción o reconsideración. Dependiendo de la gravedad, puede intervenir un director, un responsable de seguridad, recursos humanos, un experto en la materia, un representante de los empleados o un comité independiente. Las cuestiones jurídicas pertenecen a alguien con la experiencia adecuada.

Los evaluadores no sólo miran el resultado, sino también la previsibilidad, la intención, el conocimiento, la capacitación, las alternativas disponibles y las circunstancias en el momento de la acción. Un resultado grave no demuestra en sí mismo un comportamiento imprudente; un buen resultado no hace que un comportamiento conscientemente peligroso sea aceptable.

No trate la duda como prueba contra la persona en cuestión. Reúna datos adicionales, pida a alguien con conocimientos expertos que analice las opciones reales de acción y pruebe si otros podrían haber tomado una decisión similar en las mismas circunstancias. Distinguir entre lo que es visible después y lo que la persona razonablemente podría haber sabido en ese momento.

Registre la compensación y la incertidumbre restante. Una medida drástica de personal requiere un proceso más riguroso e independiente, con audiencia y oportunidad de reconsideración. Además, resolver las debilidades del sistema de inmediato; El desacuerdo sobre la responsabilidad individual no es razón para que exista un problema de seguridad demostrable.

Los informes confidenciales significan que la identidad solo la conocen las personas que la necesitan para un proceso cuidadoso. La notificación anónima significa que el destinatario no conoce la identidad. La confidencialidad permite más preguntas y comentarios personales; el anonimato puede reducir el umbral si alguien teme represalias o conflictos de intereses.

Ofrezca ambas rutas cuando corresponda y explique honestamente de antemano qué se puede proteger y qué no. No siempre se puede garantizar técnica o legalmente el anonimato completo, y los detalles de un evento pueden hacer que alguien sea reconocible indirectamente. Por tanto, no recopile más datos personales de los necesarios y limite los plazos de acceso y conservación. Las normas de aviación europeas mencionan proteger y eliminar datos de identificación como formas de respaldar la confianza en los sistemas de notificación. Véase la explicación de EASA al Reglamento 376/2014.

La Cultura Justa y la protección de los denunciantes tienen un objetivo relacionado: las personas deberían poder denunciar problemas graves sin verse injustamente desfavorecidas. Sin embargo, legal y prácticamente no son lo mismo. Un acuerdo interno de Cultura Justa nunca puede reemplazar los derechos legales, un canal de denuncia externo o la protección contra represalias.

Asegúrese de que los empleados, contratistas y voluntarios sepan qué canal corresponde a cada informe y dónde pueden obtener asesoramiento independiente. No trates una denuncia como una cuestión de lealtad ni intentes bloquear contractualmente un canal externo legalmente permitido. La protección precisa depende de la ley aplicable. La Directiva de denuncia de irregularidades de la UE incluye normas sobre canales confidenciales, seguimiento y protección contra represalias.

No. Siguen aplicándose las obligaciones de informar de un incidente, violación de datos, sospecha de un delito penal u otro suceso. Un supervisor, juez o empleador autorizado también conserva su función legal. Just Culture no estipula que la información deba permanecer siempre secreta y no otorga inmunidad.

Sin embargo, la Cultura Justa requiere procedimientos claros, proporcionados y consistentes: separar el aprendizaje de la toma de decisiones disciplinarias cuando sea posible, limitar el acceso a la información y explicar cuándo puede ser obligatorio informar. Adaptar el enfoque a la legislación laboral, la legislación sobre privacidad, las normas de denuncia de irregularidades, las normas sectoriales y la participación existente de los empleados. En caso de duda, haga evaluar legalmente la situación específica.

Primero, determine cómo la gente está informando ahora, dónde hay miedo o incertidumbre y cómo se han tratado los casos anteriores. Luego, junto con los empleados y los representantes pertinentes, elabore reglas simples: qué informa, a través de qué canal, quién ve la información, cómo se lleva a cabo la investigación, dónde está el límite de comportamiento y cómo se puede reconsiderar una decisión.

Formar a directivos e investigadores con ejemplos realistas. Practique el proceso, maneje los primeros informes con visible cuidado y publique los puntos de aprendizaje y el progreso de forma anónima. Medir la confianza y dar seguimiento y ajustar el proceso. Es mejor empezar poco a poco y completar que con un programa grande y sin capacidad. EASA aconseja a las organizaciones que incluyan procesos claros de Cultura Justa en sus políticas de seguridad e involucren a los representantes de los empleados. Consulte la Guía EASA para sistemas de informes.

Los errores comunes incluyen: equiparar la cultura justa con nunca hablar, establecer límites solo después de un incidente, confundir la gravedad del resultado con la culpabilidad del comportamiento, examinar solo la última acción humana y tratar casos similares de manera diferente. La difusión de nombres, la filtración de información de informes y un directivo directamente implicado, investigador y tomador de decisiones también dañan la confianza.

Otro error es solicitar informes pero no proporcionar comentarios ni mejoras. El reportero asume entonces el riesgo mientras la organización no cumple la promesa de aprendizaje. El remedio es verificable: roles claros, protección de la información, retroalimentación oportuna, acciones de mejora visibles y pruebas periódicas de coherencia.

Una Cultura Justa orientada a la recuperación no sólo analiza las reglas, las causas y la prevención futura, sino también el daño que las personas y las relaciones han experimentado como resultado de un evento y la respuesta al mismo. Las preguntas incluyen: ¿quién se ha visto afectado, qué necesitan, quién tiene el deber de restaurar algo y cómo se puede reconstruir la confianza de manera responsable?

Esto puede conducir a un reconocimiento, una explicación, una ayuda práctica, un restablecimiento de los acuerdos laborales o una conversación guiada. La participación debe ser cuidadosa y apropiada; la recuperación no debe convertirse en un medio de presión para imponer el perdón, el silencio o la renuncia a derechos. La literatura científica sobre la cultura justa restaurativa está creciendo, pero la [revisión del alcance de 2026] (https://pubmed.ncbi.nlm.nih.gov/41612347/) concluye que la evidencia sobre las intervenciones y la implementación exitosa aún es limitada.

Pregunte por separado qué necesitan los directamente afectados, los periodistas y otras partes involucradas. Piense en información objetiva, una persona de contacto permanente, descanso o tareas adaptadas, apoyo de pares y acceso a ayuda profesional. Explique lo que la investigación puede y no puede hacer y cuándo se proporcionará retroalimentación. Evite la especulación y proteja los datos personales.

El apoyo no es un juicio de culpa y no debe depender del comportamiento posterior. Al mismo tiempo, puede ser necesaria una medida de seguridad temporal, por ejemplo supervisión adicional u otra tarea. Justificar tal medida, limitarla a lo necesario y reevaluarla tan pronto como se conozcan más hechos.

En un casi accidente, algo salió mal o surgió un peligro, pero los daños graves no fueron causados por casualidad, una intervención oportuna o una capa adicional de seguridad. Es entonces cuando una organización puede aprender sin que nadie tenga que soportar primero todas las consecuencias. Los desvíos recurrentes, las instrucciones poco claras y las desviaciones menores también pueden ser señales tempranas de un problema en el sistema.

Por lo tanto, no se pregunte simplemente “¿qué salió mal?”, sino también “¿qué hizo que todo saliera bien?”. y “¿qué barrera funcionó?”. Facilite la presentación de informes y proporcione comentarios. Una revisión sistemática de los cuasi accidentes en el sector sanitario encontró que el apoyo del liderazgo, las rutas simples de denuncia, el conocimiento y una respuesta no punitiva influyen en el comportamiento de denuncia. Consulte la revisión en PubMed.

No limitar Cultura Justa a empleados con contrato indefinido. Proveedores, contratistas, investigadores, pasantes y voluntarios pueden ser los primeros en ver una vulnerabilidad, un error o una situación insegura. Bríndeles una ruta de denuncia comprensible, explíqueles qué protección se aplica y deje claro en los acuerdos quién investigará y brindará comentarios.

La organización no puede controlar unilateralmente todas las leyes laborales o consecuencias contractuales de otra parte. Por lo tanto, acuerde de antemano cómo se protegerá la información, cuándo se compartirá y cómo se evitarán represalias o conflictos de intereses. Además de los empleados, las normas europeas de aviación también se refieren al personal contratado; las normas de denuncia de irregularidades de la UE también pueden incluir, dentro de su alcance, a voluntarios, trabajadores autónomos y contratistas.

No. La soberanía no es autarquía y no requiere independencia total. Las organizaciones y los estados siempre dependen del conocimiento, los proveedores, las materias primas y la cooperación.

El objetivo es que las dependencias sean visibles, manejables y reemplazables cuando sea necesario. Puede subcontratar el trabajo y seguir manteniendo el control, siempre que las responsabilidades, los derechos, el acceso, la continuidad y las opciones de salida estén adecuadamente organizados.

No. Ningún producto puede garantizar la soberanía digital por sí solo. La soberanía surge de la combinación de gobernanza, contratos, jurisdicción, arquitectura, apertura, conocimiento, gestión y alternativas viables.

OpenKAT y OciDeck pueden proporcionar elementos básicos concretos: más conocimiento, verificabilidad, formatos abiertos, autogestión y menos dependencia innecesaria. La organización debe diseñar conscientemente y continuar probando estas opciones.

Registre una medición de referencia y un nivel deseado para cada sistema crítico. Luego mida propiedades concretas, como la proporción de partes de la cadena conocidas, la exportación de datos probados, las claves administradas por el cliente, la recuperación sin proveedores, las interfaces abiertas y el tiempo necesario para cambiar.

Informar también las dependencias restantes y los riesgos aceptados. El progreso no significa que desaparezca toda dependencia, sino que la organización gana más conocimiento, libertad de elección y margen de acción demostrable.

Hacer exigencias antes de la celebración del contrato. Pregunte sobre jurisdicción, propiedad, ubicaciones de datos, subcontratistas, gestión remota, gestión de claves, estándares abiertos, formatos de exportación, derechos de auditoría, continuidad y terminación.

También registre cómo se proporciona la evidencia y cómo se informan los cambios. Una marca de calidad o una afirmación de marketing general no reemplaza un acuerdo verificable. Utilice los objetivos del ECSF y los niveles SEAL como lenguaje común cuando corresponda.

No. El almacenamiento de datos europeo es relevante, pero no lo dice todo sobre jurisdicción, propiedad, gestión, acceso a claves, subcontratistas y dependencia técnica.

Por lo tanto, evalúe toda la estructura: ¿qué entidades brindan el servicio, qué derechos se pueden invocar, quién puede realizar acciones de gestión, quién administra las claves de cifrado y qué opciones de salida están disponibles?

Sí. La dependencia puede afectar la disponibilidad, integridad y confidencialidad de la información. Considere la falla o terminación de un servicio, acceso no deseado bajo un sistema legal diferente o cambios que la organización no puede controlar por sí misma.

Por eso la soberanía reside en la regulación, la organización y la tecnología: las tres partes interrelacionadas descritas en el libro como ROT. No es una cuestión política aparte de la seguridad de la información.

No cuando los requisitos apuntan a riesgos manejables y se aplican por igual y de manera verificable a todos los proveedores. El proteccionismo protege principalmente la propia industria; La política de soberanía protege el control, la continuidad, la integridad y la confidencialidad.

Por lo tanto, la nacionalidad por sí sola es un criterio débil. La jurisdicción, los acuerdos ejecutables, el aislamiento técnico, la apertura y las opciones de salida son más sustanciales.

No. Un nombre o ubicación europea no es una garantía completa. Un proveedor europeo también puede ser absorbido, declararse en quiebra, depender en gran medida de tecnología no europea o ofrecer garantías contractuales deficientes.

Observe las características estructurales controlables: propiedad y control, ley aplicable, gestión y acceso a claves, dependencias de la cadena, estándares abiertos y un plan de salida ejecutable.

No. El código abierto proporciona derechos importantes para estudiar software, modificarlo y hacer que otros lo mantengan. Por lo tanto, puede apoyar la transparencia, la reemplazabilidad y la creación de conocimientos.

Pero esos derechos sólo tienen valor práctico si hay documentación, personas, gestión, financiación, actualizaciones seguras y acceso a los propios datos. El código abierto también puede depender de un mantenedor, un servicio de nube cerrado o una infraestructura que es difícil de reemplazar.

No. La soberanía depende del contexto. El nivel deseado surge de la criticidad del proceso, la sensibilidad de los datos, los requisitos legales, el apetito de riesgo y las alternativas disponibles.

El nivel más alto para todos los sistemas puede resultar innecesariamente costoso o inviable. Una elección motivada por sistema es más fuerte que un objetivo general sin prioridades.

No es necesario. Los requisitos de interoperabilidad, transparencia, seguridad y reemplazabilidad pueden en realidad estimular la innovación porque los nuevos proveedores pueden conectarse más fácilmente y los clientes quedan menos atrapados.

Existen compensaciones reales en torno al costo, la velocidad y la funcionalidad. Estos deben hacerse explícitos. El contraste entre “innovación o soberanía” es demasiado simple; se trata de innovación responsable dentro de un perfil de riesgo elegido.

Comience con conocimiento. Cree una descripción general de los procesos, datos, sistemas, proveedores, subcontratistas, acceso de gestión, jurisdicción aplicable y opciones de salida existentes.

Luego vincule las dependencias más importantes con la disponibilidad, la integridad y la confidencialidad. Sólo cuando esté claro qué es crítico y de qué depende, se podrá elegir un objetivo y las medidas adecuadas.

El libro ¡Soberanía! ¿Cómo? analiza el desarrollo histórico, la relación con la seguridad de la información, el ECSF, los argumentos del debate y un camino práctico de crecimiento para las organizaciones.

El mensaje central tiene los pies en la tierra: la soberanía no es un concepto de todo o nada ni un proyecto aislado. Es la organización permanente de conocimiento, dirección y espacio para la acción.

El concepto tomó forma en Europa a finales de la Edad Media y principios de la Edad Moderna. En el siglo XVI, Jean Bodin describió un poder estatal supremo y permanente. La Paz de Westfalia de 1648 vinculó entonces fuertemente la soberanía a los estados territoriales y el principio de no interferencia.

Posteriormente, la legitimidad pasó de los monarcas al pueblo y los estados comenzaron a ejercer poderes de manera conjunta, por ejemplo dentro de la Unión Europea. La historia muestra que la soberanía siempre gira en torno a la misma pregunta central: ¿quién tiene en última instancia la última palabra?

Porque la soberanía no se trata sólo de probabilidad, sino también de impacto y capacidad de acción. Un evento puede ser improbable y aun así tener consecuencias inaceptables para un proceso crítico.

Además, la dependencia ya puede tener influencia sin llegar a bloquear el acceso. La posibilidad de sanciones, órdenes legales o despidos puede cambiar el espacio de toma de decisiones y negociación.

Los gobiernos, las empresas y las organizaciones sociales se han vuelto altamente dependientes de un pequeño número de proveedores de nube, software de oficina, comunicaciones e inteligencia artificial. Al mismo tiempo, la propiedad, la legislación, las sanciones, las adquisiciones y las relaciones geopolíticas pueden cambiar.

Como resultado, el control formal puede entrar en conflicto con la dependencia real. La pregunta urgente no es sólo si un proveedor es confiable hoy, sino también si la organización aún podrá actuar mañana si las reglas, el acceso o los intereses cambian.

Distinguir entre funciones verdaderamente indispensables y dependencias que han surgido debido a la costumbre, la falta de conocimientos o viejas elecciones. Mapee concretamente conexiones, formatos de datos, licencias, procesos y habilidades.

Luego practicar la exportación, la recuperación y las alternativas antes de que haya una crisis. Un plan de salida que nunca ha sido probado ofrece poca certeza. A veces, la migración completa no es factible de inmediato, pero los formatos abiertos, la arquitectura modular y una segunda ruta de implementación ya pueden mejorar la posición.

Entonces es aconsejable un enfoque gradual. Primero determine para qué procesos la dependencia representa el mayor riesgo y qué funciones son realmente necesarias. Luego mejore los contratos, la arquitectura y la portabilidad, y migre cuando haya una alternativa adecuada disponible.

El hecho de que una alternativa sea menos madura hoy en día es un argumento sobre el ritmo y la ejecución, no automáticamente una razón para ignorar el riesgo. Por lo tanto, el libro analiza una vía de crecimiento en lugar de una gran transición.

La soberanía digital es el grado en que un gobierno u organización realmente mantiene el control sobre sus funciones, datos y dependencias digitales. Los derechos formales y las opciones reales de acción cuentan.

Las preguntas específicas son: ¿dónde se encuentran los datos, quién puede acceder a ellos, qué ley se aplica, quién administra las claves, puede continuar el servicio en caso de conflicto y es realmente posible cambiar?

El ECSF es un marco europeo de evaluación de la soberanía de la nube. Ayuda a las organizaciones públicas a describir los riesgos de soberanía, establecer requisitos de compra y comparar la situación actual y la deseada.

El marco desvía la conversación de afirmaciones generales, como “europeo” o “soberano”, a propiedades comprobables. Analiza la jurisdicción, los datos, las operaciones, las cadenas, la tecnología, la seguridad y la sostenibilidad, entre otras cosas.

La soberanía se trata de autoridad y dirección: ¿quién tiene la última palabra y asume la responsabilidad? La autonomía se trata de la capacidad práctica de actuar de forma independiente y utilizar alternativas.

Una organización puede estar autorizada formalmente pero tener poca autonomía si técnicamente no puede realizar el cambio o si sólo un proveedor puede gestionar el sistema. La soberanía sin suficiente margen de acción queda en gran medida en el papel.

La soberanía es la autoridad para tomar decisiones vinculantes y asumir la responsabilidad de ellas. En entornos digitales, la pregunta principal es quién decide en última instancia sobre los datos, la infraestructura, la tecnología y el acceso.

No significa que una organización tenga que construir o gestionar todo por sí misma. Sin embargo, debe poder tomar decisiones conscientes, hacer cumplir acuerdos y actuar cuando las circunstancias cambian. El libro ¡Soberanía! ¿Cómo? Esto funciona como una cuestión administrativa práctica.

Los niveles SEAL describen niveles crecientes de soberanía en la nube. El nivel 0 es una nube pública estándar sin medidas de soberanía adicionales; El nivel 4 representa un entorno altamente soberano con autonomía demostrable.

Los niveles no son una calificación para un proveedor. Ayudan a una organización a determinar un nivel actual apropiado (IST) y un nivel deseado (SOLL) por aplicación. Por lo tanto, a un sistema crítico se le puede dar un propósito superior al de un servicio público o fácilmente reemplazable.

El código abierto puede ayudar porque una organización puede estudiar el software, hacer que otra parte lo revise, ajuste y mantenga. Por lo tanto, los derechos abiertos apoyan la transparencia, la reemplazabilidad y el desarrollo del propio conocimiento.

El código abierto no es una garantía automática de soberanía. El valor práctico también depende de la documentación, las personas, la gestión, la financiación, las actualizaciones seguras, los formatos de datos abiertos y la infraestructura en la que se ejecuta el software.

El ECSF distingue ocho objetivos interrelacionados: soberanía estratégica; soberanía jurídica y jurisdiccional; soberanía de datos e inteligencia artificial; soberanía operativa; soberanía en cadena; soberanía tecnológica; soberanía de seguridad y cumplimiento; y soberanía sustentable.

Esta clasificación evita que una característica, como la ubicación de un centro de datos, se utilice erróneamente como prueba de la soberanía total. Un servicio puede marcar fuerte en un gol y débil en otro.

OciDeck respalda la soberanía de la información y la tecnología al permitir que el contenido de la presentación permanezca en Markdown legible. Los formatos abiertos hacen que el contenido sea más controlable, reutilizable y portátil que cuando está contenido únicamente en un formato de aplicación cerrado.

El procesamiento local, la exportación de HTML sin conexión y las funciones de privacidad y uso compartido dirigido pueden reducir la dependencia de servicios de presentación de terceros y la distribución accidental. La soberanía última también depende del almacenamiento, la gestión y las elecciones del usuario. Lea más en OciDeck.

OpenKAT ayuda principalmente con la soberanía operativa, tecnológica y de seguridad. Reúne objetos digitales, relaciones, observaciones y hallazgos para que una organización pueda comprender y monitorear mejor su propio entorno y riesgos.

Debido a que OpenKAT es de código abierto y puede ejecutarse por sí misma, una organización puede monitorear su funcionamiento y elegir quién administra el sistema. OpenKAT no proporciona una soberanía completa: siguen siendo necesarios una gestión, un alcance, una protección de datos, un conocimiento y un seguimiento cuidadosos. Lea más en OpenKAT.

Un enfoque útil es: 1. inventariar procesos, datos y dependencias; 2. determinar el nivel deseado de soberanía por sistema; 3. mejorar las compras, los contratos, la arquitectura, el conocimiento y las alternativas; 4. Comprobar periódicamente si las medidas siguen funcionando y realizar ajustes.

Trate esto como un ciclo. Proveedores, propiedad, legislación y cambio tecnológico. Por lo tanto, una evaluación única rápidamente queda obsoleta.

La junta es en última instancia responsable de la dirección, el apetito por el riesgo y la aceptación del riesgo residual. Las compras, los asuntos legales, la seguridad de la información, la arquitectura, la privacidad, la gestión y el propietario del proceso proporcionan una parte necesaria del panorama.

Dado que las elecciones suelen tener consecuencias duraderas, el libro llama a la soberanía “chefsache”. El tema no puede limitarse únicamente a la tecnología o la gestión de contratos.

El código abierto es una forma de concesión de licencias. El creador o titular de los derechos da permiso a otros por adelantado para usar, estudiar, copiar, distribuir y adaptar la obra.

El derecho a hacer ajustes es esencial. Si no se permite la modificación, no es de código abierto.

El núcleo es legal. El código abierto trata sobre la forma en que se ejercen los derechos de autor: a través de una licencia que otorga amplios derechos de uso.

Puede que detrás de esto haya ideas técnicas y sociales, pero sin una licencia adecuada algo no es código abierto.

Significa que el titular de los derechos da permiso para usar, estudiar, copiar, distribuir y modificar el código fuente a través de una licencia de código abierto.

El software permanece protegido por derechos de autor. La licencia determina qué derechos y condiciones se aplican.

El código abierto y el software libre tienen que ver con derechos: usar, estudiar, compartir y adaptar. El software gratuito generalmente significa simplemente que algo es de uso gratuito.

Dominio público significa que ya no existe ninguna restricción de derechos de autor, o que el titular de los derechos ha renunciado a ella en la medida de lo legalmente posible. Eso es diferente del código abierto.

No. El código abierto otorga muchos derechos, pero siempre dentro de los términos de la licencia.

Estas condiciones pueden, por ejemplo, referirse a la atribución, conservar los textos de la licencia o compartir cambios bajo la misma licencia.

El creador o titular de los derechos sigue siendo el propietario de los derechos de autor, a menos que ese derecho haya sido transferido.

El código abierto no significa que no haya propietario. Significa que el propietario otorga amplios derechos a otros a través de una licencia.

Sí. El código abierto no excluye el uso comercial. Una empresa puede utilizar código abierto, vender servicios de código abierto u ofrecer software de código abierto.

El modelo de precios e ingresos están separados de los derechos de código abierto.

El código abierto se refiere a los derechos sobre una obra, generalmente software. Los estándares abiertos se refieren a acuerdos, especificaciones o protocolos que pueden ser utilizados por múltiples partes.

Pueden reforzarse mutuamente, pero son cosas diferentes.

Una licencia de código abierto es un permiso previo otorgado por el titular de los derechos. Indica lo que otros pueden hacer con el trabajo y qué condiciones se aplican.

Sin dicha licencia, se siguen aplicando los derechos de autor normales y, por lo general, no se permite la reutilización.

Porque los derechos de autor surgen automáticamente. En principio, cualquiera que cree un texto, diseño o software tiene derechos sobre él.

Una licencia deja claro qué permiso reciben los demás. Con el código abierto, este permiso es amplio y está organizado de antemano.

El código es entonces visible, pero no de uso gratuito automáticamente. La visibilidad no es consentimiento.

Sin una licencia, otra persona generalmente no puede copiar, distribuir o modificar el código, excepto en excepciones legales limitadas.

Las licencias permisivas brindan mucha libertad y normalmente imponen condiciones limitadas, como la atribución y retención del texto de la licencia.

Las licencias Copyleft también otorgan amplios derechos, pero pueden requerir que las obras derivadas se distribuyan bajo la misma licencia o una similar.

El copyleft es un principio de concesión de licencias en el que se debe transmitir la libertad. Cualquiera que distribuya la obra, a menudo en forma adaptada, debe conceder a otros los mismos derechos.

Por lo tanto, no se trata de una renuncia a derechos, sino más bien de una forma activa de utilizar los derechos para mantener la apertura.

Eso depende de la licencia y de lo que hagas. Algunas licencias copyleft pueden requerir divulgación si distribuye software modificado.

Sólo el uso interno no suele dar lugar automáticamente a dicha obligación, pero el resultado exacto depende de la situación y de la licencia.

Sí, muchas licencias de código abierto permiten el uso comercial. Esa es precisamente una característica del código abierto.

Sin embargo, debe cumplir con las condiciones de la licencia. Considere mencionar su nombre, textos de licencia o condiciones de distribución.

Sí, el código abierto debería permitir la personalización. También es posible la venta, siempre que se cumplan las condiciones de la licencia.

Algunas licencias requieren que usted proporcione o ponga a disposición el código fuente modificado cuando distribuya el trabajo modificado.

Estas son formas de mantener visibles al creador original y la licencia. Atribución suele significar atribución. Un archivo de aviso contiene avisos legales. El encabezado de la licencia suele estar en la parte superior de un archivo.

Estas obligaciones garantizan que los derechos y el origen sigan siendo reconocibles.

Una cláusula de patente garantiza que los usuarios también reciban permiso de los contribuyentes para patentes relevantes bajo ciertas condiciones.

Esto puede ser importante porque el software puede verse afectado no sólo por los derechos de autor, sino también a veces por los derechos de patente.

El principal riesgo es que no se cumplan las condiciones de la licencia. Entonces es posible que esté utilizando la obra sin un permiso válido.

Esto puede dar lugar a obligaciones de reparación, reclamaciones legales, daños a la reputación o problemas con las ventas, licitaciones o auditorías.

El cumplimiento del código abierto significa que una organización sabe qué código abierto utiliza, qué licencias lo acompañan y qué obligaciones se aplican.

Se trata principalmente de una gestión jurídica y organizativa normal: registrar, comprobar, cumplir y poder explicar lo que se ha utilizado.

No, no por la naturaleza de código abierto. La seguridad depende del diseño, mantenimiento, control, uso y seguimiento de las vulnerabilidades.

La apertura permite el control, pero no es una garantía automática de seguridad.

No. A menudo todos pueden hacer propuestas, pero eso no significa que todos puedan simplemente hacer cambios.

Para proyectos serios, los administradores evalúan qué contribuciones se incluyen. La confiabilidad depende de la gobernanza y el mantenimiento, no solo del tipo de licencia.

No. El apoyo puede ser voluntario, impulsado por la comunidad o comercial. Muchas empresas ofrecen soporte pago para código abierto.

La licencia determina los derechos sobre la obra; El soporte es un servicio separado.

No. El código abierto se trata de derechos de uso, no de precio.

La descarga de un producto de código abierto puede ser gratuita, pero el soporte, el alojamiento, la certificación, la capacitación o la personalización pueden ser de pago.

No. Gratis se trata de precio. Gratis se trata de derechos.

Un producto gratuito puede cerrarse estrictamente. Un producto de código abierto otorga derechos para usar, estudiar, compartir y modificar.

No. El código abierto lo pueden crear voluntarios, pero también empresas, gobiernos, universidades y fundaciones.

La licencia no dice nada sobre profesionalismo. Hay que evaluar esto en función de la calidad, la gestión y el contexto.

No. El código abierto puede ser muy profesional y el software comercial puede tener un mantenimiento deficiente. Lo contrario también es posible.

El profesionalismo es evidente en el mantenimiento, la documentación, la gobernanza, la calidad y los acuerdos, no solo en las licencias abiertas o cerradas.

La apertura significa que todos pueden mirar, incluidos los malintencionados. Pero también significa que es posible el control por parte de usuarios, investigadores y proveedores.

La seguridad no proviene únicamente del secreto. Requiere mantenimiento, respuesta y uso cuidadoso.

No. Los derechos legales son relevantes para todos: usuarios, administradores, compradores, abogados, auditores y responsables políticos.

Los desarrolladores suelen trabajar con el código, pero las organizaciones también se benefician de la transparencia, la libertad de elección y la auditabilidad.

Esto puede ser una compensación, pero no es automáticamente una desventaja. El código abierto consiste en determinar conscientemente qué partes desea compartir y bajo qué condiciones.

A veces, el intercambio abierto es estratégicamente útil, por ejemplo para promover la colaboración, la confianza o la estandarización.

Eso varía según el proyecto. El control puede provenir de mantenedores, usuarios, investigadores de seguridad, auditorías, escaneos automáticos y organizaciones que implementan el software.

El código abierto hace posible ese control, pero no lo organiza por sí solo.

Eso depende de la situación. Los administradores del proyecto pueden crear una actualización, pero el usuario u organización también debe aplicar esa actualización.

El código abierto no cambia el hecho de que cualquiera que utilice software sigue siendo responsable de una gestión cuidadosa.

Eso varía mucho. Los proyectos activos pueden responder rápidamente; No abandones los proyectos. Lo mismo se aplica también al software cerrado.

Por lo tanto, no sólo observe la licencia, sino también el mantenimiento, el proceso de generación de informes y las prácticas de liberación.

Los riesgos de la cadena de suministro surgen cuando se depende de piezas de otros. Si dicha parte es vulnerable, maliciosa o está mal mantenida, esto puede tener consecuencias para su propio producto.

Este riesgo no es exclusivo del código abierto, pero el código abierto a menudo hace que las dependencias sean más visibles.

Las dependencias son partes en las que se basa un producto. En el caso del software, suelen ser bibliotecas o paquetes de otros.

Son importantes porque los derechos, las vulnerabilidades y el mantenimiento de esas partes también influyen en su propio uso.

Mira la licencia, el mantenimiento, la documentación, cómo se revisan los cambios y cómo se manejan las alertas de seguridad.

La confiabilidad es una combinación de claridad jurídica, calidad y gestión.

Las señales saludables son información clara sobre licencias, actualizaciones recientes, documentación comprensible, un proceso de presentación de informes activo y una toma de decisiones visible.

También ayuda que varias personas u organizaciones contribuyan, para que el proyecto no dependa completamente de una sola persona.

Busque versiones antiguas, notificaciones sin respuesta, información de licencia faltante, mantenedores poco claros o falta de respuesta a problemas de seguridad.

Estos son los riesgos del proyecto. Ocurren en software abierto y cerrado, pero en código abierto suelen ser más visibles.

Durante una auditoría de seguridad, alguien evalúa específicamente si existen vulnerabilidades o puntos débiles. Con el código abierto, el código fuente se puede examinar directamente.

Una auditoría es una instantánea. El mantenimiento y el seguimiento seguirán siendo necesarios.

Un SBOM es una lista de materiales de software: una descripción general de los componentes de software usados.

Esta descripción general ayuda a gestionar licencias, vulnerabilidades y dependencias. Es especialmente útil para organizaciones que necesitan poder explicar lo que están utilizando.

Un proyecto de código abierto se crea cuando un titular de derechos publica un trabajo bajo una licencia de código abierto. Esto incluye a menudo documentación, un lugar para las contribuciones y una forma de toma de decisiones.

La licencia es la base legal; la comunidad y el método de trabajo determinan cómo el proyecto continúa creciendo.

Esto normalmente lo hacen los mantenedores o administradores del proyecto. Evalúan si una contribución está en consonancia con la calidad, la dirección y los acuerdos del proyecto.

El código abierto no significa que cada cambio pase automáticamente a formar parte del proyecto oficial.

Un mantenedor es alguien que gestiona un proyecto. Esa persona o grupo revisa las contribuciones, realiza publicaciones, monitorea la dirección y mantiene la documentación o los procesos.

En el código abierto, este papel es importante porque los derechos son amplios, pero la colaboración aún requiere organización.

Un colaborador es alguien que contribuye a un proyecto. Esto podría ser código, pero también problemas de documentación, traducción, pruebas, diseño, explicación o informes.

Por lo tanto, las contribuciones del código abierto son más amplias que la programación.

Una bifurcación es tu propia copia de un proyecto en la que alguien puede seguir trabajando de forma independiente. Esto es posible porque el código abierto permite su modificación y distribución.

A veces una mejora se refleja posteriormente en el proyecto original. A veces una bifurcación crece en su propia dirección.

Esa es una propuesta para incluir un cambio en un proyecto. El administrador puede revisar, discutir, ajustar o rechazar el cambio.

Es una forma práctica de organizar la colaboración en torno al código abierto.

La gobernanza comunitaria se trata de los acuerdos con los que un proyecto toma decisiones. Considere quién puede participar en la toma de decisiones, cómo se resuelven los conflictos y cómo se nombran nuevos administradores.

La licencia otorga derechos; La gobernanza regula la cooperación.

En los proyectos liderados por la comunidad, el control recae principalmente en una comunidad de participantes. En los proyectos liderados por empresas, ésta suele desempeñar un papel importante o decisivo.

Ambas formas pueden funcionar bien, siempre que quede claro quién decide y bajo qué condiciones.

Eso depende de la gobernanza. Algunos proyectos tienen reglas de decisión, códigos de conducta o fundamentos claros. Otros proyectos son más informales.

Los buenos acuerdos son importantes porque los derechos abiertos no significan automáticamente que todos estén de acuerdo.

Los proyectos se detienen cuando los mantenedores se quedan sin tiempo, falta financiación, la necesidad desaparece o surge una mejor solución.

Esto no es exclusivo del código abierto. La diferencia es que con el código abierto, otros a veces pueden continuar con una bifurcación.

Las empresas no necesariamente ganan dinero vendiendo exclusivamente el código, sino con los servicios que lo rodean. Considere alojamiento, soporte, implementación, gestión, capacitación, certificación o personalización.

La licencia abierta y el modelo de negocio son dos capas diferentes.

Los modelos comunes incluyen soporte pago, alojamiento administrado, consultoría, certificación, capacitación, licencia dual y núcleo abierto.

El punto de partida suele ser el siguiente: los derechos básicos están abiertos, pero se puede pagar por la comodidad, la seguridad o los servicios adicionales.

Núcleo abierto significa que el núcleo de un producto es de código abierto, mientras que algunas funciones adicionales son cerradas o de pago.

Eso puede funcionar, pero requiere una comunicación clara. Los usuarios necesitan saber qué parte está abierta y cuál no.

La doble licencia significa que el mismo trabajo está disponible bajo dos licencias diferentes. Por ejemplo, una licencia de código abierto y una licencia comercial.

Esto puede dar a las organizaciones una opción, pero sólo es posible si el titular de los derechos tiene derecho a ofrecer ambas licencias.

Alojamiento administrado o SaaS significa que alguien ofrece software de código abierto como servicio. De este modo, el usuario no tiene que instalar ni gestionar el software por sí mismo.

El software puede ser de código abierto, mientras que el servicio que lo rodea es de pago.

Las empresas pueden hacer esto para aumentar la confianza, estimular la colaboración, establecer un estándar o acelerar la adopción.

El código abierto también puede ayudar a reducir la dependencia de un único proveedor y construir un ecosistema.

Porque a otros se les permite aprovechar el trabajo existente. No tienen que empezar de nuevo y pueden compartir mejoras.

La licencia hace que esa colaboración sea legalmente posible.

El código abierto puede reducir la dependencia de un proveedor porque los usuarios tienen derechos para estudiar el software, modificarlo y gestionarlo en otro lugar.

Esto no significa que el cambio sea siempre fácil, pero la base jurídica es menos cerrada.

El código abierto es interesante cuando la colaboración, la transparencia, la verificabilidad, la reutilización o la independencia son importantes.

Es especialmente fuerte en infraestructura compartida, valores públicos y situaciones donde la confianza requiere más que una promesa de un proveedor.

El código abierto es menos adecuado cuando el titular de los derechos quiere limitar la distribución, el acceso o la modificación. Ésa es una elección estratégica sobre el control.

También es menos apropiado si una organización quiere otorgar derechos sin estar preparada para registrar claramente las condiciones y la gestión de la licencia.

Las empresas emergentes pueden aprovechar los componentes existentes más rápidamente y ganar confianza más fácilmente a través de la apertura. También pueden desarrollar una comunidad o mercado en torno a un proyecto abierto.

Deben ser conscientes de las licencias, el posicionamiento y su modelo de ingresos.

Para los gobiernos, el código abierto puede contribuir a la transparencia, la auditabilidad, la reutilización y una menor dependencia de un solo proveedor.

Esto encaja bien con la responsabilidad pública, siempre que la gestión, la seguridad y el cumplimiento legal se organicen adecuadamente.

La educación puede utilizar el código abierto para aprender de ejemplos reales, compartir materiales y permitir que los estudiantes contribuyan a proyectos existentes.

Dado que se permite la adaptación, los materiales o el software didácticos pueden alinearse mejor con la práctica educativa.

El código abierto puede ayudar porque las organizaciones no dependen completamente del conocimiento cerrado o de un solo proveedor. Pueden comprobar cómo funciona algo y ajustarlo.

La soberanía requiere algo más que código abierto, pero los derechos abiertos son un componente importante.

El código abierto hace visible bajo qué condiciones se puede utilizar una obra y, en el caso del software, cómo es el código fuente.

Esto facilita el control y la explicación. La transparencia sólo surge realmente cuando la documentación y la gobernanza también son claras.

Debido a que otros pueden usar y adaptar el trabajo existente, no todos tienen que recrear lo mismo.

Esto puede reducir el desperdicio y compartir el mantenimiento, especialmente cuando varias partes tienen el mismo problema.

El código abierto muestra cómo funciona una organización, qué calidad busca y qué representa. Las personas pueden contribuir o enterarse fácilmente de lo que está sucediendo.

Esto puede resultar atractivo para los profesionales que valoran la apertura y la artesanía.

Los competidores pueden colaborar en piezas que todos necesitan, sin que esas piezas tengan que ser el producto distintivo.

La licencia proporciona claridad de antemano sobre los derechos, de modo que la colaboración depende menos de acuerdos separados.

La infraestructura pública requiere confianza, continuidad y verificabilidad. El código abierto puede ayudar porque la base no está completamente a puertas cerradas.

Esto hace más posible el control independiente y el mantenimiento conjunto.

En estas áreas, el código abierto puede contribuir a la verificabilidad, la reutilización y la investigación independiente.

Al mismo tiempo, siguen siendo necesarios la buena gobernanza, la gestión de datos, la seguridad y la evaluación jurídica. El código abierto es un requisito básico para ciertas formas de control, no una solución total.

Empieza por la licencia: ¿está permitido el uso que tienes en mente? Luego mire el mantenimiento, la documentación, la calidad y las dependencias.

Un paquete popular no es automáticamente adecuado. La elección debe ajustarse al propósito, riesgo y gestión.

Consulta la licencia, origen, estado de mantenimiento, vulnerabilidades y necesidad. Pregunte también si la pieza es realmente necesaria.

Cada dependencia suma derechos, obligaciones y gestión.

Registre qué componentes se utilizan, qué versión, qué licencia y en qué está incluido el componente.

Asegúrese también de que quede claro quién es el responsable de las actualizaciones y del cumplimiento de las condiciones.

Utilice una combinación de herramientas de registro, verificación periódica y escaneo de dependencias.

Lo más importante: acordar quién revisará las notificaciones y quién decidirá sobre las actualizaciones o reemplazos.

Existen muchas herramientas que mapean dependencias, licencias y vulnerabilidades. Los ejemplos incluyen escáneres en plataformas de desarrollo, administradores de paquetes y herramientas de cumplimiento especializadas.

La herramienta es sólo una herramienta. La organización todavía tiene que tomar decisiones y organizar el seguimiento.

Lea primero las instrucciones de contribución y la licencia. Describe claramente qué quieres mejorar y por qué.

Una buena contribución puede ser código, pero también documentación, pruebas, traducción o un problema claramente descrito.

Esto tiene sentido si desea que otros puedan usar, monitorear, compartir y modificar el trabajo.

Haga esa elección conscientemente: determine el propósito, la licencia, el mantenimiento, la gobernanza y lo que espera o no de las contribuciones.

Primero decide qué quieres permitir y proteger. Si desea una reutilización amplia, busque licencias permisivas. Si quieres que se transmita la libertad, mira el copyleft.

Preferiblemente utilice licencias conocidas y existentes en lugar de escribir el texto usted mismo.

Proporcione documentación clara, una forma amigable de hacer preguntas, toma de decisiones clara y expectativas realistas.

Una comunidad no se crea simplemente poniendo código en línea. Requiere atención, confianza y mantenimiento.

Dividir derechos y responsabilidades. Documente los procesos, haga que las publicaciones sean portátiles y otorgue derechos de gestión a múltiples personas de confianza.

Esto aumenta la continuidad y hace que el proyecto sea menos vulnerable.

Una Oficina de Programas de Código Abierto, a menudo llamada OSPO, es un equipo o función que organiza el uso y las contribuciones del código abierto dentro de una organización.

Ayuda con políticas, licencias, colaboración, comunidades y publicación responsable.

Como mínimo, se necesitan políticas de uso, contribución, publicación, control de licencias y seguimiento de seguridad.

La política debe ser práctica: la gente debe saber qué está permitido, cuándo pedir consejo y quién decide.

Explique en lenguaje sencillo qué significan los derechos de autor, las licencias y las obligaciones. Utilice ejemplos de su propio trabajo.

La formación no sólo debe ser jurídica, sino también práctica: ¿qué registras, qué verificas y dónde pides ayuda?

Todo, dependiendo de la elección. Aspectos jurídicos de los derechos y obligaciones. La seguridad analiza las vulnerabilidades y la gestión. La ingeniería analiza la calidad y la aplicación. Adquisiciones analiza los contratos y los proveedores.

El código abierto a menudo afecta a múltiples responsabilidades al mismo tiempo.

Asegúrese de que quede claro qué piezas se han utilizado, qué licencias se aplican, qué controles se han realizado y qué decisiones se han tomado.

Auditable significa principalmente: poder explicar después qué pasó y por qué.

Incluir conscientemente el código abierto en los requisitos, criterios de evaluación y condiciones contractuales. No preguntes sólo por un producto, sino también por derechos, portabilidad y gestión.

De esta forma evitas que la apertura se quede en un simple deseo y no acabe en el encargo.

Vea el soporte como un complemento a los derechos de código abierto. El contrato puede contener acuerdos sobre tiempos de respuesta, actualizaciones, responsabilidad, alojamiento o gestión.

El software puede ser abierto, mientras que el soporte es profesional y pago.

No mire sólo los costos de licencia. También incluye gestión, soporte, capacitación, integración, migración, cumplimiento y mantenimiento.

El código abierto puede ser más barato, pero el valor real suele radicar en el control, la flexibilidad y la menor dependencia.

Trate el código abierto como parte de la gestión normal de riesgos. Mire las licencias, el mantenimiento, la seguridad, las dependencias y la continuidad.

El riesgo no es que algo sea de código abierto, sino que su uso se produzca de forma inconsciente o desatendida.

No se limite a medir los costos ahorrados. Observe también la reutilización, la velocidad, la transparencia, la dependencia evitada, la colaboración y la calidad del control.

Algunos valores son financieros, otros valores están en la autonomía y la confianza.

No. El código abierto proporciona libertades importantes, pero no dice nada automáticamente sobre todas las opciones éticas relacionadas con el uso, el impacto o la gobernanza.

La apertura puede ayudar a permitir el debate, el control y la rendición de cuentas.

No del todo. Las licencias de código abierto permiten un uso amplio y, por lo general, no restringen para qué alguien usa el trabajo.

Cualquiera que quiera limitar el abuso acaba yendo rápidamente más allá del código abierto clásico y tiene que pensar en otros medios legales u organizativos.

Las licencias clásicas de código abierto no restringen los fines de uso. Otorgan derechos a todos, incluso si el creador considera que algunas aplicaciones no son deseables.

Existen licencias con restricciones de uso ético, pero generalmente no se consideran de código abierto en sentido estricto.

El código abierto da a otros control sobre su propio uso: pueden estudiar, adaptar y compartir. Por lo tanto, el creador original renuncia a cierto control exclusivo sobre la distribución y modificación.

Eso no es un error, sino exactamente la elección que hace que el código abierto sea especial.

El código abierto puede respaldar valores públicos como la transparencia, la auditabilidad, la reutilización y la independencia.

Pero los valores públicos también requieren buena gobernanza, accesibilidad, seguridad, financiación y responsabilidad.

Esto varía mucho según el proyecto. Algunas comunidades son abiertas y útiles, otras son de difícil acceso o dependen de redes informales.

La inclusión requiere atención activa al lenguaje, el comportamiento, la documentación, la toma de decisiones y la participación segura.

Ésa es una cuestión importante. Gran parte de la infraestructura digital se utiliza ampliamente, pero no siempre se financia ampliamente.

El código abierto hace posible su uso, pero el mantenimiento requiere tiempo, dinero y responsabilidad por parte de las partes que dependen de él.

El código abierto puede difundir poder porque los usuarios tienen más derechos que simplemente comprar lo que ofrece un proveedor. Pueden hacer que lo revisen, ajusten o cambien.

Esto fortalece la autonomía, pero sólo si hay conocimiento, capacidad y gobernanza para utilizar esos derechos.

Por lo general, la prevención completa no es posible con el código abierto clásico. Sin embargo, los proyectos pueden optar por licencias adecuadas, gobernanza, acuerdos comerciales y una cultura en la que las contribuciones sean normales.

Los usuarios también pueden asumir la responsabilidad devolviendo mantenimiento, dinero o conocimientos.

El código abierto sigue siendo importante para la infraestructura digital, el gobierno, la educación, la nube, la inteligencia artificial y la seguridad. El núcleo sigue siendo legal: otorgar derechos para usar, estudiar, compartir y adaptar.

El gran desafío es la gestión sostenible: garantizar que los proyectos abiertos no sólo se utilicen, sino que también se mantengan y gestionen de forma responsable.

MIAUW significa Metodología para la investigación de seguridad de la información con valor de auditoría. Es una forma de realizar investigaciones de seguridad, como una prueba de penetración, de forma estructurada y verificable.

El objetivo es que una organización no sólo reciba un informe, sino que también pueda demostrar mejor lo que se ha investigado, cómo se hizo y qué conclusiones se derivan de ello.

Lea más en MIAUW.

Muchas investigaciones de seguridad producen resultados útiles, pero son difíciles de evaluar posteriormente. A veces no está claro qué estaba exactamente dentro del alcance, qué pasos se llevaron a cabo o qué evidencia respalda una conclusión.

MIAUW ayuda a registrar mejor estos componentes antes y durante la investigación. Esto hace que la investigación sea más útil para la recuperación, la rendición de cuentas y las auditorías.

Lea más en MIAUW y en ¿Qué significa valor de auditoría?.

No. Una prueba de penetración es una forma de investigación de seguridad. MIAUW es una metodología para estructurar, registrar y hacer más controlable dicha investigación.

Por lo tanto, se puede realizar una prueba de penetración según MIAUW, pero MIAUW es más amplia que la simple realización de pruebas técnicas.

Lea también ¿Qué es una prueba de penetración? y MIAUW.

El valor de auditoría significa que una investigación puede evaluarse adecuadamente posteriormente. Un auditor u otro evaluador debe poder ver lo que se ha acordado, lo que se ha probado, qué evidencia hay y cómo se han llegado a las conclusiones.

Esto hace que una investigación no sólo sea útil para la tecnología, sino también para la gobernanza, el cumplimiento y la rendición de cuentas.

Lea más en MIAUW y ¿Qué es un informe de auditoría en MIAUW?.

MIAUW está destinado a clientes, probadores de penetración, auditores, especialistas en cumplimiento y directores.

El cliente gana más control sobre la investigación. El investigador recibe una estructura clara. El auditor recibe información más verificable. Los directores obtienen más certeza sobre lo que dice y lo que no dice un informe.

Lea más en MIAUW.

No. Ninguna metodología puede garantizar que un sistema sea seguro.

MIAUW ayuda a realizar mejor la investigación de seguridad, documentarla mejor y utilizarla mejor para mejorar. Por tanto, aumenta la calidad y la utilidad de la investigación, pero no reemplaza una buena gestión de la seguridad.

Lea también ¿Qué es fundamental para un estudio MIAUW?.

La atención se centra en acuerdos claros, un alcance claro, evidencia imitable, hallazgos reproducibles e informes que sean útiles para diferentes grupos objetivo.

Un equipo técnico quiere detalles para resolver problemas. La gerencia quiere saber qué significa el riesgo. Un auditor quiere poder evaluar si la investigación se ha llevado a cabo con cuidado.

Lea más en MIAUW.

Alcance significa: lo que es y lo que no es parte de la investigación. Piense en sistemas, dominios, aplicaciones, cuentas, redes, períodos y preguntas de investigación.

Un alcance claro evita malentendidos. Sin un alcance, es difícil decir después si algo se dejó fuera de la vista deliberadamente o no se examinó accidentalmente.

Véase también ¿Cómo maneja OpenKAT el alcance y los permisos?.

La evidencia hace que los hallazgos sean verificables. Un informe no sólo debe decir que algo anda mal, sino también mostrar en qué se basa esa conclusión.

La evidencia puede incluir registros, capturas de pantalla, resultados de comandos, datos de configuración u otros registros. Naturalmente, la información sensible debe manejarse con cuidado.

Lea también ¿Qué significa seguridad basada en evidencia?.

Un hallazgo es un problema, riesgo o punto de atención identificado en la investigación.

Un buen hallazgo describe lo que se ha encontrado, por qué es importante, qué evidencia está involucrada, cuál podría ser el impacto y qué medida ayuda a reducir o resolver el problema.

Lea también ¿Cuál es la diferencia entre un riesgo y una vulnerabilidad?.

Una vulnerabilidad es un punto débil. Un riesgo tiene que ver con lo que esa debilidad puede significar para la organización.

Una vulnerabilidad en un sistema de prueba sin datos confidenciales a menudo tiene un riesgo diferente que la misma vulnerabilidad en un sistema público con datos personales. Entonces el contexto es importante.

Lea también ¿Qué es un hallazgo?.

No. Las organizaciones grandes suelen tener requisitos de cumplimiento y auditoría más formales, pero las organizaciones más pequeñas también se benefician de acuerdos claros, mejores evidencias e informes útiles.

De hecho, MIAUW puede ayudar a que la investigación en seguridad sea más comprensible y transferible.

Lea más en MIAUW.

La declaración de un auditor puede ayudar a demostrar que una investigación se ha llevado a cabo según los acuerdos, sin que sea necesario compartir ampliamente todos los detalles técnicos.

Esto es útil cuando un informe completo es demasiado delicado para una distribución amplia, pero una organización debe demostrar que se ha realizado una investigación seria y verificable.

Lea también ¿Si hago un pentest con MIAUW tengo que hacerlo público?.

Una prueba de penetración, o prueba de penetración completa, es una investigación de seguridad controlada. Los investigadores intentan encontrar vulnerabilidades antes de que lo hagan los malintencionados.

Una prueba de penetración no es un ataque aleatorio. Existen acuerdos sobre alcance, permiso, enfoque, presentación de informes y debida diligencia. Los investigadores utilizan técnicas que los atacantes también pueden utilizar, pero con el objetivo de mejorar la seguridad.

En la Metodología para la investigación de seguridad de la información con valor de auditoría (MIAUW), hemos discutido ampliamente una definición dirigida por el Sr. V.A. los Pous. Esto resultó en esta definición:

‘Una investigación de seguridad ofensiva que debe ser llevada a cabo por nuestro propio personal o por terceros, que implica una búsqueda controlada de vulnerabilidades en una o más redes seguras y sistemas de información o partes de los mismos, que pueden usarse para irrumpir en estos sistemas y/o que pueden, sin intención o de forma autónoma, interrumpir el procesamiento de datos de la organización bajo investigación o tener consecuencias adversas de otro modo.’

Lea también ¿Qué es MIAUW?.

No, eso no es necesario. El objetivo de MIAUW es poner al cliente en primer lugar. Si paga por un informe, tiene sentido que tenga control sobre el producto que compra. Por eso MIAUW dice algo sobre el proveedor: no puede imponer restricciones de distribución al cliente. Se describe así:

No se imponen restricciones al cliente con respecto a la difusión, publicación o almacenamiento del informe y los documentos subyacentes. Se excluyen de esto los datos financieros relacionados con la realización de la investigación, como tarifas por horas, precios y facturas.

El objetivo mayor es que con una prueba de penetración también puedas demostrar que los asuntos importantes se han arreglado correctamente. Eso es difícil si no se le permite mostrar o proporcionar la investigación a otros. No es necesario compartir la información financiera sobre la investigación, porque no dice nada sobre el estado de seguridad.

¿Hay demasiada información confidencial en el informe como para compartirla ampliamente? Entonces el informe de un auditor puede ayudar. Esto le permite demostrar que se realizó el estudio y cuál fue el resultado principal, sin distribuir todos los detalles técnicos.

En resumen: el cliente determina qué nivel de información se comparte con socios, reguladores u otros, sin verse obstaculizado por el proveedor.

Lea también ¿Qué es un informe de auditoría en MIAUW?.

CVSS 4.0 proporciona un método abierto y neutral para capturar las características técnicas y la gravedad de una vulnerabilidad. El vector también muestra qué valores y suposiciones llevaron a la puntuación. Esto hace que una evaluación sea más transferible y verificable que simplemente la etiqueta de “alta” o “crítica”.

MIAUW utiliza este lenguaje de medición común para informar la gravedad y la fundamentación de los hallazgos de manera imitable. MIAUW no determina automáticamente si se aplica una vulnerabilidad y no prescribe una decisión de recuperación. Según la especificación oficial de FIRST, CVSS es una entrada para el análisis de riesgos, no el análisis de riesgos completo.

No. CVSS describe la gravedad técnica de una vulnerabilidad. Un riesgo organizacional también incluye, por ejemplo, la posibilidad de un mal uso, el valor y la función del sistema, las personas afectadas, las obligaciones legales, los posibles daños y las medidas de control existentes.

Por lo tanto, FIRST llama al CVSS un insumo para el análisis de riesgos. Factores como el daño financiero, el daño a la reputación, el número de clientes afectados y los requisitos legales están cubiertos por expresamente fuera de CVSS. Una organización sopesa estos factores en su propia gestión de riesgos.

Sí. CVSS 4.0 incluye explícitamente contexto. Las métricas de amenazas describen la madurez actual del abuso. Las métricas ambientales procesan el entorno de implementación concreto, incluidas las medidas de seguridad existentes, la accesibilidad real, la importancia requerida de la confidencialidad, la integridad y la disponibilidad, las características técnicas modificadas y las posibles consecuencias para la seguridad humana.

Las métricas complementarias añaden más contexto, como seguridad, recuperación, automatización y esfuerzo de recuperación. No cambian el número CVSS, pero según Preguntas frecuentes sobre CVSS 4.0 de FIRST pueden influir en la prioridad local.

Un CVSS-B publicado públicamente generalmente contiene solo las métricas base. Eso no es lo mismo que decir que CVSS no tiene contexto: el cliente completa las métricas ambientales y de amenazas para su propia situación y, por lo tanto, recibe un CVSS-BTE. FIRST recomienda este enriquecimiento para obtener un resultado más significativo en su propio entorno.

La puntuación técnica básica puede ser la misma, pero la puntuación CVSS-BTE local no tiene por qué serlo. Un entorno de prueba aislado, una estación de trabajo interna, un servicio de identidad público y un dispositivo crítico para la seguridad pueden diferir en accesibilidad, medidas, protección requerida y consecuencias para otros sistemas o personas.

CVSS 4.0 puede capturar tales diferencias con métricas ambientales y de amenazas. La seguridad humana también puede influir directamente en la puntuación dentro de las Métricas Ambientales. El contexto adicional también puede influir en la clasificación local sin cambiar el número. Un sistema interno no recibe automáticamente una puntuación más baja: cada ajuste debe seguir propiedades demostrables del entorno real. Ver los grupos de métricas y reglas de evaluación de FIRST.

Sí. Un acierto del escáner o el número de versión correspondiente no prueba que el código vulnerable esté presente, sea accesible o ejecutable. Por lo tanto, primero verifique el componente y la versión utilizada, la configuración, la ruta de llamada y posibles medidas. La investigación del código fuente, un SBOM, VEX, un análisis de configuración y pruebas dinámicas pueden proporcionar evidencia adecuada para esto.

Si el producto parece no estar afectado, documente esta no aplicabilidad con evidencia. No dé artificialmente una puntuación CVSS baja a una vulnerabilidad que no se aplica. FIRST también describe en Preguntas frecuentes sobre CVSS 4.0 que un proveedor debe volver a evaluar la puntuación del producto concreto y puede utilizar VEX para comunicar la aplicabilidad.

Un método uniforme ofrece a proveedores, investigadores y compradores los mismos conceptos y un vector legible por máquina. Esto les permite intercambiar evaluaciones, comprobar suposiciones y perfeccionar la puntuación para su propio entorno. La investigación sobre datos de vulnerabilidad muestra que las clasificaciones de gravedad inconsistentes pueden reducir en gran medida la calidad de una mayor priorización (Croft, Babar y Li, 2022).

Esa ventaja no significa que todas las organizaciones deban utilizar la misma secuencia de recuperación. El acuerdo significativo es: estandarizar el criterio, no la decisión. La amenaza local, el contexto del sistema, la política y la aceptación del riesgo siguen siendo decisivos.

No en el sentido de un modelo empírico que predice la probabilidad de abuso o el daño esperado. CVSS es una convención de medición estandarizada basada en definiciones técnicas y opiniones de expertos. Para la versión 4.0, los expertos han agrupado y clasificado millones de posibles vectores; PRIMERO publica este método en el manual del usuario.

Hay pruebas, pero son limitadas. NIST examinó la fórmula CVSS 3 contra reseñas de los diseñadores. Que soporta el funcionamiento interno de esa fórmula, no la predicción de incidencias o daños y no automáticamente la versión 4.0. La investigación también encuentra diferencias entre los evaluadores humanos. Por lo tanto, CVSS es útil como método de medición transparente y compartido, no como una certeza científica.

No. Una puntuación CVSS alta significa que las consecuencias y condiciones técnicas son severas según el vector elegido. No existe una probabilidad calibrada de que la vulnerabilidad sea explotada dentro de un período de tiempo determinado. Las investigaciones muestran que priorizar únicamente los umbrales CVSS puede resultar ineficaz (Jacobs y otros, 2020).

CVSS 4.0 puede incluir la madurez del exploit actual en las Métricas de amenazas. Por ejemplo, EPS se puede utilizar para una estimación de probabilidad; Los ataques confirmados y la información patentada sobre amenazas también son relevantes. Estas fuentes tampoco reemplazan la evaluación de riesgos local.

No. La política determina, entre otras cosas, el apetito de riesgo, clases de sistemas, plazos, excepciones, responsables y condiciones de aceptación del riesgo. CVSS puede registrar consistentemente la gravedad técnica, la amenaza actual y los factores ambientales, pero no toma una decisión administrativa.

En el manejo de riesgos, la organización combina esa información con aplicabilidad, impacto comercial, seguridad, privacidad, obligaciones legales y medidas disponibles. Luego decide, por ejemplo, restablecer, limitar, evitar, transferir o aceptar motivadamente. La puntuación y el vector proporcionan evidencia de esa decisión; no reemplazan la política, decisión o justificación declarada.

Un orden útil es:

1. verificar que la vulnerabilidad se aplica al producto;
2. verificar la puntuación base CVSS y el vector de ese producto;
3. agregar información sobre amenazas actuales y factores ambientales reales;
4. incluir contexto adicional, como seguridad, recuperabilidad y obligaciones legales;
5. aplicar su propia política de prioridad, tratamiento y aceptación de riesgos;
6. Hacer constar la decisión y fundamentación.

Esto no crea una lista de reparación automática, sino una decisión que se puede seguir. FIRST recomienda utilizar métricas ambientales y de amenazas para obtener un resultado más significativo y llama al resultado un aporte para su propia vulnerabilidad y manejo de riesgos.

OpenKAT es la herramienta abierta de análisis de vulnerabilidades. Es un software de código abierto que ayuda a las organizaciones a mapear su panorama digital y hacer visibles las vulnerabilidades, las configuraciones incorrectas y los riesgos.

OpenKAT tiene que ver con el conocimiento: ¿qué tenemos, qué es visible, qué está cambiando y con qué necesitamos hacer algo?

Lea más en OpenKAT.

OpenKAT ayuda a comprender mejor su interior y exterior digital. Recopila información sobre sistemas, dominios, software y configuraciones y la convierte en información procesable.

En lenguaje sencillo: OpenKAT ayuda a ver dónde se encuentran las puertas, ventanas y cerraduras digitales y cuáles necesitan atención.

Lea más en OpenKAT.

La superficie de ataque es todo lo que un atacante podría intentar utilizar para obtener acceso o causar daño.

Piense en sitios web, servidores de correo, entornos de nube, API, VPN, dominios antiguos, entornos de prueba olvidados y servicios configurados incorrectamente. Cuanto mejor conozca esa superficie, más protección específica podrá brindar.

Lea también ¿Por qué es importante el conocimiento continuo?.

Los entornos digitales cambian constantemente. Se agregan sistemas, se actualiza el software, se cambian las configuraciones y se descubren nuevas vulnerabilidades.

Por lo tanto, un escaneo único es una instantánea. El conocimiento continuo ayuda a ver cambios y responder más rápido cuando algo se deteriora o vuelve a ser vulnerable.

Lea también ¿OpenKAT puede mostrar cambios a lo largo del tiempo?.

No. OpenKAT y las pruebas de penetración se complementan entre sí.

OpenKAT proporciona información técnica continua y puede recopilar muchas señales. Una prueba de penetración es una investigación dirigida por personas, con contexto, creatividad y profundidad. OpenKAT puede ayudar a orientar mejor las pruebas de penetración y realizar un mejor seguimiento de los resultados.

Lea también ¿Qué es una prueba de penetración? y OpenKAT.

No. Ningún producto de seguridad encuentra todo automáticamente.

OpenKAT ayuda a recopilar y evaluar mucha información de forma estructurada. Pero siguen siendo necesarios un buen alcance, interpretación, gestión y seguimiento. El contexto humano sigue siendo importante.

Lea también ¿Cómo ayuda OpenKAT con la priorización?.

En OpenKAT, un pícaro es una pequeña tarea de investigación o escáner que recopila información específica. Por ejemplo, puede comprobar algo sobre DNS, TLS, versiones de software u otras propiedades técnicas.

La idea es modular: muchas tareas pequeñas juntas proporcionan una imagen más rica del entorno digital.

Lea también ¿Qué es la normalización en OpenKAT?.

Un hallazgo es una señal que requiere atención. Esto podría ser una vulnerabilidad, pero también una configuración incorrecta, falta de medidas de seguridad o una desviación de la política.

Un hallazgo no siempre es inmediatamente un incidente. Es principalmente una razón para evaluar lo que significa y qué seguimiento es necesario.

Lea también ¿Cómo ayuda OpenKAT con la priorización?.

La seguridad basada en evidencia significa que las conclusiones se basan en datos registrados, no sólo en sentimientos o suposiciones vagas.

OpenKAT ayuda guardando observaciones y vinculándolas con los hallazgos. Esto hace que sea más fácil ver en qué se basa una conclusión y cómo cambia la situación con el tiempo.

Lea también ¿Por qué es importante la evidencia en MIAUW?.

El cumplimiento consiste en demostrar que se cumplen las reglas, estándares o acuerdos. OpenKAT puede vincular observaciones técnicas a políticas o estándares.

Esto deja más claro qué hallazgos técnicos también son relevantes desde el punto de vista administrativo o legal. Esto ayuda con auditorías, informes y priorización.

Lea también ¿OpenKAT puede ayudar con NIS2?.

No. Los especialistas en seguridad necesitan los detalles técnicos, pero OpenKAT también es útil para administradores, auditores, equipos de cumplimiento y directores.

Cada rol mira de manera diferente la misma realidad: detalles técnicos para la resolución, resúmenes para la dirección y evidencia para la rendición de cuentas.

Lea más en OpenKAT.

Sí. OpenKAT es de código abierto y puede utilizarlo usted mismo. Esto requiere conocimiento técnico, gestión y diseño cuidadoso.

Por tanto, algunas organizaciones optan por la autogestión. Otras organizaciones prefieren trabajar con un socio para el alojamiento, el diseño, la gestión o el soporte.

Consulte también Partners y OpenKAT.

OpenKAT es una herramienta de seguridad y debe usarse con cuidado. El escaneo sólo se realiza dentro de un alcance acordado y con permiso.

Los resultados pueden ser sensibles porque dicen algo sobre vulnerabilidades e instituciones. Así que proteja bien esa información y solo dé acceso a las personas que la necesiten.

Lea también ¿Cómo aborda OpenKAT la privacidad?.

OpenKAT trabaja con objetos que se pueden examinar. Podría ser, por ejemplo, un nombre de dominio, dirección IP, sitio web, servidor, certificado u otro componente técnico.

Al registrar dichos objetos por separado, OpenKAT puede establecer relaciones: qué sitio web pertenece a qué dominio, qué certificado pertenece a qué servicio y qué hallazgo pertenece a qué componente.

Lea más en OpenKAT.

Los escáneres suelen producir resultados aproximados. Normalizar significa convertir esa salida en datos que OpenKAT pueda comprender y comparar de forma fija.

Esto es importante porque OpenKAT quiere combinar información de diferentes fuentes. Sólo cuando los datos están claramente estructurados se pueden vincular con objetos, hallazgos, estándares y cronogramas.

Lea también ¿Qué significa seguridad basada en evidencia?.

Un escáner de vulnerabilidades suele buscar vulnerabilidades técnicas específicas. OpenKAT es más amplio: puede combinar datos de múltiples fuentes, establecer relaciones, mostrar cambios a lo largo del tiempo y vincular los hallazgos con políticas o estándares.

Por lo tanto, OpenKAT puede utilizar escáneres, pero en sí mismo es principalmente una plataforma para reunir observaciones, contexto y seguimiento.

Lea más en OpenKAT.

OpenKAT está destinado a la investigación dentro de un alcance acordado. De este modo, sólo escanea sistemas para los que tiene permiso y para los que está claro qué se puede examinar.

Esto es importante por razones legales, técnicas y organizativas. La investigación de seguridad sin un alcance claro puede generar riesgos y dañar la confianza.

Véase también ¿Cuál es el alcance de una investigación MIAUW?.

Sí. Una idea importante detrás de OpenKAT es que no sólo quieres una instantánea, también quieres ver cómo está cambiando la situación.

Esto ayuda con preguntas como: ¿se ha resuelto un problema, ha regresado, ha surgido algo nuevo y la situación de seguridad está mejorando o empeorando?

Lea también ¿Por qué es importante el conocimiento continuo?.

No todos los hallazgos tienen la misma urgencia. Un problema técnico en un sistema de prueba sin importancia suele ser menos grave que el mismo problema en un sistema público con datos confidenciales.

OpenKAT ayuda vinculando las señales técnicas con el contexto, las políticas y los estándares. Esto permite a una organización determinar mejor qué debe abordarse primero.

Lea también ¿Cómo ayuda OpenKAT con el cumplimiento?.

OpenKAT puede ayudar con el lado práctico de la resiliencia digital demostrable: obtener información sobre los sistemas, las vulnerabilidades, las configuraciones erróneas y los cambios a lo largo del tiempo.

NIS2 no se trata sólo de tecnología, sino también de gobernanza, riesgos y demostrabilidad. OpenKAT puede proporcionar soporte técnico para esto, pero no reemplaza un programa NIS2 completo.

Lea también ¿Cómo ayuda OpenKAT con el cumplimiento?.

OpenKAT examina principalmente datos técnicos, pero los resultados pueden ser confidenciales. Un informe de vulnerabilidad o error de configuración puede usarse indebidamente si termina en el lugar equivocado.

Por eso es importante limitar el acceso, proteger bien los resultados y escanear sólo dentro de un alcance claro.

Lea también política de privacidad de este sitio web y ¿Es seguro utilizar OpenKAT?.

Los resultados de las exploraciones individuales suelen ser difíciles de interpretar. Las relaciones dejan claro cómo se relacionan los componentes: qué dominio pertenece a qué sitio web, qué servicio se ejecuta en qué sistema y qué hallazgo pertenece a qué objeto.

Estas relaciones hacen de OpenKAT más que una lista de notificaciones. Se convierte en un modelo del entorno digital que ayuda a comprender mejor las causas, el impacto y el seguimiento.

Lea más en OpenKAT.

Sí. OpenKAT es interesante porque puede combinar información de diferentes fuentes. Considere escáneres, fuentes de datos externas, comprobaciones de configuración y tareas de investigación propias.

El objetivo no es reemplazar todas las herramientas, sino reunir mejor los resultados y hacerlos útiles para el análisis, el seguimiento y la rendición de cuentas.

Lea más en OpenKAT.

OciDeck es un programa de presentación que se centra en el contenido. Las diapositivas se crean a partir de formas, datos y texto claros, en lugar de deslizar objetos manualmente por un lienzo.

Lea más en OciDeck.

OciDeck está destinado a personas que ven las presentaciones como portadores de conocimientos. Piense en formadores, investigadores, profesionales de la seguridad, desarrolladores, auditores, formuladores de políticas y organizaciones que quieran mantener el control de su información.

Es especialmente interesante cuando el contenido, la reutilización, la verificabilidad y el intercambio seguro son importantes.

Lea más en OciDeck y Características de OciDeck.

Muchos programas de presentación comienzan con un lienzo en blanco. Arrastra cuadros de texto, imágenes y formas a su lugar.

OciDeck comienza con el contenido. Tú eliges el tipo de diapositiva, completas el contenido y dejas que a partir de ella surja la presentación. Esto hace que las diapositivas sean más fáciles de comprobar, reutilizar y exportar.

Lea también Por qué Marp es importante para OciDeck.

Marp es una forma de crear presentaciones con Markdown. Markdown es una notación de texto simple.

Marp es importante para OciDeck porque significa que la presentación sigue siendo texto sin formato. Esto hace que los cambios sean controlables y garantiza que el contenido no esté bloqueado en un formato de archivo cerrado.

Lea más en Por qué Marp es importante para OciDeck.

No necesariamente. OciDeck ofrece editores estructurados por tipo de diapositiva. Para que pueda trabajar sin escribir Markdown todo el tiempo.

Markdown es principalmente la base abierta para la presentación. Cualquiera que conozca Markdown puede beneficiarse de esto, pero no es un requisito estricto para todos los usos.

Lea también ¿Qué es Marp?.

Las presentaciones suelen contener información más sensible de lo que la gente piensa: nombres, direcciones de correo electrónico, detalles del cliente, tokens, capturas de pantalla, notas del orador o detalles técnicos.

OciDeck ayuda a que dicha información sea visible antes, antes de compartir o exportar una presentación.

Lea más en Funciones de privacidad en OciDeck.

OciWacht busca localmente datos potencialmente confidenciales en una presentación. Piense en números de identificación, direcciones de correo electrónico, números de teléfono, tokens, claves u otros patrones sensibles.

Para cada hallazgo, el creador puede elegir qué hacer con él: aceptarlo, marcarlo u omitirlo en la presentación y exportación.

Lea más en Funciones de privacidad en OciDeck.

No, no para el procesamiento normal de tu presentación. OciDeck web funciona en tu navegador: la aplicación Flutter web se carga desde el servidor y después la edición, la vista previa en vivo, OciWacht, la exportación a PDF/PPTX/HTML y el constructor CVSS ocurren del lado del cliente. El contenido del deck no se envía a un backend para procesarse.

Tampoco hay telemetría ni analytics integrados. El servidor de alojamiento de OciDeck no obtiene visibilidad a nivel de aplicación sobre tu deck, tus cambios, los hallazgos de privacidad ni las exportaciones.

Hay matices. Como cualquier webhost, el servidor puede tener logs de acceso ordinarios, por ejemplo dirección IP, hora, archivos solicitados y user-agent. Eso muestra que alguien cargó la aplicación, pero no lo que esa persona hace en OciDeck.

También hay un fetch proxy opcional para importar URL cuando una fuente no permite acceso CORS. Solo cuando abres una URL non-CORS mediante ese proxy, el servidor ve la URL introducida y reenvía los bytes.

Otras conexiones salientes son iniciadas por el usuario y van a destinos que eliges o configuras tú, como asistencia de IA opcional, WebDAV/Nextcloud, una base de datos CVE, provisioning de secmodule o una URL que importas tú mismo.

Si quieres usar OciDeck en el navegador, ve a ocideck.nl.

Lea más en Funciones de privacidad en OciDeck.

No. Ningún escaneo encuentra todo.

OciWacht es una herramienta para identificar riesgos de manera temprana y compartirlos de manera más consciente. El creador sigue siendo responsable del contenido y siempre debe pensar por sí mismo en presentaciones delicadas.

Lea también ¿Por qué son importantes las funciones de privacidad en OciDeck?.

No todas las diapositivas están destinadas a todos los públicos. OciDeck puede ayudar a determinar por presentación y por diapositiva con qué amplitud se puede compartir la información.

De este modo, OciDeck puede ayudar a evitar que una diapositiva interna termine accidentalmente en una presentación o exportación más amplia.

Lea más en Comparte al nivel correcto.

TLP significa Protocolo de semáforo. Es un sistema de colores para indicar qué tan confidencial es la información y con quién se puede compartir esa información.

No es necesario conocer la abreviatura para comprender el principio. La pregunta práctica es: ¿quién puede ver esta información?

Lea más en Comparte al nivel correcto.

Sí. Los gráficos en OciDeck permanecen conectados a los datos. Esto los hace más controlables y menos dependientes de capturas de pantalla o imágenes creadas manualmente.

Esto es útil para investigaciones, informes, paneles y presentaciones donde las cifras deben permanecer correctas.

Lea más en Características de OciDeck.

Sí. Las listas de verificación se pueden marcar durante la presentación.

Esto es útil para capacitaciones, talleres, demostraciones, revisiones de seguridad e informes en los que el progreso debe ser visible. La lista de verificación se convierte entonces en parte de la historia, no en algo adicional a la presentación.

Lea más en Características de OciDeck.

Sí. OciDeck se centra en trabajar desde una única fuente y exportar a formatos utilizables como PDF, PPTX y HTML independiente sin conexión.

La ventaja es que el mismo contenido se puede utilizar para diferentes propósitos, sin tener que crear nuevas copias manualmente cada vez.

Lea más en Características de OciDeck.

Sí. OciDeck es de código abierto. El código fuente está en Forgejo:

https://pawprint.vigilis.online/LibreKAT/Ocideck

Lea también OciDeck.

Las formas de diapositiva son tipos fijos de diapositivas, como título, lista, tabla, gráfico, ejemplo de código, pregunta, línea de tiempo o panel.

Al trabajar con formas de diapositivas, el creador tiene que desplazarse menos manualmente. El contenido es central y OciDeck puede mostrar, controlar y exportar ese contenido de manera más consistente.

Lea más en Características de OciDeck.

Sí. OciDeck admite diapositivas con código fuente y resaltado de sintaxis. El código sigue siendo texto real en lugar de una captura de pantalla.

Esto es útil para presentaciones técnicas, capacitación e informes de seguridad en los que el código debe permanecer legible y auditable.

Lea más en Características de OciDeck.

Sí. OciDeck puede utilizar diapositivas Markdown gratuitas que incluyen diagramas de sirena y matemáticas LaTeX.

Esto significa que los gráficos y fórmulas se pueden guardar como contenido de origen, en lugar de como una imagen separada que es difícil de cambiar más adelante.

Lea más sobre lo que hace posible Marp Markdown.

El modo Markdown está destinado a usuarios que desean trabajar directamente en la fuente de texto de una plataforma. Esto puede resultar útil para buscar y reemplazar, cambios rápidos de texto o comprobaciones técnicas.

No siempre es necesario utilizar el modo Markdown. Los editores estructurados permanecen ahí para aquellos que prefieren trabajar por diapositiva.

Lea también ¿Qué es Marp?.

OciDeck incluye un módulo de prueba de lápiz MIAUW opcional. Este módulo está destinado a informes según la Metodología para la Investigación de Seguridad de la Información con Valor de Auditoría.

Piense en encontrar diapositivas, resúmenes, listas de verificación, resúmenes del alcance y soporte para informes. El módulo está desactivado de forma predeterminada y está destinado a situaciones en las que MIAUW es realmente relevante.

Lea más en Características de OciDeck y ¿Qué es MIAUW?.

La exportación de HTML sin conexión significa que una presentación se puede transportar o compartir como una versión HTML independiente, sin necesidad de acceso a la red durante la visualización.

Esto es útil para capacitaciones, demostraciones y entornos en los que no desea depender de presentaciones en la nube o servicios externos.

Lea más en Características de OciDeck.

Sí. OciDeck admite presentaciones con, entre otras cosas, visualización en pantalla completa, navegación con teclado, cronómetro, notas, modo de ensayo y presentador de pantalla dual.

Esto convierte a OciDeck no sólo en un editor, sino también en una herramienta para realizar presentaciones.

Lea más en Características de OciDeck.

Sí. OciDeck puede trabajar con notas del orador y notas separadas para los participantes.

Esto es útil porque no es necesario que toda la información esté en la propia diapositiva. Un orador puede necesitar contexto adicional, mientras que los participantes necesitan un resumen o una referencia clara.

Lea más en Características de OciDeck.

Sí. OciDeck puede utilizar Nextcloud/WebDAV como fuente para paquetes OciDeck y plataformas Marp Markdown.

Esto es adecuado para organizaciones que prefieren mantener los documentos bajo su propia gestión o en su propio entorno colaborativo.

Lea más en Características de OciDeck.

OciDeck se centra en una interfaz accesible, que incluye controles de teclado, etiquetas de lectores de pantalla, escala de texto y anuncios de cambio de diapositivas.

La accesibilidad también tiene que ver con la estructura. Debido a que las diapositivas contienen contenido real, es más fácil mantener ese contenido comprensible y verificable.

Lea más en Características de OciDeck.

¿Estás utilizando cerveza casera? Luego ejecute estos dos comandos. El primero apunta a Homebrew a nuestra propia forja, el segundo instala OciDeck:

brew tap librekat/ocideck https://pawprint.vigilis.online/LibreKAT/homebrew-ocideck.git
brew install --cask librekat/ocideck/ocideck

La línea de dirección es realmente parte de esto. Si lo omite, Homebrew buscará en GitHub y no encontrará nada.

Esta es la ruta canónica: tanto la receta como la app salen de nuestra propia fragua. Si Forge no está disponible temporalmente, el espejo de GitHub es la copia de seguridad. Esto se hace con un solo comando, porque la forma corta de Homebrew por definición apunta a GitHub:

brew install --cask brennodewinter/ocideck/ocideck

Independientemente de cómo lo instale, Homebrew extrae la versión directamente de nuestra propia forja y verifica la suma de verificación automáticamente. La aplicación está firmada con un ID de desarrollador de Apple y certificada ante notario por Apple, por lo que se abre con un simple doble clic.

Para actualizar a una versión posterior, ejecuta:

brew upgrade --cask ocideck

La cask es solo una referencia a esa misma versión firmada y notarizada; Homebrew no aloja la aplicación y no se añade ningún intermediario adicional. Homebrew Cask existe únicamente para macOS: en Windows y Linux descargas OciDeck directamente.

¿Prefieres no usar Homebrew? Entonces descarga OciDeck directamente desde la página de OciDeck. Allí también se explica, por plataforma, cómo abrir y verificar la descarga.