Información publicada

[soporteseguridad]

Buenos días,

Desde el equipo de seguridad de Ineco vemos como se mantiene información de la organización de forma abierta en Github. Nos referimos a los siguiente:

https://github.com/PucelaBits/websegura/blob/cd39b472e7d2a0a4ef36b70767ad9fae3291eeff/_data/results/dmarc/www!ineco!com.json

Comprendemos que esto es información pública del dominio de Ineco, pero entendemos que no hace ningún bien facilitar estos datos a todo Internet. No vemos necesaria la exposición y, si es necesario por diferentes automatismos, esta podría ser ocultada. Esto no es una ayuda para mejorar la seguridad, si no una ayuda para contribuir a un posible ataque.

Por otro lado, comentar que el análisis de sitios web sin autorización no está permitido, así como el uso de marca Ineco.

Por todo ello, solicitamos la ocultación o eliminación de los datos comentados en el enlace anterior.

Gracias.

[RBauglir]

No soy responsable del proyecto, ni miembro de PucelaBits, así que solo voy a intervenir para aportar algunas aclaraciones sobre las que se podrían interpretar como amenazas veladas por parte de Ineco, con el fin de que en Pucelabits, y en la propia Ineco, sepan cuál es la situación jurídica real del asunto:

1. Los que no están permitidos legalmente son los análisis de sistemas informáticos (como páginas web) realizados, inequívocamente, como actos preparatorios de una intrusión informática (acceso ilegal informático: Código Penal, art. 197 bis, punto 1), o realizados causando una afectación de los recursos y servicios prestados desde el sistema informático (daños informáticos: CP art. 264). Es más que evidente que ninguno de esos dos supuestos se dan en la actividad del proyecto de websegura, toda vez que esta consiste en el análisis de información alojada por los propios titulares (en este caso, Ineco) en registros públicos externos y, en todo caso, de información procedente de otras fuentes públicas, como la Fundación Mozilla, quien la obtiene de conexiones convencionales con la página web y no de procedimiento intrusivos.
2. No existe ninguna obligación legal de ocultación de información pública por razones de seguridad, salvo que la revelación de tal información sea, de nuevo, inequívocamente, un acto facilitador de un ataque informático. Las políticas de revelación responsable (responsible disclosure) son de carácter informal pero, además, no son aplicables a la situación actual dado que la inseguridad de la página web de Ineco está constatada, como poco, desde el año 2016, y sus vulnerabilidades son debidas a omisiones (que no errores) evidentes en la configuración de sus servicios y no a descuidos o descubrimientos técnicos sorpresivos. Por explicarlo de forma más sencilla, la web de Ineco no está mal configurada, es que está sin configurar, que es muy distinto, con lo que Ineco no puede aducir que no fue preavisada (entiendo que no piden la ocultación indefinida porque eso sería bastante impresentable) de que su web era vulnerable porque tal situación tenía que ser evidente para la propia organización: no hace falta realizar un preaviso a un empresa porque su web no siga los estándares de la IETF (HSTS) o las recomendaciones de la W3C (CSP y SRI), porque tales carencias son omisiones voluntarias.

Me atrevería a recomendar a Ineco que, en futuras ocasiones, consulte a sus servicios jurídicos antes de realizar publicaciones de este cariz.

Un cordial saludo.

[ssaavedra]

Hola!

Disclaimer: no tengo ninguna afiliación con este proyecto ni con PucelaBits; soy un tercero, entusiasta del software libre y proyectos relativos a la seguridad y privacidad, y conciudadano al que le interesa la seguridad de la información de sus organismos y entidades públicos, que ha visto este mensaje en Internet. No soy abogado, y ninguna parte de este mensaje ha de entenderse como consejo legal. Este mensaje es mi opinión personal y no está relacionada ni puede entenderse como derivada de la posible opinión de ningún organismo, institución, empresa o asociación del que pueda formar o haber formado parte.

En mi opinión, los datos que están disponibles en este repositorio son públicamente accesibles, con lo que ya están disponibles a "todo Internet". La única "facilidad" que ocurre aquí es la de compendiar qué dominios son de qué administraciones públicas.

Puede utilizar cada organización los mecanismos que considere mejor para protegerla ante ataques informáticos así como para proveer servicios a sus usuarios de la forma más eficaz posible. Que "por medio de automatismos, esta podría ser ocultada" es irrelevante, lo que ocupa a este proyecto es entender cuál es el estado actual de las infraestructuras públicas. Los departamentos encargados de ello "podrían hacer su trabajo", pero hasta que no lo hagan con eficacia, este proyecto tiene relevancia de interés público.

