 Hello everyone, thanks for joining this talk, especially so early in the morning. My name is Emmanuel Bouillon, and I'm going to discuss with you today some security issues that you might have to cope with when dealing with federated identity. And more precisely, I'm going to discuss a specific type of federated identity which is a SAML-based federated identity. So first, I'm an infosec guy, and more importantly, everything that I'm going to say today expresses only my own view, my own views, and especially do not involve any of my previous, current, and future employers. And everything is provided for educational purpose only. Ok, so that being said here is the outline of this presentation. It's made of six parts. First, an introduction, what is it about and why should we care. In the second part, I'm going to discuss what is the problem we are trying to solve and how have we been doing it up to now. And then in the third part, I'm going to introduce some, not all, but some of the standards and specifications around the federated identity area. I'm just going to give the minimum material so that everybody will have in mind what is needed to take the most of the rest of the presentation. And the rest of the presentation is going to be made of two parts. One is how can we adapt classical web application scanner in order to have them to better cope with the SAML-based, SAML-protected web application, web applications. And in this part, I'm going to illustrate how the type of results that these kind of tools can provide. And in the last part, I'm going to present and to discuss some security considerations and issues that we need to have in mind prior considering joining or creating such a federation. And finally a conclusion. So let's get started. So SAML stands for Security Accession Market Language. And this talk is about SAML token and claims-based identity and access management. So I'm going to take a radically low-level approach of this protocol. That means I'm not going to discuss the API provided to developers in order to implement this kind of protocol. Maybe you're familiar with Windows Identity Foundation API, which is the .NET API that allows developers to somehow transparently integrate SAML protocols in their applications. So I'm not going to use this kind of level of abstraction, but I'm just going to look at the lowest level of those protocols. And also this presentation is not about a consistent and formal study of every involved standard. I'm just going to cursorily introduce two of them, but you'll see that that's enough to get some interesting results. So basically the approach I've been using is some sort of standards reverse engineering. Basically find vulnerabilities and then go back into the specification and see why something got wrong. So what are going to be the takeaways of this presentation? First tools, adaptive tools in order to have a classical web application scanner to better cope with SAML protected web applications. Then I'm going to demonstrate an assumption which is that involved standards can be read as an attempt to circumvent the same origin policy. I'm going to show a demonstration about that. And finally some important security considerations that you might have in mind before joining or creating such a federation. So why should you care? The thing is that the protocol and specification I'm going to discuss in this presentation are getting more and more prevalent. Actually many influential major industrial players are currently pursuing the development of SAML-based protocol to achieve federated identity management. And also it's support of the federation that makes SAML particularly suitable for cloud deployment as to why it's getting ubiquitous. So whether you like it or not, it's coming your way. And the last point is that depending on the context of deployment you're considering being business to business, banking, government for tax payment for instance. This kind of deployment and associated security issues might entail some very thorny contractual, legal and even privacy issues. That's why it's important to take care of that. So now where do we come from? What is the main problem that this kind of standard tries to solve? Let's say that the single sign-on solution or issue within a single domain has been solved now for a while. So initial solution for this single sign-on problem in a single domain were very efficient from an administrator point of view but maybe not that satisfactory from a security point of view. Maybe some of you still have in mind some yellow page solutions and NIS systems for instance. So that was very interesting from an administrator point of view but maybe not that interesting from a security point of view. But today this problem has been solved by more robust protocols like Kerberos for instance. Kerberos is a protocol you use very commonly to solve a single sign-on issue within a single domain. Typically that's what you're using if you're using active directory environment. The thing is that now we need to solve this single sign-on solution but between organizations, between different domains and that's typically what SAML tries to solve. So the goal is to have a user and administrator friendly cross-organization boundaries single sign-on. So here I'm going to focus on web applications. So that needs to be secure, scalable, easy to manage and ideally taking care of privacy and anonymity issues. So this problem is not new and of course previous solutions have already been deployed. Usually these solutions rely either on duplicating user accounts, user accounts more or less intelligently or by establishing trust relationships between security domains, typically Kerberos trust relationships between active directory domains be it unilateral or bidirectional trust relationships. And of course these type of solutions come up with some drawbacks and that's this kind of drawbacks that SAML tries to solve and to tackle. And also regarding the problem of privacy and anonymity some previous standards have been defined but never really been deployed nor widely adopted. So what do we need to know about federated identity standards? So in this part I'm just going to give a very, very high level view of some of the involved standards around federated identity. So here you have a diagram that shows the complete ecosystems of specification around federated identity. As you can see there are quite numerous and most of them are supported by an organization called OASIS, the OASIS Consortium which stands for Organization for the Advancement of Structured Information Standards. So I'm not going to discuss all of them but just to introduce two of them. So first the SAML specification which in fact it's a set of specification itself and secondly the WS Federation specification which basically describes how to orchestrate flows in order to achieve this multi-domain single sign-on solution. So let's start with SAML. SAML stands for Security Assertion Markup Language and basically it consists of of building stone components which once put together allow a given number of use cases to be supported and these components primarily allow the transfer of identity information like authorization, attributes and so forth between autonomous organizations that have an established trust relationship that's the primary goal of SAML. And there is also something you need to know if you start looking at this kind of specification and document that's the fact that there is there are some terms which have a specific definition in this context so it's better to know their definition. So basically you have SAML assertions, SAML protocol, bindings and profile. So SAML assertions, I'm going to go back to that later but typically it's a signed XML document which contains statements about principle, a user for instance, that given a certain party claims to be true. SAML protocol are basically the description of requests and response that are needed in order to obtain or to submit a SAML assertion. And SAML bindings are the mapping between SAML protocols and other layer of transport protocol like typically you have bindings for SAML and SOAP, you have the HTTP redirect binding and the HTTP post binding. And finally you have what they called SAML profiles which basically is the combination of assertions, protocol and bindings in order to support a given number of use case of federated scenarios. So within the standard there are several profiles defined like the web browser SSO profile or the single logout profile. I'm just going to mention two of them during this talk. First the web browser SSO profile because that's really the most common use case, the most widely used use case regarding SAML specification. And the second one is identity provider discovery profile. I'm going to mention this one because actually it is prone to some security issue. So what are SAML assertions? So as I said, SAML assertion is a signed XML document containing claims or attributes about a user. And it's a set of claims contained in SAML assertions that define the identity in regard to what we call the reliant parties, that means let's say the web application. So what you need to have in mind also is that these claims do not need to be distinctive for this user. It doesn't have to be a login name for something like that. It can just be a statement like yes this user has paid his monthly fee for the public library or yes this user is over 21. So here is how it looks like. So it's a, with no surprise, it's a signed XML document which follows the XML digital signature standard. So you get information regarding the issuer, regarding the signature, how it has been computed, etc. You get information about the subject. And more interestingly, you get information about the attributes contained within this SAML assertion. And typically in the enterprise use case, these attributes are obtained from an enterprise directory that can be a group membership, yes this user has this role in my organization or yes this user has this email address in my organization. And as you can see above, there is also some specific attributes that can be of interest, like the audience attribute. So the audience attribute is basically a statement that says for which reliant party this SAML assertion has been made of. So that's interesting because that allows to prevent some SAML reuse attack. But for this to be effective, it needs to be taken into account by the reliant party side of the implementation. And as we'll see later, it's not always the case. So implementation do not verify that. And that's obviously a security issue. So how is SAML used? SAML is standard based, so widely supported and supposedly interoperable part include xml encryption, xml digital signatures and x509 certificate. It heavily relies on HTTP for conveying the SAML assertion through the network that easily goes through firewall. There are several ways or types of deployment. It can be deployed in a local network. It doesn't have to be in a federated environment. It supports branch offices deployment. It supports users to access the corporate network. But also, and more importantly, it supports federation and the federated scenario. And I'm going to discuss that more into detail later. Into more detail later. So basically the idea is to have a nice, neat, cross domain single-signal solution so that our beloved users are happy with their experience. So how does it work here? I'm going to focus on the web browser SSO profile. Basically it's a four steps process. First you have your user who request access to claim the web application and at this request do not contain any SAML assertion. The web application is going to redirect the web browser to the user's identity provider using the HTTP ROCCORD 302. And at this point the user's identity provider is going to authenticate the user one way or another. We don't have to know the type of authentication that is going to be used at that point. It can be providing a login password or just using the corporate single-signal solution, typically Kerberos-based. So once the identity provider has authenticated the user then the identity provider is going to build a claim with appropriate attributes inside and sign it and send it back to the user's browser with an HTTP post form with an auto-submit request to the web application. So that's how it's going to be transparently, this SAML assertion is going to be transparently sent back to the web application and as this web application is claims aware it's going to grant access to this user according to the SAML assertion. And that's how you achieve the single-signal solution so that our user are happy with that. And that's really interesting from an administrator and developer point of view because in fact from the web application side you don't have to know and to deal with what kind of authentication mechanism has been used. So the corporate environment can completely change the way authenticated the code so that the web application still remains the same. That's what makes it really interesting from a developer point of view. So now you could say so what because indeed ok we have a single-signal solution for web applications but actually there are other ways to achieve that. Typically you can use espinigo over GSS API with either Kerberos or NTLM as a security underlying so the main actually the main idea for that is that it supports federation that is the sharing of identity between domains what they call in the specifications the multi-domain SSO issue. It also supports delegation that's the maintenance of identity to backend services and also it provides an enhanced access control which we call role-based access control. It provides a finer granularity regarding how you can provide access control to your web application. So that's it for SAML so the second standard I wanted to introduce here is the WS federation standard. WS federation is an approved OSD specification that defines mechanism to allow different securityism to federate. So what does it mean? Basically access to resources managed in one realm can be provided to users or principles whose identities and attributes are managed in other realms. So that's how you guarantee the fact that users management stays on the side of their own authoritative domain. You don't have to bother about users management of other domain. So that's why it's really interesting and also it includes mechanism for brockering of identity, attribute and authentication between realms et le développement. En termes de la specification la dernière chapter est sur la considération de sécurité. C'est une petite chapter, c'est une page. Et la dernière boulette de cette chapter est sur les services compromis. Je vais vous dire que je vais revenir à ça et voir comment cette considération peut être une issue selon la manière dont vous considérez. Donc ici c'est ce qui commence par avoir votre web browser, votre client connecté à l'application web. Comme vous n'aurez pas à propos d'une claim de cette application, elle va vous redirecter à sa propre identité de provider. À ce point, le domaine de l'antide de l'antide de l'antide sera redirecté à l'antide de l'antide de l'antide de l'antide de l'antide. À ce point, l'antide de l'antide de l'antide de l'antide sera redirecté à la même dramatik de l'antide de l'antide dans un site de service de l'antide de l'antide. Et si ce soit authentiqué, l'identité de provider sera redirectée sur des attributes d'une entreprise directrice planif, signé et senté chez l'adjecteur en utilisant un direct poste pour être redirecté à l'identité de l'antide de l'antide attributes within the claim, sign it back, sign it and send it back to the web, to the web browser with a post redirect to the web application. At that point, the web application which is going to receive this signed claim, this claim, this claim is signed by its own identity provider, so it's going to be trusted and according to attributes contained in this claim it's going to grant access to its resources. So that's basically how this multi-domain solution at the very high level is achieved. And just to be complete, just be aware that they are, okay, I've just introduced a very simplest use case, but there are more complex architecture supported by the standard and the specification. And like typically what they call the procured federation model which basically is when you have a centralized identity provider which is destructed by many others. And also please be aware that users can be, can have several identity providers depending on its context. And that's in some sort, the user can have several identity and doesn't only have to trust one identity provider. So that's it about the introduction of the standards. Just to be complete, I've just added a list of what I consider as important security study, preview security study on that domain. So some security issue has already been discovered in regarding SAML. So either regarding SAML standards themselves or regarding some of their, of SAML implementations. So now that's where things are getting interesting. When you look at the complete, within the complete documentation of OASIS regarding SAML, there is one document called SAML technical overview. So it's still a draft, but basically that's in the document where they explain all the rational behind SAML. And what is really interesting at that point is that the really main driver, and that's how it is written in the document. The main driver for SAML is the limitations of browser cookies. And it's written like that. Typically browser cookies are never transmitted over DNS domain. And basically, when you read that, you have the things that they consider that's quite sad. And SAML solves this problem. So of course, the multi-domain signal solution is relevant and a legitimate issue to be solved. But on the other end, if browser cookies do not fly between DNS domain, there are good reasons for that. And basically it's part of the same origin policy. So from a security point of view, what I mean here is that we could read that as, okay, soaps sucks, let's build a workaround. So from a security point of view, these kinds of considerations of rational has a great potential for security issues. So the question is, is it a fail or not? Typically, can a bad guy steal cookies? So I'm going to provide the response later, so you need to be patient. To conclude with this part, just a few words regarding implementation security. Typically, for implementations I've been looking at, like a DFS, Schiboleth, or simple SAML PHP, there are some good aspects, like the fact that by default, tokens are encrypted. And by default, also replay attacks are properly addressed. So you might also meet some problems regarding the compliance with the standards, like the fact that unsigned logout request gets accepted, or the fact that the targeted ODN attribute is not verified. And finally, you also have some implementations which have some vulnerability. And I'm going to demonstrate to two of them an open redirection vulnerability and a cookie leak or cookie theft within one implementation. So before that, I'm just going to explain how to adapt our classical web application scanners in order to have them to properly cope with SAML protected web applications. So regarding our tool set, I think that these considerations have already been mentioned this morning by the presentation of related to SOAP and how to adapt web application scanners to better access web service based on SOAP. So, but typically, web application scanner tool set is made of several kinds of combinations of different tools chosen by more or less objective criteria. So typically, it can be made of professional or community edition of commercial tools, like web inspect, analytics, and others. You can use free and open source software for web application scanning, skipfish, Necto, and typically some Firefox plugins also. And also, very often, when you discuss with people doing that for a living, they very often use their own homemade custom scripts that they have been developing throughout their experience. Regarding methodology, it's a little bit of the same. Suppositely, some more or less formal procedures are supposed to be followed. You can rely on some generally accepted best practices, like the OWASP testing guide or the OSSTMM framework. But finally, it's always heavily relies on habits and personal preferences. And also, still many manuals ad hoc and improvised steps are needed. So that's why I think we still need to adapt our tool set. Even though if some great presentation regarding how to do web application assessment states that we should not be a tool, the only tool we need is our brain, I still think that properly using the right tool often makes a difference, especially because usually it's a time constraint exercise. And regarding SAML, there are two reasons to adapt our tool set, the fact that it allows a traditional assessment of web application scanner to cope with SAML tokens, to assemble protected web applications. And also, these kind of applications and their security, they often relies on very complex configuration settings. So these configurations are prone to error and we need tools to assess that the good configuration settings are effectively in place. So the thing is that there are already some existing tools that can help the web application scanner, the web application pentester when they have to cope with SAML. So I've listed some of them here, at least all those I know of. So you've got the Uninet SAML tracer, which actually is a Firefox plugin, which allows you to see decoded SAML tokens that your browser is receiving and sending. You have the SAML debugger, the Finder SAML debugger, it's an online application that allows you to submit tokens, either encoded or decoded, and then you receive the answer, which is either decoded or encoded. And the last one is a really interesting one. It is provided by the Un3 Identity Federation, part of their initiative called Federation Lab. Basically, it's an online automated checks of service provider implementation. So if you have a SAML implementation of the service provider side, you can trust the Federated Lab STS, and then online ask a scan of your implementation, and then you're going to get a result of how compliant is your implementation regarding the standard. So I'm going to show you the result of this kind of scan just later. And of course, you can always use a manual approach to encode and decode SAML tokens. So here, you can see an example of a report from a Federation Lab service provider tester. So I've just installed an out of the book Hello World application using Sybil-Sable PHP, which is one implementation of SAML standards. So the good news is that you have many success, so that means somehow some compliances with the protocol, but you also get some errors regarding these compliances, like the fact that, indeed, single logout, unsigned single logout requests are accepted, and that the targeted audience attribute is not checked by the service provider side, which is, in fact, a security issue. So we still need to adapt our tool set, and there is one area where this application is proved to be very, very useful. It's when encoding and decoding SAML tokens, and the gain of this encoding and decoding touches several parts of the assessment of the efficiency of the web application scanner. First, having access to, clear to this SAML token, or having access to the SAML token decoded, allows you to really, more accurately understand the meaning of all these requests and what these tokens are made for, what are the attributes involved, for which redine parties, so that helps understanding what is going on. Also, it allows you to do some more relevant request mongling, and if your web application scanner happens to be a further, then you instead of fuzzing a big chunk of meaningless data, you're going to fuzz properly, more accurately, each specific parameter, and also it allows you to sort some anti-replaceive guards, like the fact that you need to change random numbers and teach different requests, and it allows you also to update timestamp on the fly, which then allows you to have longer scans to unfold properly, which avoide some false negative results. So, here is the approach I've been using. So, it's not a new approach, because typically it has already been used by people from JDS Security when they have been assessing the Microsoft proprietary binary encoding of SOP request for WCF. So, the idea is to chain proxies. So, first you have a preprocessing proxy whose role is to decode requests and encode responses. The middle proxy is actually your real scanner when you do your real assessment and when your intelligence takes place, and then you have the post-proxies which encode the request back and decode the response back. So, this way the application still receives the request in the proper expected format so it can work properly. So, to implement that, I've been using BERT ProSuit, so I guess most of you know this web assessment tool. It has a very, very good cost-benefit ratio. And what is really interesting with this tool is that it provides a Java API to extend BERT ProSuit functionalities and it's particularly suitable for pre and post-processing. And also, there exist some bindings both for Python and Ruby. So, I've been using the Ruby framework to extend BERT ProSuit which is called Ruby. The complete tutorial has been presented and is available on the net. And for this kind of tool, you only need to hook either even proxy message or even HTTP message. So, the proof of concept I've been developing is freely available at this URL and you can use and test it basically to retrieve all the results I'm going to present now. So, I'm not going to discuss the code itself. I'm just going to show you how it looks like. So, here is a pre-processing proxy which receives the initial browser request so as you can see or maybe you can just guess that you see a sampled token a non-coded sampled token so very difficult to understand. And this pre-processing proxy is going to edit this request and decode the sampled token. So, now you have in the edited request the complete decoded sampled token which is sent to your real proxy which is actually your real web application scanner. So, typically, if you're using Burp as a middle proxy then you can send this request to Burp intruder for instance to have specific parameters to be mongled with. And at that point the middle proxy is going to send this request like that and to the post-processing proxy which will receive the decoded token in clear if you want and then post-processing proxy is going to encode the sampled token back to the appropriate format so that it's going to be sent to the application as it expects to be sent. So, that's basically how it works. So, I'm just going to illustrate some results you can obtain using this approach. So, I've chosen two results to illustrate these tools. And I've chosen these two because actually these results and these vulnerabilities are more standard related to standard and specifications themselves than related to implementation. So, that was more interesting and more fun to discuss these two vulnerabilities. So, the first one is an open redirection. So, an open redirection is just the fact that you can craft a request so that the target is going to respond with a redirection to another site which is controlled by the attacker. Right? So, it's not critical and as you're going to see, it's somehow built-in in the sampled standards. And then I'm going to illustrate how this can lead to a cookie theft that means that we are going to be able to make cookies fly between DNS domain using these kind of vulnerabilities. And secondly, if you visit this site a bad guy can inconspicuously discover your identity provider that means what is your originating organization. So, that's at least a privacy issue. So, to demonstrate that I've been leveraging an existing live open to everyone test environment which is provided by the user domain account. And the cookie I'm going to steal actually is htpsopenidp.fighter.no So, what you're going to see is a complete four-step sampled authentication. And then you'll see how a bad guy can just steal this cookie. So, it's a three-steps process. First, the victim accesses un site contains a craft get request to the service provider which will actually leverage open or redirection to get back to send back the cookie to its own control website. So, to make it more visual this redirection will not go to the bad guy website but I've crafted Google search request using as an argument the cookie so that you can see that indeed the Google search request. So, let's see. So, at the beginning you're going to see that this is the only just the open redirection vulnerability. So, I don't know if you see anything but basically here you see that it's a get request that goes to openidp.fighter.no and when you click on this link you're going to be automatically redirected either to Google or to DevCon website. So, that's Google redirection then you have the same thing with this request goes to openidp and gets redirected to DevCon. So, that's just the open redirection vulnerability, so nothing very critical but then, let's imagine that your user is connecting to a service provider that use a SAML and openidp it's identity provider. So, here this is a service relying party on id.net I choose my identity provider then automatically I get redirected to my identity provider I need to authenticate, so here by using a login password and then you'll see that this identity provider is going to craft a SAML request and send back to the application so that I get authenticated so that's the four step process you know, you have been describing and now I choose a link you'll see that the redirection end up with the theft of the cookie right? So, that's the demonstration I hope that's clear so that's how you can steal a cookie and make cookie flies between DNSDOM using this kind of vulnerability so the thing is that actually if you go back to the standard implementation issue but more specification issue because it comes from the identity provider discovery service profile and actually it's built in the open redirection, when you look at the standard it's written like that the open redirection is in the specification and actually when they wrote this specification they somehow felt that there was a kind of issue this is a quotation of the standard this protocol has the potential opportunity for phishing so at least they were aware that it was dangerous and they propose the worker round based on the service provider metadata but it's only should worker round and there's no way they don't explain how we could exchange between the service provider and the discovery service so basically the developer have just implemented properly the standard and they get vulnerable so that's what I wanted to show you about this part and the last part is about question regarding the design of consideration about the deployment and trust apologies so as you remember this is the simplest use case of federation scenario so you have two organizations with a trust relationship but of course you there are more complex there are more complex deployment scenario does it really does this kind of deployment implement new risk it's a contentious issue but basically other solutions are not that more secure so that's to be simple that's what we can say about that so here is a very simple deployment scenario you have one organization which try to access another organization application and the access control is based for instance on the user's email address so and typically what happens in real life is that you have several domain organization B as several customers accessing its application so now the question is what if one of the organization gets either malicious or compromised typically what if organization C sign claim for a user of organization B the thing is by default if you installed everything by default that means that your application is going to grant access regarding the attribute which is in the claim because from a signature point of view everything is fine so you need to implement yourself all the business checks at that point that will prevent this kind of attack to be working but that's not you need to do that that's not implemented by default but at least in this simple scenario you can do it and more realistic scenarios where it's getting more complicated typically when you have an indirect trust relationship where you have a central trust broker that convey trust between organization so at that point, so here is how it works you've got one organization which trust organization D which then is trusted by organization B so and then you have this single sign-on solution that's worked perfectly will find the same way flowing between these three organizations organization C sign the claim for a user which is not part of its organization let's say, what if organization C gets either my issues or compromised the thing is in this case if organization D do not do his job by checking everything that needs to be checked and which is not done by default then organization B has no way to see the trick and to see that things got wrong so if the STSD sign the token then STSD has no way to see that something went wrong so that means that in fact organization B fully relies on organization D to properly check some claims but so that means then what is the policy for that do we have a way to verify is auditing permitted etc and how to prove other parties compliance with relevant requirement so that typically the questions that are usually answered so the bottom line is what about the mal issues or compromised ADP in a federation and can a mal issues ADP impersonate another domain users that's really the main bottom line issue is there any safeguards in place business set that prevent that and who own this safeguard do you as an organization own this safeguard or do you use this kind of safeguard so that's in fact because when you look at implementation by default these safeguards are not implemented and if you get back to the standard then fail actually this kind of consideration has just been cursorily mentioned in the bullet I mentioned previously which is the compromise services and indeed they recognize that this is really a very major issue but on the other hand in practice it works by default and there are no proposed solutions on how to prevent that so in the case of a third party broker trust you need to control the loss of controls who's availability is involved etc what are other parties obligations and that's the concept I've called some old claims laundering so all relies on a teacher level this must be done since default settings are permissive so typically ways to do that is to have key attributes which are kept adding to avoid the turning situation into a blind trust to this organization part and the thing is also on main federations when you join a federation usually you don't have access to this policy you don't know exactly what checks are in place and that's an issue so that ends up this presentation so the main takeaways of this presentation are first knowledge and tools to keep on properly assessing SAML protective web application how to adapt the tool sets classical web applications tester a tool set to cope with SAML protective web application then proven assumption the fact that standard can be read as an attempt to circumvent the same origin policy so you've got the tools and process to go there and also important security design consideration the thing is that without taking care insecurity by design is possible and typically when you have cross domain trust relationship with active directory for instance if one domain gets compromised the domain cannot impersonate other domain users whereas with SAML indirect trust implementation it's possible by default so we need to take care of that with SAML cross domain by default this kind of situation will occur of course this approach applies to other form of delegation of a federation these field developers and marketers are ahead of security guys yet default security thing are not secure so the make it working approach might lead to insecure deployment and that's why we need to keep up with this kind of protocol to avoid big deployment security failure and post mortemly discover that there has been an issue so we need to get acquainted with the involved protocol to assess the design and the deployment of such a federation and also adapt our tool set because probably bad guys will and very probably also that would be helpful to have better guidance or improve standards on how to protect to avoid this kind of issue because today it's really relies on diligent administrators and developers to implement these checks if we had a common way to solve this kind of issue then even in term of assessing it could be far more easier I guess that's all I have for today so I'd like also to thank one of my great colleague which is called Rui Fisk for his great help and extensive knowledge ensemble and if you have any question I can try answering them now or I will be in room 2 Q&A thanks a lot for your attention