==============================================================================================================================================
Cette semaine, l'affaire RSA a connu une nouvelle étape. RSA propose désormais de remplacer tous les tokens en circulation pour ses clients.
Par conséquent, il va de soit que tout le monde se prononce sur l'utilité ou non (et l'urgence) de remplacer les tokens ou carrément la solution RSA par une solution alternative.
Je vous laisse lire tous les avis et vous faire le vôtre.
De ce que j'ai lu, je suis plutôt en phase avec ce qui est proposé par Dan Kaminsky et Help Net Security. On est là dans une approche mesurée et pragmatique. Clairement, on ne peut pas remplacer tous les tokens d'un coup. Comme mentionné dans certains articles, RSA remplace les tokens, mais ne prend pas en charge les coûts de migration/re-déploiement. Si votre base installée est très importante, cela risque de s'avérer long et coûteux car les personnes utilisant des tokens ont souvent la mauvaise habitude d'être mobiles et donc hors de portée pour un remplacement simple. Par ailleurs, si vous avez à renvoyer des tokens physiques, gérer la logistique, ou effectuer des imports massifs de tokens logiciels, c'est quand même du boulot.
Ceci dit, il est clair également que pour des utilisateurs exposés à des menaces plus importantes (personnes ayant accès à des informations confidentielles, des brevets, etc...) il peut être bon de remplacer les tokens assez rapidement. Pour le plus long terme et pour le reste de la population, une analyse de risques sérieuse et la mise en place de renforcements de la sécurité (sensibilisation des utilisateurs, changement régulier du code PIN malheureusement pas toujours pratiquée, ajout de nouveaux critères de sécurisation, remplacement partiel ou total de la solution, etc...).
Mais tout cela s'inscrit dans une démarche raisonnée. L'action rapide n'a pas de sens dans la gestion de la sécurité et des failles en particulier, j'en veux pour preuve l'exemple que je trouve très bon de Kaminsky qui grosso modo explique que quand une faille est découverte sous Windows, vous ne passez pas tous vos postes sous Linux !!
Pas faux, un point pour Kaminsky.
Tristan
==============================================================================================================================================
Les tokens RSA à la benne ?
http://sid.rstack.org/blog/index.php/485-les-tokens-rsa-a-la-benne RSA Says Lockheed Attack Not a New Threat to SecurID, But Will Replace Users' Tokens
http://threatpost.com/en_us/blogs/rsa-says-lockheed-attack-not-new-threat-securid-will-replace-users-tokens-060711 RSA remplace sa solution SecurID corrompue
http://pro.01net.com/pro.01net.com/editorial/534092/rsa-remplace-sa-solution-securid-corrompue RSA forced to replace nearly all tokens after security breach
http://news.hitb.org/content/rsa-forced-replace-nearly-all-tokens-after-security-breach DSD tells agencies to replace RSA tokens
http://news.hitb.org/content/dsd-tells-agencies-replace-rsa-tokens Dan Kamsinky On The RSA SecurID Compromise
http://news.hitb.org/content/dan-kamsinky-rsa-securid-compromise http://dankaminsky.com/2011/06/09/securid/ "I recommend replacing devices in an orderly fashion, possibly while increasing the rotation rate of PINs. I dismiss concerns about source compromise on the grounds that both hardware and software are readily reversed, and anyway we didn’t change operational behavior when Windows or IOS source leaked."
Only now does RSA appoint a security chief?!
http://news.hitb.org/content/only-now-does-rsa-appoint-security-chief Can RSA repair the broken trust?
http://news.hitb.org/content/can-rsa-repair-broken-trust http://www.net-security.org/secworld.php?id=11136 "Anyone using RSA tokens should take this as an opportunity to:
1. Conduct a comprehensive risk assessment relating to their remote access infrastructure.
2. Review their remote access policy and ensure only authorized personnel has the appropriate access.
3. Ensure that users are educated and aware of the RSA compromise and to be alert for any suspicious emails or social engineering attempts to get the PIN for their token.
4. Ensure appropriate logging is turned on to detect any suspicious behaviour from remote users or repeated attempts to log in.
5. Ensure remote users have only access to systems they need access to when working remotely.
6. Implement additional authentication mechanisms on secure systems or indeed remove remote access from them until RSA shares some useful information about what was compromised.
7. Ensure that remote users systems are secured with up-to-date anti-virus software and signatures and that their systems are patched with the most up-to-date software.
8. Restrict remote access to known and verified remote locations, e.g. users home networks or remote offices, and/or restrict access to certain times of the day."
Concerned with the vulnerability of authentication tokens?
http://news.hitb.org/content/concerned-vulnerability-authentication-tokens http://www.net-security.org/secworld.php?id=11129 RSA's SecurID Quandry: Replace or Recall?
http://threatpost.com/en_us/blogs/rsas-securid-quandry-replace-or-recall-060711 "However, RSA hasn't offered discounts or licensing deals to ease the pain of replacement."
/https%3A%2F%2Fassets.over-blog.com%2Ft%2Fcedistic%2Fcamera.png)
/image%2F0999431%2F20171231%2Fob_01a7bc_dsys3jsueaawem3.jpg)
/image%2F0999431%2F20170101%2Fob_6af365_c1affncxaaa9biq.jpg)