Archive for the 'Uncategorized' Category

22
Apr
16

Learning Moments From Security Conversations – Part 1

Attacker With Administrator Rights

This conversation was a discussion of an attacker gaining administrative privileges on a network.  This conversation started out benign enough and yet rapidly escalated into a full on war of words.  I had to spend almost 40 minutes arguing with an administrator over the facts that if an attacker had administrative rights it was then “game over” for their organization.  I could not believe the lengths that this administrator went to prove I was wrong.

What started this fiasco was a discussion of the results of their vulnerability scans and penetration testing reports.  The reason the conversation got tense was that the administrator was arguing about how the penetration tester was able to escalate privilege to administrator.  At the core of the argument was the “Low” rated vulnerabilities that were used by the penetration tester to gain access to the system and ultimately compromise the environment.

I am not sure where this idea/myth actually started, but it continues to persist even today after around 20 years of vulnerability scanning.  That idea is that “Low” rated vulnerabilities are somehow not a threat.  Even when you try and explain that regardless of ratings, vulnerabilities are vulnerabilities, some are just easier to use than others and provide quicker compromises than others.

Another reason this is an issue is that most information security personnel are not penetration testers.  Penetration testing is not so much a skill as it is an art form.  Anyone can take high and medium vulnerabilities and leverage them to compromise an environment.  That is why they are rated so high in the first place.  But it takes a true artist with a tremendous amount of knowledge in networking, operating systems and applications to look at the results of a vulnerability scan, take certain low rated vulnerabilities, pair those with certain other vulnerabilities, compromise a system and then compromise the environment.  Not that this always ends up leading to a compromised environment, but it is not as simple and easy which is why it is a shock when it happens.

What the penetration tester did once they had compromised a few systems is that they discovered a way to escalate their privilege to domain administrator through the use of a keyboard logger on a compromised system.  They then collected the domain administrator credentials and it was “game over”, or at least that was the penetration tester’s and my opinion.

So the first point of contention were those “Low” vulnerabilities that the penetration tester used to gain access to a system on the network.  Somehow the administrator believed that those vulnerabilities were off limits because they were rated “Low”.  I did my spiel on vulnerabilities are vulnerabilities and that even the PCI DSS states that all vulnerabilities must be patched within 90 days (some of the “Low” vulnerabilities were over 90 days old).

Finally the administrator conceded that at least those old vulnerabilities needed to be patched but continued to argue that using any “Low” vulnerabilities were not “fair”.  Fair?  I tossed that back in their face and asked what attacker would play “fair”?  Point taken and we moved on.

The next point from the administrator was that even if the penetration tester had domain administrator privileges, they did not have access to the data bases and encryption keys.  Those rights are kept in a different group away from the domain administrators.

I could not believe what I was hearing.  So I next asked if domain administrators could modify the members to those domain groups.  “Of course,” was the quick answer back.  So our simulated attacker could have created a new domain administrator account and added them to the data base and encryption groups?  “Well, yeah, I suppose so,” was the quiet answer back as the administrator was starting to see where things were heading.

Then the argument moved on to control of network devices and the exfiltration of data outside.  This revolved around the fact that domain administrators did not have access to network devices.  However, the RADIUS server that did control access to the network devices was integrated with their Active Directory environment.  So I asked what would stop someone with domain administrator rights from creating a new account and adding that account to the network administration group which would then be replicated to the RADIUS server.

The silence created by that question was deafening.  The administrator was speechless.  They now understood the gravity of the situation.  They were owned and they really did not like that fact.  Granted we had not taken things that far because it is a pain to clean up.  But the client now understood after 40 minutes of arguing about it, that the game was over and their environment was no longer under their control.

This is the problem that most organizations face.  They see everything framed in the control paradigms they have implemented.  The problem is that attackers do not care about controls or their paradigms.  They just care about getting access to information and they structure their efforts accordingly without regard to a control environment.

This is why monitoring is so very important and why near real-time monitoring can save your life if it is configured properly.  But monitoring only works if rules have been structured around those same control paradigms so that when the paradigms are violated, alerts are generated.

