cancel
Showing results for 
Search instead for 
Did you mean: 
Create Post

PCI DSS Requirements and Your SolarWinds Installations

Product Manager

Several SolarWinds products can help with various areas of the Payment Card Industry (PCI) Data Security Standards (DSS) requirements. The purpose of the PCI DSS is to set a baseline of minimum security for any vendor that takes credit cards. This is good for the consumer as it (theoretically) institutes best practices that reduce the risk of a security breach that could expose their data, making vendors that are PCI compliant less likely to put you and I at risk for identity theft that way. This is good for IT shops because it's been historically difficult to get IT budget money for security and privacy initiatives, even if you know they are really the right way to do it. PCI is also an ongoing cost for IT, though, because many of the controls are not one-time checkboxes, they are continuous mandates to help you stay out of the headlines.

What Does SolarWinds Do for PCI DSS Compliance?

The PCI DSS is broken down into several sections. These sections cover everything from physical security requirements to secure IT implementation to scanning and monitoring.

SolarWinds Network Configuration Manager (NCM)

NCM is a network configuration management system that provides auditing of network device policies and changes, and allows you to institute change management procedures (including approvals) around device changes. More info about NCM's features as they apply to PCI compliance can be found here, but here's the specific items it can help with:

  • Addressing PCI Requirement 1.1: Establish Firewall and Router Configuration Standards (especially 1.1.1, approval of changes, and 1.1.6, reviewing policies)
  • Auditing your compliance with PCI Requirement 1.2: Building Restrictive Firewall Configurations, 1.3: Prohibit Direct Public Access, 2.1: Change Default Device Passwords & SNMP Communities/Remove Extra Accounts, 2.3: Allowing Only Encrypted Admin Access to Devices

NCM provides specific reports for PCI compliance to make it easy to audit configuration settings and changes.

SolarWinds Patch Manager

Patch Manager provides integration with native Windows patching technology (WSUS/SCCM) AND provides built-in third-party application patching. More info on Patch Manager's features can be found here, but here's the specific items it can help with:

  • Addressing PCI Requirement 6.1: Ensure Software has Latest Patches within 1 Month of Release
  • Assisting with PCI Requirement 6.4: Ensure Patches are Tested/Reviewed (by way of distributing patches to a test environment, providing back-out/uninstallation of patches)

SolarWinds Serv-U Managed File Transfer

Serv-U MFT provides the ability to ensure security of transferred files, supporting configurations that keep your sensitive data from hanging out in the wild. If you use file transfer when it comes to cardholder data, Serv-U is for you. More detail is available here on the Serv-U site: Serv-U FTP Server PCI Compliance, but here's the specific items it can help with:

  • Assisting with PCI Requirement 1.2 and 1.3: Restricting access from the Internet/Untrusted Networks
  • Assisting with PCI Requirement 3: Protect Stored Cardholder Data
  • Assisting with PCI Requirement 4: Encrypt Transmission of Cardholder Data
  • Assisting with PCI Requirement 7: Limit Access to Cardholder Data
  • Assisting with PCI Requirement 8: Use unique access credentials

SolarWinds Log & Event Manager (LEM)

SolarWinds LEM is a Security Information & Event Management (SIEM) and Log Management system that provides capabilities around log collection, real-time correlation/notification/response, flexible and extensive historical search, compliance reporting, and some endpoint security. More info about LEM's features as they apply to PCI compliance can be found here, but here's the specific items it can help with:

  • Addressing PCI Requirement 10.5: Secure Audit Trails, 10.6: Review Logs for All System Components, 10.7: Retain Logs
  • Addressing PCI Requirement 11.5: Use File Integrity Utilities
  • Detecting potential violations to compliance with PCI Requirement 2.1: Usage of Default Accounts, 4.1: Usage of IM/E-Mail with Sensitive Data (by way of IM monitoring and DLP solutions that can log this activity OR usage of IM in general), 5.2: Ensure AV is Generating Log Data, 7.1: Least Privilege Access to Sensitive Data, 8.5: Usage of Inactive/Default/Generic/Shared Accounts and Other Account Policies, 10.2: Logging various audit trails, 10.3: Include Timestamps with Logs, 10.4: Changes to Clock, 11.1: Detect Wireless APs (depending on your detection method), 11.5: Review of File Integrity Monitoring data

