A veces las APIs (estoy pensando que existe una analogíca ‘clásica’ con los gestores de bases de datos) no nos proporcionan suficiente granularidad a la hora de gestionar los activos digitales (en los gestores de bases de datos suele haber la granularidad, pero no siempre querremos dedicar tiempo a configurar nuestros programas y, además, los permisos de las bases de datos; seguramente un error, pero es lo que se hace a veces).

Sobre este tema y cómo lo gestionaron en su caso nos habla ‘Statgirl Flowers’ en Building a stateless API proxy:

It turns out GitHub’s API has extremely coarse access control on API tokens. For example, imagine if you wanted to write an editor plug-in to turn your Gists into easily-accessible snippets in your editor. People would have to grant your plug-in write access even though it only really needs read access. There’s a big Dear GitHub post on the subject, but this is not uncommon - many APIs have permissions systems that don’t quite always fit the needs of users.

La solución pasa por crear un proxy donde se gestionan los permisos y qué cosas pueden hacer unos programas y otros no.

So what I really want is a token that can read but not write gists. The proxy can issue its own token. It can keep track of the fact that the token is only allowed to read Gists and not write them. When it gets a request for the GitHub API it can check permissions before forwarding the request and the real token to GitHub.

Curioso.

Estoy convencido de que la mayoría de los desarrolladores quieren que su código sea seguro. El problema es que, además, quieren cumplir plazos, sus jefes quieren mantener los costes contenidos, …. y eso lleva a que la seguridad no sea una prioridad.

En 86% of developers don’t prioritize application security nos lo confirmaban. En una encuesta de Secure Code Warrior, el 86% de los desarrolladores no consideraban la seguridad una prioridad de primer nivel.

While many developers acknowledge the importance of applying a security-led approach in the software development lifecycle, 86% do not view application security as a top priority when writing code.

No sólo eso, sino que solamente un 29% de ellos creen que esto debería ser una prioridad.

This is a contributing factor to another major finding – that only 29% of developers believe the active practice of writing code free of vulnerabilities should be prioritized.

Entre los aspectos que deberían ayudar, como no, la formación:

Training remains a major influence over developers’ application of secure coding as 81% are utilizing the knowledge gleaned from training on a near-daily basis.

Las responsabilidades de que esto no se considere una prioridad: cumplir los plazos, desconocimiento, falta de formación al respecto y, finalmente, los fallos que introducen otros.

36% attribute the priority of meeting deadlines as a primary reason their coding still possesses vulnerabilities

33% don’t know what makes their code vulnerable

30% feel that their in-house security training could most be improved if it had more practical training with real world scenarios and outcomes

30% say the biggest concern with the implementation and practice of secure coding is dealing with vulnerabilities introduced by co-workers

Le vamos dedicando más atención a las APIs (esos sistemas que nos permiten ofrecer la funcionalidad de nuestro sitio a otros -o a nuestros propios desarrolladores- más allá de la que sea nuestra aplicación principal -si es que eso existe-).

En Secure APIs in ASP.NET una serie de recomendaciones para este lenguaje (poco nombrado, aunque con su cuota de uso) pero, como casi siempre, con uso en muchos otros casos.

Las recomendaciones:

Validar que la petición es correcta, esto es: formato adecuado, tamaño adecuado, contenido adecuado…

The first step in the model is to validate that the incoming request is valid HTTP, with the correct format and a reasonable size. Otherwise, it should be rejected as early as possible before reaching our application code.

Validar los tokens, que sería una forma de validar las peticiones, pero refiriéndose a la parte de identificación, autentificación, autorización… Siempre, con el modelo de aceptar lo que es correcto, esto es: hacer obligatoria la autorización.

An essential part of step 2 is that we make authorization mandatory. The policy lines in the code above ensure that the default behavior requires an authenticated request. Security should never be opt-in. Instead, you opt out when needed.

Transformar los tokens de acceso en permisos: a una autentificación correcta, y ante cualquier intento de realizar acciones hay que estar seguros de que esa autorización permite realizar la acción solicitada.

Before moving to step 4, we want to emphasize the importance of striking the right balance between what the token contains and the permissions we need for access control.

Validar los datos de la petición: los parámetros son los que tienen que ser, de los tipos adecuados, … Así evitaremos que a través de los parámetros puedan entrar inyecciones peligrosas de datos.

For the endpoint in our controller, we have one parameter: the product identifier. In our case, the identifier is not an arbitrary string of any size! It can contain only letters and digits and be ten characters or less. If the input string does not follow those rules, we can immediately return a 400 Bad Request. This input validation will make injection attacks a lot harder.

Validar los permisos para realizar la operación. Si una petición no viene con la solicitud adecuada de permisos (de acuerdo a nuestro sistema interno, claro), no permitiremos la acción.

We base the permission to perform an operation on the transformed permissions in our domain code and not directly with scopes and user identity.

Finalmente, validar los permisos para acceder a los datos: una vez que los permisos son correctos, están adecuadamente incluidos, tenemos que validar en nuestra aplicación que esos datos se pueden proporcionar de acuerdo a la política que tengamos definida.

The final step is to validate access to the actual data that the request will read or modify. Sometimes we can validate access by looking at the request, and other times we need to retrieve the data before deciding.

Viene con ejemplos en el lenguaje y más comentarios interesantes.

