Dec 3rd, 2007 by Jesper Kråkhede
To be able to comply with PSD there are quite a lof of criterias that has to be fullfilled. One is the fourth point of article 10: Granting of authorization. It states that there has to be a clear chain of responsibility for all parts of the payment service business. It all breaks down to implementing ITIL or some other framework to be able to handle such compliance. The biggest issue is to set a information owner and a system owner on all parts of the chain. Without this and without a clear organization it is not possible to handle security incidents. This is in essence not any different from any other compliance scheme. Same thing is stated in PCI DSS but with other wordings. It is all about mitigating risks, nothing else.
Posted in Compliance | No Comments »
Dec 3rd, 2007 by Jesper Kråkhede
PSD, Payment Service Directive is a very interesting directive from EU regarding opening up for payment flows all over EU. Read more here: http://register.consilium.europa.eu/pdf/en/07/st03/st03613-re02.en07.pdf
This of course will create changes in the current systems on how money is tranfered within EU today. From my point of view the possible need for changes in the security organization is very interesting due to the fact that many changes that this will create for the IT-systems. If the following post I will try to identify some of the bigger changes that this creates.
All entities that are affected by this directive sure has a lot of work to be done. In some cases more then in other. Here is a list from the directive showing affectred entities:
(a) credit institutions within the meaning of Article 4(1)(a) of Directive 2006/48/EC;
(b) electronic money institutions within the meaning of Article 1(3)(a) of
Directive 2000/46/EC;
(c) post office giro institutions which are entitled under national law to provide payment
services;
(d) payment institutions within the meaning of this Directive;
(e) the European Central Bank and national central banks when not acting in their
capacity as monetary authority or other public authorities;
(f) Member States or their regional or local authorities when not acting in their capacity
as public authorities.
Posted in Compliance, Security Architecture | No Comments »
Oct 6th, 2007 by Jesper Kråkhede
Lately I have recieved several comments from companies only wanting to promote their products. I will from now on not publish those. If I have the time I will review the webiste and product and possible write a blogentry about it. This policy affects all comments already accepted as well.
Posted in Uncategorized | No Comments »
Oct 2nd, 2007 by Jesper Kråkhede
A big security issue is that we want have a centralized authentication solution to more efficiant handle security. On the otherhand we want it to be PCI DSS compliant. With multiple hetrogenic systems using the LDAP this could be cumersome. One way is to use a secure LDAP in parallel to the ordinary one. If you choose to use your ordinary LDAP as part of your cardholder environment make sure it could withstand a penetration test and also do not handle unsecure authentication like hashes but instead uses 100% Kerberos or other such solution.
Posted in Compliance | No Comments »
Oct 2nd, 2007 by Jesper Kråkhede
Another scoping question we have is how we should look at system connecting into the card holder environment (the secure area within firewalls that has the PAN:s). With the strictest definition of system components all systems connecting into the card holder environment is within scope and all system connecting to that is also in scope. This of course as way to strict and the answers I got back today from our auditors is that the system connecting in is within scope or part of the compensating control. The “illness” is not spread to connecting systems.
This is of course very interesting. This means a lot for authentication, patch management, antivirus etc. that otherwise could have been a hassle. But the most interesting part is the way of defining the connecting system as part of the compensating control. I have a setup at a customer that I cannot show here where we actually uses the till as part of the compensating control along with some other stuff. I await aproval from the auditors but most possibly it will be enough.
Posted in Compliance | No Comments »
Oct 2nd, 2007 by Jesper Kråkhede
I have been in deep discussions regarding several scoping issues in how to define system components and how we should look at different setups. One setup is where we have a till with a serial connected terminal where all logic is inside the terminal, a.k.a. smart terminals. Even with this setup the serial cable is regarded as a network and therefor makes the till in scope due to the definition of system components. IP-terminals is most probably the way to go if you have an old POS that you wont or can´t change.
Posted in Compliance | No Comments »
Sep 29th, 2007 by Jesper Kråkhede
Apparently there is a ongoing misunderstanding regarding the difference in what you have to do when you are a level 1 or level 4 merchant. It is important to understand that ALL rules apply no matter your level but the way you prove it to the auditor differs. The main issue is that if there is a breach that is tracked back to you there will be a fullscale audit. If you have taken the short road and only made yourself compliant to reach the selfassesment questions you are in for a bad surprise when the auditors finds what you have missed. Just in a flash you are not compliant anymore and that will be very costly.
Posted in Compliance | No Comments »
Sep 16th, 2007 by Jesper Kråkhede
Now and then I am asked to do high profile forensics for customer, institutions or other organisations. One big problem is the internal politics that often moves around the edges of the investigation. It is sometimes in someones interest that an investigation is announced to media making it a lot harder for me to do the investigation. Speed is of essence when you start at an assignment so that you get you hands on as much data as possible before anyone could start muding the water.
A few times I have been approached by reporters when it has been known that I am involved in a investigations. These people are very very skilled in getting answers so my advice it to not even speek with them. Ignoring them as you pass or when they call you. Yes, I know it is rude but if there is even a remote risk that your integrity in an investigation could be threatend you have to make sure that you get out on top. Loss of integrity is loss of assignment. So keep media out.
Posted in Computer Forensics | No Comments »
Sep 11th, 2007 by Jesper Kråkhede
Just want to share my joy regarding a certification.
I do now possess GPCI, GIAC Payment Card Industry, from www.giac.org. Apparently number 50 world wide.
Posted in Compliance | 1 Comment »
Aug 16th, 2007 by Jesper Kråkhede
During my years as a security consultant I have seen many solutions that makes me wonder: “What were they thinking?” The last few weeks I have had the opportunity to learn a lot about the settlement transfers from POS(Point Of Sale) to the clearing house. I many cases they turned out to be good but some solutions make me shudder.
One of the worser example was a POS where the tills saves all transactions in an encrypted database like they should. In end of day a function was started that created a settlement file ready for transfer. It is here the bad things start. The file was created in cleartext. It was then sent to the clearing house with cleartext FTP through an ordinary internetconnection.
The most interesting part was that the POS have passed an audit before and therefore was marketed as PCI DSS compliant. That is of course a fraud becuse a system is not PCI DSS compliant. It is a specific setup at a company that could be compliant.
I just wonders what the auditors will say about the ftp transfer and the settlement file this time. 😉
Posted in Compliance | No Comments »