One of the biggest headaches that Information Security Officers face is dealing with compliance surrounding legacy computing environments. Modern system architectures contain more progressive and disseminated areas which fall into modularity design. This makes it easier to "separate" modules from one another so data transfer and process communication do not become part of a QSA's scope.
Due to numerous co-mingled factors related to software modules on legacy platforms, the separation strategy is sometimes impossible. Legacy development processes and infrastructure tended to keep everything "on one box." For example, an IBM midrange AS/400 system containing two decades of homegrown RPG code with minimal COTS investment can only partially subscribe to the concept of separation. If a QSA does not believe there are adequate access controls in place (kind mind, many legacy systems were developed before many standard information security and audit/control objectives were published), they may start placing other parts of the system in scope which have nothing to do with payment card data, yet just by being in the "flow path" of data they are automatically included. Finding mitigating controls can even be more difficult to remove these from the QSA's "scope rope", as many IAM (identity & access management) tools do not operate well in environments with hundreds of custom created applications.
Breaking out and fully separating the credit card processing functions from legacy systems is typically the best answer. Many merchant banks now support the concept of tokenization and building or using an MSP (managed service provider) for payment gateway services is a great way to accomplish fast time to market and shifting of liability. Cost savings from an ROI perspective can be found from the removal of operational duties spent in supporting payment card services in legacy environments along with a reduction in maintenance and encryption services and/or software.
Post a Comment