Las personas de perfil técnico olvidamos a veces que la parte tecnológica es, normalmente, el apoyo a algún otro asunto o negocio que hay que llevar a cabo. Es importante, y muy necesaria (¿totalmente?), pero no es el objetivo.

Por eso es bueno leer textos como Cybersecurity as a Business Decision: A Manifesto donde se recuerdan estas cuestiones.

La ciberseguridad, nos dicen, es el elemento número uno en cualquier listado de inversiones en tecnología. No sólo eso, la ciberseguridad es un asunto del negocio, y no de tecnología. Sin embargo los comités de dirección no saben manejar la ciberseguridad en este contexto.

Cybersecurity is now the #1 spend item on the technology investment list. In 2022, 88% of boards say that cybersecurity is a business issue, not a technical one. Unfortunately, boards have no idea how to govern cyber AS a business issue and executives have no idea how to guide cyber investment as a business issue.

Nadie es capaz de explicar el valor para el negocio de los controles de seguridad y, por lo tanto, es difícil discutir sobre estas inversiones.

Bottom line, no one can explain the business value of a security control, so we can’t have an adult conversation about business investment in security.

La cuestión no es si hace falta más dinero (siempre seremos capaces de gastar más) sino de gastarlo de manera inteligente.

After all my board interactions, my conclusion is that we need smarter money, not just more money.

Una aproximación frecuente entre los especialistas en seguridad es la idea de que más seguridad es mejor.

Most damaging of all, security officers are trapped in a recurring and crippling ideology that MORE security is always better.

Pero, nos recuerda, cualquier incidente de ciberseguridad estará relacionado con un fallo en la toma de decisiones, no en la tecnología.

Look at any cybersecurity incident and you’ll find a failure of decision making, not a failure of technology.

Por ejemplo, casi ninguna organización hace pruebas de recuperación para sus actividades críticas. Es costoso, y arriesgado ‘apagar’ un negocio y verificar si somos capaces de activarlo de nuevo.

You know why most organizations don’t test their recovery processes for their critical functions? Because it’s very expensive and risky to take a fully functioning business system down to bare metal and hope that you can bring it back.

Por lo tanto, podríamos gastar tanto dinero como queramos en ciberseguridad y, sin embargo, recibir un ataque exitoso al día siguiente.

The reality is that you can spend every available dollar on cybersecurity and you could still get hacked tomorrow, because there is no such thing as perfect protection.

También podemos ponernos tan exigentes con la ciberseguridad que el trabajo no pueda llevarse a cabo. Y eso es un problema.

And he said “Oh, I get it, if we lock everything down so tightly that we start to take the tools away that people need, then we’ll hurt our business.” Exactly.

Así que hay que empezar a pensar en un escenario donde la pregunta correcta es: ¿cuál es la cantidad correcta de ciberseguridad? Porque está claro que no podemos ignorar el problema completamente.

Neither can you just ignore security. So the right question is “what is the right amount of security?”

Y cambiar el objetivo: no se trata de prevenir todos los ataques que puedan afectarnos, se trata de establecer un balance adecuado entre la protección y las necesidades de funcionamiento de la organización.

The real purpose of a security program is NOT to prevent the organization from being hacked, because that’s an impossible goal. The purpose of the security program is to balance the needs to protect with the needs run the business.

El problema actual es que invertimos en herramientas y capacidades, en lugar de en resultados.

Cybersecurity investment is broken because we invest in tools and capabilities, not outcomes. That has to change.

Modestamente, intentamos explicar estas ideas en Ciberseguridad: ocuparse para no preocuparse y nos vino bien el texto de Gartner para recordar estas preocupaciones.

Parece que hoy en día la cuenta de usuario es la moneda (mínima) de cambio. Luego ya hablamos de como protegerlas, las contraseñas y otros artefactos y allí estamos. Es verdad que para muchas cosas sería necesario, pero parece que es inevitable y la gente de f-droid nos muestran que no es así.

En No user accounts, by design nos recuerdan que es posible proporcionar servicios sin este elemento, y que su decisión de diseño fue no hacer seguimiento de los usuarios, y evitar recopilar sus datos.

There are no user accounts used, ever, in the process of delivering apps to users. This is by design. F-Droid has never had a method to identify or track users in the Android client app, and getting information from f-droid.org has also never required any kind of identity information.

Tener una cuenta simplifica algunas cuestiones, como son los votos para conocer las mejores aplicaciones. Pero el precio que se paga es tener información del usuario fácilmente identificable (diría que sin cuentas, probablemente, también haya formas, pero no estamos hablando de eso aquí).

Having user accounts makes some problems much easier to solve: it makes it easy to include ratings and reviews and to manage editing of documentation. However, having user accounts makes other problems much more difficult to solve. User accounts inevitably mean that personally identifiable information (PII) will be collected and stored.

Pero, como decíamos, ¿son necesarias las cuentas para proporcionar un servicio? En f-droid creen que no.

It turns out that user accounts are rarely a requirement for building a service, even though many services make it seem that way.

Lo cierto es que hay algunas cosas que funcionan bien sin cuentas de usuario: el navegador (chrome, Google, atentos…), wikis, libretas compartidas y otros servicios.

It turns out that F-Droid is not alone in delivering key services without user accounts or profiles. There are browsers, wikis, shared notepads, video conferencing, and even messaging and analytics. Many systems that use accounts also allow reading and even editing without logging in.

Vale la pena leer y aprender de los que toman estos caminos, en un mundo donde el ‘dato’ parece que es tan importante.