LEM provides extensive audit log reporting capabilities for all of the collected log data, whether it's for auditing compliance with any of the standards mentioned above, or the specific items mentioned in 10.6.

Do my SolarWinds Products Need to be "PCI Compliant" Themselves?

No. SolarWinds products do not capture credit card data directly, provide access to card data directly, or authenticate card data directly. Products that are "in scope" for PCI compliance themselves would include things like databases, file servers, firewalls and routers used for networks that store or access cardholder data, user accounts used to directly access cardholder data. Our management products are used to meet specific PCI requirements at what you could think of as a meta level - they aren't providing the cardholder data, they are providing information about access to the cardholder data, networks, and systems.

For LEM, when we collect audit trail data, this data does not include cardholder data, again, only information about access to cardholder data. With NCM, you can approve/modify firewall configurations, but we are not collecting or reviewing network traffic. With other products that monitor or live on the network (like NPM and NTA), we are, again, not collecting or storing actual network traffic that may contain cardholder data, only information ABOUT network traffic. With SAM, we are similarly monitoring system activity, but not directly related to cardholder data itself. With SEUM, your recorded transactions contain the data you choose to submit, which would not be customer cardholder data that they may be submitting to the same site (if you're testing performance on a form related to card number submission). Patch Manager can inform you of missing patches or the state of patching of a system that stores or accesses cardholder data, but never accesses the system for any purpose other than patching.

Even Though my SolarWinds Installs Don't Fall Under PCI, I Want to Implement Some Best Practices. Can I?

Requirements such as default user accounts, SNMP communities, and audit trails are often general security best practices. Some of them can be applied to SolarWinds products, others can't. The answer is a solid "it depends."

Specific configuration changes we've been asked about:

  • SNMP community strings. The big issue with SNMP community strings is where they are used for making configuration changes. Exposing default SNMP read-write communities puts your devices at risk for unexpected changes. The next big issue is SNMP communities for monitoring, which can lead to information exposure. Even with SNMP read-only, you can view device statistics, log data, and configuration settings. The last capability of SNMP is trap sending and receiving, which is generally informational activity, often used for alerting or in place of syslog. In this case, setting default communities is less critical, because it's generally a one-way communication mechanism outbound from your devices to ours.
    • Active SNMP monitoring (not traps) using non-standard communities: all SolarWinds products that collect data via SNMP monitoring (connecting to devices and polling via SNMP) do allow you to specify a non-standard community. You can also set the systems you run on that provide SNMP monitoring themselves to non-standard communities. Some products, such as LEM, do not have SNMP monitoring capabilities and this doesn't apply. The Orion family products live on Windows systems, if you're monitoring those systems with SNMP, the SNMP settings apply to the system, not our products.
    • Active SNMP configuration changes (not traps) using non-standard communities: The good news is no SolarWinds monitoring products modify system configuration settings via SNMP (LEM, NCM, NPM, etc). SNMP, in these cases, is either used for monitoring (NPM, SAM) or only with traps (LEM).
    • SNMP Trap sending: Many SolarWinds products can send alerts via SNMP traps. All products that can submit traps to other systems allow you to specify the address and community to use, if not standard.
    • SNMP Trap receipt: Many SolarWinds products can also receive alerts via SNMP traps. As of today, in some cases including SolarWinds LEM, the community string is the default ("public") and cannot be modified. As mentioned above, these SNMP traps are consumed by SolarWinds systems for storage and search, and do not make direct changes to any of your systems by their nature.
    • SNMP v3/encryption support: Several SolarWinds products do support using SNMPv3 for monitoring activity. Some systems that receive traps, including SolarWinds LEM, do not provide the ability to use SNMPv3 as it stands today (meaning, traps submitted to LEM will not be encrypted, much like syslog data).
  • Admin Credentials and Default Users. Many customers have a desire to apply best practices around default admin credentials, even though our systems do not fall directly under PCI requirements themselves.
    • Changing admin passwords: All SolarWinds products have the ability for customers to change the default administrator user's password.
    • Adding additional admin users (and not using the default): All SolarWinds products have the ability for customers to add more than one administrative user and not use the out-of-the-box administrator. This allows you to use named users for making administrative changes and avoid using a shared admin account.
    • Disabling the out-of-the-box admin user: Some SolarWinds products do not have the ability to delete or disable the default admin user. SolarWinds LEM, for example, does not allow customers to delete the default admin, to ensure that there is always an admin present that can be reset and used in event of administrative turnover. SolarWinds Virtualization Manager, on the other hand, provides the ability to delete the built-in user as long as another administrative user exists.
  • Least Privilege Access/Use
    • Active Directory Integration: Many SolarWinds products allow you to retrieve group information or authenticate against Active Directory. For basic authentication and information, you do not need to use a user with administrative access.
    • Monitoring: For SolarWinds products that do remote polling, it is generally possible to use lower privilege users (i.e. not root or administrator). Specifically, SAM polling can be done against a non-administrative user with these instructions.
    • Installation & Services: In most cases, SolarWinds products do need to have administrative or fairly broad system privileges to install and run due to technical limitations. Where installers require administrative privileges on Windows, generally they will show the UAC prompt for administrative access automatically.

A Quick Note About PCI DSS v3.0

Most of the changes in PCI DSS v3.0 don't affect your SolarWinds implementations, and product changes were not necessary though your implementation and processes might need to be tweaked. Notable changes that can apply to SolarWinds products:

  • In general, the PCI council added guidance about integrating products into ongoing PCI compliance. As a part of this, having a SIEM helps customers be more proactive in this process rather than only looking at logs when an audit comes through – focusing on security, not just compliance. We didn’t have to make product changes here, but it’s noteworthy.
  • Requirement 10 changed slightly to focus more on identifying suspicious activity and more flexibility in reviewing less critical logs. We didn’t have to make product changes here either, but requirement 10 is the one that specifically deals with logs so it’s noteworthy. (Customers may actually have to generate or review fewer reports of “normal” activity for auditors.)
  • Requirement 2 added a specific note about detecting changes to default passwords for service/backup accounts, not just user accounts, which LEM can help monitor (and NCM can help manage as well). We didn’t have to make product changes to help deal with this, but the clarification helps customers implement it properly.

Questions About Implementing or Auditing for PCI DSS?

If you've got questions about how SolarWinds products are used for PCI, what specific reports or features to look for, or how to implement any of the best practices security configurations, leave them in the comments. I'll update this page with any other common questions we get related to PCI configuration and can direct link any features if that's helpful.

14 Comments
Level 21

Awesome information.  I would love to see the same thing for HIPAA!

Level 9

Also, if you dont already have an incident response plan, using an inventory list of your PCI devices from orion can help getting started. Those re in requirement 12 I believe.

SolarWinds Serv-U MFT Server has also published a PCI DSS file transfer server guide.

(Unlike most other SolarWinds products, Serv-U MFT Server IS often used to directly handle batches of information that include cardholder data, so it features a deployment model that keeps data out of the DMZ, etc.)

Level 7

Hi I'm currently attempting to implement LEM into our PCI-DSS environment as I was told this was not an issue when I was sold the product.

Reading your comments above about not having to be compliant to the PCI standard because they don’t directly touch CHD is not true.

If a device is providing a core function to environment such as a central log/monitoring server, which is a requirement then it is in scope for all sections.

There are parts when it won’t be applicable, such as encryption, secure deletion as its not storing CHD etc but the rest is still a requirement and unless you like writing a number of compensating controls to avoid being as secure the requirements are defined in the standard (and I dont know an auditor who "likes" compensating controls).

A perfect example would be we transmit any CHD through our perimeter firewall, but it is used to provide internet access to our CDE for Linux/Windows/AV updates, etc.

For that reason would you treat the security of this device any different to a SQL database holding CHD? I hope not!

The only time things would not require to meet the full standard would be if they are out of scope and if they are out of scope they are clearly not a requirement to achive the standard.

Product Manager
Product Manager

Fair point - there is still a minimum level of standards that you'd want to apply if something is going into your cardholder network. You wouldn't want something vulnerable to exploit on that network, for example, because it could be leveraged against other things on that network. A lot of (most?) customers are not deploying LEM into the cardholder network directly, but into a segmented network, which changes the requirements.

We're working on a publication that will address these points, too, and offer some tips and pointers for deploying directly onto the cardholder network or not.

Level 7

Hi Nicole I would be intrested in the publication, please dont view my previous comment as being rude....maybe straight to the point!

I merely would of liked to use LEM as my central logging server and provide alerts and monitoring.

I think the product its self is realy good (it still impresses me on a day to day basis) I just find myself annoyed it cant fit straight in and can only be used more as an addon to an existing central logging server that I would of liked to have got rid of (one less server to have to support!!)

If in the future these issues could be addressed the product would be a perfect solution and I dont think they are massive issues either, but probbly not on the top of your priority list.

Regards

Product Manager
Product Manager

No worries, Rhys, feel free to join us over on the Log & Event Manager thwack space if we can be of direct assistance. There's some other folks there that have also worked with LEM for PCI, too.

Level 9

Also, if you dont already have an incident response plan, using an inventory list of your PCI devices from orion can help getting started.

The Serv-U file transfer management stood out.  Is that still the way to go?

Absolutely.  When I worked for RhinoSoft (since purchased by SolarWinds) I helped design the Serv-U Gateway, and I spec'ed out the "no data in the DMZ, no connections from the DMZ to the internal network" requirements of the Serv-U Gateway specifically to meet PCI-DSS requirements about holding CCNs or other sensitive data in the DMZ.  (Before I joined RhinoSoft, I'd worked in the MFT industry about ten years, and served as another company's representative to the PCI Council for a couple of years, so I'd seen which products sailed through PCI audits and which ones raised questions.)


