Patterns for security

4 Sep 2005 7:27 PM

STom

I have several clients that are entering into situations where credit card
information is flowing through their system. So from a public web server, a
person enters their credit card information, the information must flow to an
application server (possibly even through BizTalk) and then onto either SQL
databases or mainframes.

Are their any patterns or best practices for the types of components a
person would need to design to handle such a task?

I would envision, from the web server, having a component that would encrypt
the data and pass it through the system. The information would have to be
unencrypted on the mainframe, but not while enroute to the mainframe.

I'm certainly a beginner at this secure data transmission topic and would
appreciate any help.

(I have cross posted into the microsoft.public.security.crypto group because
I'm not sure I'm asking the question in the right place)

Thanks.

STom

4 Sep 2005 11:19 PM

rounner

You're writing a web app that needs credit card info?
There are standard practices for handling this, and the security
considerations are known and discussed and you can risk mitigate. For
example you may arrange to have SSL certificates sent to your clients
to secure the transaction (look up mutual SSL authentication and check
phishing/ pharming too). If you have millions of clients then this may
be deemed too logistically difficult.
When you say a clients confidential data will not be stored securely on
the mainframe... you might want to reconsider.

5 Sep 2005 12:13 AM

STom

Yes, this is a web app that will pass the request through the DMZ, through a
firewall to the app server. I believe at this point we may be using BizTalk,
which really doesn't have much to do with it I guess.

The problem still remains, keeping the CC info encrypted all the way
through.

You say there are standard practices for doing this. Thats what I'm looking
for. Any links you could provide?

Thanks.

STom
<roun***@yahoo.com> wrote in message
Show quoteHide quote

news:1125875972.665194.5200@g47g2000cwa.googlegroups.com...
> You're writing a web app that needs credit card info?
> There are standard practices for handling this, and the security
> considerations are known and discussed and you can risk mitigate. For
> example you may arrange to have SSL certificates sent to your clients
> to secure the transaction (look up mutual SSL authentication and check
> phishing/ pharming too). If you have millions of clients then this may
> be deemed too logistically difficult.
> When you say a clients confidential data will not be stored securely on
> the mainframe... you might want to reconsider.
>

16 Sep 2005 12:11 AM

carion1

If the back end is SQL Server just use SSL. I am sure BizTalk would support
an SSL connection. Got me on the main frames.

--

Derek Davis
ddavi***@gmail.com

Show quoteHide quote

"STom" <stombiztal***@hotmail.com> wrote in message
news:%23PN7k6asFHA.2072@TK2MSFTNGP14.phx.gbl...
> Yes, this is a web app that will pass the request through the DMZ, through
> a firewall to the app server. I believe at this point we may be using
> BizTalk, which really doesn't have much to do with it I guess.
>
> The problem still remains, keeping the CC info encrypted all the way
> through.
>
> You say there are standard practices for doing this. Thats what I'm
> looking for. Any links you could provide?
>
> Thanks.
>
> STom
> <roun***@yahoo.com> wrote in message
> news:1125875972.665194.5200@g47g2000cwa.googlegroups.com...
>> You're writing a web app that needs credit card info?
>> There are standard practices for handling this, and the security
>> considerations are known and discussed and you can risk mitigate. For
>> example you may arrange to have SSL certificates sent to your clients
>> to secure the transaction (look up mutual SSL authentication and check
>> phishing/ pharming too). If you have millions of clients then this may
>> be deemed too logistically difficult.
>> When you say a clients confidential data will not be stored securely on
>> the mainframe... you might want to reconsider.
>>
>
>