In the above example, alerts that would have raised red flags are:

  • Creation of administrative accounts. Such accounts are only rarely created in most environments so when they are created there should be an alert generated and then matched against the account creation request.
  • Addition of accounts to administrative groups. As with administrative accounts, there are very infrequent changes made to these groups.  Again when such an alert is generated, there should be a corresponding change request of some sort.
  • Changes to configurations of network devices and/or servers. These can be problematic because of volume particularly on “Patch Tuesdays” or whenever you do volume patching.  But matching changes to change tickets pays off in discovering attackers.  Since attackers do not register their changes in the change management system, any changes popping up that do not have a corresponding change ticket are likely to be part of an attack.
  • Redirection of network traffic to public IP addresses outside of your business partners or other legitimate IP addresses. Where organizations are most at risk is communications with business partners.  Because of the speed of business these days, a lot of information security people do not sufficiently restrict network traffic between their organization and business partners so that they do not have to constantly make changes.  While that allows near immediate communication flexibility it also allows business partners to be a ready source of attacks and data exfiltration points.
  • Significant increases in outbound traffic volume over ports such as DNS that should not have such increases. Attackers do not obey the port protocol rules, particularly if they are trying to avoid changes to network devices.  In the Target breach, the attackers exfiltrated Target’s cardholder data out through port 53 (DNS).  The reason is that because in most instances port 53 will be open and will not have a restriction on IP addresses allowed to communicate with port 53.

But the obvious area that should receive attention are the patching of those medium and low ranked vulnerabilities.  It just amazes me the twisted logic that sometimes gets used to justify putting off applying patches until the very, very last possible moment all because the vulnerabilities being addressed are not high or critical.  As I said earlier and I cannot stress this enough, vulnerabilities are vulnerabilities regardless of their rank.  They make devices/systems vulnerable, hence their name.

I will share another such discussion in a future post.

09
Apr
16

Living In PCI Denial

This was one of those weeks where you see something and all you can do is shake your head and wonder what some organizations think when it comes to PCI.  What added insult to injury in this case was that the organization arguing over PCI compliance is the manufacturer of card terminals, also known as point of interaction (POI).  It shocked me that such an organization was so clueless about PCI as a whole when you would think it is their business to know. But to add insult to injury, my client’s transaction processor and acquiring bank are also apparently clueless.

As background, I am working on a client’s Report On Compliance (ROC).  This client has almost completed with their roll out of an end-to-end encryption (E2EE) solution at all of their 4,000+ retail locations.  This E2EE solution will take all but the POI at those retail locations out of scope for PCI compliance.  That is the good news.

But if there is good news, you know there must be bad news.  In reviewing their documentation of this E2EE solution, I discovered that the POI vendor is providing management and updates to the POI through a terminal management system (TMS).  Since this TMS solution/service connects directly to my client’s cardholder data environment (CDE), I naturally asked the client for a copy of the vendor’s Attestation Of Compliance (AOC) for the TMS solution/service.

I thought those worthless PCI Certificates of Compliance took the cake.  Then, BAM!  I got the following message forwarded to me by my client from the POI vendor.  I have redacted all of the potential information that could identify the relevant parties and the TMS solution/service.

“Please see the follow up note below that you can send to your QSA for review and feedback:

  1. TMS systems in our industry do not require any type of PCI certification since PCI is concerned about card holder information that would be at risk. Since [vendor solution] does not have any card holder data at all, it falls outside of PCI requirements.  [Vendor solution] is merchant configuration and estate management tool only and as such, no payment card information passes through it, or directed to it.  In addition, no secure keys are stored on [vendor solution] so transaction data cannot be decrypted with anything on [vendor solution] or POS.
  2. [Vendor] Hardware and [vendor solution] Software are all PCI PTS compliant and certified and listed on the PCI website. Transactions are encrypted in hardware using the [encryption solution] keys which again [vendor solution] has no knowledge.  Transaction information can only be decrypted by [processor] the processor.  [Vendor solution] has no knowledge of this encrypted information being sent directly from the [vendor] to the processor.
  3. The beauty and simplicity of [vendor solution] semi-integrated terminal application is that is has all transaction data go directly to the Processor ([processor]) and no customer data is directed to the POS or [vendor solution] which makes the POS out of PCI Scope by the very nature of no card holder data in their environment.
  4. [Client] has a merchant certification with [processor] for the [encryption solution] with our [vendor solution] terminal application. Any questions regarding the certification should be directed to [acquiring bank] or a [processor] representative.

Let us know if your QSA has any further questions and we can also schedule a concall with all parties to address any concerns on [vendor solution] TMS and PCI.”

The first thing that wound me up is that this vendor is a business partner of my client’s transaction processor.  The processor is also a business partner of my client’s acquiring bank.  Those two organizations put forth this vendor to my client as being able to provide POI compatible to the processor’s E2EE and tokenization solution.  Obviously from this vendor’s response, these two well-known institutions did nothing in the way of due diligence to ensure that this vendor and its services were PCI compliant.

