Preguntas frecuentes
Respuestas a preguntas frecuentes sobre la Fundación LibreKAT, MIAUW, OpenKAT y OciDeck.
Fundación LibreKAT
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.
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.
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.
Soberanía
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.
Código abierto
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
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?.
OpenKAT
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.
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
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.