Por otro lado, los resultados de dmarc no tienen que ver con sitios web, sino con la seguridad del correo electrónico, un protocolo diferente, si bien ambos se pueden servir a través de Internet, pero me resulta extraño que sea precisamente esto sobre lo que pide la retirada puesto que es la única configuración razonable que tiene en todo el dominio; al utilizar Office 365, Outlook les obliga a configurar de una forma mínimamente aceptable el correo electrónico para su funcionamiento. Muchos otros organismos son susceptibles de suplatanción de email por utilizar cabeceras DMARC y SPF más permisivas que las de su institución.

Además, sin entrar en (la falta de) el fondo jurídico de una acusación tan grave, el pensar que esto pudiera ser "una ayuda para un próximo ataque" es extremadamente preocupante para mí como ciudadano, ya que significa que usted no tiene absolutamente ni idea de como funciona Internet: este tipo de escaneos no son intrusivos y los pueden hacer tanto actores inocuos como malevolentes, y la respuesta adecuada por parte de la responsabilidad de seguridad del organismo es la de cubrir estos problemas con soluciones técnicas relevantes y acordes a lo que los estándares de la industria requieren, ya que por encima de los posibles atacantes de no cumplir la ley también está la obligación de las administraciones de salvaguardar sus infraestructuras, entre otras, la recogida en el Artículo 17 de la Ley 39/2015 de Procedimiento Administrativo Común de las Administraciones Públicas. Siendo esto así, espero que si las personas que ostentan actualmente este puesto de trabajo no son competentes para ello, saquen urgentemente a concurso público las plazas que necesiten para cubrir esta carencia.

Por otro lado, la marca no se está utilizando en ningún contexto que vulnere la Ley 17/2001, hasta donde yo veo. Si puede usted referir en la ley cuál es su velada acusación respecto de lo que pueda considerar "uso de la marca", supongo que estaría agredecido todo el mundo presuntamente implicado.

En cualquier caso, la política de funcionarios públicos de amenazar con acciones legales sin base jurídica es una lacra que tenemos en diversos organismos públicos en diversos estamentos y es algo realmente anacrónico, contrario a los trasfondos legislativos de los últimos cuarenta años y, en definitiva, al interés general.

En su lugar, ver personas que hagan su trabajo más diligentemente y como a partir de identificar los problemas de seguridad se ven solucionados, como hizo policia.es o radarcovid, es síntoma de una administración que comienza a escuchar los problemas y sugerencias de sus ciudadanos y a tomarse la seguridad un poco en serio.

Realmente le habría costado más o menos lo mismo subir 50 puntos la seguridad de su web (según el Observatorio de Mozilla) como escribir su contribución en este foro, así que gracias por pasarse por aquí, pero yo le habría agradecido más haber visto el cambio en el Observatorio de Mozilla.

Literalmente, en la página inicial solo tendría que haber cambiado los enlaces de jQuery del actual src="//ajax.googleapis por un src="https://ajax.googleapis. Que en mi opinión sigue siendo una decisión triste ver a una empresa pública depender de la CDN de Google teniendo tantas otras maneras de servir un recurso como jQuery, pero como digo, ese cambio de 12 caracteres sería probablemente suficiente para no requerir SRI. Que si quiere "hacerlo bien", de una forma más robusta, en Mozilla le dicen cómo puede cargar precisamente jQuery de una forma más segura al hablar de Subresource Integrity.

Si estuviesen interesados estoy seguro de que hay multitud, no solo de autónomos y empresas, sino hasta incluso de personas que a modo particular estarían dispuestas a ayudar a entidades públicas a mejorar su seguridad como, en mi opinión, pretende hacer este proyecto.

Un saludo cordial.

[comunicacionineco]

Buenos días,

Desde la Subdirección de Comunicación de Ineco lamentamos el comentario aportado en este hilo. Agradecemos la labor que desarrolla el Observatorio de Seguridad Web desde la comunidad PucelaBits cuyos resultados nos permiten seguir reforzando y mejorando la ciberseguridad de nuestra web.

Un cordial saludo,
Subdirección de Comunicación de Ineco

[nukeador]

Gracias a vosotros, desde aquí siempre vamos a estar encantados de ayudar a que las webs públicas sigan mejorando.

Un saludo.