The second thing that totally irritated me is that there is no excuse for this vendor’s uneducated response.  Granted, this vendor is new to the US market, but they have been supplying POI to other merchants all over other parts of the world.  Which then starts to make you wonder just how lame are the banks, processors, card brands and other QSAs that they have not been called on the carpet about this before.  But that is a topic for another post and a good reason why the FTC is investigating the PCI compliance industry.

So let me take apart this vendor’s response.

“TMS systems in our industry do not require any type of PCI certification since PCI is concerned about card holder information that would be at risk.”

Wrong!  On page 10 of the PCI DSS the first paragraph under ‘Scope of PCI DSS Requirements’ clearly defines what is in scope for PCI compliance.

“The PCI DSS security requirements apply to all system components included in or connected to the cardholder data environment. The cardholder data environment (CDE) is comprised of people, processes and technologies that store, process, or transmit cardholder data or sensitive authentication data. “System components” include network devices, servers, computing devices, and applications.”

The operative phrase the TMS solution/service falls under is “connected to”.  The TMS solution/service directly connects to my client’s CDE.  That solution/service may not process, store or transmit cardholder data (CHD) or sensitive authentication data (SAD), but it is directly connected to my client’s CDE.  As a result, according to the above definition, the TMS solution/service is definitely in scope for PCI compliance.

“[Vendor] Hardware and [vendor solution] Software are all PCI PTS compliant and certified and listed on the PCI website.”

PTS certification is a card brand requirement, not a PCI DSS requirement.  Nowhere in the PCI DSS does it require that a PTS certified POI be used so I really do not care about this statement as it has nothing to do with my PCI DSS assessment activities.  If PTS were a PCI DSS requirement, then all of those people using Square and the like would be non-compliant.

“In addition, no secure keys are stored on [vendor solution] so transaction data cannot be decrypted with anything on [vendor solution] or POS.”

“Transaction information can only be decrypted by [processor] the processor.”

True, your TMS solution/service does not have the encryption keys.  But the firmware delivered by the TMS solution/service does have access.  (Unless you are the first POI vendor I have ever encountered that spent the huge amount of money required to truly create a hardware-only encryption solution.)  Given the low retail price and discounting of your POI you gave my client, I very seriously doubt that is the case.  So the firmware that your TMS solution/service delivers is what is doing the encryption and therefore has access to the encryption keys.  So while the TMS solution/service does not have the keys, it could be used to deliver rogue firmware that could obtain them.

Then there is the firmware delivery itself by your TMS solution.  If someone hacks your TMS environment, how easy would it be for them to have it deliver a rogue version of your firmware?  Since my client has no AOC, I have no idea if your security measures surrounding your TMS solution are adequate to prevent such an attack.

“[Client] has a merchant certification with [processor] for the [encryption solution] with our [vendor solution] terminal application.”

Such a statement ranks up there with those previously mentioned worthless PCI Certificates of Compliance.  Any QSA is required to obtain an AOC for the TMS solution/service to ensure that it is PCI compliant or the solution/service must be assessed as part of the merchant’s PCI assessment.

PCI DSS requirements under 12.8 are very clear as to everything a merchant needs to be able to provide to their QSA regarding third party PCI compliance.  Primarily of which is that AOC for your TMS solution/service among other items of evidence.

So I have a conference call with my client’s bank to discuss this situation.  I pushed back very hard when they told me that my client needs to do a compensating control for their business partner’s incompetence.  I even got an “atta boy” from the bank for identifying to them that they have a PCI compliance and potential security issue.  But I could not make the bank budge on the compensating control so I am off to get that written.

The lesson to be learned from this post is that nothing can be taken for granted when doing a PCI assessment even when you transaction processor and bank are involved.  A lot of people and QSAs would assume that a POI vendor would know better and that their bank and transaction processor had vetted the POI vendor.  Therefore, why do I have to worry about this vendor?  However as I have pointed out, you can never take anything for granted even when it involves organizations that you would think would know better.

This is just one way of many that could result in an organization being breached.  The TMS solution/service is a gateway directly to the merchant’s CDE.  Yet there has been no PCI assessment of that solution/service to ensure that it is PCI compliant and the risk it could be subverted has been minimized.

Thank goodness it is the weekend.  Oh, wait.  This weekend’s project is my income taxes.  Looks like I will be cranky all weekend as well.

31
Mar
16

Council Releases PCI v3.2 Dates

The dates given are not hard and fast such as Tuesday, April 26, more like general points in time such as “late April”.  But at least they are providing a form of schedule for the release of the new PCI DSS and PA-DSS standards an the retirement of v3.1 standards.

See their blog post for all the details.