I'm also the original author of the Serv-U PCI DSS Guide - feel free to reply back or PM if you have any questions about that. 


-- Jonathan Lampe, CFTP, CISSP


Thank you very much.

Rick S.

Level 7

Any word on TLS 1.0 being disabled for PCI-DSS 3.1 compliance?  Is there any chance it will be fixed my July 2016? We failed our internal pen test because tls1.0 is still enabled on Log and Event Manager. Anybody out there in the same boat?

Level 11

Hi tlsorensen,

We are working on removing TLS 1.0 in a future version.  We are unable to talk specific time frames, but we are trying to address this as quickly as possible.  My suggestion would be to contact support about TLS 1.0, so you can be put on the list to be contacted for a release candidate to help you get it earlier than when it releases.

In the mean time the work around would be to go into the cmc console and use restrictconsole . This will then only accept requests from specific ip addresses to connect with the console.

1. Login to the cmc

2. After typing the service command, the cmc::scm# prompt appears

3. Type restrictconsole

4. Follow the prompts and add in the ip address that you want to be able to connect to the console

Level 8

I'm interested in monitoring this in our LEM appliance, I don't think we have it configured because I haven't seen logs coming in from IM/Email.  How can I turn this on?

  • Detecting potential violations to compliance with PCI Requirement 2.1: Usage of Default Accounts, 4.1: Usage of IM/E-Mail with Sensitive Data (by way of IM monitoring and DLP solutions that can log this activity OR usage of IM in general)
About the Author
After working all aspects of IT from lab/helpdesk support to complete IT responsibility over the span of 10 years, Nicole turned Product Manager to help bring accessible IT management software to the masses. She joined SolarWinds with the acquisition of Log & Event Manager in 2011 to find it felt just like home.