Entries categorized as ‘Payment Card Industry Data Security Standard’
So, there are tremendous implications for their business model, but to place the spotlight on one area lets focus on data security and regulations (my favorite). AMEX is one of the organizations that built the PCI DSS, PCI SSC, and all recent publications. The intent of PCI was to have industry forced mandates that protect cardholder data. As private companies, Visa and MasterCard, had a lot of leeway on how they handled operations and were able to contain the management of requirements. Given the IPOs of these two associations, and now AMEX becoming a bank does present a future that is far different then it was 3 months ago and 12 months ago.
Banks are regulated under extensive regulations and there is substantial information surrounding the safeguarding of data through information technology controls. The FFIEC books are world renowned for their coverage in this area. In addition to these known requirements there are additional third party requirements that will be introduced. If anyone has done with a financial institution that is required to abide by GLBA, they know that they too must satisfy the requirements.
My highlighting of GLBA and regulatory leakage (when requirements of one trickle down into other sectors of the economy – SOX anyone) is that while PCI DSS is here to stay, there must be greater forms of validation surround Information Technology and Controls. Those who operate within the payment industry would be strongly advised to continue to practice PCI DSS, but also maintain a more holistic view of contributing and supportive regulation mandates to ensure smooth operations in the near future.
Other thoughts on how AMEX becoming bank will impact business?
Kind regards,
James DeLuccia IV
Event Update: BOOK Signing, Free Tastings, and such at Starbucks 1400 Dunwoody Rd, 2-4pm Nov. 23rd. (there will be prizes, so feel free to stop by even for just a moment!)
Categories: Compliance · IT Controls · PCI DSS · Payment Card Industry Data Security Standard · Sarbanes-Oxley · regulations
September 11, 2008 · 2 Comments
On September 10th I spoke at the CSO Conference on the PCI DSS with an impressive group of speakers and representatives from across the industry, including Chris Mark and numerous CIOs. The discussions focused on the current state of the union within the Payment Transaction vertical. There was plenty of focus on the usage of ERM, quantification of risk through trending of individual business experience, in addition the transitioning of risk ownership to executives within an organization.
In attendence there was a wide ranging of executives, but the primary population included the financial industry and mainly CIOs. The topics of the conference included “The State of PCI DSS”, Business Process First, Time Inc. ‘Time Goes Global with Compliance”, Best Practices from the PCI Knowledge Base, and of course a panel discussion. Attendees, and friends of CSO Magazine can see the archived presentations (some were VERY rich, more so than is commonly provided) starting today. While it is impossible to breakdown the great sessions and extensive discussions that I experienced, I do want to highlight a few points that stuck with me.
- Future of PCI DSS: PCI DSS is evolving into a risk based approach. It was both predicted by the attending experts that the council will transform to a pure risk based approach to adhere to the global practice.
- RISK Ownership: Success of PCI and compliance engagements partly depends on the ownership and visibility of the benefits of achieving PCI compliance. This was achieved uniquely by several organizations, but the most common was distribution of risk ownership.
- Conflicts of Interest: Separation of Duties – enforcing a mechanism to eliminate the conflicts of interest that exist – the assessment, implementation, and attestation. Specifically companies must put in a frame work (leverage your Internal Audit groups) to restrict individual parties from conducting all three phases.
- Crosswalk / Regulation Alignment / Shared Documentation: It is ideal to leverage the documentation across different compliance efforts – for example BITS. Usage of these must address the amount of overlap that actually exists (i.e., is the overlap sufficient to warrant the work to have a positive return), also is the scope of controls equivalent between the two approaches. Specifically each standard is focused on risks (PCI on Card Holder Data; BITS Financial data), and therefore only addresses those risks. Organizations have numerous risks, and therefore must manage these risks appropriately with each individual set of standards. Organizations should consider bringing together the documentation efforts, and the degree of efficiency that can be achieved through simplifying the controls by limiting the variety of similar control types.
Action: Take a look at how your managing your PCI and other compliance initiatives. Do you have the responsibility? Should you own it, all? Don’t reinvent the wheel – leverage your Risk Management / Internal Audit teams, all the documentation, tools, and charters are there for you to use.
A great seminar where extensive discussions were enabled through the format and quality of the attendees. I paid for this trip to NYC out of my own personal pocket, and found the value to be well worth it.
If readers have specific requests about the presentations (here is the conference agenda), please post them and I will answer them as fully as possible.
Best,
James DeLuccia IV
Categories: Compliance · IT Controls · PCI DSS · Payment Card Industry Data Security Standard · audit
A recent engagement and publication reminded me of the criticality of limiting the ability of systems within an organization. To be specific – servers should have a limited amount of services operating on them; these systems should have restricted access (inbound and outbound); chaining of servers and services must be avoided.
While this is fairly well published by NIST, NSA, CIA, PCI DSS (the standard), ISACA, and non-technical professional groups such as the IIA, there is a propensity for network operators and firewall operators to not enforce these restrictions. Why – a common few reasons include:
- The objective of network and server operators is to provide services – eliminating services is against the grain
- A lack of clarity in what services are required by each system (and some services that require excessive services and access, i.e. Microsoft Exchange) make it hard to confidently clean-up servers
- Firewall and security people would love the idea of restricting by source-destination and service; however, if the server/application owners cannot articulate what services in which direction are necessary then the ACLs cannot be put in place without breaking the network
The importance of eliminating these services was recently highlighted by the extremely talented folks over at Sense Post. Their 2008 Black Hat Presentation is here regarding “reDuh“. A tool that simply allows one to create a “TCP circuit through validly formed HTTP requests”. The tool is free with registration. Simply put this tool shows the threat in allowing one server to access another server without restriction “because it is inaccessible from the firewall”.
Security professionals and operators should consider the following:
- Services should be limited, and the availability of virtual systems the ability to test company specific setups is possible – security can restrict until true security is achieved
- When acquiring technology you (the buyer) should not send the check until you get the absolute list of services (applications) and ports (inbound and outbound) required to make the application work
- Evaluations should consider the chaining effect – What can be done from X, Y, and Z server. Most times security is a single line in the sand, and such follies lead to disaster.
The intent of restricting by server and service is not to inconvenience, but instead to leverage the existing security technology to the optimal state. Once the public facing systems are secured an effort should be done to segment out the end user networks.
Generally this control applies to PCI DSS Sections 1.3.1, 1.3.2, .1.3.3, 1.2, 1.4, and 2.2
Other ideas?
James DeLuccia IV
**Please join me at the CSO Executive Seminar Series on PCI Compliance & Application Security on September 10th, New York City
Categories: Compliance · IT Controls · PCI DSS · Payment Card Industry Data Security Standard
I am a strong believer in group “live” training experiences where I am in a room with individuals who have different perspectives, challenges, and questions. Unfortunately, the real world keeps spinning and constant training is not always possible, so the web (yes… that which gives and takes) has online training. For those unaware there are several very good online free training seminars for PCI DSS. In fact, the one I am highlighting is “sponsored” by MasterCard.
After free registration – the simplest I have yet to see, you are provided with a list of sessions to listen to or you can download the PDFs! You can find nearly currently a dozen sessions here. They cover the following topics:
- Maximize Internal Preparation for PCI DSS New!, by Mathieu Gorge – CEO Vigitrust
- Network Segmentation New!, Mark Lippman – Senior Partner, Arsenal Security Group
- Data Encryption: Understanding Encryption and PCI DSS New!, by Gerard Onorato and Jeffrey Foresman
- An Introduction to the PCI Security Standards Council, by Bob Russo – General Manager, PCI Security Standards Council
- A Detailed Look at PCI DSS Requirements, by Andrew Henwood – Director of Operations, One-SEC/Trustwave
- A look into the new Self Assessment Questionnaire, by Jennifer Mack – Vice President, MasterCard Worldwide
- A Merchant’s Journey towards PCI Compliance, by Alexander Grant, General Manager British Airways
- Understanding Account Data Compromise, by A. Bryan Sartin – Vice President Investigative Response, Verizon Business
- Preparing for a Successful PCI Assessment, Lessons from the Field, by Michael Walter – Senior Partner, Arsenal Security Group
- Reducing Your Risk: A Look Into PCI Vulnerability Scanning, by John Bartholomew – Vice President, Security Metrics
- Security and the Payments Systems, By John Verdeschi – Vice President, MasterCard Worldwide and Jeremy King – Vice President, MasterCard Worldwide
- Compliance Validation & Beyond, by Sally Ramadan – MasterCardWorldwide
I have gone through several thus far, and my comments on a few are as follows:
- Maximize Internal Preparation – Helpful. Core Message: Setup a diverse team with senior management, and leverage your QSA’s experience
- Understanding Account Data Compromise – Educational. Great walk through! Check out Michael Dahn’s excellent ongoing articles on the carder market
Check out the online webinars here. I am sure there are many others, so please add them below in the comments to help everyone!
Best,
James DeLuccia
Categories: Compliance · IT Controls · PCI DSS · Payment Card Industry Data Security Standard · Security
Tyson Kpczynski of NetworkWorld has an article highlighting 6 free tools you shouldn’t live without for the security minded. He highlights a few of the numerous available tools, but neglects a few foundation security applications. He suggests the following tools (comments added):
- Metasploit – a superb tool! Necessary for everyone. It provides the user with a clear understanding of the true risks of chaining vulnerabilities, provides concrete results, and is lead by one of the most brilliant crews around. Be aware this tools should be used with caution on pre-production systems, and only on systems that are redundant.
- Splunk – excellent interface and allows for excellent review of large amounts of data. A great tool if the budget exists – other resources are Zenoss and Nagios systems
- Google – always great for data mining, but check out the data exploration tool below as an addition to your arsenal
- KeePass – centrally locating your passwords is great, so long as you use a secure key – fyi this is not a proper alternative to your enterprises key management process.
- Helix – Knoppix is a great platform to work from and a top tool in my kit.
- Netwox – Never used this particular tool, but the capabilities speak for themselves.
Check out his full article which describes their usage and his thoughts of each tool here.
Personally I would add the following to any individual charged with security responsibilities (who isn’t these days) and to those key individuals tasked with attesting to the state of an environment (so, yes I would expect auditors for PCI DSS and AICPA / PCAOB efforts to leverage such tools):
- WireShark (formerly Ethereal) – network sniffer that is useful for superb network diagnosis and analysis of network traffic (i.e. finding decrypted communications with cardholder data and such things)
- Nessus – of course, great vulnerability scanner to quickly assess the state of an environment (use in conjunction with deeper assessment tools – such as Metasploit)
- BackTrack in lieu of a generic LiveCD this is a great – cheap / free / 0 effort – security environment to get your feet wet and super simple to customize to create your own company / personal security tool environment.
- John the Ripper – test password strength – i.e. truly validate whether passwords are meeting secure settings. Also check out ophrack which comes as a LiveCD and utilizes Rainbow tables.
- Wireless testing of access point security tools in your kit should include – The Shmoo Group (not a tool, but they lead the way in bluetooth, 802.11, and other channels), Aircrack-ng, Kismet, and you may experiment with wicrawl (here is a video of their preso at Defcon 15)
- Tyson recommends Google as a discovery tool, and it is an excellent tool (check out here where a custom search identifies SSN and credit card data in cached pages), but there are others – in no particular order of preference check out SEAT (Search Engine Assessment Tool) Information collection tool, and Bidiblah by Sensepost ($)
- Extreme packet manipulation (for those with savy technical backgrounds) is ideal for truly testing the resilience and secure coding practices of the systems on your network. Check out Scapy for such a test.
PCI DSS Requirement 11, FFIEC Information Security booklet and numerous others define the expected level of vigilance that must be taken, as an example.
A long standing universal reference for security professionals has been this list hosted by Insecure.org (developers of NMAP) – Click here for top 100 tools. This list is based on votes from users of the tools and includes supported platforms, UI, and whether it costs any dough.
Please add comments for the best security tools that address your challenges. Free is preferred, but products with nominal fees can be worth the expense. If any of the above are unknown to you – download them and experiment, it truly is the only way to understand your control environment.
Best,
James DeLuccia
Categories: IT Controls · Payment Card Industry Data Security Standard · Security