09
Mar
16

The FTC Enters The Fray

On Monday, March 7, the United States Federal Trade Commission (FTC) issued a news release that I am sure got a lot of notice by practice leaders of the PCI qualified security assessor companies (QSAC). On Friday, March 4, the FTC commissioners decided in a 4-0 vote to compel the following QSACs to respond to a 6(b) Special Report order.

  • Foresite MSP, LLC;
  • Freed Maxick CPAs, P.C.;
  • GuidePoint Security, LLC;
  • Mandiant;
  • NDB LLP;
  • PricewaterhouseCoopers LLP;
  • SecurityMetrics;
  • Sword and Shield Enterprise Security, Inc.; and
  • Verizon Enterprise Solutions (also known as CyberTrust)

The first thing that is notable in my mind is that some of the big players in the PCI assessment business are absent from this QSAC list. I am not sure how the FTC arrived at this QSAC list, but it would be interesting to know their methodology.

But even more interesting and concerning is the information the FTC is requesting. From their request, here is a sample of some of the questions they are asking and the information they are seeking.

  • For each year of the Applicable Time Period, state the number and percentage of clients for which You completed a Compliance Assessment and for which You declined to provide: a “Compliant” designation on the Attestation of Compliance (“AOC”); or an “In place” designation on the final Report on Compliance (“ROC”).
  • For each year of the Applicable Time Period, state the number and percentage of clients for which You completed a Compliance Assessment and for which You provided: a “Non-compliant” designation on the AOC; or a “Not in place” designation on the ROC.
  • The extent to which the Company communicates with clients in determining the adequacy of any compensating control. As part of Your response, provide all documents related to a representative Compliance Assessment that considered a compensating control, including all communications between the Company and the client or any third party such as PCI SSC, a Payment Card Network, an Issuing Bank or an Acquiring Bank.
  • The policies and procedures for completing a Report on Compliance (“ROC”), including, but not limited to a discussion of whether a draft report is created, whether that draft is shared with the client or any third party such as PCI SSC, a Payment Card Network, an Issuing Bank or an Acquiring Bank, whether the Company accepts input on the draft from the client or any third party, and whether the Company ever makes changes to the draft report based upon the client or other third parties’ input. As part of Your response, provide all documents relating to a representative Compliance Assessment in which You provided a draft of the report to the client and/or any third parties, including a copy of the draft report, any communications with the client or third parties about the draft report, and the final ROC.
  • Provide: a copy of the Compliance Assessment with the completion date closest to January 31, 2015; and a copy of a Compliance Assessment completed in 2015 that is representative of the Compliance Assessment that the Company performs. For each Compliance Assessment provided in response to this specification, the Company shall also include a copy of any contract with the client for which the Compliance Assessment was performed, all notes, test results, bidding materials, communications with the client and any other third parties, such as the PCI SSC, a Payment Card Network, an Issuing Bank or an Acquiring Bank, draft reports, the final ROC, and the AOC.
  • State whether the Company ever identifies deficiencies in a client’s network during a Compliance Assessment and gives the client the opportunity to remediate the deficiency before the Company completes its final ROC. If so, provide all documents relating to a representative Assessment where the Company gave the client an opportunity to remediate before completing the ROC, including any communications between the Company and the client or any third parties such as PCI SSC, a Payment Card Network, an Issuing Bank or an Acquiring Bank, and the final ROC and AOC.
  • State whether the Company ever identifies deficiencies in a client’s network during a Compliance Assessment and issues a final ROC before the deficiencies are remedied based on assurances that the client will remedy the deficiencies in the future. As part of Your response, provide copies of all policies and procedure related to remedying deficiencies.
  • State whether the Company has any policies or procedures relating to potential conflicts of interest, including, but not limited to, any policies that prevent the Company from providing Compliance Assessments to clients to which it has also provided another type of service, or that concern the marketing or provision of other services to clients for which You have provided a Compliance Assessment. As part of Your response, provide copies of all relevant policies and procedures.
  • State the annual number of the Company’s Compliance Assessment clients that have suffered a Breach in the year following the Company’s completion of the Assessment for each year of the Applicable Time Period. For each such client, state whether it was subsequently determined not to be PCI compliant and provide the date of the initial Compliance Assessment and any communications between the Company and client or any third parties such as PCI SSC, a Payment Card Network, an Issuing Bank or an Acquiring Bank related to the Breach.

All of these questions lead one to believe that the FTC is looking to confirm that the PCI assessment process is a sham.

It will be very interesting to see how the FTC interprets the results of this effort. However, based on these questions and how I know they will end up being answered, I would venture to say that the result will be the government getting into the data security game with regulations.

