tag:blogger.com,1999:blog-57042483680302123512024-03-13T23:04:17.380-04:00PCI DSS News and Information for Higher EducationTreasury Institute for Higher Education ~ Payment Card Industry Data Security Standards (PCI DSS) BlogGenehttp://www.blogger.com/profile/13307650260688914470noreply@blogger.comBlogger238125tag:blogger.com,1999:blog-5704248368030212351.post-24100549307041093232016-04-07T16:44:00.000-04:002016-04-08T16:15:45.026-04:002016 PCI Workshop Agenda AnnouncedThe Agenda for the 2016 Treasury Institute for Higher Education PCI DSS Workshop was announced this morning. There are still spaces left if you have not registered. Please join us for this lively and highly informative event specifically programmed for the Higher Education community.<br />
<br />
Information on registering is in the right sidebar.<br />
<br />
<br />
<h3>
Sunday May 22, 2016</h3>
<br />
<b>4:00 pm - 6:00 pm - Early Conference Registration</b><br />
<br />
<b>6:00 pm - 7:30 pm - Welcome Reception</b><br />
Those who arrive early can mingle, meet friends old and new, share challenges and triumphs, plan questions, and generally get ready for the event.<br />
<br />
<h3>
Monday May 23, 2016</h3>
<br />
<span style="color: #45818e;"><b>Monday Morning Pre-Workshop Events<br />(included with conference registration)</b></span><br />
<br />
<b>10:00 am - 1:00 pm - Conference Registration</b><br />
<br />
<b>10:00 am - 10:30 am - PCI Workshop Orientation</b><br />
<span style="color: #45818e;">Whether you are new to the PCI Workshop or new to PCI in general,this
session will give you some insight, tricks of the trade, provide you
with resources, and start your PCI workshop out on the right foot.</span><br />
<br />
<b>10:30 am - 12:00 pm - PCI DSS Refresh</b><br />
<span style="color: #45818e;">An optional and interactive session for attendees who want to refresh their knowledge of the PCI to ensure they get the most out of the workshop.</span><br />
<br />
<b>12:00 pm - 1:00 pm - LUNCH ON YOUR OWN</b><br />
<br />
<b>1:00 pm - 1:15 pm - Workshop Begins & Opening Remarks</b><br />
<br />
<b>1:15 pm - 2:30 pm - Secret Service</b><br />
<i>Secret Service Agent Bernard Wilson</i><br />
<br />
<b>2:30 pm - 3:00 pm - Networking Break</b><br />
<br />
<b>3:00 pm - 4:00 pm - BUSINESS TRACK</b><br />
We're All Imposters - Overcoming Self Doubt to Leave the Workshop a Winner <br />
<i>Preston DuBose - Texas A&M</i><br />
<br />
<b>3:00 pm - 4:00 pm - IT TRACK</b><br />
How to Monitor Threats to PCI Compliance<br />
<i>Shiva Hullavarad - University of Alaska</i><br />
<br />
<b>4:00 pm - 5:00 pm - BUSINESS TRACK</b><br />
Organizing an RFP for a QSA, ASV, and/or a Merchant Processor<br />
<i>Campus Guard and Indiana University</i><br />
<br />
<b>4:00 pm - 5:00 pm - IT TRACK</b><br />
PCI Compliance in Hospitality Management Systems Point of Sale and Hotel Property Management Systems<br />
<i>Joseph Goodman, Virginia Tech</i><br />
<br />
<b>5:00 pm - 6:30 pm - The 90 Minute Networking Hour</b><br />
Our discussions of PCI and your compliance journey will continue informally. We created a special 90-minute hour so you can join colleagues and our sponsors in a relaxed atmosphere to share experiences, renew old friendships, and make a few new ones. Refreshments will be provided. Afterward, attendees are on their own to enjoy the many restaurants, attractions, and entertainment opportunities nearby.<br />
<br />
<h3>
Tuesday May 24, 2016</h3>
<br />
<b>8:00 am - 9:00 am - Buffet Breakfast</b><br />
<br />
<b>9:00 am - 10:15 am - Surviving the First 48 Hours of a Breach</b><br />
<i>Sikich</i><br />
<br />
<b>10:15 am - 10:45 am - Break</b><br />
<br />
<b>10:45 am -12:00 pm - PCI Compliance - An Auditor View</b><br />
<i>Tim Marley, Oklahoma University</i><br />
<br />
<b>12:00 pm - 1:00 pm - Lunch</b><br />
<br />
<b>1:00 pm - 2:15 pm - BUSINESS TRACK</b><br />
What a Processer Needs from a University to Validate Compliance<br />
<i>VANTIV</i><br />
<br />
<b>1:00 pm - 2:15 pm - IT TRACK</b><br />
QSA Top 10 List of Compliance Misses<br />
<i>CoalFire</i><br />
<br />
<b>2:15 pm - 3:15 pm - BUSINESS TRACK</b><br />
PCI DSS and Third Party Vendors. A Push-me Pull-me Relationship<br />
<i>Katie Todd, Columbia University</i><br />
<br />
<b>2:15 pm - 3:15 pm - IT TRACK</b><br />
Protecting Merchant Data: A Live Hack Demonstration<br />
<i>Gary Glover, Security Metrics</i><br />
<br />
<b>3:15 pm - 3:30 pm - Networking Break</b><br />
<br />
<b>3:30 pm - 5:00 pm - PCI DSS QUICK HITS</b><br />
This session will address multiple PCI topics that can be discussed by the speakers in 10 minutes or less.<br />
<i>PCI Workshop committee</i><br />
<br />
<h3>
Wednesday May 25, 2016</h3>
<br />
<b>8:00 am - 9:00 am - Buffet Breakfast</b><br />
<br />
<b>9:00 am - 10:15 am - PCI DSS</b><br />
The View of a CISO<br />
<i>Tim Ramsay, University of Miami</i><br />
<br />
<b>10:15 am - 10:30 am - Break</b><br />
<br />
<b>10:30 am - 11:30 am - Role Playing the Assessment of a MID</b><br />
<i>Monica Trippler, Utah State University</i><br />
<br />
<b>10:30 am - 11:30 am - Scope Reducing Ideas</b><br />
<i>Ruth Harpool, Indiana University and PayPal</i><br />
<br />
<b>11:30 am - 12:30 pm - Lunch</b><br />
<br />
<b>12:30 pm - 1:45 pm - A Story of Collaboration Across Campus Units</b><br />
<i>Mark Haas, VP Finance & Treasurer, Michigan State University<br />Rob McCurdy, CISO, Michigan State University</i><br />
<br />
<b>1:45 pm - 2:45 pm - Survey Results and Workshop Conclusion</b><br />
<br />Genehttp://www.blogger.com/profile/13307650260688914470noreply@blogger.com0tag:blogger.com,1999:blog-5704248368030212351.post-52916890116998432512016-02-18T08:00:00.001-05:002016-02-18T10:53:49.548-05:00Where 4.0 Art Thou, PCI DSS?<div dir="ltr">
In a not completely surprising move yesterday, Troy Leach of the Payment Card Industry Security Standards Council (PCI SSC) announced that there would not be a new, version 4.0 of the PCI Data Security Standard (PCI DSS) released in November of 2016. There will be a version 3.2 of PCI DSS released in the first part of this year.</div>
<div dir="ltr">
</div>
<div dir="ltr">
The PCI SSC posted information on version 3.2 of the PCI DSS on <a href="http://blog.pcisecuritystandards.org/preparing-for-PCI-DSS-32">their blog</a> yesterday. As expected, the version of the standard will extend the sunset date for SSL V3 and early versions of TLS from June 30, 2016 to June 30, 2018. But there will be other changes to the standard and it sounds like they are still working out exactly what will be included. As with previous updates, the Council has taken market feedback into consideration, but they also look deeply into the current threat landscape. This includes the results of forensic investigations in current breaches.</div>
<div dir="ltr">
</div>
<div dir="ltr">
Some of the changes may include multi-factor authentication for system administrators from within the cardholder data environment, clarification of guidelines covering the masking of displayed card numbers, and incorporating parts of the <a href="http://treasuryinstitutepcidss.blogspot.com/2015/06/designated-entities-supplemental.html" target="_blank">Designated Entities Supplemental Validation</a> (DESV) for service providers.</div>
<div dir="ltr">
</div>
<div dir="ltr">
When asked why v3.2 was coming out now instead of the fall, Leach mentioned the SSL remediation change and seemed to confirm that the three-year life cycle of the standard was a thing of the past: <em></em><br />
<blockquote class="tr_bq">
<em>"...the industry recognizes PCI DSS as a mature standard now, which doesn’t require as significant updates as we have seen in the past. Moving forward, you can likely expect incremental modifications to address the threat landscape versus wholesale updates to the standard."</em></blockquote>
He also says that these incremental changes will allow the Council to focus more of its time on emerging technologies, which are rapidly changing the ways in which payment cards are accepted.<br />
<div dir="ltr">
</div>
<div dir="ltr">
Read more in the blog post here: <a href="http://blog.pcisecuritystandards.org/preparing-for-PCI-DSS-32">http://blog.pcisecuritystandards.org/preparing-for-PCI-DSS-32</a>.</div>
<div dir="ltr">
</div>
</div>
Anonymousnoreply@blogger.com0tag:blogger.com,1999:blog-5704248368030212351.post-70514579718134206412016-01-14T17:22:00.000-05:002016-01-15T17:16:08.581-05:00Call for Presentations for the 2016 PCI WorkshopHello Friends and Colleagues in PCI DSS Compliance.<br />
<br />
It's that time of year again, the program committee is requesting your input and submissions for presentations at the 2016 Treasury Institute for Higher Education PCI DSS Workshop.<br />
<br />
The theme of the 2016 PCI DSS Workshop is<br />
<strong><em><span style="color: #cc0000;">PCI DSS: Working Together; Succeeding Together</span></em></strong>.<br />
<br />
In many schools, PCI oversight is the responsibility of the Treasurer/Finance Office yet much of the deployment and implementation of PCI DSS is a matter best left to the experts in Information Technology and/or the IT Security Office. Successful and sustainable PCI DSS compliance requires the identification and planning of common goals between finance and technology. Achieving and maintaining compliance requires top quality teamwork and documentation between Treasury/Finance (the PCI oversight group), Information Technology, third party service providers, and the individual departments that accept cards.<br />
<br />
Where has your school succeeded in closing the distance between Treasury/Finance and Information Technology? What documentation and communication success stories do you have to share? Share your challenges or your glorious successes (or even your dismal failures) in implementing and maintaining PCI DSS compliance in the face of ever changing threats and attacks.<br />
<br />
<strong>Concurrent Educational Session Topic Ideas</strong><br />
<br />
<u>(All sessions should emphasize the collaboration needed between Finance and Technology to succeed.)</u><br />
<ul>
<li>Dealing with PCI DSS and Changes in Vendor Delivered Technology</li>
<li>PCI DSS and Third Party Vendors, a Push-me Pull-me Relationship</li>
<li>PCI DSS: Funding the "Unfunded Mandate"</li>
<li>PCI DSS Change Management for Finance</li>
<li>Innovative Scope Reducing Solutions</li>
<li>Learning a new language; <em>"IT meet Treasury, Treasury meet IT"</em></li>
</ul>
<div>
The sessions are scheduled in one-hour time blocks. Your presentation should be shorter than that in order to allow for Q&A and time for folks to move between sessions that may be in different rooms.<br />
<br />
Speakers from Higher Education will be reimbursed for their workshop registration and certain travel, lodging, and meal expenses (maximum one person reimbursed per session). Speakers from outside of Higher Education will receive a complimentary workshop registration.</div>
<div>
</div>
See <a href="https://drive.google.com/file/d/0ByVXB8a3gGWJczBNNWNXOXJEODQ/view" rel="nofollow" target="_blank">General Expense Reimbursement Guidelines</a> for further information.<br />
<br />
<strong>How Do I Submit a Proposal?</strong><br />
<br />
To prepare your proposal, come up with a suggested title, a brief description of your presentation, your school's name, your contact info and suggested co-presenters, if applicable.<br />
<br />
Either send your proposal to me using the <strong><a href="https://treasuryinstitutepcidss.blogspot.com/#ContactForm1" rel="nofollow" target="_blank">Contact Form</a></strong> in the right sidebar and I will forward it on, or use that same <a href="https://treasuryinstitutepcidss.blogspot.com/#ContactForm1" rel="nofollow" target="_blank">Contact Form</a> to ask me to send you the Treasury Institute address for Ruth Harpool so that you can contact her directly. (Sorry, to avoid spam I rarely include addresses in this blog.)<br />
<br />
<span style="color: #cc0000;"><strong><em>The submission deadline is: February 1, 2016</em></strong></span><br />
<br />
This workshop will be a gathering of your friends and peers, so there is never a hostile audience. You will be welcomed warmly, even if you have never presented anywhere before. We know that many of you have valuable experiences that we would love to hear about. So get in touch and propose a session for the 2016 PCI Workshop in Savannah, Georgia this May.<br />
<br />
<ul>
<li><strong>More PCI Workshop Information:</strong><br />at <a href="http://event.treasuryinstitute.org/" target="_blank">The Treasury Institute web site</a></li>
<li><strong>PCI Workshop Registration:</strong><br />at the <a href="https://events.r20.constantcontact.com/register/eventReg?oeidk=a07ebrukbu444029fbd&oseq=&c=&ch=" target="_blank">Constant Contact web site</a></li>
<li><strong>Workshop Hotel Information:</strong><br /><a href="http://event.treasuryinstitute.org/Hotel/index.cfm" target="_blank">The Hyatt Regency Savannah</a></li>
<li><strong>Hotel Reservations:</strong><br />Make your group rate <a href="https://aws.passkey.com/g/50858212" target="_blank">reservation <br />by April 22 through Passkey.com</a></li>
</ul>
<br />
<br />Anonymousnoreply@blogger.com0tag:blogger.com,1999:blog-5704248368030212351.post-70265887402915509592016-01-08T13:08:00.004-05:002016-01-08T13:15:26.509-05:00Older versions of Internet Explorer expire January 12<strong>What's going on?</strong><br />
<br />
Microsoft announced this week that it will be ending its support for older versions of Internet Explorer (IE) on January 12, 2016. What does end of support mean? It means that starting on Tuesday, January 12 (Patch Tuesday), Microsoft will only provide technical support and security updates for the most current version of Internet Explorer available for a "supported" operating system.<br />
<br />
The most recent version of IE is version 11, and almost every Windows system should be running that version. There are a few exceptions to this, such as some specialized or older versions of the Windows operating system, like Windows Server or Windows Embedded, which may be used on integrated point-of-sale systems. These exceptions are not able to run Windows 11 at this time. See the lifecycle link below for more information.<br />
<br />
<strong>Note:</strong> <span style="color: red;">All systems in your cardholder data environment must be running the most current versions of their operating systems and software. All patching must be up-to-date. This is required by PCI DSS requirement 6.2.</span><br />
<br />
<strong>What is the impact of this announcement?</strong><br />
<br />
This means that if you are running an older version of IE on your desktop that you should upgrade to Windows 11 right away. If a new vulnerability is discovered in an older version of IE, that version will not receive a security patch to fix it. And unpatched systems are the primary targets of criminal hackers and malware. Internet Explorer 11 will continue to receive security updates, compatibility fixes, and technical support on Windows 7, Windows 8.1, and Windows 10.<br />
<br />
<strong>More information</strong><br />
<br />
For questions, help, upgrade assistance, and other resources please see the End of Support announcement page at <a href="https://www.microsoft.com/en-us/WindowsForBusiness/End-of-IE-support">https://www.microsoft.com/en-us/WindowsForBusiness/End-of-IE-support</a>.<br />
<br />
To learn more about exceptions and other supported operating systems read the Windows lifecycle FAQ sheet at <a href="https://support.microsoft.com/en-us/lifecycle#gp/Microsoft-Internet-Explorer">https://support.microsoft.com/en-us/lifecycle#gp/Microsoft-Internet-Explorer</a>.Anonymousnoreply@blogger.com0tag:blogger.com,1999:blog-5704248368030212351.post-57616652465649619652015-10-07T19:03:00.000-04:002015-10-07T19:04:20.021-04:00More Observations from the PCI SSC North America Community Meeting<em>[Our good friend Joe Tinucci also attended the Community Meeting and shares with us his impressions of this year's program. </em><span style="font-family: "Calibri",sans-serif; line-height: 107%; mso-ansi-language: EN-US; mso-ascii-theme-font: minor-latin; mso-bidi-font-family: "Times New Roman"; mso-bidi-language: AR-SA; mso-bidi-theme-font: minor-bidi; mso-fareast-font-family: Calibri; mso-fareast-language: EN-US; mso-fareast-theme-font: minor-latin; mso-hansi-theme-font: minor-latin;">–</span><em>gaw]</em><br />
<br />
I also was privileged to attend the PCI SSC Community Meeting in Vancouver. As with last year's meeting there were several trends that were apparent, both explicitly stated in the sessions and, equally important, discussed at the networking events and on the trade show floor. Here is a summary of the major trends that I heard at the meeting:<br />
<br />
<strong><em>Risk, Risk, Risk</em></strong><br />
<br />
The entire first day of the meeting was devoted to updates from the Council, virtually all of them focusing on risk and risk management. This theme has carried over from last year, and I assume that it will carry forward to future years. Using a risk management-based approach it becomes easier for merchants to prioritize what to do first and where to concentrate their scarce resources. It also makes it easier to incorporate risk avoidance into ordinary business practices.<br />
<br />
One major risk that came up repeatedly was third party service providers. It was noted that approximately 1/3 of retail breaches were due to third party vulnerabilities. Remote access by vendors to merchant systems is particularly problematic; there are standard practices that should be in place to prevent vendors from accessing merchant systems any more often than is strictly necessary.<br />
<br />
One excellent resource for managing third parties was the Responsibility Matrix found in the Council's Third-Party Assurance Information Supplement (<a href="https://www.pcisecuritystandards.org/documents/PCI_DSS_V3.0_Third_Party_Security_Assurance.pdf">https://www.pcisecuritystandards.org/documents/PCI_DSS_V3.0_Third_Party_Security_Assurance.pdf</a>). Not only does this document provide a framework for assessing the risks of third parties, but also a framework for negotiating the legal responsibilities of each party. I highly recommend that you download and use this document to help provide the structure for your third party management program.<br />
<br />
<strong><em>Collaboration</em></strong><br />
<br />
Another theme was collaboration. I think it indicates an interest on the part of the Council to expand their purview so as to bring in additional revenues and resources, and to also work with other associations, interest groups, governmental agencies, and rule-making bodies to cooperatively secure payments. Sharing of information, whether officially sanctioned through ISACs or other mechanisms, is one of the few ways that the good guys can stay current with what the bad guys are doing.<br />
<br />
<strong><em>Incident Response</em></strong><br />
<br />
There was a lot of discussion of incident response. The Council recently issued a supplemental guide, Responding to a Data Breach (<a href="https://www.pcisecuritystandards.org/documents/PCI_SSC_PFI_Guidance.pdf">https://www.pcisecuritystandards.org/documents/PCI_SSC_PFI_Guidance.pdf</a>) that can serve as a checklist or guide to building your incident response program. The guide's theme of "Preparing for the Worst is the Best Defense" was repeated in multiple presentations. Prepare now to see more requirements surrounding this area in future versions of the standard. And, if you haven't yet done so, you should consider holding a "tabletop" incident response exercise just to make sure that you have identified the key players that need to be part of your IR team and that they play well together.<br />
<br />
<strong><em>Segmentation</em></strong><br />
<br />
Another recurring theme was segmentation <span style="font-family: "Calibri",sans-serif; font-size: 11pt; line-height: 107%; mso-ansi-language: EN-US; mso-ascii-theme-font: minor-latin; mso-bidi-font-family: "Times New Roman"; mso-bidi-language: AR-SA; mso-bidi-theme-font: minor-bidi; mso-fareast-font-family: Calibri; mso-fareast-language: EN-US; mso-fareast-theme-font: minor-latin; mso-hansi-theme-font: minor-latin;">–</span> of your cardholder data environment, of course, but also as applied to other environments. Segmentation is a major scope-reduction tool for PCI DSS compliance. The newest version of the DSS has an increased emphasis on this topic, particularly validation that your segmentation is working as intended <span style="font-family: "Calibri",sans-serif; font-size: 11pt; line-height: 107%; mso-ansi-language: EN-US; mso-ascii-theme-font: minor-latin; mso-bidi-font-family: "Times New Roman"; mso-bidi-language: AR-SA; mso-bidi-theme-font: minor-bidi; mso-fareast-font-family: Calibri; mso-fareast-language: EN-US; mso-fareast-theme-font: minor-latin; mso-hansi-theme-font: minor-latin;">–</span> both from inside and outside the network segment. There was discussion of assurance for your segmentation efforts <span style="font-family: "Calibri",sans-serif; font-size: 11pt; line-height: 107%; mso-ansi-language: EN-US; mso-ascii-theme-font: minor-latin; mso-bidi-font-family: "Times New Roman"; mso-bidi-language: AR-SA; mso-bidi-theme-font: minor-bidi; mso-fareast-font-family: Calibri; mso-fareast-language: EN-US; mso-fareast-theme-font: minor-latin; mso-hansi-theme-font: minor-latin;">–</span> internal and external vulnerability scans as well as penetration testing to assure that portions of the network that are supposed to be isolated from the rest of the network / Internet truly are isolated and remain that way. This is one area that will receive even more attention going forward; if not through more requirements then from your QSA / ISAs.<br />
<br />
<strong><em>Being Compliant Does NOT Equal Being Secure</em></strong><br />
<br />
Over and over and over, just about every speaker repeated the mantra that being compliant does not mean that you are actually secure. This is partly to guard against the checklist mentality of compliance, where you do stuff only in order to be able to check the box against the compliance checklist. But it was also to remind people that we aren't infallible <span style="font-family: "Calibri",sans-serif; font-size: 11pt; line-height: 107%; mso-ansi-language: EN-US; mso-ascii-theme-font: minor-latin; mso-bidi-font-family: "Times New Roman"; mso-bidi-language: AR-SA; mso-bidi-theme-font: minor-bidi; mso-fareast-font-family: Calibri; mso-fareast-language: EN-US; mso-fareast-theme-font: minor-latin; mso-hansi-theme-font: minor-latin;">–</span> we might be compliant at this particular instant in time but the opportunity to get out of compliance presents itself with the next AV update, new machine added to the network, or vendor software upgrade. Most of the breached merchants in the last few years considered themselves compliant <span style="font-family: "Calibri",sans-serif; font-size: 11pt; line-height: 107%; mso-ansi-language: EN-US; mso-ascii-theme-font: minor-latin; mso-bidi-font-family: "Times New Roman"; mso-bidi-language: AR-SA; mso-bidi-theme-font: minor-bidi; mso-fareast-font-family: Calibri; mso-fareast-language: EN-US; mso-fareast-theme-font: minor-latin; mso-hansi-theme-font: minor-latin;">–</span> but apparently not secure. Hence, the continuing emphasis in the DSS on "Compliance as Business as Usual". Look for there to be a new direction in future versions of the standard around the associated processes that keep a merchant compliant <span style="font-family: "Calibri",sans-serif; font-size: 11pt; line-height: 107%; mso-ansi-language: EN-US; mso-ascii-theme-font: minor-latin; mso-bidi-font-family: "Times New Roman"; mso-bidi-language: AR-SA; mso-bidi-theme-font: minor-bidi; mso-fareast-font-family: Calibri; mso-fareast-language: EN-US; mso-fareast-theme-font: minor-latin; mso-hansi-theme-font: minor-latin;">–</span> change management, software upgrades, log creation and review, equipment inspection, and so forth.<br />
<br />
<strong><em>P2PE</em></strong><br />
<br />
It appears that we are finally seeing the emergence of Point-to-Point Encryption (P2PE) solutions for merchants. This can be another effective way to reduce the scope of your CDE, particularly when used with tokenization. There are two routes for a vendor to follow when creating a P2PE solution for merchants: validated or unvalidated. In a validated solution, the vendor integrates validated P2PE applications as components in their larger system, has their solution validated by a QSA specializing in P2PE, and then pays the Council to be listed on the validated solutions website. (Similarly for validated applications.) With the upgrade of the P2PE standard to version 2, validated components can now be used by merchants to "roll their own" solution. One benefit of using a validated P2PE solution, or creating your own system from validated components, is that it makes the merchant independent of their acquiring bank; that is, they can move their merchant account to a different acquirer without junking their P2PE system.<br />
<br />
Many acquiring banks have a P2PE solution available to their merchants that may not be listed by the Council as validated, but which is equally well vetted by a P2PE QSA. The advantage to the acquirer of this route is that their merchants are more closely tied to them and less able to switch acquirers without starting over with another P2PE solution. The advantage to the merchant is that <span style="font-family: "Calibri",sans-serif; font-size: 11pt; line-height: 107%; mso-ansi-language: EN-US; mso-ascii-theme-font: minor-latin; mso-bidi-font-family: "Times New Roman"; mso-bidi-language: AR-SA; mso-bidi-theme-font: minor-bidi; mso-fareast-font-family: Calibri; mso-fareast-language: EN-US; mso-fareast-theme-font: minor-latin; mso-hansi-theme-font: minor-latin;">–</span> assuming they do their due diligence with their acquirer to ensure that the offered solution is properly secure and meets their needs <span style="font-family: "Calibri",sans-serif; font-size: 11pt; line-height: 107%; mso-ansi-language: EN-US; mso-ascii-theme-font: minor-latin; mso-bidi-font-family: "Times New Roman"; mso-bidi-language: AR-SA; mso-bidi-theme-font: minor-bidi; mso-fareast-font-family: Calibri; mso-fareast-language: EN-US; mso-fareast-theme-font: minor-latin; mso-hansi-theme-font: minor-latin;">–</span> the recommended solution may cost less than a validated one and may be more closely integrated with the acquirer.<br />
<br />
As noted in Mike's posting, I also was enamored with Vancouver <span style="font-family: "Calibri",sans-serif; font-size: 11pt; line-height: 107%; mso-ansi-language: EN-US; mso-ascii-theme-font: minor-latin; mso-bidi-font-family: "Times New Roman"; mso-bidi-language: AR-SA; mso-bidi-theme-font: minor-bidi; mso-fareast-font-family: Calibri; mso-fareast-language: EN-US; mso-fareast-theme-font: minor-latin; mso-hansi-theme-font: minor-latin;">–</span> what a lovely city! Even the weather cooperated to produce picture-perfect days. The only thing that marred the stay was that I often found myself apologizing (mostly to taxi drivers and waitresses) for being from such a backward country that didn't issue credit cards with chips... <em>(More on that topic in another posting.)</em><br />
<br />
<hr />
<br />
<em>Joseph D. Tinucci recently moved from the University of Colorado Treasury to Coalfire Systems, Inc., a Colorado-based IT Security Audit and Consulting firm. At CU Joe managed the PCI DSS compliance program for over 175 merchants across four campuses. Now he is helping clients manage their compliance programs from the other side of the desk; he notes that it is a refreshing change of pace and duties to be on the "illuminating side"...</em><br />
<br />
<em>Joe can be reached by email to </em><a href="mailto:joseph.tinucci@coalfire.com"><em>joseph.tinucci@coalfire.com</em></a><em> </em>Anonymousnoreply@blogger.com0tag:blogger.com,1999:blog-5704248368030212351.post-17060798255439592092015-10-05T17:24:00.000-04:002016-01-15T17:17:30.736-05:00The 2015 PCI SSC North America Community Meeting<em>[<strong>Mike Leach</strong> sent in this terrific summary of his time at the PCI Security Standards Council's North America Community Meeting, held last week in Vancouver, British Columbia, Canada. I wasn't able to attend this year, so thanks Mike! --gaw]</em><br />
<br />
We wrapped up the PCI SSC North American Community Meeting in Vancouver, BC last week. Before I review a few key points of the meeting I want to highlight our host city: Vancouver, BC is a fantastic city! The streets are pedestrian friendly and clean, the people are friendly, the downtown is alive and vibrant after 5. I even stumbled into a shooting set for Minority Report on an evening walk. Then the waterfront and harbor called to us every day, making it hard to go back into meeting sessions. I recommend Vancouver as a vacation destination. I will be back.<br />
<br />
This year Indiana University, Michigan State, North Carolina State, Oklahoma State, Penn State and University of the Pacific were represented as well as the British contingent: University of Surrey, University of Manchester and the University of Leicester. If I overlooked any Higher Ed schools I'm sorry we missed you at the meeting.<br />
<br />
The theme this year was Educate, Empower, Protect. As a between-standards year much of the content was review and reinforcement of known topics. Building on <em>PCI as Business as Usual</em> the Council reiterated its focus on providing guidance and content for Small and Medium Businesses (Hey, that's us!).<br />
<br />
To do that they are using a 4 pronged approach:<br />
<br />
<ol>
<li>Establishing a SMB task force</li>
<li>Highlighting the QIR program</li>
<li>Encouraging us to develop Acquirer relationships</li>
<li>(The Council) Deepening relationships with Merchant Associations</li>
</ol>
<div>
</div>
There will also be a refreshed website with a preview offered here: <a href="http://communitypreview.pcisecuritystandards.org/">http://communitypreview.pcisecuritystandards.org/</a><br />
<br />
Another sub-theme was collaboration. We know the bad guys are sharing info and learning as a community. We need to do the same. As IU's Ruth Harpool reminded General Manager for the PCI Security Standards Council, Stephen Orfei, Higher Ed knows collaboration. This is one of our strengths we need to continue to leverage so none of us are left behind. When schools write to the PCI listserv with questions, please offer up your answers or experience. If you don't feel comfortable discussing with the larger group reply privately. Continue to ask and share. <br />
<br />
Keynote speaker John Nance related his experiences in aviation and healthcare to information security. Humans are the weakest link. By admitting we will fail we can plan for failure and be ready to respond to failures. John also supports the call for collaboration. Collaboration without a common goal is just disparate groups trying to cooperate. <br />
<br />
Several presentations covered the importance of P2PE and Tokenization. We are starting to see more validated solutions listed. These two services provide real card data security and scope reduction. However in speaking with merchants who have started down this path some acquirers are trying to squeeze all merchants into a category that doesn't fit well. A complete implementation will take some time and planning so start now. Caesars Entertainment reviewed their 3 year project to implement P2PE at all 37 properties in 14 states. <br />
<br />
Keynote Brian Krebs highlighted some of his adventures in learning and writing about card markets and ATM skimmers. His prediction for US EMV adoption is that we will see growth in new card/account fraud because so much of our US personal data is out there, unlike other countries with more strict privacy laws or less electronic personal data available. <a href="http://krebsonsecurity.com/">http://krebsonsecurity.com/</a><br />
<br />
Those are just some of the highlights. Please see the Council's meeting blog site for more meeting coverage: <a href="http://events.pcisecuritystandards.org/2015/blog">http://events.pcisecuritystandards.org/2015/blog</a><br />
<br />
Next year's North American meeting will be September 20-22 at the Mirage, Las Vegas, Nevada. <br />
Thank you,<br />
Mike Leach<br />
<br />
<hr />
<br />
<em>Mike Leach is a System and Network Security Analyst in the Office of Information Systems at The Pennsylvania State University. As a primary function of that job he has been managing the PCI compliance program for nine years. PSU has successfully bridged the IT-Finance/Treasury gap and in cooperation with the Office of Corporate Controller Mike oversees 55 merchant areas using some 150 merchant IDs across 24 campus locations.</em><br />
<br />
<em>Mike Leach can be reached by using the Contact Form in this site’s sidebar.</em>Anonymousnoreply@blogger.com0tag:blogger.com,1999:blog-5704248368030212351.post-21554630070239834852015-06-10T10:51:00.000-04:002015-06-10T10:51:36.482-04:00Designated Entities Supplemental Validation<br />
Who in security doesn't like the idea of making security (and thereby PCI compliance) business as usual, or BAU? The goal of BAU is to enable an entity "to monitor the effectiveness of their security controls on an ongoing basis, and maintain their PCI DSS compliant environment in between PCI DSS assessments." (<a href="https://www.pcisecuritystandards.org/documents/PCI_DSS_v3-1.pdf" target="_blank">PCI DSS v3.1</a>, page 13) It's a terrific concept, but it hasn't really taken root yet.<br />
<br />
The PCI Council offered some examples of how to implement PCI DSS into BAU activities but they didn't go much further than that in describing what BAU means for an entity subject to PCI DSS compliance. The example suggestions include but are not limited to:<br />
<ol>
<li>Monitor security controls for effectiveness.</li>
<li>Detect and respond to security failures promptly.</li>
<li>Review proposed CDE changes and follow complete change management practices.</li>
<li>Review compliance impact and PCI scope after organizational changes.</li>
<li>Communicate with personnel and review processes to confirm security controls remain in place.</li>
<li>Review technology at least annually for vendor support and security effectiveness.</li>
</ol>
<div>
</div>
They also make a suggestion I think is very important: <em>"Consider implementing separation of duties for security functions so that security and/or audit functions are separated from operational functions."</em><br />
<br />
On June 5, 2015 the PCI Security Standards Council (PCI SSC) took the idea of treating PCI compliance as BAU a step forward. And it's a <u>huge step</u>. They created a new compliance validation program and published the <a href="https://www.pcisecuritystandards.org/documents/PCI_DSS_v3_DESV.pdf" target="_blank"><em>PCI DSS Designated Entities Supplemental Validation For use with PCI DSS v3.1</em></a>. This document takes a deep dive into the BAU idea and provides a lot more guidance on how to comply in a BAU manner. It digs into the organizational environment and operational processes of the assessed entity.<br />
<br />
This new set of validation steps came about because investigations of data breaches revealed an important fact. That is, that too many entities are not maintaining PCI compliance between their annual assessments. If you read the <em><a href="http://www.verizonenterprise.com/resources/report/rp_pci-report-2015_en_xg.pdf" target="_blank">2015 Verizon PCI Compliance Report</a></em> you learn that only 28.6% of assessed entities were still compliant less than a year after their assessment. While that's an improvement from a few years ago it's still disappointingly low. But now, if acquirers or card brands want to focus in on mid-year compliance problems with certain designated entities they have a new tool in their belt to help keep these entities in line.<br />
<br />
My first reaction on reading this was Yikes! But there are some important things to stop and understand before succumbing to fear. First and foremost, Designated Entities Supplemental Validation (DESV) applies only to designated entities. That designation can only be assigned by an acquirer or card brand. A QSA can't require it during an assessment, and there is no set of self-assessment qualifications that would require you to follow it. It is an additional validation step required for particular entities. The Council provides some examples of which entities it may apply to, which could include:<br />
<div>
</div>
<ul>
<li>Those storing, processing, and/or transmitting large volumes of cardholder data,</li>
<li>Those providing aggregation points for cardholder data, or</li>
<li>Those that have suffered significant or repeated breaches of cardholder data.</li>
</ul>
<div>
</div>
<div>
My take on it is that this would apply mainly to Level 1 merchants and service providers. I can't recall if I have met someone from a university that is a Level 1 merchant. Even with aggregation my school is a Level 2. If an acquirer or a card brand gets suspicious that an entity is not trying to make PCI compliance BAU, the entity may receive the DESV designation.</div>
<div>
</div>
<div>
Secondly, the DESV does not create any new PCI requirements. Instead it tells an entity how they can meet the requirements already included in PCI DSS. It provides a path to demonstrate to their acquirer or card brand that they are maintaining compliance and it is not just an annual checkbox exercise. Each of the DESV requirements refers to the section(s) of the PCI DSS that it comes from.</div>
<div>
</div>
<div>
Here is an example:<br />
<br />
<em><strong>DE.1.1</strong> Executive management shall establish responsibility for the protection of cardholder data and a PCI DSS compliance program to include:</em><br />
<ul>
<li><em>Overall accountability for maintaining PCI DSS compliance</em></li>
<li><em>Defining a charter for a PCI DSS compliance program</em></li>
<li><em>Providing updates to executive management and board of directors on PCI DSS compliance initiatives and issues, including remediation activities, at least annually</em></li>
</ul>
<em>PCI DSS Reference: Requirement 12</em></div>
<div>
</div>
<div>
Each of these requirements also has a detailed testing procedure (often referencing specific documents) and a guidance column, just like you see in the standard itself. You will see things that you don't see in the standard, but those are often considered implicit in the PCI DSS. For example, in DE 1.1 above it references "a charter for a PCI DSS compliance program." This takes requirement 12 up a notch in terms of having tangible evidence that it is being followed.<br />
</div>
<div>
The additional validation steps are grouped into five main areas to control. Those are:</div>
<div>
</div>
<div>
<ul>
<li>DE.1 Implement a PCI DSS compliance program.</li>
<li>DE.2 Document and validate PCI DSS scope.</li>
<li>DE.3 Validate PCI DSS is incorporated into business-as-usual (BAU) activities.</li>
<li>DE.4 Control and manage logical access to the cardholder data environment.</li>
<li>DE.5 Identify and respond to suspicious events.</li>
</ul>
<br />
There are no surprises here. But I am particularly impressed with Area 2, scoping. It has concrete steps to assess and validate the scope of compliance. We all know how slippery scope can be sometimes. Area 2 sheds a lot of light on scoping here. It covers data discovery tools in some detail and also addresses data exfiltration. I particularly like the requirement to not only document the PCI scope, but also to document what is not in scope. That's thorough.<br />
<br />
Some of these new DESV requirements are different from the PCI DSS simply because they go above and beyond in terms of frequency or reporting. For example, penetration testing is required at least annually in the PCI DSS. But in DE 2.4 it becomes a semi-annual process for organizations that use segmentation to limit scope.<br />
<br />
I think the DESV program should not be a big concern for colleges and universities at this time. But things do change, and it's a rare day when PCI DSS requirements get looser instead of tighter. Take this example from the FAQ:<br />
<div>
</div>
</div>
<ul>
<li><em><strong>Q5:</strong> Can I use the DESV even if I’m not a Designated Entity?</em></li>
<li><em><strong>A:</strong> Yes. The DESV can be used to complement any entity’s PCI DSS compliance efforts, and all entities are encouraged to follow the DESV as a best practice, even if not required to validate.</em></li>
</ul>
<br />
I would agree with that. If I had the security resources available to implement DESV now I would do it! However, not many of us in this sector have those kinds of resources. But do take note of the encouragement "to follow the DESV as a best practice." We know that sometimes best practices become requirements later on. <em>Take heed, my friends.</em><br />
<br />
The Designated Entities Supplemental Validation program was released with a good set of supporting documents, including a FAQ sheet, a reporting template, and its own specific Attestation of Compliance. You can read the <a href="https://www.pcisecuritystandards.org/pdfs/15_06_05_DESV_Press_Release.pdf" target="_blank">press release</a> on the PCI Security Standards Council's web site (<a href="https://www.pcisecuritystandards.org/pdfs/15_06_05_DESV_Press_Release.pdf">https://www.pcisecuritystandards.org/pdfs/15_06_05_DESV_Press_Release.pdf</a>) and you will find the related documents in the Council's documents library.<br />
<br />
<div>
<em>Payment Card Industry (PCI) Data Security Standard</em><div>
<em>PCI DSS Designated Entities Supplemental Validation</em></div>
<div>
<em>For use with PCI DSS v3.1</em></div>
</div>
<div>
</div>
<div>
<strong>References:</strong></div>
<div>
<br />
<a href="https://www.pcisecuritystandards.org/documents/PCI_DSS_v3-1.pdf">https://www.pcisecuritystandards.org/documents/PCI_DSS_v3-1.pdf</a><br />
<a href="https://www.pcisecuritystandards.org/documents/PCI_DSS_v3_DESV.pdf">https://www.pcisecuritystandards.org/documents/PCI_DSS_v3_DESV.pdf</a><br />
<a href="http://www.verizonenterprise.com/resources/report/rp_pci-report-2015_en_xg.pdf">http://www.verizonenterprise.com/resources/report/rp_pci-report-2015_en_xg.pdf</a><br />
<a href="https://www.pcisecuritystandards.org/pdfs/15_06_05_DESV_Press_Release.pdf">https://www.pcisecuritystandards.org/pdfs/15_06_05_DESV_Press_Release.pdf</a><br />
</div>
Anonymousnoreply@blogger.com1tag:blogger.com,1999:blog-5704248368030212351.post-8735343702073520962015-04-27T18:59:00.002-04:002015-04-27T18:59:32.332-04:00New PCI DSS SAQs for version 3.1As Emma Sutcliffe mentioned to us at the PCI Workshop last week, the PCI Security Standards Council has today released version 3.1 of the Self-Assessment Questionnaires. At this time they are only available in Microsoft Word format. I expect the PDFs will come later.<br />
<br />
In addition, there are two new updates to previous documents. First, there is new version of <em>Understanding SAQs for PCI DSS v3</em>. I wish they had called it v3.1 to distinguish it from that confusing InfoSupp released last May. I have not read it in detail yet, but I did take a look at the comparison tables. Hallelujah! They removed that horrible, undefined term “acceptance” from the document. That added so much confusion. They also removed the entire “Control of Cardholder Data” comparison completely.<br />
<br />
The other updated document is <em>SAQ Instructions and Guidelines v3.1</em>, finally updated from PCI DSS v2. I haven’t had a chance to dig deeply into this either, but I’m sure it will yield some gems I can use in tomorrow’s PowerPoint!<br />
<br />
You can find the new documents on the <a href="https://www.pcisecuritystandards.org/" target="_blank">PCI SSC web site</a> in the document library under the <em>SAQs</em> tab. There is also a <strong>SAQs v3.1</strong> link on the home page: <a href="https://www.pcisecuritystandards.org/">https://www.pcisecuritystandards.org/</a>. Anonymousnoreply@blogger.com0tag:blogger.com,1999:blog-5704248368030212351.post-61257274068312493502015-04-13T17:37:00.000-04:002015-04-13T17:37:41.102-04:00Sunday Evening ReceptionHello all,<br />
<br />
There are MANY attendees checking in on Sunday this year, so you may have noticed that the Treasury Institute has added a Welcome Reception on Sunday evening. This informal event will be a great opportunity to meet and greet old friends and new. The reception will be in the Opium Terrace (by the pool) from <strong>6:00 to 7:30 PM</strong>, with beer, wine, and cheese served. <em>(Please note, the time was incorrectly listed as 5:00-6:30 in an earlier post.)</em><br />
<br />
Please make sure you hit the Workshop registration table, open from 4:00PM-6:00PM Sunday, so that you can pick up your badge for entry to the reception. As usual, many of us will join up into informal groups for dinner afterwards. Don't be shy.<br />
<br />
I’m looking forward to seeing many of you next week in Las Vegas!<br />
<br />
GeneAnonymousnoreply@blogger.com0tag:blogger.com,1999:blog-5704248368030212351.post-88598088471047767072015-04-03T16:55:00.000-04:002015-04-03T17:06:55.935-04:002015 PCI Workshop SponsorsI'm really looking forward to the Treasury Institute's 2015 PCI Workshop in <strike>Las Vegas</strike> Henderson, NV, coming up in about two weeks. The frigid Michigan winter made a PCI popsicle out of me, and I am ready to thaw out!<br />
<br />
But before I head out I want to make a mention of our workshop's <a href="http://www.treasuryinstitute.org/pci-partners-supporters/" target="_blank">Partners and Supporters</a>. Without their generous support we would not be able to have this terrific workshop, especially at the low price for registration. Most of these supporters will be there with informational tables, and it would be great if you could stop by their display and say hello during the workshop this year. They offer solutions to help us get our jobs done, and they are generally very familiar with our sector.<br />
<br />
Here is the group we will have with us later this month:<br />
<br />
<div style="text-align: center;">
<span style="color: #38761d; font-size: large;"><strong>Founding Partner</strong></span><br />
<strong>Commonfund</strong><br />
<a href="https://www.commonfund.org/" target="_blank">https://www.commonfund.org</a></div>
<div style="text-align: center;">
<br /></div>
<div style="text-align: center;">
<span style="color: #38761d; font-size: large;"><strong>Alliance Partners</strong></span><br />
<strong>Association for Financial Professionals</strong></div>
<div style="text-align: center;">
<a href="http://www.afponline.org/" target="_blank">http://www.afponline.org/</a></div>
<div style="text-align: center;">
<strong>NACUBO</strong><br />
<a href="http://www.nacubo.org/" target="_blank">http://www.nacubo.org/</a></div>
<div style="text-align: center;">
<br /></div>
<div style="text-align: center;">
<span style="color: #38761d; font-size: large;"><strong>Supporters</strong></span><br />
<strong>Bluefin Payment Systems</strong></div>
<div style="text-align: center;">
<a href="https://www.bluefin.com/" target="_blank">https://www.bluefin.com/</a></div>
<div style="text-align: center;">
<strong>CampusGuard</strong><br />
<a href="https://www.campusguard.com/" target="_blank">https://www.campusguard.com/</a></div>
<div style="text-align: center;">
<strong>Coalfire</strong><br />
<a href="https://www.coalfire.com/" target="_blank">https://www.coalfire.com/</a></div>
<div style="text-align: center;">
<strong>FreedomPay</strong><br />
<a href="http://corporate.freedompay.com/" target="_blank">http://corporate.freedompay.com/</a></div>
<div style="text-align: center;">
<strong>Higher One</strong><br />
<a href="http://higherone.com/" target="_blank">http://higherone.com/</a></div>
<div style="text-align: center;">
<strong>Nelnet</strong><br />
<a href="http://www.nelnet.com/" target="_blank">http://www.nelnet.com/</a></div>
<div style="text-align: center;">
<strong>PayPal</strong><br />
<a href="https://www.paypal.com/home" target="_blank">https://www.paypal.com/home</a></div>
<div style="text-align: center;">
<strong>PNC Bank</strong><br />
<a href="https://www.pnc.com/en/small-business/payments-and-processing/pnc-merchant-services.html" target="_blank">https://www.pnc.com/en/small-business/payments-and-processing/pnc-merchant-services.html</a></div>
<div style="text-align: center;">
<strong>SecurityMetrics</strong><br />
<a href="https://www.securitymetrics.com/" target="_blank">https://www.securitymetrics.com/</a></div>
<div style="text-align: center;">
<strong>Sikich</strong><br />
<a href="http://www.sikich.com/" target="_blank">http://www.sikich.com/</a></div>
<br />
<br />
<strong><em><span style="color: red;">See you in Vegas, Baby!</span></em></strong>Anonymousnoreply@blogger.com0tag:blogger.com,1999:blog-5704248368030212351.post-40216845749264774152015-03-30T10:52:00.000-04:002015-04-13T17:30:24.529-04:002015 PCI Workshop Program Set<em>Update, 3/30/2015: I heard from one presenter that his description of his presentation did not match up with what appears on the Treasury Institute web site. If any other have seen this, please let me know and we'll get it worked out. Also, our <a href="http://www.treasuryinstitute.org/pci-partners-supporters/" target="_blank">Sponsors and Supporters</a> page may not be complete yet, I think some paperwork still needs to be processed before all the supporters are listed. --gaw</em><br />
<br />
<span style="color: #38761d;"><strong>FRIDAY, MARCH 30, 2015</strong></span><br />
<br />
It's here at last. The program committee for the workshop has wrapped up the schedule for the 2015 Treasury Institute PCI Workshop. You can see the summary on the Treasury Institute's Workshop information page at <a href="http://www.treasuryinstitute.org/pci-2015-agenda/" target="_blank">http://www.treasuryinstitute.org/pci-2015-agenda/</a>. I will add more details in the days to come.<br />
<br />
Something new this year - we will have a (semi-official) pre-workshop reception at the resort late on Sunday afternoon. Many attendees will be checking in on Sunday April 19, so we will have an informal Welcome Reception from <strike>5:00 until 6:30 PM</strike> <strong><span style="color: red;">6:00 until 7:30 PM</span></strong>. Talk about the week ahead or just relax after a day of travel with old friends and new. In years past groups have formed up on Sunday to sample the local restaurants and we will do the same. Dine at one of the <a href="https://greenvalleyranch.sclv.com/" target="_blank">Green Valley Ranch Resort, Spa, and Casino's</a> 10 restaurants or head for the Strip! Or you can have a more laid-back night and take in the latest flick at the Regal Cinema, with 10 screens right on the resort property.<br />
<br />
Whatever your arrival day plans may be, get ready for a fun and informative week at the 2015 Treasury Institute PCI Workshop.<br />
<br />
Note: We may break attendance records for the second year in a row. If you have any problem booking your room (we're nearly sold out), our Meeting Planner Megan at the Professional Development Group will help you out. Information on Workshop rooms and Megan's contact info may be found here: <a href="http://www.treasuryinstitute.org/pci-dss-hotel-information/" target="_blank">http://www.treasuryinstitute.org/pci-dss-hotel-information/</a>.Anonymousnoreply@blogger.com4tag:blogger.com,1999:blog-5704248368030212351.post-51016205901898349742015-03-18T16:30:00.000-04:002015-03-18T16:37:41.018-04:00OpenSSL to be patched Thursday 2015-03-19If you haven't heard the recent security news yet, be forewarned that newly-discovered flaws in the <a href="http://en.wikipedia.org/wiki/OpenSSL" target="_blank">OpenSSL</a> encryption library are <a href="http://marc.info/?l=openssl-announce&m=142653572011212&w=2" target="_blank">due to be patched</a> tomorrow, March 19. Some of the weaknesses have been classified with a "high" severity.<br />
<br />
The OpenSSL libraries provide <a href="http://en.wikipedia.org/wiki/Encryption" target="_blank">encryption</a> services to protect online communications such as e-mail, file transfers, and most importantly, secure web sites. The libraries implement the (outdated) Secure Sockets Layer (<a href="http://en.wikipedia.org/wiki/Transport_Layer_Security" target="_blank">SSL</a>) and its replacement the Transport Layer Security (<a href="http://en.wikipedia.org/wiki/Transport_Layer_Security" target="_blank">TLS</a>) protocols. If you see a padlock and "https://..." in your web browser's address bar then <a href="http://en.wikipedia.org/wiki/Transport_Layer_Security" target="_blank">SSL/TLS</a> is at work. A major segment of the global internet depends on OpenSSL to maintain data privacy and secure confidential information such as banking and credit card data, transactions related to healthcare and government services, and other <a href="http://en.wikipedia.org/wiki/Personally_identifiable_information" target="_blank">personally identifiable information</a> that can be used to commit identity theft and other fraud.<br />
<br />
Recently, the <a href="https://www.pcisecuritystandards.org/" target="_blank">PCI Security Standards Council</a> announced the <a href="https://www.pcisecuritystandards.org/pdfs/15_02_12_PCI_SSC_Bulletin_on_DSS_revisions_SSL_update.pdf" target="_blank">upcoming release</a> of the Payment Card Industry Data Security Standard (PCI DSS) version 3.1. The main reason for this update to the standards is to remove the older SSL protocol from lists that provide examples of strong cryptography. SSL no longer meets that definition based on recommendations by the U.S. National Institute for Standards and Technology, known as <a href="http://www.nist.gov/" target="_blank">NIST</a>.<br />
<br />
For a good discussion of <a href="http://krebsonsecurity.com/2015/03/openssl-patch-to-plug-severe-security-holes/" target="_blank">this news</a>, please see Brian Krebs's blog, <a href="http://krebsonsecurity.com/" target="_blank">Krebs on Security</a>. His post today, <em><a href="http://krebsonsecurity.com/2015/03/openssl-patch-to-plug-severe-security-holes/" target="_blank">OpenSSL Patch to Plug Severe Security Holes</a></em>, provides more background and explains the importance of putting these patches into place as soon as possible.Anonymousnoreply@blogger.com1tag:blogger.com,1999:blog-5704248368030212351.post-77647559015259398872015-03-18T13:30:00.000-04:002015-03-18T13:30:02.866-04:002015 PCI Workshop Tentative Schedule<strong>2015 Treasury Institute PCI DSS Workshop</strong><br />
Green Valley Ranch Resort (Greater Las Vegas)<br />
2300 Paseo Verde Pkwy<br />
Henderson, NV 89052<br />
April 20-22, 2015<br />
<br />
<strong><span style="font-family: inherit;"><em>Tentative Workshop Agenda</em><span style="color: blue;">*</span></span></strong><br />
<br />
<table border="0" cellpadding="0" cellspacing="0" style="border-collapse: collapse; width: 470px;">
<colgroup><col style="mso-width-alt: 4937; mso-width-source: userset; width: 101pt;" width="135"></col>
<col style="mso-width-alt: 12251; mso-width-source: userset; width: 251pt;" width="335"></col>
<tbody>
<tr height="21" style="height: 15.75pt;">
<td class="xl65" height="21" style="background-color: transparent; border: 0px black; height: 15.75pt; width: 101pt;" width="135"><strong><span style="font-family: Calibri;">Sunday
April 19th</span></strong></td>
<td style="background-color: transparent; border: 0px black; width: 251pt;" width="335"></td>
</tr>
<tr height="20" style="height: 15pt;">
<td height="20" style="background-color: transparent; border: 0px black; height: 15pt;"><span style="font-family: Calibri;">4:00 pm-6:00 pm</span></td>
<td style="background-color: transparent; border: 0px black;"><span style="font-family: Calibri;">Early Registration</span></td>
</tr>
<tr height="20" style="height: 15pt;">
<td height="20" style="background-color: transparent; border: 0px black; height: 15pt;"></td>
<td style="background-color: transparent; border: 0px black;"></td>
</tr>
<tr height="21" style="height: 15.75pt;">
<td class="xl65" colspan="2" height="21" style="background-color: transparent; border: 0px black; height: 15.75pt; mso-ignore: colspan;"><span style="font-family: Calibri;"><strong>Monday
April 20th</strong><span class="font6"> </span></span></td>
</tr>
<tr height="20" style="height: 15pt;">
<td height="20" style="background-color: transparent; border: 0px black; height: 15pt;"><span style="font-family: Calibri;">8:00 am -1:00 pm</span></td>
<td style="background-color: transparent; border: 0px black;"><span style="font-family: Calibri;">Conference Registration</span></td>
</tr>
<tr height="20" style="height: 15pt;">
<td height="20" style="background-color: transparent; border: 0px black; height: 15pt;"><span style="font-family: Calibri;">10:00 am-noon</span></td>
<td class="xl66" style="background-color: transparent; border: 0px black;"><span style="font-family: Calibri;"><strong>Optional Session: </strong><span class="font5">Introduction to PCI</span></span></td>
</tr>
<tr height="20" style="height: 15pt;">
<td height="20" style="background-color: transparent; border: 0px black; height: 15pt;"><span style="font-family: Calibri;">Noon-1:00 pm</span></td>
<td style="background-color: transparent; border: 0px black;"><span style="font-family: Calibri;">Lunch on your own</span></td>
</tr>
<tr height="20" style="height: 15pt;">
<td height="20" style="background-color: transparent; border: 0px black; height: 15pt;"><span style="font-family: Calibri;">1:00 pm-5:00 pm</span></td>
<td class="xl66" style="background-color: transparent; border: 0px black;"><span style="font-family: Calibri;"><strong>Workshop Begins: General and Concurrent Sessions</strong><span class="font5"> </span></span></td>
</tr>
<tr height="20" style="height: 15pt;">
<td height="20" style="background-color: transparent; border: 0px black; height: 15pt;"><span style="font-family: Calibri;">5:00 pm-6:30 pm</span></td>
<td style="background-color: transparent; border: 0px black;"><span style="font-family: Calibri;">The 90 Minute Networking Hour</span></td>
</tr>
<tr height="20" style="height: 15pt;">
<td height="20" style="background-color: transparent; border: 0px black; height: 15pt;"></td>
<td style="background-color: transparent; border: 0px black;"></td>
</tr>
<tr height="21" style="height: 15.75pt;">
<td class="xl65" colspan="2" height="21" style="background-color: transparent; border: 0px black; height: 15.75pt; mso-ignore: colspan;"><strong><span style="font-family: Calibri;">Tuesday
April 21st </span></strong></td>
</tr>
<tr height="20" style="height: 15pt;">
<td height="20" style="background-color: transparent; border: 0px black; height: 15pt;"><span style="font-family: Calibri;">8:00 am-9:00 am</span></td>
<td style="background-color: transparent; border: 0px black;"><span style="font-family: Calibri;">Buffet Breakfast</span></td>
</tr>
<tr height="20" style="height: 15pt;">
<td height="20" style="background-color: transparent; border: 0px black; height: 15pt;"><span style="font-family: Calibri;">9:00 am-Noon</span></td>
<td class="xl66" style="background-color: transparent; border: 0px black;"><strong><span style="font-family: Calibri;">General Sessions</span></strong></td>
</tr>
<tr height="20" style="height: 15pt;">
<td height="20" style="background-color: transparent; border: 0px black; height: 15pt;"><span style="font-family: Calibri;">Noon-1:30 pm</span></td>
<td style="background-color: transparent; border: 0px black;"><span style="font-family: Calibri;">Lunch</span></td>
</tr>
<tr height="20" style="height: 15pt;">
<td height="20" style="background-color: transparent; border: 0px black; height: 15pt;"><span style="font-family: Calibri;">1:30 pm-5:00 pm</span></td>
<td class="xl66" style="background-color: transparent; border: 0px black;"><strong><span style="font-family: Calibri;">General and Concurrent Sessions</span></strong></td>
</tr>
<tr height="20" style="height: 15pt;">
<td height="20" style="background-color: transparent; border: 0px black; height: 15pt;"><span style="font-family: Calibri;">5:00 pm-6:30 pm</span></td>
<td style="background-color: transparent; border: 0px black;"><span style="font-family: Calibri;">The 90 Minute Networking Hour</span></td>
</tr>
<tr height="20" style="height: 15pt;">
<td height="20" style="background-color: transparent; border: 0px black; height: 15pt;"></td>
<td style="background-color: transparent; border: 0px black;"></td>
</tr>
<tr height="21" style="height: 15.75pt;">
<td class="xl67" colspan="2" height="21" style="background-color: transparent; border: 0px black; height: 15.75pt; mso-ignore: colspan;"><strong><span style="font-family: Calibri;">Wed.
April 22nd <span style="mso-spacerun: yes;"> </span></span></strong></td>
</tr>
<tr height="20" style="height: 15pt;">
<td class="xl68" height="20" style="background-color: transparent; border: 0px black; height: 15pt;"><span style="font-family: Calibri;">8:00 am- 9:00 am</span></td>
<td class="xl68" style="background-color: transparent; border: 0px black;"><span style="font-family: Calibri;">Buffet Breakfast</span></td>
</tr>
<tr height="20" style="height: 15pt;">
<td class="xl68" height="20" style="background-color: transparent; border: 0px black; height: 15pt;"><span style="font-family: Calibri;">9:00 am-noon</span></td>
<td class="xl69" style="background-color: transparent; border: 0px black;"><strong><span style="font-family: Calibri;">General Sessions</span></strong></td>
</tr>
<tr height="20" style="height: 15pt;">
<td class="xl68" height="20" style="background-color: transparent; border: 0px black; height: 15pt;"><span style="font-family: Calibri;">Noon-1:00 pm</span></td>
<td class="xl68" style="background-color: transparent; border: 0px black;"><span style="font-family: Calibri;">Lunch</span></td>
</tr>
<tr height="20" style="height: 15pt;">
<td class="xl68" height="20" style="background-color: transparent; border: 0px black; height: 15pt;"><span style="font-family: Calibri;">1:00 pm-3:30 pm</span></td>
<td class="xl69" style="background-color: transparent; border: 0px black;"><strong><span style="font-family: Calibri;">General Sessions</span></strong></td>
</tr>
</tbody></colgroup></table>
<br />
<span style="color: blue;">*Agenda subject to change at any time<span style="color: black;"><br /></span></span><br />
<strong><em>Information about sessions and speakers is coming soon!</em></strong><br />
Anonymousnoreply@blogger.com1tag:blogger.com,1999:blog-5704248368030212351.post-1077864871168611132015-03-13T15:08:00.000-04:002015-03-18T15:44:33.112-04:00Program Finalized for 2014 PCI DSS Workshop<strong>NOTE: This is for the <span style="color: red;">2014</span> Workshop. The <a href="http://treasuryinstitutepcidss.blogspot.com/2015/03/2015-pci-workshop-tentative-schedule.html">2015 schedule</a> is coming soon!</strong><br />
<br />
The program committee for the Treasury Institute of Higher Education 2014 PCI DSS Workshop has finished its work and it's all ready for you now on the Workshop registration page. Please join us for this annual sharing of information among your colleagues. The theme of the Workshop will be structured to answer your questions regarding the changes to the PCI DSS that are coming as a result of version 3.0 that is effective January 1, 2014. View the agenda by visiting the registration link at the bottom of this post.<br />
<br />
And we've moved the venue this year: The Workshop will be held in Chicago at the beautiful Palmer House, right in the heart of the city. The Palmer is truly a gem and you will have all of Chicago right out the front door.<br />
<br />
I plan on arriving Sunday to start catching up with old friends and meet some new ones as well. Sunday night is a great time to jump in start connecting with your peers at one of the informal restaurant outings. I can't overstate the importance of the networking that is available at this workshop. This is your chance to not only gather knowledge, but to gain support of your PCI compliance colleagues from all around the US and Canada.<br />
<br />
Agenda Items include:<br />
<ul>
<li>Threat Trends, Attack Vectors and What the Verizon Data Breach Investigations Teaches Us</li>
<li>Merchant and Service Provider Oversight</li>
<li>PCI DSS 3.0: What Higher Education Institutions Need to Know</li>
<li>Preparing for and Reacting to a Breach Incident</li>
<li>Evolution of Security Culture</li>
</ul>
Participants will<br />
<ul>
<li>Learn how best to manage PCI compliance at your institution</li>
<li>Understand how the PCI Council's Special Interest Groups' recommendations and new QSA Quality Assurance program will affect you</li>
<li>Share experiences of other institutions that are working on PCI compliance on their campuses</li>
<li>Get your questions answered, including what to expect from the PCI Council in the future</li>
<li>Earn up to 18.3 CPE credit</li>
</ul>
<h4>
Date and Location:</h4>
April 27-30, 2014<br />
Palmer House Hilton | Chicago, IL<br />
Registration Fee is $450.00<br />
<br />
Check It Out and Register at <a href="http://www.treasuryinstitute.org/pages/PCI-DSS-Workshop-2014.html" target="_blank">www.treasuryinstitute.org/pages/PCI-DSS-Workshop-2014.html</a>.Anonymousnoreply@blogger.com0tag:blogger.com,1999:blog-5704248368030212351.post-64523960158610868182015-02-16T15:26:00.000-05:002015-02-16T15:29:52.075-05:00SSL is No Longer Strong CryptographyOn Friday the Payment Card Industry Security Standards Council (PCI SSC) released their <a href="https://www.pcisecuritystandards.org/pdfs/15_02_12_PCI_SSC_Bulletin_on_DSS_revisions_SSL_update.pdf" target="_blank">official statement</a> regarding the acceptability of Secure Sockets Layer (SSL) version 3 for protecting payment data. Based on guidance from NIST and after months of discussions with stakeholders, no version of SSL encryption should be considered "strong cryptography" as defined by the PCI Council.<br />
<br />
The Council will be releasing version 3.1 of both the PCI DSS and the PA-DSS to address this issue. The date for the release has not yet been announced.<br />
<br />
If you are running any version of SSL on your e-commerce servers, even version 3.0, you should disable it along with older versions of Transport Layer Security (TLS). TLS should be version 1.2 or higher. Most modern and currently patched web servers should support this configuration. If you have old server software this may not be possible.<br />
<br />
More information is available in the official statement at this link:<br />
<a href="https://www.pcisecuritystandards.org/pdfs/15_02_12_PCI_SSC_Bulletin_on_DSS_revisions_SSL_update.pdf">https://www.pcisecuritystandards.org/pdfs/15_02_12_PCI_SSC_Bulletin_on_DSS_revisions_SSL_update.pdf</a><br />
<br />
<strong>PCI SSC Official Statements:</strong><br />
<a href="https://www.pcisecuritystandards.org/news_events/statements.php">https://www.pcisecuritystandards.org/news_events/statements.php</a>Anonymousnoreply@blogger.com0tag:blogger.com,1999:blog-5704248368030212351.post-44708688267207894482015-02-13T10:13:00.002-05:002015-02-13T10:13:40.719-05:00Stay tuned for a PCI Council AnnouncementInformation regarding the upcoming release PCI DSS v3.1 and PA-DSS v3.1 is supposed to be coming out today.Anonymousnoreply@blogger.com0tag:blogger.com,1999:blog-5704248368030212351.post-60211308339831980732015-01-23T18:47:00.000-05:002015-01-23T18:59:14.584-05:00Call for Presentations at Our 2015 PCI Workshop<div class="separator" style="clear: both; text-align: center;">
<a href="http://1.bp.blogspot.com/-y-y_JaJy5ug/VMLfB7Ym1QI/AAAAAAAAAIg/YRVxPxm2cmU/s1600/2015-Money.jpg" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" src="http://1.bp.blogspot.com/-y-y_JaJy5ug/VMLfB7Ym1QI/AAAAAAAAAIg/YRVxPxm2cmU/s1600/2015-Money.jpg" height="138" width="200" /></a></div>
A few of us have been working since late summer to develop a program for the <a href="http://www.treasuryinstitute.org/2015-pci-dss-conference-registration-university-only/" target="_blank"><strong>2015 PCI Workshop</strong></a> presented by the Treasury Institute for Higher Education. As in the last two previous years we are planning on offering general sessions and keynote speakers for the entire group, and also spending some of our time split into two concurrent tracks: Business and Technology. We have been going over feedback and listening to other ideas to make this another great workshop.<br />
<div>
</div>
But coming up with those ideas is the easy part; we still need to find people who are interested in presenting at the workshop.<br />
<br />
So we are turning to you, our friends and colleagues in the Higher Education community who may be interested in doing a presentation on one of these topics, or maybe another topic idea of your own that you would like to share. Here is the list we came up with:<br />
<br />
<ul>
<li>Third party/service provider management/oversight</li>
<li>Requirement 9.9 and developing programs to manage/track point of interaction (POI) devices and train employees</li>
<li>Scoping: What's in, what's out, and why</li>
<li>Choosing the correct SAQ</li>
<li>Developing campus policies</li>
<li>Managing your PCI team</li>
<li>Branded campus ID cards and the ramifications for scope, security and risk</li>
<li>Incident Response: Policy, documentation, training, testing...</li>
<li>Campus security awareness training programs: Developing, managing, and the difference from breach response training </li>
</ul>
<br />
If you have some experience in any of these areas that you would like to share, please get in touch. Or perhaps some other PCI or payment topic or project you would like to tell us about. Contact info is below.<br />
<br />
We are also lining up some terrific industry experts to discuss these topics:<br />
<br />
<ul>
<li>EMV, P2PE and Tokenization</li>
<li>Managing Merchants, Compliance and Risk from the Acquirer Perspective</li>
<li>Penetration Testing, esp. validating segmentation, pen tests vs. vulnerability scans, and tests for new SAQs</li>
</ul>
<div>
</div>
If you are interested in taking part in the <a href="http://www.treasuryinstitute.org/2015-pci-dss-conference-registration-university-only/" target="_blank"><strong>2015 PCI Workshop</strong></a>, write to one or more of us on the program committee:<br />
<br />
Ron K - CampusGuard<br />
Pete C - 403 Labs/Sikich<br />
Mike L - The Penn State U<br />
Robbyn L U of Arizona<br />
Linda W - Gonzaga U<br />
or Me!<br />
<br />
If you don't have contact information for any of these folks, you can leave a message for me by using the Contact Form on the right side of this page.<br />
<br />
Thank you in advance for considering sharing your knowledge and experience with us on the Las Vegas frontier this spring. I look forward to hearing from and seeing you all!<br />
<br />
Gene<br />
<br />
<em><span style="color: red;">Reminder: Outside of invited speakers, the TIHE PCI Workshop is open to members of the Higher Education community only.</span></em><br />
<em><span style="color: #274e13;"> </span></em><br />
<em><span style="color: #274e13;"> </span></em>Anonymousnoreply@blogger.com0tag:blogger.com,1999:blog-5704248368030212351.post-82941604613788419632015-01-09T19:36:00.001-05:002015-01-09T19:36:48.756-05:00Incident Response<em>[Here is another in our series of posts from Joe Tinucci, Assistant Treasurer of the University of Colorado. The best practices Joe shares today center on incident response, with which we all need to be concerned. Be prepared and don't think about a breach in terms of "if", but in terms of "when". Thanks for this excellent advice, Joe! --gaw]</em><br />
<br />
Given the continuing publicity surrounding merchant credit card breaches, it is vital that every merchant has a tested Incident Response (IR) plan in place. Not only is this a requirement of the PCI DSS, but it also makes good business and practical sense. One of the major benefits of a tested IR plan is the roadmap that it provides when everyone is tempted to panic and run around like chickens with their heads cut off -- believe me, your situation will be difficult enough without some sort of guide or plan in place to deal with the incident and the fallout.<br />
<br />
And, the security consensus is starting to gel around the idea that everyone should simply plan on getting breached and so your best defense is to be able to rapidly detect breaches and to move quickly to contain the damage and/or exfiltration of data. In other words, it is in your future and you might as well be ready for it...<br />
<br />
<strong>Why Should You Care?</strong><br />
<br />
Just about anyone can list a bunch of reasons why you should care about being breached. But, it would be a good exercise to list as many as possible just in case you need to lay them out for management at some point:<br />
<ul>
<li>Your contract with your acquiring bank requires you to be in compliance with the PCI DSS; being breached is considered prima-facie evidence that you were not in compliance with both your bank contract and the PCI DSS.</li>
<li>There are fines assessed by the card associations and by your acquiring bank. These fines can run to thousands, or hundreds of thousands of dollars. Someone is going to have to figure out how to pay these unanticipated costs out of their departmental or campus budget.</li>
<li>There are investigation and response costs that could easily run into five or more figures. Just bringing in an outside QSA to perform a Report on Compliance (ROC, also known as the IT Audit From Hell) could be prohibitively costly. It is likely that the IT budget wasn't set up in expectation of having one (or more) of these audits. And, like fines, it will have to come unexpectedly out of someone's budget.</li>
<li>If there is fraud committed with the stolen cardholder data it is likely that the merchant will have to absorb some or all of the losses. Given the trends today of issuing banks attempting to transfer liability for fraud directly to merchants, these costs could outweigh all others combined.</li>
<li>There will be remediation costs as well as business process changes; the impact of these could be large and could include the cost of new equipment and software and lots of hours of consultant time.</li>
<li>There will be the cost of business interruption for the merchant. Depending on the timing of the incident this cost could have enormous impact, including significant nonfinancial impacts -- imaging not being able to take online admission applications for two weeks before the application deadline.</li>
<li>Your ability to accept cards for payments could be restricted or denied. While this might not be a big deal for some departments, any department doing a significant amount of online business would have to re-implement manual payment processing. And, completely losing the ability to process cardholder payments could be beyond disastrous for the organization.</li>
<li>Finally, your reputation with your customers -- students, staff, parents, the local community, the general public -- will be impacted. If you screw up in handling the incident the reputational hit could have long lasting effects.</li>
</ul>
<br />
<strong>How Do You Know That You Have an Incident?</strong><br />
<br />
Studies have shown that most merchants do not detect their own breaches but instead are informed that they have a problem by outside entities such as the card associations, law enforcement, a bank, or through an extortion attempt. So, in many cases the first sign that you have had a breach comes via a phone call or email.<br />
<br />
Another warning sign of an incident is if staff fall prey to any of the many phishing attempts that hit their desk -- if they are trained to report that they fell for it. Of course, if they don't realize that there is a problem responding to phishing emails or they are too embarrassed to report it, you are back to hoping that you eventually receive the phone call above.<br />
<br />
Other signs include "funny" computer or system behavior -- sending out unauthorized emails or files, slow boot times, unexpected or unusual program behavior, changes to file fingerprints, and so forth.<br />
<br />
Your staff (and really, any staff members connected anywhere to your network) need to be trained to ask for help when they see these signs so their systems can be investigated and cleaned as quickly as possible.<br />
<br />
<strong>Before the Incident</strong><br />
<br />
There are several key steps that you need to take to prepare for implementing your IR plan:<br />
<ul>
<li>Understand what data is held where in your networks. This is a data inventory and classification process; everyone says that it is a good idea but not everyone has done it. At the very least you need to identify where cardholder data is stored and processed so you can designate those PCs/systems as high-risk systems holding critical data.</li>
<li>Update / patch all equipment / systems that touch cardholder data. Most organizations have processes in place for updating their PC operating systems and anti-virus / anti-malware programs, but are there other types of equipment that come in contact with cardholder data that need updating (such as copiers and firewalls)?</li>
<li>Identify your primary IR team. At a minimum, the team should be composed of representatives from Treasury, IT security, Legal, Public Relations / Communications, senior management, the merchant department, and your external IT security vendor (if applicable).</li>
<li>Identify your supplemental IR team members, if their expertise becomes necessary. This will most certainly include someone from your acquiring bank, an IT forensics vendor, local police, the FBI or Secret Service, an outside crisis communications expert, your trusted mailing house, a wholesale credit report provider, your telephone hotline provider, and possibly counselors and advisors to your customers. Other representatives should be included as the situation requires.</li>
<li>Finally, you should draw up the plan and make sure that it gets distributed to all parties holding critical data, their system owners, and their designated staff backups. I have found that a checklist format works well, or you can create it in a "Do this first, then that, then..." format.</li>
</ul>
<br />
<strong>IR Plan Components</strong><br />
<ol>
<li>Immediately contain the data exposure and minimize data loss</li>
<li>Preserve the evidence</li>
<ul>
<li> Do not access the system</li>
<li> Remove network and web access</li>
<li> DO NOT TURN OFF SYSTEM</li>
</ul>
<li>Alert all necessary parties immediately</li>
<li>Call for forensics help</li>
<li>Gather the relevant merchant data (merchant ID, merchant contacts, merchant transaction volume, last PCI DSS status, etc.)</li>
<li>Continue with your IR plan</li>
</ol>
This document can be found at: <a href="http://usa.visa.com/download/merchants/cisp-what-to-do-if-compromised.pdf">http://usa.visa.com/download/merchants/cisp-what-to-do-if-compromised.pdf</a><br />
<br />
There are many step-by-step frameworks for creating an IR plan; find one and customize it for your organization if you have to start from scratch (see resource suggestions below).<br />
<div>
</div>
<div>
<strong>During the Incident</strong></div>
<div>
</div>
<div>
<u>First</u> – Clear your calendar for the remainder of the week. This incident will take an enormous amount of time between phone calls, in-person meetings, working with the incident response team, documenting, and so forth. Kiss your calendar goodbye!</div>
<div>
</div>
<div>
<u>Second</u> – Notify and assemble the team. Decide when to bring the acquiring bank into the loop, and then bring them in. If you consider the acquirer to be your partner, you would bring them in sooner than if you consider them to be an adversary; in any case you will need to let them know eventually.</div>
<div>
</div>
<div>
<u>Third</u> – Contain the damage. Make sure that everyone involved at the merchant understands that they must:</div>
<ul>
<li><strong>STOP</strong> -- do not touch the machine, do not unplug the power</li>
<li><strong>ISOLATE</strong> -- remove the machine / system from the network by unplugging the network (or Internet) connection</li>
<li><strong>CALL FOR HELP</strong></li>
</ul>
<div>
<u>Fourth</u> – Figure out what happened to which system and how to work without it. Remember that you have a clock ticking -- the getting-back-into-business clock. While you do not want to do anything in haste, you cannot dawdle...</div>
<br />
<u>Fifth</u> – Communicate as appropriate to your constituencies, as directed by the IR team.<br />
<br />
<u>Sixth</u> – Remediate. Fix whatever business processes went wrong, and make sure it doesn't happen again.<br />
<br />
<strong>After the Incident</strong><br />
<br />
Once you are through the mad rush of responding to the incident, you should debrief the IR process. What did you learn from the incident, as well as the response to the incident? What weak technical and/or business practices were identified in this process and how can they be fixed and/or strengthened? While it is easy to skip this step, it will help strengthen your response the next time the IR plan is activated.<br />
<br />
<strong>Resources</strong><br />
<br />
There are many incident response-related resources available. As noted above, the Visa What To Do If Compromised document is a great resource upon which to base a merchant IR plan. One resource that we have found very helpful is our bank; they shared access to their risk management portal from which we drew several useful IR templates. Likewise, your organization's risk management department (if you have one) is a good resource if you need to start from scratch to draw up an IR plan, as are any insurance relationships that your organization might have. Finally, the usual security websites have lots of IR plan templates -- SANS, GIAC, ISACA, REN-ISAC, and so forth.<br />
<br />
Good luck and may all your incidents be only tests of the plan…<br />
<br />
<em>Joe Tinucci is the Assistant Treasurer at the University of Colorado, where he manages the University's banking relationships. As part of that job, he also drives the PCI DSS compliance process for approximately 160 card-accepting merchants across diverse card-acceptance environments in four campuses. </em><em>Joe can be reached at (303) 837-2185 or </em><a href="mailto:joe.tinucci@cu.edu"><em>joe.tinucci@cu.edu</em></a><em>).</em>Anonymousnoreply@blogger.com2tag:blogger.com,1999:blog-5704248368030212351.post-6312720383732592622014-11-24T11:02:00.000-05:002014-11-24T11:02:08.161-05:00PCI DSS Evolution - Best Practices<em>[Here is another in our series of posts from Joe Tinucci, Assistant Treasurer of the University of Colorado. The best practices Joe discusses today focus on supplemental guidance published by the PCI Security Standards Council. Thanks for these great reviews, Joe! --gaw]</em><br />
<em></em><br />
I mentioned in <a href="http://treasuryinstitutepcidss.blogspot.com/2014/10/report-from-orlando.html" target="_blank">my last column</a> about the activity at the PCI Security Standards Council's North American Community Meeting that there was a lot of discussion of how the PCI DSS will be evolving. Most of that conversation focused on three areas: continuous compliance, greater assurance, and the adoption of best practices. In this post, I want to look at the current best practices guidance documents issued by the Council as one way of predicting how the standard will evolve.<br />
<div>
</div>
All of these documents can be found at the PCI SSC website, in the PCI Standards Documents Library; <a href="https://www.pcisecuritystandards.org/security_standards/documents.php">https://www.pcisecuritystandards.org/security_standards/documents.php</a>, under the <u>Fact Sheets & Info Supps</u> tab.<br />
<br />
<em><strong>Best Practices for Implementing a Security Awareness Program</strong></em><br />
<br />
This is the most recent document issued by the Council to assist organizations in complying with Requirement 12.6 for a formal security awareness program. What I find most interesting about this document is how detailed and prescriptive it is - it does a very good job of laying out the specific topics on which staff should be trained at which level of responsibility. In addition, this guide discusses metrics to measure the effectiveness of the training program. Finally, it provides a Security Awareness Program Checklist for use in managing your program. With this much specific guidance, I see how it could easily be integrated into Requirement 12 of a future version of the standard.<br />
<br />
<em><strong>PCI DSS V3.0 Best Practices for Maintaining PCI DSS Compliance</strong></em><br />
<br />
This document is intended to present best practices for maintaining PCI DSS compliance AFTER a merchant organization has already successfully achieved compliance. It appears that almost 90% of compliant organizations fail to maintain their compliance by the time the next self-assessment takes place; this is reason enough to rethink how we approach security (which is the goal of this entire process rather than simple compliance). In effect, this document serves as a roadmap for making compliance your risk-based, measured, business-as-usual practice rather than a once-a-year event. Since this is the direction in which the standard appears to be evolving, this document points to future new features such as ownership for coordinating security activities, continuous monitoring of security controls, development of performance metrics, and better risk assessment processes.<br />
<br />
<em><strong>- Mobile Payment Acceptance Security Guidelines for Merchants as End-Users v1.1</strong></em><br />
<em><strong>- Mobile Payment Acceptance Security Guidelines for Developers v1.1</strong></em><br />
<br />
The first of these two Guides provides merchants with best practices for accepting / processing payments on mobile devices; the second does the same for app developers. While the world of mobile devices is constantly changing, these guides focus on three main objectives that remain true no matter the underlying technology:<br />
<ul>
<li>Prevent account data from being intercepted when entered into a mobile device</li>
<li>Prevent account data from compromise while processed or stored within the mobile device</li>
<li>Prevent account data from interception upon transmission out of the mobile device</li>
</ul>
As merchants see more mobile payments (and requests for mobile payment acceptance), expect these best practices to evolve as well as reappear as part of the next generation PCI DSS.<br />
<br />
<em><strong>- Skimming Prevention: Overview of Best Practices for Merchants</strong></em><br />
<em><strong>- Skimming Prevention: Best Practices for Merchants</strong></em><br />
<br />
When the topic of skimming devices comes up, what automatically comes to mind -- at least for me -- is skimmers attached to ATMs or gas pumps. This guidance covers far more than those two situations, including swipe card terminals and the placement of PIN-stealing cameras, and presents best practices for preventing and detecting tampering of physical equipment. Many pictures of modified devices and checklists make these guides easy to integrate into your merchant processing practices.<br />
<br />
<em><strong>Third-Party Security Assurance</strong></em><br />
<br />
As noted in a previous post, engaging a Third Party Service Provider (TPSP) does not absolve the merchant from being compliant. Even if all cardholder activities are outsourced, the merchant is responsible for the proper vetting and selection of vendors as well as ensuring that they are compliant. This guide focuses on due diligence in selecting an TPSP, correlating the services provided by the TPSP to the PCI DSS, written agreements, and monitoring. This guidance will be particularly useful for those merchants in the SAQ A environment, where payment processing is outsourced to a TPSP but where the merchant is still responsible for being compliant, but it applies to all arrangements where a TPSP is engaged.<br />
<br />
<em><strong>ATM Security Guidelines</strong></em><br />
<br />
This guidance is intended for ATM manufacturers, integrators, and deployers. However, the sections on physical security and prevention of shoulder surfing might be of interest to ATM owners or others who have ATMs in their facilities.<br />
<br />
There is one more guidance document still to come as a result of the 2014 Special Interest Groups (SIGs) -- <em>Penetration Testing Guidance</em>. Of all the requirements of the PCI DSS, this one has been most problematic for our organization to understand and meet because good pen testers are few and far between. This document should help organizations understand what they need to do, either internally if they have the appropriate skill set or through outsourcing this task to qualified pen testers.<br />
<br />
The newest SIGs have been created to address:<br />
<br />
<em>- Daily Log Monitoring: Guidance on Effective Daily Log Monitoring</em>, and<br />
<em>- Shared Responsibilities: Guidance on Determining Shared Responsibilities for Entities and Third Party Service Providers</em><br />
<br />
I am looking forward to the output from both of these groups because I think that they address particularly problematic areas in the implementation of the PCI DSS. (<a href="https://www.pcisecuritystandards.org/get_involved/special_interest_groups.php">https://www.pcisecuritystandards.org/get_involved/special_interest_groups.php</a>)<br />
<br />
Finally, there are several guidance documents that originated out of version 2 of the PCI DSS but which are still useful:<br />
<ul>
<li>eCommerce Guidelines</li>
<li>Mobile Payment Acceptance</li>
<li>Cloud Computing Guidelines</li>
<li>Risk Assessment Guidelines</li>
<li>Wireless Guidelines</li>
<li>Tokenization Guidelines</li>
<li>Virtualization Guidelines</li>
</ul>
<br />
While there are still numerous areas within version 3 of the PCI DSS that need clarification, the best practices and guidance documents above will help merchants make sense of the intent of the areas addressed and prepare for the evolution from best practices to requirements in future versions of the standard.<br />
<br />
<hr />
<em></em><br />
<em>Joe Tinucci is the Assistant Treasurer at the University of Colorado, where he manages the University's banking relationships. As part of that job, he also drives the PCI DSS compliance process for approximately 160 card-accepting merchants across diverse card-acceptance environments in four campuses. </em><em>Joe can be reached at (303) 837-2185 or </em><a href="mailto:joe.tinucci@cu.edu"><em>joe.tinucci@cu.edu</em></a><em>)</em><br />
<br />Anonymousnoreply@blogger.com0tag:blogger.com,1999:blog-5704248368030212351.post-13594813638685170192014-10-20T19:05:00.002-04:002014-10-21T17:51:24.990-04:00What is a PCI Service Provider? (FAQs)Working with third parties can be either a joy or a constant source of frustration. Or sometimes a little of both. I frequently come into contact with departments in our university who wish to work with an outside party, but have little understanding of what is involved.<br />
<br />
One difficult term is <em>"service provider."</em> It's difficult because it can mean different things to different people. And lately the PCI Security Standards Council has been emphasize that "touching" cardholder data may be a little too narrow a definition. Scope can be extended out to entities that can affect the security of cardholder data without actually touching it.<br />
<br />
I tried to come up with a short list of questions and answers that help clarify the issue when we are talking about what I call <em>PCI Service Providers</em>. These are the types of entities that are defined in the Glossary and which we are required to manage per Requirement 12.8. There are other types of service providers I will touch on later.<br />
<br />
Note: Parts of this post that are in the <span style="color: #38761d;">color green are examples from one single, particular merchant and <strong>are not intended to serve as advice or a recommendation</strong>.</span><br />
<br />
<strong>What is the official definition of a Service Provider?</strong><br />
<em>From the Payment Card Industry Security Standards Council (PCI SSC) Glossary</em><br />
<br />
<strong>Service Provider</strong><br />
<ul>
<li>Business entity that is not a payment brand, directly involved in the processing, storage, or transmission of cardholder data on behalf of another entity. This also includes companies that provide services that control or could impact the security of cardholder data. Examples include managed service providers that provide managed firewalls, IDS and other services as well as hosting providers and other entities. If an entity provides a service that involves only the provision of public network access—such as a telecommunications company providing just the communication link—the entity would not be considered a service provider for that service (although they may be considered a service provider for other services).</li>
</ul>
<div>
</div>
<strong>How does a Merchant determine if an entity is a PCI Service Provider?</strong><br />
<ol>
<li>If a third party business entity processes cardholder data on behalf of a Merchant, and the transactions are processed using a Merchant ID (MID) obtained by the Merchant from the Merchant's acquiring bank, that entity is a PCI Service Provider for the Merchant and falls within the Merchant’s scope of PCI DSS compliance.</li>
<li>If a third party business entity provides services for, or on behalf of a Merchant, and those services control or could impact the security of cardholder data or of transactions that are processed through the Merchant's MID, that entity is a PCI Service Provider for the Merchant and falls within the Merchant’s scope of PCI DSS compliance.</li>
</ol>
<div>
<strong>What are a Merchant's obligations to its acquiring bank in regards to its PCI Service Providers?</strong></div>
<ol>
<li>The Merchant must register all PCI Service Providers with its acquiring bank. </li>
</ol>
<div>
<strong>What are a Merchant's obligations under PCI DSS in regards to its PCI Service Providers?</strong><br />
<div>
The Merchant must manage all PCI Service Providers according to PCI DSS Requirement 12.8 and all sub-requirements.</div>
</div>
<ol>
<li>The Merchant must verify that all PCI Service Providers are compliant with PCI DSS.</li>
<li>A written agreement must be maintained in which the PCI Service Provider acknowledges responsibility for the security of the Merchant’s cardholder data.</li>
<ul>
<li>For services provided in 2015, the entity must be assessed under version 3.0 of the PCI DSS, unless the relevant services have been previously assessed under PCI DSS version 2.0 and that assessment is valid during the 2015 service period.</li>
<li><em><span style="color: #38761d;">(My organization's standard for validation is a registered Visa or MasterCard Level 1 Service Provider, validated as compliant for all the services that are covered in the agreement between the PCI Service Provider and the Merchant. Each Merchant must decide its own standard)</span></em></li>
</ul>
<li>The Merchant must exercise proper due diligence before engaging a service provider.</li>
<li>The Merchant must monitor the PCI compliance of all PCI Service Providers at least annually.</li>
<li>The Merchant must maintain information about which PCI DSS requirements are managed by each PCI Service Provider, and which PCI DSS requirements are managed by the Merchant.</li>
</ol>
<div>
<strong>What if a business entity that is not a Visa or MasterCard Level 1 Service Provider wishes to work with the Merchant?</strong></div>
<ol>
<li>Each Merchant must decide this question itself, based on its own risk assessment process, following PCI DSS v3, Requirement 12.2.</li>
<li><em><span style="color: #38761d;">My organization has operated under the following internal guidelines. You should work with your own QSA to determine what is best for your organization.</span></em></li>
<ul>
<li><span style="color: #38761d;">Any such business entity must be approved in writing by [the owner of Merchant Services] before doing business with the University. Before such approval is given, the entity must meet the same standard of PCI DSS compliance validation as a Level 1 Service Provider would meet. That is, the submission of a valid and properly signed Attestation of Compliance (AOC) and the executive summary section of the accompanying Report on Compliance (ROC) prepared by a PCI Qualified Security Assessor in good standing with the PCI SSC at the time of the assessment.</span></li>
<li><span style="color: #38761d;">The submission of a PCI Self-Assessment Questionnaire, or SAQ, is not sufficient for validation of compliance for PCI Service Providers.</span></li>
</ul>
</ol>
<div>
All Merchants must develop their own policies and procedures for working with third-party Service Providers. There isn't a one-size-fits-all solution. How about you share your approach in the comments section?</div>
<div>
</div>
<div>
For additional guidance, please see the PCI SSC Information Supplement on this subject, <a href="https://www.pcisecuritystandards.org/documents/PCI_DSS_V3.0_Third_Party_Security_Assurance.pdf" target="_blank"><em>Third-Party Security Assurance</em>,</a> written by the Third-Party Security Assurance Special Interest Group and published in August 2014 by the PCI Security Standards Council.</div>
<div>
</div>
Anonymousnoreply@blogger.com2tag:blogger.com,1999:blog-5704248368030212351.post-61677687003587011042014-10-17T15:23:00.000-04:002014-10-20T08:59:16.016-04:00Unsolicited and Unwelcome ContactsGood Afternoon!<br />
<br />
Over the past several days many people associated with the Treasury Institute for Higher Education have received emails and phone calls from a representative of one side in a long-running labor dispute in Nevada between a labor group and a casino owners group.<br />
<br />
These uninvited calls/emails are part of one side's aggressive tactics to force a particular outcome in the dispute at the Green Valley Ranch Resort (our host facility for the upcoming 2015 PCI-DSS Workshop). To all our friends and participants that were disturbed by this outreach, the Treasury Institute sincerely apologizes as well as the Green Valley Ranch Resort.<br />
<br />
Please do not respond or engage these representatives, and refer all requests to <a href="http://www.prodev.com/" target="_blank">Professional Development Group II, Inc</a>. (our meeting's planning and organizing company) or the Institute’s Executive Directors. We will continue to work directly with the resort to ensure that the upcoming workshop is unaffected by these tactics.<br />
<br />
Contact:<br />
<em>Jon K. Speare</em><br />
<em>Executive Director</em><br />
<a href="http://www.treasuryinstitute.org/" target="_blank"><em>The Treasury Institute for Higher Education</em></a><br />
<br />
<br />
<br />Anonymousnoreply@blogger.com0tag:blogger.com,1999:blog-5704248368030212351.post-50575618481300306782014-10-03T16:29:00.002-04:002014-10-03T16:29:32.556-04:00Report from Orlando<em>[Here is another in our series of posts from Joe Tinucci, Assistant Treasurer of the University of Colorado. Thanks for the report, Joe! --gaw]</em><br />
<em></em><br />
If you have been around the PCI DSS for any length of time, you know that the standard is developed and maintained by the PCI Security Standards Council (PCI SSC). Every year the PCI SSC holds a series of Community Meetings around the globe; this year's North American meeting was held in Orlando, FL, on September 9 - 11, 2014. This meeting serves as a good opportunity to find out what is on the Council's mind regarding current issues and the direction of the PCI DSS, to network with other merchants, and to talk to the payment card brands.<br />
<br />
There were several trends and/or important issues apparent at the meeting; a short summary follows.<br />
<br />
<strong>Evolution of the Payment Card Industry Data Security Standard (PCIDSS)</strong><br />
There was a lot of discussion of the best practice guides and information supplements issued by the Council over the past couple of years to clarify the PCI DSS. It was clear from the conversations that these best practices will be integrated into the next version of the PCI DSS. So, if you want to plan for tomorrow’s requirements, look at today’s guidance and best practice documents.<br />
<br />
<strong>Compliance as Business-As-Usual</strong><br />
It was emphasized repeatedly that real system security cannot come from a once-a-year compliance event but must be integrated on an ongoing basis into a business-as-usual process. Several speakers noted that ongoing compliance monitoring saves a significant amount of time and money over an annual point-in-time assessment. It was also pointed out that most of the cardholder data breaches in the past year or two were of compliant entities who had let their security posture degrade, or whose compensating controls for PCI DSS requirements that could not be met directly didn’t adequately compensate for the risks / threats they were intended to counter.<br />
<br />
<strong>Compensating Controls May Not Be Adequately Compensating</strong><br />
I got the sense from the official and unofficial discussions at the meeting that future guidance will tighten up on the issue of compensating controls. A compensating control is put in place because an entity cannot meet one or more of the PCI DSS requirements, and is intended to address the risk but with a different approach. Since many of the breaches of compliant merchants appear to have been at the point of a compensating control, extra attention will be given to the justification for a compensating control, the implementation of the control, the verification that the control is actually meeting the goal of the security control it was intended to replace, and the maintenance of the control. If you need compensating controls, you need to fully document why, what, how, for how long, and who accepted the risk of not implementing the required control.<br />
<br />
<strong>Risk Management Approach</strong><br />
If there was a clear theme to the meeting it was that merchants and service providers have to adopt a risk management approach rather than a check-the-box mentality to security, whether for cardholder data or any other sensitive data. Documented risk assessment, ranking, management, and acceptance processes are crucial to best using limited resources to best advantage. Also, it was noted that the PCI DSS was moving toward risk-based requirements in future versions.<br />
<br />
<strong>Scoping is Essential</strong><br />
Reducing the scope of the merchant environment wherever it contains cardholder data is an essential technique for reducing the risk for a merchant; that is, limit the machines and systems that hold sensitive data to the fewest possible to process card transactions. Written documentation of how and why the scope was determined, how the isolation of the cardholder data environment is accomplished and maintained, and how that isolation was tested is a current best practice and very soon to be a requirement. This includes documentation of how the merchant determined that the scope of isolation from the rest of the network / infrastructure / environment was verified through penetration testing. The Council has a much-anticipated workgroup creating penetration testing guidelines; once these are issued institutions will need to quickly bring their security staff up to speed on this security technology / technique.<br />
<br />
<strong>Web Site Security for Ecommerce Transactions</strong><br />
There is a new emphasis on the security of merchant web sites / web applications that hand over the processing of payment card transactions to a third party service processor. Multiple recent breaches have been initiated with a compromise of the merchant web site, even though the actual payment was processed by the third party gateway processor. The newest version of the PCI DSS, version 3.0, splits apart the old assessment used with third party service providers in two – one for completely outsourced situations and the other for any other type of ecommerce web site.<br />
<br />
<strong>Managing Third Party Service Providers</strong><br />
Many organizations outsource the actual processing of a payment card transaction to a third party service provider. There was a lot of discussion of best practices in managing these service providers, including the requirement to renegotiate contracts to be much more specific about which party is responsible for each of the PCI DSS requirements. Documentation should be provided for how third party service providers were vetted, how their performance is monitored, and to whom they are providing data from the merchant’s customers and the compliance status of those other parties.<br />
<br />
<strong>Chipcards Are Coming But Are Not The Complete Answer</strong><br />
Chipcards, or smartcards with an onboard computer processing chip that conforms to the Europay / MasterCard / Visa (EMV) standard, are being issued (slowly) by financial institutions and merchants must be prepared to process them. The implementation of EMV cards is being spurred by an October 2015 deadline by which liability is switched from the card issuer to the accepting merchant for card-present fraud if the merchant cannot process EMV card transactions, as well as announcements of large retailers that they will be upgrading their equipment to accept EMV transactions (most of the announcements have come after massive breaches, with Target and Home Depot providing some recent examples). EMV cards provide much better protection against counterfeit plastic but do not provide much additional protection against other types of fraud. Also, other countries that have adopted the EMV standard for the card networks have seen fraud migrate from card-present transactions to card-not-present and ecommerce transactions.<br />
<br />
<hr />
<em></em><br />
<em>Joe Tinucci is the Assistant Treasurer at the University of Colorado, where he manages the University's banking relationships. As part of that job, he also drives the PCI DSS compliance process for approximately 160 card-accepting merchants across diverse card-acceptance environments in four campuses. </em><em>Joe can be reached at (303) 837-2185 or </em><a href="mailto:joe.tinucci@cu.edu"><em>joe.tinucci@cu.edu</em></a><em>)</em><br />
<em></em>Anonymousnoreply@blogger.com0tag:blogger.com,1999:blog-5704248368030212351.post-43938551135304124432014-08-27T10:06:00.000-04:002015-02-06T14:46:33.285-05:00Announcing: The 2015 PCI DSS Workshop<div style="text-align: center;">
<b><span style="color: black; font-family: "Arial","sans-serif";">PCI DSS Workshop 2015<o:p></o:p></span></b></div>
<div style="text-align: center;">
<b><span style="color: black; font-family: "Arial","sans-serif"; font-size: 10pt;">April 20
- 22, 2015</span></b><span style="color: black; font-family: "Arial","sans-serif"; font-size: 10pt;"> </span><br />
<span style="font-family: "Arial","sans-serif"; font-size: 10pt;"><strong><span style="color: red;">(Dates corrected)<o:p></o:p></span></strong></span></div>
<div style="text-align: center;">
<b><span style="color: black; font-family: "Arial","sans-serif"; font-size: 10pt;">Green
Valley Ranch Resort, Spa and Casino<br />Henderson, NV (Las Vegas metro area)</span></b><span style="color: black; font-family: "Arial","sans-serif"; font-size: 10pt;"><o:p></o:p></span></div>
<div style="margin: 0in 0in 0pt;">
</div>
<div style="margin: 0in 0in 0pt;">
<span style="color: black; font-family: "Arial","sans-serif"; font-size: 10pt;">The Treasury Institute for Higher
Education is facilitating its annual PCI DSS Workshop. This program is
geared toward business, financial, or IT manager responsible for PCI-DSS. The
workshop will once again explore the unique PCI compliance challenges facing
Higher Education institutions. As well as offer a deeper understanding of PCI,
how institutions can achieve and maintain compliance, and the opportunity to
make valuable new contacts with peers at other institutions facing the same
challenges.<o:p></o:p></span></div>
<br />
<div align="center" style="margin: 0in 0in 0pt; text-align: center;">
<span style="color: green; font-family: "Arial","sans-serif";"><span style="color: green;"><a href="http://www.treasuryinstitute.org/2015-pci-dss-conference-registration-university-only/" target="_blank">Register Online Today!</a></span><o:p></o:p></span></div>
<br />
<div class="MsoNormal" style="margin: 0in 0in 0pt; text-align: center;">
<i><b><span style="color: black; font-family: "Arial","sans-serif";">Please note that attendance at this program
is<br />limited to representatives from colleges and universities only.</span></b></i></div>
Anonymousnoreply@blogger.com0tag:blogger.com,1999:blog-5704248368030212351.post-11237627132497087312014-08-12T16:23:00.000-04:002014-08-12T16:23:05.852-04:00Higher Ed PCI ListservIf you are a subscriber to the Payment Card Industry Compliance Discussion listserv, please be aware that there will be a change to the list address coming this week. You should see an announcement from the list in your Inbox soon.<br />
<br />
You may need to change your anti-spam filters to keep the messages coming without interruption.<br />
<br />
--GeneAnonymousnoreply@blogger.com0tag:blogger.com,1999:blog-5704248368030212351.post-44345903179658772232014-08-06T18:07:00.001-04:002014-08-06T18:20:29.875-04:00Who Should Drive PCI DSS Compliance?<em>[This is our second guest post from Joe Tinucci, Assistant Treasurer of the University of Colorado. --gaw]</em><br />
<em></em><br />
Whenever I talk to my colleagues around the country about who in their organization is responsible for managing PCI DSS compliance, I usually get two different answers -- either the technical security side of the organization or the business side. Of course, the merchant is the responsible entity as far as the acquiring bank or the payment card associations are concerned but when there are multiple merchants in the organization there needs to be someone coordinating / managing the compliance effort. So, who is in a better position to drive / manage the compliance effort? (Or, as we say around here, who is responsible for herding the cats?)<br />
<br />
There are good arguments for letting the technical security people drive the process:<br />
<br />
<ul>
<li>They are closer to the actual technology used to process transactions at the merchant level.</li>
<li>They understand the security techniques used to secure the transactions (blinking lights and all).</li>
<li>They control the infrastructure through which transactions are processed (network, firewalls, phone lines, PCs, and so forth) -- or they have direct links to the people who control it.</li>
<li>They understand the techno-speak language in which the PCI DSS / PA-DSS is written, and, in particular, understand the objectives behind each of the standard's requirements.</li>
<li>PCI DSS compliance is a security thing and that is what they are paid to do.</li>
</ul>
<br />
You can probably add other reasons why PCI DSS compliance belongs on the technical side.<br />
<br />
On the other hand, I feel that there are good arguments for making the business side of the house responsible for driving PCI DSS compliance:<br />
<br />
<ul>
<li>They control the money, including funding for those parts of the security process that might need outsourcing (penetration testing, ASV scans, QSA assistance, and so forth). And, in the event that remediation is required, they are generally the ones who have to figure out where to find the money, often on an emergency basis.</li>
<li>They already deal with multiple other compliance regimes in a lot of other areas; that experience can be directly applied to the PCI DSS compliance process.</li>
<li>The business side of the organization is already doing risk assessments in other areas and so can assist with the critical but non-technical aspects of PCI DSS risk assessments (in areas such as phishing, social engineering, broken processes, etc.).</li>
<li>They are already managing business risk trade-offs in other areas of the organization (particularly in treasury) and can apply that expertise to PCI DSS compliance -- particularly with respect to accepting risk or implementing compensating controls.</li>
<li>Treasury, in particular, speaks that really strange language that only bankers speak (ACH? settlement? OFAC? credits and debits?) and they manage the organization's relationship with the Acquiring Bank. It is really that relationship that is driving the organization’s PCI DSS compliance efforts. In addition, if a merchant account needs to be cut off, it is the business side that needs to work with the Acquirer to close out the merchant account.</li>
<li>They understand the larger context of the business and how all the moving parts, including payment acceptance, fit together.</li>
<li>They understand good business practices and procedures that should be in place in every merchant environment.</li>
</ul>
<br />
It is this last point that really convinces me that the business side (most likely Treasury) should be driving the compliance process. God bless the technical security staff but they will secure whatever they are asked to secure -- including horrible business practices that should never have been allowed in the first place.<br />
<br />
In reality, of course, neither side can have a successful compliance process without the other; it is a complex dance between partners with the goal of making each and every merchant secure through both best business practices and best technical security implementations.<br />
<br />
Your thoughts on the issue?<br />
<br />
<hr />
<br />
<em>Joe Tinucci is the Assistant Treasurer at the University of Colorado, where he manages the University's banking relationships. As part of that job, he also drives the PCI DSS compliance process for approximately 160 card-accepting merchants across diverse card-acceptance environments in four campuses. Joe can be reached at (303) 837-2185 or </em><a href="mailto:joe.tinucci@cu.edu"><em>joe.tinucci@cu.edu</em></a><em>)</em>Anonymousnoreply@blogger.com1