I turn to the Offspring for a bit of lyrical wisdom in terms of my latest PCI-DSS ramblings. All humour aside, please pay attention to what I am about to tell you. I cannot stress this enough:
The number one thing you should focus on for PCI-DSS is Network Segmentation. If you do not employ proper network segmentation, your PCI compliance efforts will be painful at the best, and a disaster at the worst.
Maybe your company already handles HIPPA/HITECH or SOX. Maybe you have had some other security initiatives running for a while. That's great. PCI-DSS is a very different game, and if you don't segment your network, you will drown in work.
You may have other confidentiality requirements in place. You may be tempted to place HIPPA Data or sensitive financial data in the same network segments as your PCI data. I am telling you now, resist that temptation. It may seem like a perfectly reasonable approach, but it should be avoided if possible.
With proper segmentation of your networks, you give yourself the opportunity to approach your goals in a phased risk-based approach. This will help maximize your efficiency when try to achieves these goals, and will also ensure that you are adding the most possible security benefit at each step of the process.
Completion of this Network Segmentation depends upon some sort of systems Inventory Process. You need to be aware of exactly what is in your environment, how they interact, and what their roles are. Without this, you will fail to segment your network properly and will never be able to truly add meaningful security as a whole.
Let's say that you have three primary Information Security concerns. PCI,HIPPA, and SOX. This means you are concerned with 4 primary data classifications:
1.PCI Data (Credit Card #s , Expiration Dates, CCVs etc)
2.PII/HIPPA Data ( Any personally identifieable information and healthcare data)
3.Financial Reporting Data
4.Everything Else
Let's talk about a perfect scenario where you are a fairly sizable company, and you have a solid budget for this security initiative you are undertaking. That being said, we will go ahead and break down #4 into some additional categories that will help with your overall security posture
1.Critical Infrastructure (Servers and Network Devices that are responsible for core business applications and services. i.e. Email, Telephony, Primary Line of business applications etc)
2.Desktop Ranges (where all of your users should be sitting)
3.QA/DEV Environments (Even if you are not doing any in-house development, you should have some QA environments to test things like configuration changes. Keeping these separate is important for a number of reasons we will get into later)
4.Non-Critical systems (everything else)
So now we essentially have 7 distinct areas mapped out. Let's talk a bit more about each of these areas.
PCI Data – This area will include any device that Stores, Processes, or Transmits Credit Card data as defined by the PCI-Council. In our scenario, this is the area that is going to be subject to some of the most stringent security requirements. This area should be strongly separated from all of the other regions, permitting as little contact between these networks and any others as possible. The rule of thumb should be Deny by Default. These hosts will all be subjected to regular vulnerability scanning and penetration testing efforts. Any applications hosted in this environment should be subject to source code review and Application Security Assessments.
Within the PCI environment, the hosts should be further separated where possible. Any external(Internet) facing Presentation layer should be strongly segmented away from the Application and Data layers. This is to try and mitigate the chances that your presentation layer will be sued as an entry vector deeper into the environment.
PII/HIPPA Data – This area is going to be a concern from a regulatory standpoint as well. However, HIPPA's guidelines on security requirements are nowhere near as stringent as those set forth by PCI. Your company should create a set of standards and ensure that they are applied against all hosts in this environment. These standards should include topics like Access Control, Encryption (transport and at rest), approved applications, approved services etc. The environment should be audited regularly to ensure that these standards are being upheld. Regular vulnerability scans should be a priority in this environment as well. Code Reviews, Application Security Assessments and penetration tests should be a goal, but should take a lower priority to completing these same tasks within the PCI environment.
It is possibly even more important that the External facing Presentation Layer be segmented off from the rest of the environment here. This is because any Internet facing hosts are in-scope for PCI external vulnerability scanning and penetration testing. If you do not segment the rest of the PII zone off, you can quickly find this entire zone considered in scope for PCI as well. This will mean that you will now be required to enforce the same standards on this environment that you do in the PCI Zone. This may not seem like a bad thing, but the work load can get out of hand quickly.
Financial Reporting Data – This is the zone where your SOX standards come into play. SOX is, in my experience, one of the most vague sets of standards out there. It mandates that Financial reporting data be secured to maintain accuracy and integrity. The big concern in this Zone can be summed up in a word : Accountability. If we apply the CIA model(Confidentiality, Integrity, Availability) to this Zone, we will see that Integrity is our number one concern, followed by Integrity, and Availability come in a very distant third.
What you should focus on:
· User Account Management
· Access Control
· Auditing/Activity Monitoring
The focus here is going to be a lot more process oriented than technical. Ensure that user accounts are set up properly on all systems, with only the access they need. Make sure there is no sharing of accounts, or use of generic accounts. Make sure that activity on all Financial Reporting systems is logged for auditing to maintain maximum accountability.
Regular audits should be done on this zone to ensure all standards and policies are being properly observed within the zone. Regular vulnerability scanning in this Zone may be a good idea, but is not a must. If time and resources allow Source Code Review, Application security Assessments, and Penetration Tests should be performed to help validate the security mechanisms in place.
Like the other zones, any Internet facing Presentation Layer should be segmented from the rest of the zone as much as possible. Remember, all Internet facing hosts are subject to PCI.
Critical Infrastructure – The separation of this Zone is probably going to be less dramatic than with the ones we’ve just discussed. It is still a good idea to tightly control the flow of data in and out of this zone though. Regular Vulnerability scans should be performed in this Zone, but only after the above Zones have reached a point in their maturity where the Vulnerability Management efforts are running smoothly. That will allow you to have time for working with System Admins on remediating any findings. Availability may be a much larger concern in this Zone than in some of the others. This zone represents the core of your operations and should be treated carefully. In addition to the Vulnerability Scans, Penetration Testing efforts are a very good idea in this zone.
Do I need to say it again? Any Presentation Layer facing the Internet needs to be additionally segmented. I think you’ve probably got this idea down pat by now.
Desktop Ranges – Desktop networks are a tricky subject. They should be segregated out as much as possible for a couple reasons. One is that you don’t want a compromise of the outer systems to be able to get into the Desktop networks and run amok. Secondly, you don’t want the opposite to happen. Desktop ranges are honestly going to be the most likely entry vector into your network. A lot of attacks on companies start by tricking users into going to web page, or opening a file that they shouldn’t. If your desktop users have unfettered access, then it is game over.
I cannot stress the importance of applying standards here. Some chief things to think about when looking at standards for your Desktop networks:
1. Approved Software – Make sure you know what software is safe to run on machines, and don’t allow any other software to be installed without authorization.
2. Update management – Make sure that all approved software can be updated in a controlled and uniform manner.
3. File Shares – In my experience as Penetration Tester, this is where you see the most heinous failures. Users often open up shares on their computers to trade files back in forth. The problem is that they do not necessarily know how to secure those shares properly
4. Running Services – If your desktops are all running Windows Messenger or Chargen, you better have a good reason for it. Aside from these obvious concerns, also think about things like Remote Registry. Remote Registry allows for a lot of troubleshooting and remote administration, but it also opens potential security risks. Weigh the benefits and risks accordingly for your environment.
5. Anti-virus – I don’t think I need to explain this.
6. Account Policies – Password complexity, expiration, and lockout policies. Also policies on shared or generic accounts. This also applies to the Local Administrator account. If all of your Desktops run with the same local Admin password, it will only take one Desktop being compromised for this entire Zone to be in danger.
Vulnerability scanning on Desktop ranges is not an easy decision point. There are benefits and risks associated with this activity. As previously stated, the Desktops are going to be one of your most likely entry vectors for an attack. However Vulnerability scans can be potential disruptive, and if you are doing Authenticated scans, you may return a lot more results than you are going to want to look at. If you decide to do Authenticated Vulnerability scans, it will be very important that you have items 1 and 2 from above firmly in place first.
There really shouldn’t be anything to do in terms of Sources Code Review, or AppSec Assessments here. Penetration Test efforts will almost certainly have a field day in this zone. If there is anything directly Internet facing in this Zone you have done something horribly horribly wrong!
Non-Critical infrastructure – Let’s jump to the ‘Everything Else’ group for a second. This is going to be all of your non-critical systems. These are the things that don’t handle sensitive data, and are not required for day-to-day operations to succeed. The separation of this zone should be defined by the separation and controls placed around all of the other zones. No additional work should be required for separating these hosts out. All of your security activities such as Vulnerasbility Scanning, Penetration Testing, AppSec Assessments, and Code Reviews should all be long term goals. Start working on these only after everything is running smoothly in all of these other zones. This is the point at which you’re just cleaning up the rest of the garbage in your Enterprise. If you get to the point where you are cleaning up this Zone you are well on your way to the sustainment phase of your overall Security Initiative.
QA/DEV Systems – QA and DEV environments are a quagmire. The best advice I can give you is as follows.
· Separate QA and DEV out from the rest of your environment as much as possible.
· Try to avoid any contact between QA/DEV and the internet.
· Do not ever allow real production data to reside within a QA or Development Zone.
· Do NOT Vulnerability Scan your QA and Dev environments. These zones will be extremely volatile, and will be in a constant state of flux. You will be bogged down chasing vulnerabilities that disappear and reappear at random. If you have segregated these zones appropriately, there is nothing to be gained from Penetration Testing or Vulnerability Scanning in this Zone. Save yourself the headache.
Below is a crude diagram to try and help illustrate this concept. Please note that this does not reflect actual firewall or network placement. It merely tries to illustrate the segmentation.
No comments:
Post a Comment