IBM Security Services PCI Blog
Andi Baritchi 27000216AA email@example.com Tags:  service vendors providers sharing pci 1,288 Visits
PCI DSS Requirement 12.8 seems to be a source of confusion for lots of folks in the industry.
"What's a service provider?"
"What counts as sharing credit card data?"
This example, from a totally different industry, really helps illustrate the intent behind requirement 12.8. That intent being, make sure the people who help you store, transmit, or process cardholder data don't mess up. That includes people helping you manage your systems, host your systems, or monitor your IDS...
Andi Baritchi 27000216AA firstname.lastname@example.org Tags:  security flow analysis mapping data 892 Visits
Install and lock down firewalls. Change your passwords. Encrypt this. Encrypt that. Secure it all ad nauseam. And you're done. Right?
Well, not so much...
It takes a thorough understanding of how something works in order to fix it. In the case of security, that means understanding what it is you're trying to secure. The more experienced the security professional (or should I say jaded? ), the more likely you are to see him or her perform a data flow mapping as step zero of any infosec project. This exercise isn't just about plotting data points - you're performing a business process analysis and documenting how the business functions. You just happen to be focusing on how the data is stored, transmitted, secured, etc. in the process.
This is a prereq for any PCI security assessment, but it applies to all the other kinds of sensitive data. Does your business deal with SSNs? Protected Health Information? ITAR data? Or is perhaps your own corporate data of value to you?
If so - can you confidently say you know all the places you're currently storing, transmitting, processing, or otherwise touching ___-data? Can you identify all the security measures in place?
Andi Baritchi 27000216AA email@example.com Tags:  pci dss malware appliance anti-virus point-of-sale usb 725 Visits
If they see cardholder data - YES. Check out The TJX Effect and Keeping Point-of-Sale Equipment Secure for the rationale behind this.
Any merchant should protect their point-of-sale environment to the same level as the rest of their cardholder data environment. Maybe even a higher level since the POS's are more vulnerable to physical threats.
Cute commercial from the PCI Security Standards Council explaining the virtues and requirements of the DSS...
Hat tip to Martin.
Andi Baritchi 27000216AA firstname.lastname@example.org Tags:  virus trojan lawsuit pdf malware compliance heartland merrick qsa virtualization 2009 recession security computing pci savvis year cloud review new 1,658 Visits
Wow . Another one's gone by. 2009 felt like a flying lap around the Nürburgring. The ups. The downs. The slip angles. And ah yes, the opposite lock.
So... Let's take a look at look at the top events and trends that helped shape the year from a PCI perspective:
Best of luck to everybody in the new year and have a happy, successful 2010!
¡Felíz año nuevo! La mulţi ani!
David Mundhenk 2700022KT6 email@example.com Tags:  pci compliance hardening system wmq middleware 1,770 Visits
PCI Compliance Blind Spot: Middleware
One of the great things about industry standards is that there are usually more than one to salute at any given time. The true acid test for any security compliance standard is how applicable the standard remains given changes in technology, business and governmental requirements and ever evolving threats.
The PCI Data Security Standard is one that, despite grumbling by some detractors in the market space, is written well enough to do exactly that. When one thinks of PCI compliance as it relates to various IT architectures one usually thinks of traditional Point of Sale systems, e-commerce web implementations, and payment processing gateways. To date most of these architectures have involved classical client-server types of infrastructure, and in some instances even with some integrated components that are mainframe based.
A not-so-new, albeit rapidly evolving web-facing IT architecture implemented over recent years is currently testing just how well written the PCI DSS is. It is known as a Service Bus Architecture (SBA) and also sometimes referred to as a Service Oriented Architecture (SOA). It is from these types of implementations that highly sophisticated, large-scale web portals are often comprised. Essentially well-designed, and they often employ non-trivial web application front ends which provide large scale, highly available access to multiple and duplicitous web service offerings and highly diverse database storage capabilities. Due to their scalability and stringent service level fulfillment capabilities they often comprise the core of industrial scale e-commerce, banking and finance web applications and services.
Certainly one can view this type of architecture as essentially being built from a myriad of various client server based modular components. Often they require the addition of additional auxiliary software systems to help ‘sew together’ the components into a cohesive, highly dynamic web and data services framework. These components are often referred to as ‘middleware’. A very specific type of middleware that helps to translate complex messaging across this type of architecture is called, quite simply, message-oriented middleware or "MOM".
From Wikipedia we derive the following definition of MOM:
“Message-oriented middleware (MOM) is infrastructure focused on sending and receiving messages that increases the interoperability, portability, and flexibility of an application by allowing the application to be distributed over heterogeneous platforms. It reduces the complexity of developing applications that span multiple operating systems and network protocols by insulating the application developer from the details of the various operating system and network interfaces.”
Traditionally PCI DSS compliance assessments of web-facing applications have focused on assessing the security of the overall web-facing server and applications components, DMZ-based logical separation components such as firewalls and routers, relevant database storage elements deployed in the interior network, and the communications services between them all. Assessing the PCI data flows associated with such traditional client-server based web application infrastructures is a fairly straightforward endeavor.
Assessing the PCI compliance of highly sophisticated SOA or SBA implementations, however, is a bit more challenging. This is due to the multiple cardholder data flow combinations possible throughout the various SOA application interfaces, numerous database components and possible interconnections with customers, and also between various business partners. This is not a bad thing – it’s exactly why SOA/SBA architectures have been conceived of, and implemented wide scale in the first place. If well designed and correctly implemented, they are remarkably suited and scaled to accommodate industrial scale web application based business services provision.
In large part, a good percentage of communications between such non-trivial architecture components is facilitated by middleware messaging software and systems. And as one might suspect is the case when dealing with the storage, processing, and transmission of cardholder data, it is often precisely the scheme used to help transmit various aspects of the payment card transaction authorization and settlement processes. These can include actual transaction requests and responses, back-end settlement capabilities, and various types of reporting.
When considering middleware systems compliance with the PCI DSS, the very same requirements that are applied to client-server or mainframe systems applies. At a very high level they can be summarized as follows:
1) Develop and maintain system build standards that reflect industry recommendations for securing such systems. These are often referred to as “hardened” build standards.
There are obviously more subtle aspects to the PCI DSS that also apply, however, the fact remains that middleware is by no means allowed any differing or diminished security considerations than any other systems handling cardholder information.
As with many operating systems, web software, payment applications, network components, etc., it is often the case that default installations of associated software are not auto-magically configured to be compliant with PCI DSS or any other security standard. It is incumbent upon those architecting and implementing such systems to sufficiently harden their configurations such that standards compliance, and indeed optimal critical data protection is achieved. A good example of this is with respect to message-oriented middleware software is IBM’s WebSphere MQ (WMQ). A default installation of the product right out of the box will most assuredly not be PCI DSS compliant.
The good news is that IBM has its own core WMQ subject matter expertise, and indeed an evangelizing subject matter expert on the proper assessment and securing of WMQ implementations. His name is T.Rob Wyatt.
T.Rob has many years of experience with WMQ and has provided guidance to quite literally hundreds of IBM customers, as well as the IBM ISS Global PCI Practice in assessing and supporting PCI compliant WMQ implementations.
T.Rob’s diligence, passion for “getting the message out” and un-yielding efforts to accurately convey WMQ best practices and techniques are commendable. He is a tremendous asset and is ready, willing and able to help. His thinking and efforts are entirely consistent with the philosophy of the Information Security industry whereby “security through obscurity” never works out. Even if attempted, more damage will probably occur over the long run than not. He also believes that the best defense is a good offense when it comes to securely configuring WMQ and other systems. As was said in Ghostbusters the movie, “…we have the tools and we have the technology.” Now let's go forth and make it a better, no check that, “let’s make it a smarter WMQ world”.
You can find more about T.Rob and his efforts at the following website and twitter:
In the next blog installments, we will review T.Rob's WebSphere WMQ best practices recommendations, and how not addressing them can adversely affect your overall PCI compliance if using WMQ in PCI environments.
Andi Baritchi 27000216AA firstname.lastname@example.org Tags:  security website compliance ibm solutions pci iss 1,218 Visits
Andi Baritchi 27000216AA email@example.com Tags:  pci business security compliance roi 997 Visits
IBM whitepaper hot off the presses: The Return on Investment of PCI DSS Compliance (PDF).
David Mundhenk 2700022KT6 firstname.lastname@example.org Tags:  pci nrf qsa compliance dss retail 1,862 Visits
It has been no secret that retail merchants and their industry representation have been extremely unhappy with having to comply with Payment Card Industry Data Security Standard (PCI DSS) requirements. Their industry representative presentations at the recent Congressional hearings on the effectiveness of PCI DSS showed that their spokespeople could barely contain their vitriol during testimony. In addition, the National Retail Federation has also recently published an ‘open letter’ to the PCI Security Standards Council regarding their collective discomfort over PCI requirements. A copy of this letter can be found at their own website via the following link:
This blog entry is not intended to make light of the concerns of the retail industry regarding PCI DSS, nor to dismiss their assertion that having to comply with the requirements isn’t pain or duty free. The challenges of complying with PCI DSS are measurable, and for some businesses difficult to address. This is especially true for small-to-medium sized businesses which may lack the expertise, bandwidth or resources to formulate an effective response to meet the requirements. The NRF collective attempts to make overall industry improvements for the better should be applauded, however, after reviewing the highlights of their recommendations it appears that they may have been drafted in haste.
What they have proposed is interesting and deserves some analysis and an objective response. The following is a representative sampling of NRF recommended improvements with respect to the current PCI compliance requirements, and also an interpretive viewpoint on the items noted:
National Retail Federation (NRF): Incorporate a formal review and comment phase on revisions to the PCI DSS by participating membership before they are issued.
Objective Response (OR): This is already taking place. The PCI SSC solicits feedback from certified QSAC’s and their respective QSA’s prior to finalizing version changes. In addition they sponsor “town hall” meetings where merchants and service providers who attend can ask questions, make recommendations, and vent their frustrations.
NRF: Ensure the amount of time from issuance of a revision to the
PCI DSS and the effective date is appropriate for all merchants, including
Level-1 merchants making enterprise-wide changes, based on the revisions that
are being implemented,
OR: This is purely subjective, no matter how much time is allotted there will be a contingent of merchants and others who feel like they need more time. The PCI SSC has to draw a line in the sand somewhere. In addition the PCI SSC has recently provided additional assistance for level 2, 3, and 4 merchants with their new, improved Self Assessment Questionnaires and their recommendations for a “prioritized” approach to achieving compliance.
NRF: Follow, and adopt, the ASC X9 announcement of its plan to develop a new standard to protect cardholder data that may include end to end data encryption.
OR: This is very interesting, and apparently their lone
recommendation toward relieving all the perceived pain and suffering associated
with having to comply with the PCI standard. They actually seriously propose
adopting yet another compliance standard? Especially one that is not even
mature yet? Yessir, and
They also propose adopting the supposed “holy grail” of cardholder data protection which is sometimes called “end-to-end” encryption. Sounds like a great idea in principle, but implementing end-to-end encryption will be a serious challenge for all parties currently involved in payment processing and settlement across the globe. It may actually be a viable prospect for the future and possibly successful over the long term. Initially, however, it will be incredibly expensive to deploy, administer, and maintain on a global scale. One also wonders what it will be like for everyone involved to re-initialize and then maintain all those crypto keys in a secure, PCI compliant fashion.
NRF: Utilize the concepts of key controls and controls rationalization to restructure the more than two hundred detailed requirements of the PCI DSS.
OR: This one too is fairly entertaining since the PCI DSS is already
constructed to accommodate what is known
SOX and SAS70 requirements permit unencumbered business operations to continue even if total compliance with their requirements has not been achieved. Also in some instances the auditor and the entity audited sit down prior to the exercise and “agree” upon the audit criteria to be measured against. "What? You don't want to rotate your encryption keys because you 'feel' like it is too much work? OK then! You don’t have to do it." This approach is not going work for PCI, which is one of the few required security frameworks that actually incorporates some level of enforcement for those who refuse to comply.
NRF: Require credit card companies and their banks to provide merchants with the option of keeping nothing more than the authorization code provided at the time of sale and a truncated receipt, rather than requiring merchants to store credit card information for dispute resolution, putting customers at unnecessary risk.
OR: Where PCI compliance is concerned this is a non-issue. Nothing within the PCI DSS nor the PCI PA-DSS requires the merchant to retain anything post authorization. Even section 3.1 & 3.2 of the PCI DSS clearly states the following:
3.1 Keep cardholder data storage to a minimum. Develop a
data retention and disposal policy. Limit storage amount and retention time to
that which is required for business, legal, and/or regulatory purposes,
3.2 Do not store sensitive authentication data after authorization (even if encrypted).
The PCI DSS doesn’t require having the merchants store any CHI post authorization. Some “issuer-processors” may actually be doing so on behalf of their customers (i.e. – banks, financial institutions, credit unions, etc.) who already own the data they are asking to be collected. In addition any sensitive authentication data being captured by them is usually collected during the pre-authorization process. Since the banking industry already "owns" this data, why shouldn't they be allowed to collect it? The additional audit compliance requirements imposed by the card brands on their issuer-processors accommodate a trusted relationship that allows for this to take place only under extremely special circumstances.
If a merchant does not want to collect CHI information for any reason what-so-ever post authorization they currently can choose not to do so. In reality it is usually the case that merchants have been collecting this type of information for years for their own business intelligence and data mining purposes. They are often unwilling to commit the resources required to re-tool their IT applications and infrastructure to support not storing CHI.
It has been reported in some Internet postings that the PCI DSS offers "minimum general recommendations for security" for systems storing or processing CHI. This is a myth. The PCI DSS is indeed a standard and a framework, not detailed process or procedural recommendations on how to secure PCI systems. This is somewhat akin to the OSI model defining the seven protocol and architecture layers for computing systems and networks, but not detailing “how” they should be configured down the system level. The corresponding PCI DSS Requirements and Security Assessment procedures, however, are exacting in spelling out how to measure PCI DSS compliance within a given environment.
The effects of changing or re-engineering an operational business enterprise to become PCI compliant are usually measurable and often significant. Sometimes dealing with any change to normal business operations especially in tough economic times is very uncomfortable, however, managing change and potential risk to business assets is a simply a major component of doing business safely and securely. Reducing or eliminating the emotional aspects of having to do so helps provide focus and reduces anxieties associated with doing so. It also helps to aid in complex decision making. The PCI DSS and related compliance processes are not perfect, but their adoption has resulted in a significant industry improvement over doing nothing, or adding additional security standards to the mix.
Andi Baritchi 27000216AA email@example.com Tags:  cardholder risk security compliance breach lawsuit pci 1,733 Visits
Co-written by Andi Baritchi and David Mundhenk
The recent news that Merrick Bank is suing Savvis for negligence regarding the CardSystems compromise back in 2004 is creating quite a buzz on security blogs and other sites across the web. Merrick Bank is alleging that Savvis was negligent when conducting a CISP audit (a contributing predecessor to PCI DSS assessment) for CardSystems, that this negligence led to a serious breach of credit card information, and ultimately to related large scale liabilities and costs that Merrick Bank incurred. They are seeking compensation for these costs, to the tune of $16 million.
This news is polarizing the security blogosphere. The popular “buzz” over the announcement is that this is supposedly a wake-up call for the industry, especially if Merrick ultimately proves that Savvis was indeed negligent. The mounting anxiety over this is creating a scenario whereby all those who have complained about the pitfalls and complexities and costs of compliance, in a figurative sense, are now lining up with a big stick in hand ready to flail away at the PCI compliance piñata. They are ready to vent their collective pent-up frustrations by disparaging and dismissing the PCI compliance process, and especially the QSAs who perform these assessments. (Note they are now called assessments by the PCI SSC, not audits). They do so hoping the figurative “spoils” that might spill from the busted PCI piñata will include relaxed compliance requirements and reduced fines and penalties for non-compliance.
The PCI SSC has gone to great lengths to write a unified security standard to help protect the cardholder information (CHI) for the founding member card brand customers. It has developed a fairly rigorous training and certification program for those who perform PCI DSS compliance assessments. Only certified companies with certified Qualified Security Assessor (QSA) personnel can perform such work. In addition, there are Quality Assurance steps in place to help identify and restrict those QSAs that do not, or cannot perform to minimum levels of professional competency. There are also stipulations that companies who perform this work must not only recommend their own products for solutions. That having been said, no standard is perfect, nor are companies or people. There can be instances where mistakes are made. It is also quite possible that there are some bad apples involved in this business who have somehow circumvented the checks and balances designed to establish and maintain a minimum level of professional competency. But this is why the Council has its QA process.
The PCI DSS at a rudimentary level can be compared to Information Security 101, but it goes much deeper than that. Much like the more mature audit frameworks in the financial sector, the goal of PCI is to protect sensitive private information – and in doing so install a level of transparency into enterprise information security, reduce fraud, reduce risk, and increase confidence. PCI isn’t perfect, and its biggest weakness is its reliance on the integrity of the business being assessed. It is, however, the strongest driver for information security in the business world we’ve seen to date. Thus far PCI and its predecessors have identified and helped mitigate a staggering amount of risk to CHI due to insecure systems and business processes.
While there has been an impressive improvement in the overall protections afforded by all of these Infosec standards both individually in a collectively, there is still no guarantee that systems assessed for compliance are completely secured against compromise or misuse. There are no guarantees with this, just as there are no guarantees in business. A significant component of managing businesses and organizations involves managing all risk to corporate assets. And even if all reasonable and cost effective protections are in place, stuff can still happen. In addition it is important to understand that all IT environments, including those that process credit card payments are highly dynamic environments. An audit or an assessment of such an environment takes place over a finite time period. It represents a “snapshot” in time at the time of the assessment. The assessor attests to the overall compliance of a given environment during that time period, and then provides a reference date for making that assertion. If a compliant business or organization induces any change to that environment after the fact, there are no guarantees that the environment is still compliant.
What does this all mean when it comes to the Merrick Bank lawsuit against Savvis? Merrick has a large burden of proof ahead. They have to prove that (a) Savvis was negligent and that the alleged noncompliance was there at the time of the CISP audit, meaning their Report On Compliance (ROC) was false, (b) the breach would not have occurred had they been compliant, and (c) this is their biggest hurdle: they have to prove that Savvis is somehow liable for Merrick’s damages even though Savvis had no business relationship with Merrick Bank (Savvis was hired by CardSystems, not Merrick). Whichever way the lawsuit goes (with today’s legal system I’d rather go to Vegas than call that one), the real lesson here is to be damn sure all requirements are met before professionally attesting to security related organizational compliance.
There is one key to
understanding PCI compliance (or any compliance program for that
matter) – there is no ‘silver bullet’ solution. There are vendors that
will try to sell you solutions that will guarantee 100% hackproof
security with full compliance, however the truth is that such a thing
doesn’t exist. It’s a panacea to think otherwise. Security is all
about risk management, and the bad guys tend to be pretty skilled and
resourceful. Not only that, they only have to be “right” just one time.
As a merchant or service provider pursuing PCI compliance, the goal
shouldn’t be to achieve it and then put a “safe from hackers!” sticker
on your website. Doing so or anything like it will only increases
possible risk. The end goal is to determine your business’ risk tolerance, and bring your risk tolerance profile to acceptable levels.
Similar decisions are made when determining “should I become compliant
with PCI or just pay the costs of noncompliance?” Same risk management
model as the one you use every day deciding whether to speed on the
freeway, except PCI compliance actually makes sense.
Look for our new IBM ISS white paper on the ROI from PCI Compliance, coming to this blog soon.
David Mundhenk 2700022KT6 firstname.lastname@example.org Tags:  secure dss jfs compliance pci delete 1,507 Visits
Meeting the Spirit of PCI Secure Delete
3.2 If sensitive authentication data is received and deleted, obtain and review the processes for deleting the data to verify that the data is unrecoverable.
The critical concept contained in this statement is that of rendering the sensitive data no longer needed “unrecoverable”. If sensitive data is stored within RAM then it is a pretty safe bet that once data has been deleted from RAM elements, then the intensive I/O dynamics of a system’s RAM offers its own built-in extensive data space ‘over-writing’ capabilities. In this sense the data is rendered “unrecoverable” very quickly, i.e. – no matter the time and resources available, it would be virtually impossible to reconstruct the original data structures. Even if one could, extracting and preserving real-time RAM data presents its own challenges and also should require highly privileged access to a given system. It is reasonable to conclude that the degree of difficulty in trying to extract bits and pieces of sensitive data from RAM given this scenario would render the data ‘virtually’ unrecoverable.
Securely deleting files from any file system including JFS requires using a ‘mil-spec’ data eradication utility. While doing so may not completely remove all sensitive data from low level data elements, it creates a scenario whereby a significant work effort is required try to recover meaningful data. It would require more so than if the data elements were simply deleted via file system utilities. Increasing the number of successive passes of this data eradication utility over the same data space would further reduce the probabilities that it could be successfully recovered.
So this yields the philosophical and yet highly practical question, “…how many passes from a ‘secure delete’ utility are enough to render the data virtually unrecoverable?” The answer to this question depends upon many factors, but obviously some reasonability should be applied here. The goal is to increase the difficulty and the amount of work required to recover any remaining data following the secure delete function, thereby rendering it an extremely time-consuming, expensive and highly dubious process. Ultimately the time and resources required to reconstruct such data would not be worth the prize of being able to successfully do so. In addition, limiting the types and quantities of sensitive data being stored and/or processed by the system also enhances this security proposition. This is because less sensitive stuff is ultimately being captured, preserved, and at some future time required to be ‘end-of-lifed’. Another consideration is to reduce the amount of journaling being done by the file system, and some JFS’ actually provide the capability to adjust journaling attributes. If possible, a combination of all of the above should be considered to optimize overall security and ensure compliance with PCI DSS requirements.
As most know there are relatively few absolutes in this world. Given this fact, Journaling File Systems present some interesting challenges with respect to PCI compliance. The ultimate goal is to provide a reasonable, cost effective effort to ensure that sensitive PCI information no longer needed be indeed rendered virtually ‘unrecoverable’. Now given the possibility of unlimited time and resources, it may be theoretically possible to recover data given the aforementioned scenario. The amount of time and effort required to do so, however, would cost far more than the data is worth. This yields an effective deterrent to those considering an attempt at such a data recovery. It would also require privileged access to the system, all of which should be detectable by the other required PCI controls for payment processing systems. As always the judgment on whether security controls are sufficient enough to validate PCI DSS compliance rests with the PCI Qualified Security Assessor.
Anybody want to start a pool on how long it takes before we start seeing longer PIN numbers?
It won't help at all with the cases where they're stolen at the source, but it would certainly cut off brute forcing and shoulder surfing dramatically.
I will be attending RSA 2009 in San Francisco on April 20th and 21st and will be at the ETA conference (http://www.electran.org/content/view/230/270/) on April 22nd and 23rd. Send me an email if you will be attending as well, always glad to meet new, current and former customers, partners and members of my team.
Most working with PCI DSS and PA-DSS compliance are very familiar with the requirement to securely delete cardholder information and cryptographic materials once the data is no longer needed. Examples of such a requirement include:
3.2 If sensitive authentication data is received and deleted, obtain and review the processes for deleting the data to verify that the data is unrecoverable.
…and from the PA-DSS v1.2
1.1 If sensitive authentication data (see 1.1.1–1.1.4 below) is stored prior to authorization and then deleted, obtain and review methodology for deleting the data to determine that the data is unrecoverable.
This requirement is based upon the fact that simply deleting files from a Windows or Unix file systems does not completely purge the information from the hard drive or partition. During a delete operation, typically the metadata of the file is altered such as the file pointer, etc. has been altered, however, the actual data itself may still be resident in part or even whole. Currently, computer forensics professionals have various tools and techniques available to recover parts or all of the data contained with files that were simply deleted by the operating system. So the real question becomes how can sensitive data that is no longer needed be securely deleted, or in the very least, rendered such that is no longer ‘recoverable’ as described the above requirement from PCI DSS? To obtain some guidance regarding this issue we can review another section of the PCI PA-DSS v1.2:
1.1.4 Securely delete any magnetic stripe data, card validation values or codes, and PINs or PIN block data stored by previous versions of the payment application, in accordance with industry-accepted standards for secure deletion, as defined, for example by the list of approved products maintained by the National Security Agency, or by other State or National standards or regulations.
Now this sounds fairly straightforward; one simply obtains a commercial product or open-source software tool that has the capability to over-write consecutive binary data elements (usually all “1”’s or all “0”’s) over all the locations where the file contents were stored on the hard drive or partition. One directs the product or tool at the target files and enables a secure delete, “shred” or other function that consecutively over-writes the previously sensitive data numerous times. Problem solved, work is done, and case closed, right? Well, not necessarily.
While performing a PA-DSS assessment of the MainStreet Softworks payment processing application Monetra (which was ultimately found to be compliant by the way) IBM ISS PA-QSA’s were introduced to an interesting twist to the problem of secure file deletion. MainStreet Softworks CTO, and Senior Engineer Brad House revealed to the on-site QSA’s that it is extremely difficult if not even impossible to securely delete files from many modern file systems, especially what’s known as a Journaling File System (JFS). Brad has even written a technical paper addressing this issue in detail that even includes proof of concept code to prove this assertion.
What is a JFS? I am glad you asked. According to Wikipedia the definition of a Journaling File System is as follows:
“A journaling file system is a file system that logs changes to a journal (usually a circular log in a dedicated area) before committing them to the main file system. Such file systems are less likely to become corrupted in the event of power failure or system crash.”
Most, if not all Unix systems provide several options for file systems and many utilize Journaling. In addition most recent incarnations of the Windows Operating system also provide some JFS capability. As such, if systems that store, process, or transmit PCI cardholder information are built upon JFS systems, then attempting to securely delete sensitive authentication data and cardholder information becomes almost impossible. Even if one tries to implement some a tool or software technique to overwrite sensitive data within a JFS, there still is a probability that some, if not all of the data can be recovered using forensic tools and techniques.
So what can be done to be done to ensure the PCI compliance of credit card payment processing systems that are built on systems using JFS?
Next Post – Meeting the Spirit of PCI With Secure Delete
I will be a panelist speaker at the NACHA Payments 2009 conference in Orlando, Florida on April 6th 2009 @ 1:45pm. The topic of the panel will be "Is PCI Compliance Enough?" and will have a distinguished panel of PCI experts. Bob Russo, General Manager, PCI Security Standards Council, David Taylor, President, PCI Knowledge Base, myself and Chuck Phipps, AVP of Merchant Acquiring and ACH Services at Palm Desert National Bank.
A link to the conference is below
Hope to see you there!
Andi Baritchi 27000216AA email@example.com Tags:  breaches middleware security webinar pci 620 Visits
Got middleware above your databases? You won't want to miss this webinar:
Middleware Security Holes You Need to Know About
With T.Rob Wyatt, Senior Managing Consultant at IBM
April 15th at 12 Noon ET / 9 am PT
Andi Baritchi 27000216AA firstname.lastname@example.org Tags:  card compliance security dss credit cardholder iss pci 2 Comments 956 Visits
In today’s challenging economic landscape, clients in every vertical are looking harder than ever to lower costs and maximize ROI. It’s a delicate balancing act between tactical and strategic – one we often see left unbalanced.
In order to be successful, a security program must be:
All cost centers, including security and compliance, have been made prime targets for CFOs’ slash hunts. The most common mistake we’ve observed in such times is to shift security and compliance to a tactical-only paradigm. This shift may save costs in the short term, but chops ROI at the knees in the long run.
For example, building a security program for your organization wholly around PCI DSS compliance is a sexy, but fallacious idea. A security program built on top of the DSS is totally dependent on the Standard – you’ll have to re-think your security strategy every time the PCI Security Council issues an update (and/or clarification). Same goes for any other reg.
Before you ask us the question, I don’t have the budget to get an A in security – I just need a C in compliance, consider the consequences of building a security program that hyperfocuses on compliance.
To contrast, say you implement a sound security framework that, as one of its core dimensions, addresses cardholder data security and PCI DSS compliance. Other dimensions may address your company’s other regulatory, security, and privacy vectors – such as SOX404 compliance, web 2.0 threats, and so on. All the elements of this comprehensive security framework, if designed properly, will work together to keep your and your customers’ data secure. Compliance will just be a natural byproduct.
As a final thought, remember that any standard, whether it’s religious, regulatory, or simply an internal rule, can only be effective once all stakeholders understand and adopt it both in spirit and in function.