Problem to Solve:  My company must comply with PCI.   How can I best leverage my APM/NPM tools ‘to be PCI compliant’ inside my business?

Contributing Author – Robert Wright, Network Engineer with 15+ years experience

In our last segment, we reviewed that APM/NPM tool sets could be utilized in your cardholder data environment (CDE). If you happened to miss that article, you can read it here  http://problemsolverblog.czekaj.org/troubleshooting/npm-apm-pci-dss-world/   Today’s installment will touch on the first two requirements of PCI DSS v3.0.  You may be surprised at the numerous areas where APM/NPM tool sets can assist! Our goal, now that we know we can utilize an APM/NPM tool set, is where we can place them according to requirements one and two. So lets zoom into these trees and get a better look.

Our first requirement, “Install and maintain a firewall configuration to protect cardholder data”, will examine what many of you will find as being “common sense actions” we should all be taking. We will also highlight one of the key new items that PCI 3.0 will be bringing to us in 2015.

The second requirement “Do not use vendor-supplied defaults for system passwords and other security parameters” will likely surprise many at how shockingly similar it is to my PKI certificate article listed here  http://problemsolverblog.czekaj.org/troubleshooting/detection-invalid-certificates-packet-analysis/      Additionally we will address what steps we need to perform, should we determine that our tool sets need to fall under PCI.

 

Tree – Install and maintain a firewall configuration to protect cardholder data

When you read requirement 1, you will see “firewall” mentioned 14 times just on the first page! Much of the literature will discuss various processes and procedures which must be followed to maintain compliance. This may come across to you as not having anything to do with your tools. That is absolutely incorrect!

As we add additional devices into the pathway, especially firewalls, the complexity and skillset required to troubleshoot the network increases exponentially as we all know. Some will see this as an increased burden to the IT professional, but I challenge this view and instead suggest we view it as an opportunity – the opportunity to safe guard our customer, brand integrity, and quite frankly our job.

We can also look at the areas which fall under PCI compliance (CDE), and assign a level of business importance/risk. If we don’t have PCI data flowing efficiently across systems or experience application issues, we are likely impacting the business’ bottom line.

So what are some of the areas we should be adding visibility to? Let’s review the table below:

Requirement	Brief Description	My Viewpoint
1.1	Implementation of firewalls	Your tool sets will require visibility on each side of your firewall for troubleshooting. This will be inside and outside of your CDE.
1.1.1	Testing of firewall changes	What if your change doesn’t work when tested? How will you troubleshoot? Will you trust the fox guarding the hen house? Your tools need visibility; did every packet going in also make it out?
1.1.4	Each internet connection must have a firewall.	Visibility is the utmost importance at this layer. If you’re not utilizing your APM/NPM tools here, you are really missing out. Many flag ship applications “last stop” will be through this area. Get visibility here now!
1.1.4 Continued	A firewall is required between each DMZ and between the internal zone.	This area has always been problematic. Why? Many business-to-business VPNs live here. Any time you add more people and more equipment there is an increase in complexity. Quick tip: Add a tool set which supports anomaly detection to reap the many benefits.
1.1.6	Documentation of insecure protocols and business justification of use.	As in 1.1.4, utilize tool sets which can alarm should an insecure protocol (Telnet, HTTP, POP3,etc) appear. Get to it before the auditors do!
1.2	Firewall rules to restrict connectivity to/from untrusted networks	Many tool sets will provide you the ability to create a whitelist of permitted traffic. Any traffic which deviates from that whitelist can cause an alarm to fire!
1.2.1	Restrict traffic to only that which is necessary to/from the CDE.	Again, another use case for utilizing a tool set which permits whitelisting of traffic and the generation of an alarm.
1.2.3	Firewall wireless networks and only permit authorized traffic.	We have beaten firewall visibility to death. As in 1.2 and 1.2.1 you should often utilize “under-championed” features of your products.
1.3.1	Deployment of DMZ to limit inbound traffic.	This will likely be customer facing traffic. Utilizing your APM/NPM solution here will result in lower MTTR.
1.3.2	Limit IP addresses from the outside to the DMZ	Creation of white or black lists within your APM/NPM tool set can assist with alarming should this condition suddenly change.
1.3.3	Direct connections from the outside and the CDE should be prohibited	Much like your firewall rules, if we add an alarm stating that only a particular address block is permitted, we can add another set of eyes that protect our CDE.
1.3.4	Protect against spoofing/ IE block internal addressing from entering from the internet	As stated previously, add internal IP addressing to a black list for those tools covering that area, and now you can be informed should this invalid traffic start being active or routed.
1.3.8	Do not disclose IP addressing or routing information to the internet.	The visibility we set out to accomplish in 1.1 and others provides us the ability to now validate that technology such as NAT is deployed.  Or should you deploy a proxy, and validate that the proxy is operating appropriately?

 