18
Feb
16

The Council Surprises

So I posted my thoughts on where I thought the PCI SSC was headed with v4 of the PCI DSS and today the Council announced there apparently will be no v4. Instead we will get v3.2 of the PCI DSS and PA-DSS. And those new standards will be out sometime in the next month or two.

Read all about it on their blog post.

Not sure what to say or think as they have apparently decide the three year model for standards updates no longer needs to be followed after beating into our heads for the last seven years.

27
Jan
16

Do Consumers Really Bail On Breached Merchants?

Conventional wisdom is that when a retailer suffers a breach their customers leave and do not come back. As a result, this threat is what a lot of retail CISOs point to as one of the primary reasons for beefing up information security.

But is that threat real? Do consumers really leave retailers that have been breached?

That is what the Merchant Acquirer’s Committee (MAC) and Dr. Brandon Williams decided they needed to find out. On Tuesday, January 26, 2016, they released the results of their survey they conducted of consumers and their attitude toward retailers that had been breached. I got to speak with Dr. Williams just before the release of the report to discuss what the survey found regarding the issues of retailer breaches.

The good news for retailers that get breached is that while customers tend to avoid a retailer immediately after the announcement of a data breach, those customers eventually return. I was particularly surprised that even with the multiple Michael’s breaches within two years of one another, most customers came back to them.

In discussing this behavior with Dr. Williams, we both came to the conclusion that this behavior was most likely driven by the fact that, unless a consumer suffers identity theft or a loss of money, a breach did not create an incentive for customers to leave a retailer permanently. Yes, a customer most likely received a new credit/debit card because of a breach. Yes, that new card likely created some hassles due to any recurring payments tied to that card. But in the end for most customers, if there was no harm to them therefore there was no foul to the retailer.

My only concern with the results of this study are that it will give some merchants the idea that since a breach does not impact their business they can therefore avoid truly complying with the PCI standards. However, I would remind everyone that their Merchant Agreement contractually obligates them to comply with all relevant PCI standards. So while a breach might temporarily affect business revenue, a breach definitely puts the business on the hook for any fines and penalties levied by the card brands or transaction processors and the costs of any resulting lawsuits. As a result, there should be significant justification for complying with all of the relevant PCI standards.

The full report can be obtained from the MAC web site here.

11
Dec
15

Have You Noticed?

I was on a call with our person who coordinates and does most of our quality assurance (QA) reviews for the firm. They were asked if they had any updates to provide the team regarding PCI. They took over the meeting and had us go to Part 2g of the Service Provider Attestation Of Compliance (AOC). The topic of the discussion was that we needed to make sure that we followed the Note in that section that states:

Note: One table to be completed for each service covered by this AOC. Additional copies of this section are available on the PCI SSC website.”

PCI SP AOC Part 2gThey said that in conversations with other QA people in the PCI arena, this had come up in the discussions as to how he was dealing with the requirement. They said that, until it had been pointed out, they really had not thought about it until just recently when one of our Service Provider clients needed their AOC created and their multiple services necessitated multiple 2g tables.

But that brought up the concern as to how many QSAs and their QA people have noticed this requirement, let alone are doing it correctly? Likely only a few.

However, it is important that the Service Provider AOC gets properly filled out as the service providers’ customers are relying on the AOC to fill out their own matrices based on the service provided by the service provider.

As a result, for every check box checked below in Part 2a, there needs to be a corresponding table filled out in Part 2g.

PCI SP AOC Part 2aIf you are doing service provider assessments and are not following that process expect a big black checkmark in your next PCI SSC AQM review. The question is, will it cause any QSACs to go into remediation?

Happy holidays.




Announcements

If you are posting a comment, be patient, as the comments will not be published until they are approved.

If your organization has a PCI opportunity, is in need of assistance with a PCI issue or if you would like the PCI Guru to speak at your meeting, you can contact the PCI Guru at pciguru AT gmail DOT com.

I do allow vendors to post potential solutions in response to issues that I bring up in posts. However, the PCI Guru does not endorse any specific products, so "Caveat Emptor" - let the buyer beware. Also, if I feel that the response is too "sales-ee", I reserve the right to edit or not even authorize the response.

Calendar

May 2016
M T W T F S S
« Apr    
 1
2345678
9101112131415
16171819202122
23242526272829
3031  

Enter your email address to subscribe to the PCI Guru blog and receive notifications of new posts by email.

Join 1,545 other followers


Follow

Get every new post delivered to your Inbox.

Join 1,545 other followers