Kantara Initiative's User-Managed Access WorkGroup (UMAWG)will reach a new milestone this month.
The UMAWG will be present at the European Identity Conference on April 17th in Munich (today).
It's mission: to show some UMA real-world examples during the Kantara Initiative Summit , which is chaired by my good friend Joni Brennan.
These examples include SMARTAM.org and a UMA-based app by Fraunhofer AISEC.
Before the UMA-show UMAnitarians have been busy with interop testing of the mentioned UMA examples.
Between 12.00 and 13.30 the UMAWG will share it's latest status, it's heritage with Oauth and OpenIDConnect and the status of the current implementations.
Unfortunately I can't be present today, but through blogs and tweets I will support my fellow UMAnitarians in answering questions and giving info on interop testing.
The UMA Interop won't be finished this day, it's just the beginning.
Because OpenID has a very good wiki on OpenID interop testing, OSIS, the UMAWG asked OSIS for help with setting up a UMA interop wiki.
With the help of the OSIS folks the UMAWG will make an effort to start interop testing of all available UMA implementations.
UMAnitarians and other UMA-interested people are invited to take a look at the OSIS-wiki and start interop testing their
UMA-based apps the OSIS-way.
Exciting times ahead for the UMAWG.
No worries, the quality of UMA is my gig, bugs are NOT allowed!
Monday, April 16, 2012
Saturday, February 4, 2012
UMA back to the future
The last 2 years I have done Some UMAnitarian work: Co-developing and evangelizing the User-Managed Access protocol.
My input: specify testcases and devise a interoperability testplan.
I also blog, tweet and FaceBook about UMA, counting THE retweets, blog and faceBook-likes & reads UMA is doing a good job.
Online UMA-marketing, I love it!
Back to testing.
Last year the UMA-specs were delivered to the IETF. A UMA-milestone, but also a wakeup-call for me.
Specs were changed, so my 2010 testcases were outdated.
Next to this, The UMA workgroup aka UMAWG, works along with OpenIDConnect for interoperability and changes in spec were necessary.
Also, more organizations got interested in implementing UMA, so it was back to the drawingboard.
However, waiting for a moment when less spec-changes were going on was wiser.
This moment has arrived and for the last two weeks UMA filled my evenings again: pseudocoding with megamugs of coffee.
Hopefully next week a draft can be sent to the UMAWG for review.
Also promising is the interoperability testing of The OpenIdConnect group (OSIS).
This interests me because of the re-usability of testmethods.
Well, that's my UMAnitarian work in a nutshell.
If this interests you, the UMAWG will be holding a UMA tweetchat, focusing on development, specs, interoperability and implementations of the UMA-protocol.
UMA tweetchat
8 February 2012
9-10am Pacific time
Tweethandle: #umachat
Ok, back to the specs for some good ol' pseudocoding
My input: specify testcases and devise a interoperability testplan.
I also blog, tweet and FaceBook about UMA, counting THE retweets, blog and faceBook-likes & reads UMA is doing a good job.
Online UMA-marketing, I love it!
Back to testing.
Last year the UMA-specs were delivered to the IETF. A UMA-milestone, but also a wakeup-call for me.
Specs were changed, so my 2010 testcases were outdated.
Next to this, The UMA workgroup aka UMAWG, works along with OpenIDConnect for interoperability and changes in spec were necessary.
Also, more organizations got interested in implementing UMA, so it was back to the drawingboard.
However, waiting for a moment when less spec-changes were going on was wiser.
This moment has arrived and for the last two weeks UMA filled my evenings again: pseudocoding with megamugs of coffee.
Hopefully next week a draft can be sent to the UMAWG for review.
Also promising is the interoperability testing of The OpenIdConnect group (OSIS).
This interests me because of the re-usability of testmethods.
Well, that's my UMAnitarian work in a nutshell.
If this interests you, the UMAWG will be holding a UMA tweetchat, focusing on development, specs, interoperability and implementations of the UMA-protocol.
UMA tweetchat
8 February 2012
9-10am Pacific time
Tweethandle: #umachat
Ok, back to the specs for some good ol' pseudocoding
Saturday, November 5, 2011
Exploring the Dutch security ecosystem in one day!
My activities with testing the UMA-protocol gave me a good insight in how companies specialized in identitymanagement deal with these protocols.
The funny thing is, I had not yet looked at how the IT-security companies look towards identityprotocols like UMA, OpenID and OAuth. Functional testing and document reviewing is one thing, but penetration testing (pentesting) requires a different method of approach.
When I found out InfoSecurity Benelux 2011 was going to take place in Utrecht I registered and attended this exposition.
Why? To find out more about the possibilities in the Netherlands to learn and practise pentesting.
Together with a mate of mine we spent a day exploring the Dutch security-ecosystem, ranging from network to antivirus companies. And more important, IT-security companies.
We visited stands, listened to keynotes and had valuable discussions with Dutch keyplayers in IT-security.
Starting with the stands, they were organized like any exposition, with the big networkcompanies like Cisco having the biggest stands and the IT-security companies the smaller ones.
Also, like any ecosystem, companies (read predators) were luring their customers (read prey) with goodies, lovely ladies (yes, I saw those too) or a F1-racing car experience (seen that before).
In half an hour both our bags were full of security-goodies and folders and we had seen some very good looking ladies (not only the promo-girls).
Then it was time for business: explore the pentest-community.
Companies like Fox-IT (remember the DigiNotar-blog), Madison Gurkha (lockpicking isn't my thing :-) ) and Dionach were on our list and they did not disappoint us.
We also found out a lot of pentesting certifiers were there, like the already mentioned Dionach with their TIGER-scheme, but also Certified Ethical Hacker (CEH)- certifiers (TSTC) and 'free' online trainers (Certified Secure).
It reminded me of the time when I visited the earlier testexhibitions where visitors were blown away with the newest testapproaches like ISEB, ISQTB, TMAP and TestFrame.
IMHO, every approach has its (dis)advantages, and a good pentester should have sufficient knowledge of these different approaches when needed. However, we have to start somewhere, so more digging in this type of certification-world will be necessary.
The afternoon was spent on listening to keynotes addressing recent security developments like the mobile banking facilities of a particular Bank, the security of social media and the history of PKI.
Very interesting stuff, and the presenters gave a clear insight in how they operate in their business with security.
Before we knew it, it was already 16.00 O'clock and exhibition stands were broken down. There was still one thing I had to do.
I had to visit the exhibition of CRYPSYS Data Security, a Dutch ICT Security Distributor for the Benelux with over 20 years of experience. And, more important, with a recent interest in my blog and tweets :-). So, I had to meet these people, although they're no pentestspecialists.
Not a wasted time, because CRYPSYS gave me a good understanding of how they do business and were very patient with my questions. A company for me to watch and learn from.
Then it was over, a few drinks and back in the train going home.
It was a very interesting day at InfoSecurity Benelux 2011, discovering new challenges, learning interesting stuff and meeting great people.
Certainly a follow-up for 2012.
The funny thing is, I had not yet looked at how the IT-security companies look towards identityprotocols like UMA, OpenID and OAuth. Functional testing and document reviewing is one thing, but penetration testing (pentesting) requires a different method of approach.
When I found out InfoSecurity Benelux 2011 was going to take place in Utrecht I registered and attended this exposition.
Why? To find out more about the possibilities in the Netherlands to learn and practise pentesting.
Together with a mate of mine we spent a day exploring the Dutch security-ecosystem, ranging from network to antivirus companies. And more important, IT-security companies.
We visited stands, listened to keynotes and had valuable discussions with Dutch keyplayers in IT-security.
Starting with the stands, they were organized like any exposition, with the big networkcompanies like Cisco having the biggest stands and the IT-security companies the smaller ones.
Also, like any ecosystem, companies (read predators) were luring their customers (read prey) with goodies, lovely ladies (yes, I saw those too) or a F1-racing car experience (seen that before).
In half an hour both our bags were full of security-goodies and folders and we had seen some very good looking ladies (not only the promo-girls).
Then it was time for business: explore the pentest-community.
Companies like Fox-IT (remember the DigiNotar-blog), Madison Gurkha (lockpicking isn't my thing :-) ) and Dionach were on our list and they did not disappoint us.
We also found out a lot of pentesting certifiers were there, like the already mentioned Dionach with their TIGER-scheme, but also Certified Ethical Hacker (CEH)- certifiers (TSTC) and 'free' online trainers (Certified Secure).
It reminded me of the time when I visited the earlier testexhibitions where visitors were blown away with the newest testapproaches like ISEB, ISQTB, TMAP and TestFrame.
IMHO, every approach has its (dis)advantages, and a good pentester should have sufficient knowledge of these different approaches when needed. However, we have to start somewhere, so more digging in this type of certification-world will be necessary.
The afternoon was spent on listening to keynotes addressing recent security developments like the mobile banking facilities of a particular Bank, the security of social media and the history of PKI.
Very interesting stuff, and the presenters gave a clear insight in how they operate in their business with security.
Before we knew it, it was already 16.00 O'clock and exhibition stands were broken down. There was still one thing I had to do.
I had to visit the exhibition of CRYPSYS Data Security, a Dutch ICT Security Distributor for the Benelux with over 20 years of experience. And, more important, with a recent interest in my blog and tweets :-). So, I had to meet these people, although they're no pentestspecialists.
Not a wasted time, because CRYPSYS gave me a good understanding of how they do business and were very patient with my questions. A company for me to watch and learn from.
Then it was over, a few drinks and back in the train going home.
It was a very interesting day at InfoSecurity Benelux 2011, discovering new challenges, learning interesting stuff and meeting great people.
Certainly a follow-up for 2012.
Thursday, September 22, 2011
A one stop NFC testing shop
As I expected a few months ago when blogging about Google Wallet
and NFC mobile payments, companies would also venture on the further development and implementation of this specific payment product.
One of the companies I followed the last months is Collis, a Dutch company with many years of experience in management of introducing new payment products.
Because testing is an important asset of Collis, I immediately thought of them when exploring the testing of mobile NFC payments.
For clarity, I have no commercial ties with this company, only the enthusiasm for testing NFC mobile payments.
So, when following the news of the NFC World Congress I found out Collis launched yesterday a Mobile Test Center for TSMs (Trusted Service Manager), which enables NFC solutions to be checked for
compliance with specifications set by a wide range of industry bodies like MasterCard, VISA, but also the NFC Forum.
Not surprising, if you keep in mind this company does the same for checking creditcard compliance for the already mentioned creditcard companies, which also are huge stakeholders in the adoption of NFC mobile payments.
The NFC-TSM ecosystem is very complex and trust is here the key issue. If its infrastructure is not trustworthy, it looses its stakeholders and it will get destroyed (compare DigiNotar and the digital certificate ecosystem).
Collis could work as a one stop shop for testing of all components of this ecosystem and contribute to the trust of NFC mobile payments, which could enhance its adoption.
As a tester I agree with the method of my Dutch colleagues at Collis and I hope I can help them improve the quality and trustworthiness of the NFC mobile payment ecosystem.
and NFC mobile payments, companies would also venture on the further development and implementation of this specific payment product.
One of the companies I followed the last months is Collis, a Dutch company with many years of experience in management of introducing new payment products.
Because testing is an important asset of Collis, I immediately thought of them when exploring the testing of mobile NFC payments.
For clarity, I have no commercial ties with this company, only the enthusiasm for testing NFC mobile payments.
So, when following the news of the NFC World Congress I found out Collis launched yesterday a Mobile Test Center for TSMs (Trusted Service Manager), which enables NFC solutions to be checked for
compliance with specifications set by a wide range of industry bodies like MasterCard, VISA, but also the NFC Forum.
Not surprising, if you keep in mind this company does the same for checking creditcard compliance for the already mentioned creditcard companies, which also are huge stakeholders in the adoption of NFC mobile payments.
The NFC-TSM ecosystem is very complex and trust is here the key issue. If its infrastructure is not trustworthy, it looses its stakeholders and it will get destroyed (compare DigiNotar and the digital certificate ecosystem).
Collis could work as a one stop shop for testing of all components of this ecosystem and contribute to the trust of NFC mobile payments, which could enhance its adoption.
As a tester I agree with the method of my Dutch colleagues at Collis and I hope I can help them improve the quality and trustworthiness of the NFC mobile payment ecosystem.
Saturday, September 3, 2011
NFC-payments and PCI-compliance: a tester's adventure!
Summer 2011 is finishing, the evenings are getting shorter in the Netherlands, so time to start blogging again.
This time I was in a dilemma, or reporting about the fraudulent certificate Google-Iran DigiNotar incident , or about looking at how NFC-payments affect payments regulations and testing.
Well, because the former is just fresh and still very guessy, I will share my thoughts on the theme which intrigued me this summer: testing mobile NFC-payments.
So, where to start?
Why not first look at what testing methods there already are on payments, especially focused on security.
For 8 years now I'm in the testing business, mainly for financial institutions, and I saw lot of compliance rules come by. One of these is for payment cards: Payment Card Industry Data Security Standard aka PCI DSS.
Hey, this seems a good start to look for testing NFC payments with a contactless card or mobile phone.
Mind you, I never tested this way, this is, for the moment, just my theoretical view on how to test NFC-payment using the PCI DSS standard. And because it's a big quest, it will take some blog posts to finish it.
But what's PCI DSS and how does it relate to NFC payments?
First I have to find out what the purpose of PCI DSS is.
Its website says:
The PCI DSS is a multifaceted security standard that includes requirements for security management, policies, procedures, network architecture, software design and other critical protective measures. This comprehensive standard is intended to help organizations proactively protect customer account data.
Aha, OK and are there any testing procedures an organisation should undertake to be compliant with the PCI security standards and get its benefits?
Oh yes,both for PCI-solutions vendors and by all entities that process, store or transmit account data must be validated against PCI compliance, except, according to Wikipedia, issuing and acquiring banks.
For vendors ,PIN transaction security must comply with the requirements and guidelines specified in the following documents: a Device Testing and Approval Program Guide and the POI Modular Security Requirements.
The program guide reminds me of the Kantara Initiative Interoperability testing programs I saw last year, so this experience comes in handy.
As every testing program it describes the purpose, the testing process in overview and detail, and what to do if a security breach or compromise takes place. These are specialized security tests done by specialized evaluation labs like T-systems as seen on this list.
For organisations handling large volumes of transactions, validation of compliance is done annually, by an external Qualified Security Assessor (QSA) , or by Self-Assessment Questionnaire (SAQ) for companies handling smaller volumes like small webshops.
To avoid a SAQ, and lessen the burden, a webshop can outsource its creditcardhandling to a payment acquirer like PayPal. PayPal is the one who should be PCI compliant, as long as the webshop does not store, transmit, or process payment card information.
This shows how complex the ecosystem is and how stakeholders are affected by the PCI compliancy.
How does NFC-payments affect the relationship between PCI compliancy and its stakeholders in the creditcard industry?
IMFO, the primary change is the method of authentication by the customer, but the underlying technology to execute this, should be PCI compliant. This means the device enabling NFC payments should be PCI compliant (meaning a different annual PCI-compliance test for authentication for the vendor) and the same for the company or payment acquirer, if the creditcard handling is affected.
Visa is even eliminating the requirement for US merchants (European program already in process) to annually validate their compliance with PCI DSS if 75% of the merchant’s annual Visa transactions originate from chip-enabled terminals.
This is done to prepare the US payment infrastructure for NFC-based mobile payments. So, the NFC-stakes are high for the creditcard companies.
Not to forget, Mobile payments brings also a new species (and not a small 1) in the creditcard PCI DSS ecosystem: the cell phone company.
It should also be PCI compliant because it is a part of the processing (I haven't seen a cellphone customer of PayPal) and can also put the creditcard bill on the phone bill or via a NFC chip put in it like Visa’s payWave or MasterCard’s PayPass.
So, for a tester there is enough adventure in the creditcard PCI DSS Ecosystem. Different stakeholders, different chains and different tests to do. I look forward to it and will share my thoughts and experiences in this new ecosystem.
This time I was in a dilemma, or reporting about the fraudulent certificate Google-Iran DigiNotar incident , or about looking at how NFC-payments affect payments regulations and testing.
Well, because the former is just fresh and still very guessy, I will share my thoughts on the theme which intrigued me this summer: testing mobile NFC-payments.
So, where to start?
Why not first look at what testing methods there already are on payments, especially focused on security.
For 8 years now I'm in the testing business, mainly for financial institutions, and I saw lot of compliance rules come by. One of these is for payment cards: Payment Card Industry Data Security Standard aka PCI DSS.
Hey, this seems a good start to look for testing NFC payments with a contactless card or mobile phone.
Mind you, I never tested this way, this is, for the moment, just my theoretical view on how to test NFC-payment using the PCI DSS standard. And because it's a big quest, it will take some blog posts to finish it.
But what's PCI DSS and how does it relate to NFC payments?
First I have to find out what the purpose of PCI DSS is.
Its website says:
The PCI DSS is a multifaceted security standard that includes requirements for security management, policies, procedures, network architecture, software design and other critical protective measures. This comprehensive standard is intended to help organizations proactively protect customer account data.
Aha, OK and are there any testing procedures an organisation should undertake to be compliant with the PCI security standards and get its benefits?
Oh yes,both for PCI-solutions vendors and by all entities that process, store or transmit account data must be validated against PCI compliance, except, according to Wikipedia, issuing and acquiring banks.
For vendors ,PIN transaction security must comply with the requirements and guidelines specified in the following documents: a Device Testing and Approval Program Guide and the POI Modular Security Requirements.
The program guide reminds me of the Kantara Initiative Interoperability testing programs I saw last year, so this experience comes in handy.
As every testing program it describes the purpose, the testing process in overview and detail, and what to do if a security breach or compromise takes place. These are specialized security tests done by specialized evaluation labs like T-systems as seen on this list.
For organisations handling large volumes of transactions, validation of compliance is done annually, by an external Qualified Security Assessor (QSA) , or by Self-Assessment Questionnaire (SAQ) for companies handling smaller volumes like small webshops.
To avoid a SAQ, and lessen the burden, a webshop can outsource its creditcardhandling to a payment acquirer like PayPal. PayPal is the one who should be PCI compliant, as long as the webshop does not store, transmit, or process payment card information.
This shows how complex the ecosystem is and how stakeholders are affected by the PCI compliancy.
How does NFC-payments affect the relationship between PCI compliancy and its stakeholders in the creditcard industry?
IMFO, the primary change is the method of authentication by the customer, but the underlying technology to execute this, should be PCI compliant. This means the device enabling NFC payments should be PCI compliant (meaning a different annual PCI-compliance test for authentication for the vendor) and the same for the company or payment acquirer, if the creditcard handling is affected.
Visa is even eliminating the requirement for US merchants (European program already in process) to annually validate their compliance with PCI DSS if 75% of the merchant’s annual Visa transactions originate from chip-enabled terminals.
This is done to prepare the US payment infrastructure for NFC-based mobile payments. So, the NFC-stakes are high for the creditcard companies.
Not to forget, Mobile payments brings also a new species (and not a small 1) in the creditcard PCI DSS ecosystem: the cell phone company.
It should also be PCI compliant because it is a part of the processing (I haven't seen a cellphone customer of PayPal) and can also put the creditcard bill on the phone bill or via a NFC chip put in it like Visa’s payWave or MasterCard’s PayPass.
So, for a tester there is enough adventure in the creditcard PCI DSS Ecosystem. Different stakeholders, different chains and different tests to do. I look forward to it and will share my thoughts and experiences in this new ecosystem.
Subscribe to:
Posts (Atom)