I'm looking for the whole list of security standards for internet banking.
I know that the internet bank has to comply with the Payment Card Industry Data Security Standard (PCS DSS).
Could you please suggest to me other similar standards/certifications for the internet-banking?
Related
I was uncertain of the correct site in StackExchange to ask this but since it's about APIs I just went with Stack Overflow.
In the US currently more and more States and companies are setting up Health Information Exchanges to electronically exchange records between different hospitals, practices, etc. What I'm wondering is: are any of these protocols, APIs, etc documented anywhere? Off and on over the last few weeks I've tried to find anything, from any state, detailing how these work specifically, but I cannot find anything. I do find vague references to "documentation" and "standards," with no detail on the protocols, encoding, etc.
It may be a case of just not searching with the correct terminology, though part of me is beginning to suspect that none are documented anywhere.
Time for an acronym stew.
I'm not aware of any specific products/platforms provided by specific HIE vendors that expose public APIs. But, there are a variety of standards in the HIT community that are commonly used by HIEs:
The HL7 standards define a large number of data exchange and message formats for all sorts of patient health information. HL7 v2 is a custom delimited format. HL7 v3 is an XML format. Both have similar semantics. This is commonly used to exchange health information with an HIE. Note that this is a very broad standard and HL7 messages are highly subject to interpretation or customization in terms of which individual elements are required or utilized by each vendor.
CCD and CCR are also commonly used for exchange of health data, especially in conjunction with PHR (Personal Health Record) systems such as HealthVault.
LOINC and SNOMED are sets of standard names and identifiers used, among other places, in HL7 messages.
I've often seen SAML used in SOAP messages to provide additional security.
SAML only provides authentication/authorization support. HL7 is not encrypted so for HIPAA compliance when communicating between enterprises you either need to encrypt the connection via SSL or a VPN or use an application layer encryption solution such as CloudPrime
Disclosure: I am an advisor to CloudPrime.
Imagine that you have thousands or millions documents signed in CAdES, XAdES or PAdES format. Signing certificate for end user is typically issued for 1-3 years. After few years, certificate will expire, revocation data (CRLs) required for verification will not be available and original crypto algorithms will not guaranee anything after 10-20 years.
I am courious if there is some mature and ready to use solution for this. I know that this can be handled by archive timestamps, but I need real product which will automatically maintain data required for long term validation, add timestamps automatically, etc.
Could you recommend me some application or library? Is it standalone solution or something what can be integrated with filenet or similar system?
The EU does currently try to endorse Advanced Digital Signatures based on the CAdES, XAdES and PAdES standards. These were specifically designed with the goal of providing the possibility for long-term archiving and validation.
CAdES is based on CMS, XAdES on XML-DSig and PAdES on the signatures defined in ISO 32000-1, which themselves again are based on CMS.
One open source solution for XAdES is the Belgian eid project, you could have a look at that.
These are all standards for signatures, they do not, however, go into detail on how you would actually implement an archiving solution, this would still be up to you.
These are all standards for signatures, they do not, however, go into detail on how you would actually implement an archiving solution, this would still be up to you.
However, this is something what am I looking for. It seems that Belgian eid mentioned above does not address it at all. (I added some clarification to my original question).
You may find this web site helpful. It's an official site even though its pointing to an IP address. The site discusses in detail your problem and offers a great deal of advise in dealing with long term electronic record storage through a Standards based approach.
The VERS standard is quite extensive and fully supports digital signatures and how best to deal with expired signatures.
The standard is also being adopted by leading EDMS/ECM providers.
If I got your question right, our SecureBlackbox components support XAdES, PAdES and CAdES standards and pulls necessary revocation information (and timestamps) and embeds them in to the signature automatically.
What are the PCI rules to follow for storing credit card numbers in a database?
1) is this allowed?
2) if so, what rules do we have to follow?
Im looking at this site https://www.pcisecuritystandards.org/security_standards/index.php
which document should I be reading here?
1) Yes, it is allowed but very, very discouraged. Having this information in your database makes you an extremely attractive target for hackers. And if you think you can protect it, think again. Hackers have defeated the security of companies with excellent security. Your security won't be any better.
2) You have to follow the PCI rules outlined in this guide. But you may find this guide easier to understand. Go to page 14 for what you need to know. Basically you can store it but it has to be encrypted according to PCI standards. Your server and network also must be secure. If any piece of the puzzle is not PCI compliant you cannot store the credit card numbers. That rules out most shared hosting companies as a solution.
This is not a direct answer, but a suggestion. Please don't downvote; I'm just trying to be helpful. After much experience with PCI compliance, I strongly suggest you avoid having credit card information on your systems if at all possible.
The approach we have used (with great success) is Tokenization. There are services that will collect and store your credit card information for you. You make an API call to get a token, generally a hash of some kind, which represents the credit card's primary account number. When you want to bill the card, you pass the token and other transaction details, and they process they payment.
Here is an straightforward article about the process:
http://www.creditcards.com/credit-card-news/tokenization-to-fight-credit-card-id-theft-1282.php
There are lots of options for this these days:
https://www.adyen.com/blog/tokenization-payment-technology-guide
http://www.elementps.com/software-providers/security/pass/
http://www.cybersource.com/products_and_services/payment_security/payment_tokenization/
For more information on that approach you can use the Google Search: Credit Card Tokenization.
You can but it's expensive to do.
You need to have DNS provided by another service or a dedicated DNS server.
You need to have a dedicated server running your SQL Server database and nothing else.
You need to use PCI approved software.
Your Database server needs to be within the same Data center as your Web Server else you will have poor performance.
So it's best to either host your site on a PCI secure host or setup your servers as I described.
I am developing a project in cakephp. And the requirement is to integrate all types of payment getway for donet. I dont know how to integrate credit card like master card, visa, american express etc. into my project in cakephp format.
Please help me. I am very grateful to you.
CakePHP is a programming framework not a banking service.
If you need to do financial transactions, you will need to contact service providers that do this. Major banks mostly provide credit card transactions as a service. They have their own APIs and workflows, mostly something RESTlike.
See for yourself on PayPal for example:
https://merchant.paypal.com/cgi-bin/marketingweb?cmd=_render-content&content_ID=merchant/home
https://www.paypal.com/hu/cgi-bin/webscr?cmd=_merchant-outside
Cake will be a good friend implementing it, though.
Depending on which country you are conducting business in, there may be regulations to adhere to. These usually revolve around confidentiality and security, i.e. card data.
It is far easier to use third party gateways or the APIs provided by banks through their merchant accounts as you transfer the responsibility for that data to them. PayPal is the obvious one - and there are other similar payment mechanisms, but it isn't an ideal solution in every situation.
If transactions need to go straight into a business account, discuss it with your bank. Most banks have their own or a franchised solution.
We build shops with ZenCart and use SagePay as a payment solution, but I doubt it would be available outside of the UK.
Money being money, it makes money every time it is moved and a lot of people want a piece of that. As a result there are a plethora of options to choose from.
If it was a personal / non-business site, I'd use PayPal for ease. What I wouldn't do is try to build my own gateway.
Don't forget, Cake is just PHP and as such is as easy to deal with as any other PHP website. Choose your gateway provider, study its API and everything will become clear.
I've just discovered J2ME and I love the possibilities that it presents. I'm currently working on a simple application and I'd like to maybe release it as an open-source project sometime in the future.
As part of my research into J2ME and mobile devices, I looked into applet signing. It seems that people who want to create applets for free are caught between and rock and an awful shite-place. Applet signing is extremely expensive and extremely convoluted - and the expense can't be justified when coding for free.
There are a huge number of J2ME compatible devices out there - I think it would be a shame to have to ignore them, and just wait patiently for the next wave (e.g. Android).
I was wondering if other people have any ideas about ways to approach this problem?
UPDATE: I found this blog article which summarises the problem for those interested... http://javablog.co.uk/2007/08/09/how-midlet-signing-is-killing-j2me/
I thought about setting up a non-profit umbrella organisation for open-source J2ME developers who want a VeriSign certificate (as a certificate can sign code an unlimited amount of times). I would aim to raise the $500 and then enable group members to share the purchased certificate. Had a quick chat to a VeriSign rep and they thought the idea could work (as long as the organisation was registered as a legal entity).
However, since handset manufacturers now seem to be moving to support only UTI root certificates (which you can only get through the 'Java verified' programme) - this might not be as useful as I thought it could be... if anyone has any ideas would be great to hear them.
I am afraid that you are fighting a battle that you can't win. Using the restricted APIs is getting harder and harder and this is not accidental. As you've read in the blog entry you've mentioned the biggest problem is the network operators. Even if you buy a certificate from Verisign or Thawte (which is by the way cheaper), your application won't run in network operators branded phones, since these have their own CA rules.
At first it was possible for a developer to install his/her own certificate, but even this is now not possible. This strict rule is mandated by the phone manufacturers (Nokia for example) and applies to all phones (even no branded ones). I believe that this too is not accidental and is mainly because of pressure put to device manufacturers by the network operators.
Finally, although MIDP 3.0 has been announced for years, nothing has really come out of it. It seems that even Sun believe that J2ME is only for games.
All of these have been extensively discussed in J2ME forums for a long time. The general consensus is that the network operators do not want to have every phone available in the market operate as a smart phone and be able to run a third-party application. Then it will be very easy for everyone to use a cheaper, web-based alternative instead of SMS messaging for a example. This may sound as a conspiracy theory, if you are new in the J2ME world, but have in mind that network operators sell phones with their own firmware that lock even basic functionalities (e.g. transferring photos via Bluetooth or using MP3s as ringtones) to force the owner to use paid services!
I don't know if this is going to change now that smart phones (iPhone, Android, Windows Mobile) are gaining momentum. Have in mind that restrictions apply also for these platforms (notably Symbian, which is also very unfriendly for open source).
You can create a signing certificate
that you self-sign. Your users have
to be willing to trust you.
You can instruct your users how to
create a cert and self-sign with it.
Then the users have to be able to
trust themselves.
There are more or less open CAs; you
have to be willing to trust them and
convince your users to trust them.
The Java Tutorial has a section on signed applets that will lead you through the steps.
I'm a J2ME application developer and i totally agree your post. The costs for signing a MIDlet are simply unaffordable for open source initiatives and unless your're developing simple games, you'll soon or later end up in using restricted APIs to access sockets or Location API just to name two of them. This is very frustrating and if you consider that the permission policies are not always threated the same on various devices, the thing get worst: on some mobile phone you can tell the OS to trust the entyre MIDlet and never bother you at all, other continue to ask you permission every time you call for a restricted method. It's tragic!
I rellay appreciate your proposal and i think it would be a great achievement for JavaME developers.