On Wed, 9 Mar 2011, Chris Hoogendyk wrote: > On 3/9/11 10:47 AM, Charles Polisher wrote: >> Ryan Dorman wrote: >>> I echo Nick's comments. I'm responsible for security at an L1 >>> service provider, L3 merchant and PA-DSS development shop (along >>> with the 1k other things everyone on this list does :) ) and I >>> have found that the two cardinal rules of payment applications >>> are: >>> >>> 1. Limit the scope >>> 2. Outsource, outsource, outsource >>> >>> Since I'm repeating what someone else said I'll only cop to this being my >>> $0.01 >> This resonates with me, but not in a good way. It's certainly >> the best advise - I don't mean to criticize answer number (2), >> except that I am going to, in the context of how our shop goes >> about it. I'm lifting the outsourcing issue out of it's >> PA-DSS/PCI-DSS context and plunking it down into one of my >> choosing. >> >> My shop outsources all the time. The theory is that we >> exchange money for time. In many cases we don't have the time >> to suss out requirements, anaylze problems, or evaluate >> technology. We don't make the time to bring technical staff >> together to discuss alternatives. We rely on consultants and >> salespeople to guide our decisions, backed by favorable writeups >> in the industry Consumer Reports-like publication. (Vendors pay >> to get evaluated in that report; self-selection issues and >> integrity of its analysis is problematic, yet it has enormous >> clout to go with its spotty track record.) >> >> We're caught between vendors' shiny brochures and the Tragic >> Quadrant. Silver bullet salesmen have scrawled their >> hobo-sign[*] on our front gate (Top Hat). Technical >> staff are in shock over decisions taken, generally *after* >> they're announced. We've entered a positive feedback loop: >> we're too busy supporting ill-fitting solutions to examine >> our process and make corrections to it. From a Systems Admin >> viewpoint it's ... challenging. Silver lining: I get to >> sharpen my troubleshooting and integration skills. >> >> TL;DR: 2. Outsource if you must. Be careful with due diligence. >> >> [*] >> https://secure.wikimedia.org/wikipedia/en/wiki/Hobo_sign#Hobo_.28sign.29_code > > Two ends of a spectrum. > > Bringing it back into focus with respect to order processing and financial > transactions -- this is a > specialized and regulated area that has legal responsibilities, financial > consequences for security > failures, and serious potential liability. If it is a central part of your > business, and you are > large enough and have the staff to focus on all those issues (including both > accounting and legal > staff on top of the systems and development staff), then go ahead and do it. > If you don't, then > outsource. There is just too much risk in taking it on yourself. Of course, > I'm talking to the > company. Sysadmins may or may not have much influence on the decision. > > Credit unions, small banks, and small businesses all outsource this stuff. > Even some of the larger > banks outsource it. There are standard places to go for it. There are also > regulations and both > financial and legal recourse if those places fail you. Best of all, the > liability is not on your > shoulders, and you can dump them and switch. It can hurt your business, but > it shouldn't deep six > you with the weight of the liability.
I work at one of the companies that the banks outsource things to. Believe me you do not want to have to get involved with this area if you can avoid it. the regulations have good ideas behind them, but they are nebulous enough in some areas, and overly specific in other areas to be a problem (how do you maintain anti-virus on AIX systems for example). The meaning of the regulations depends on the individual that is assigned to review your company (this individual is assigned from a company that you hire to dothe review), and there is little room for appeal if you disagree with their interpretation. you will spend many times more hours dealing with audit paperwork, discussins, legal folks, etc than you will spend doing anything technical (including designing and implementing all the security measures involved) this same individual can also make decisions that will make you question their sanity about how lax things can be, you really want to make sure that you management is willing to go beyond what they require you to do if you and your staff see other things that should be done. You don't want to end up in the press about being broken into and try to defend based on 'but we were PCI certified', and this has happened, repeatedly. David Lang _______________________________________________ Tech mailing list [email protected] https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech This list provided by the League of Professional System Administrators http://lopsa.org/