As you can see there are numerous areas where APM and NPM tool sets can be utilized. You may view this list and think, wow there goes my budget! Not necessarily true, with the advent of aggregation switches! These switches, unlike those utilized in infrastructure, give the ability for your tools to gain visibility to many more areas of your network with a lower price point. Any of your tool vendors will be well versed in this technology.

New addition to PCI  — Uh Oh !!

One requirement which was recently included was section 1.1.3, and we should all be very much aware of this change! We may see folks including areas of the network simply to whip out this little gem in the middle of a meeting.

“1.1.3 Current diagram that shows all cardholder data flows across systems and networks”

Wow! How many times have we been in the middle of a troubleshooting call and we asked the question, “How does application ‘X’ flow on the network?” Then the reply is returned with a blank stare. Well if that application falls under PCI jurisdiction, then now you would be found to be non-compliant.  We can utilize many of our APM/NPM tools to provide us with a view of how the application works. Look for “non-agent” based tool sets which can provide a dynamic view across protocols for the most success. Why agentless? Well if you know the box exists to place an agent on it, then you likely know what role it performs! Agent less technology allows you to find the unknown!

 

Tree – Do not use vendor-supplied defaults for system passwords and other security parameters

Our APM/NPM tools may need to be compliant

We must remember that our APM/NPM tool sets are not immune to being compliant to PCI just like our data communication networks. As you read the list below, remember that I have summarized, so if a particular point fits your fancy, remember to go review the particular requirement and make your own assessment.

• SNMP strings (2.1.1)
  • No public/private
  • No vendor defaults no matter the complexity
• OS level passwords (2.1.1)
  • Administrator/root
• APM/NPM application user passwords(2.1.1)
  • Default account passwords need to be changed or disabled
• Check with your vendor if your application is hardened
  • Enable only necessary services, protocols, daemons (2.2.2)
  • Remove unnecessary functionality, drivers, scripts, etc (2.2.5)
• Utilize secure protocols (2.2.3) and non-console administration should be encrypted (2.3)
  • SSH, SSL, SFTP, etc
• Configure appropriate application security parameters (2.2.4)
  • Does every user need packet level access??
• Communicate with the appropriate teams to ensure the steps you are taking fall in line with policies and procedures. (2.5)

Enforcing non-vendor defaults

This section provides a few sample workflows for supporting this “non-vendor default” challenge.   This references my blog article regarding locating invalid PKI certificates, and Ken Czekaj’s post concerning API.  If you were to combine the two workflow concepts, you would have the ability to locate invalid PKI certificates, by leveraging an API to do the dirty work.   The same mindset and workflow could be used to run queries against packets look for the following common SNMP communities

1. Public
2. Private
3. Cisco
4. Secret
5. default

 

Conclusion

Thank you for taking the time to read my article today. Please take the time to provide any feedback concerning the article you read today. As we review the strategic locations for our tool visibility, we must also be aware of the necessity to maintain their compliance.