Understanding the New PCI DSS Scoping Supplement

Understanding the New PCI DSS Scoping Supplement

In this webinar, SecurityMetrics' Bruce Bogdan, Principal Security Analyst, QSA, PA-QSA, CISSP, covers:

• How the scoping supplement impacts you
• Clarification on the scoping supplement
• De-scoping principles and examples

This webinar was hosted on February 23rd, 2017.

‍

Transcript

Okay. We're gonna go ahead and get started. Thanks again for everyone's attendance. We're excited to be talking to you today. Our webinar is understanding the new PCI DSS scoping supplement. So this is gonna be going over the information supplement guidance for PCI DSS scoping and network segmentation that the PCI Community Council came out within December.

So before we get started, just a little bit about security metrics.

We've been helping organizations comply with mandates, avoid security breaches, and recover from data theft since two thousand. We've been in the PCI space since day one, so a lot of experience and involved in these different supplements and breaking them down as soon as they come out.

Our presenter today will be Bruce Bogdan, who is a principal security analyst here at Security Metrics and holds credentials such as QSA, PA QSA, and CISSP.

Bruce has been working here at Security Metrics for nine years, has done a lot of assessments, and will be able to share a wealth of knowledge with us today. A few housekeeping items before we get started. We get this question a lot. Will there be a recording sent out, and can I get the slide deck?

And the answer is yes. You should receive both the recording and a copy of the slide deck within the next few days to the email that you used to register for the webinar. So watch your inbox with that email address that you used, and we'll be sending that out in the next few days. Throughout the webinar, if you have questions, please chat them in.

I'm sure with the new supplement, there will be plenty of questions. So chat them in. We'll address as many as we can at the end of the webinar. If we don't get to your question, we'll reach out to you on an individual basis, make sure you get helped and that your question is answered.

During today's q and a, we are going to only answer more general questions that will be applicable to the majority of the audience. So if you have questions that are specific to your environment, to your scope, then we will probably tackle those offline so that we can get into the details and make sure that we give you a good answer. So with that said, I'm gonna turn it over to Bruce, and we'll get into the presentation.

Alright. Thanks, Colin. And one thing I'd like to say, if any of you have trouble hearing me, because as I turn towards my screen, I kinda turn away from the microphone, just send a quick message to Colin, and I'll pay more attention to talking into the mic.

So the audience for this, the people that this was sent out to, our merchants, acquirers, service providers, and anybody else that's responsible for meeting the PCI DSS compliance of your organization.

The agenda today, we're gonna clarify the scoping supplement because it was quite thorough and somewhat confusing.

We're gonna talk about how the supplement impacts you, and we're gonna talk about basic segmentation principles and examples.

As Colin said, we're not gonna be talking specifics. If you want if you have specific questions, you can get in touch with me with us. We're more than happy to set up some consulting time with you to talk about your specific specific environment.

K. So let's go over a few scoping basics.

So this the, supplement was released in December, provides clarification and guidance on network scoping and segmentation, and the council is very specific on this. It does not create new PCI DSS requirements.

The purpose is to help define what an in scope system is, what a connected to system is, and what out of scope systems are.

It's also intended to reduce the risk of pivot attacks.

Why was it released now?

A lot of merchants and service providers are requesting more guidance on scoping, and pivot attacks are becoming a more common cause of the compromise of cardholder data. Now a quick little explanation on what a pivot attack is.

If you remember the target breach of is it two years ago now or a year and a half ago?

The attackers compromised an out of scope system, which happened to be a heating and air conditioning control system that happen to be connected to the same network as the in scope network and use the same credentials to log into that server as to log into the more secure servers. So when they compromise the less secure server, they could then turn, use the open ports between that server through the firewall into the in scope system, and then use the same exact credentials to log in to the in scope systems. So that's what a pivot attack is, where you compromise a less secure system, work your way through the network into the more secure areas.

K. Some basics on PCI DSS scoping.

Scoping is necessarily difficult, but keeping your in scope system separate can be.

K.

It's PCI d s s security requirements apply to all system components included in or connected to the cardholder data environment. Cardholder data environment is comprised of people, processes, and technologies that store, process, or transmit cardholder data or sensitive authentication data. I think we're all familiar with that.

Connected to systems are any systems that directly connect to or from the CDE well, to the CDE, indirectly access cardholder data through a directly connected system, and segmented systems are systems that have absolutely no connectivity into the CDE.

So the wording on that for me I know in the past, we've described segmented as just taking your flat network and segmenting it into different network zones, one in scope, one out of scope, one corporate, one may be administrative.

Now that the PCI councils is defined segmented as the the systems that have no access at all to the cardholder data environment. So that's an important point to remember as we go through these slides.

Connected two systems, we'll get into that more in a second. So a segmentation check is part of the penetration test, and that's where our penetration tester will check to make sure that the segmented systems really have no connectivity to the cardholder data environment.

So let's define segment they're connected to systems a little bit.

Examples are systems that directly connect to the CDE, systems that indirectly connect to the CDE, and, no, that doesn't mean the Internet's in scope, and we'll define we'll clarify that a little bit further on.

Systems that impact configuration or security of the CDE, systems that provide security to the CDE, systems that segment the CDE systems from out of scope systems and networks, and systems that support PCI DSS requirements.

So examples are systems that directly connect, means, you know, they have an open network path to the cardholder data environment, indirectly connect such as, say, administrative systems going through a jump box, systems that impact configuration or security of the CDE. So a web redirection server or a name resolution server.

Provide security to CDE, so network traffic filtering systems like WSUS systems that update your patches, authentication management such as domain controllers or or, radius.

And then segments of CDE systems from out of scope systems, that'd be your firewalls and your switches with ACLs on.

And then supports PCI DSS requirements, such as time servers, logging servers, things like that.

K.

Your responsibility as the merchant or service provider is you're responsible for for your scope. So you determine the scope, and you tell the QSA what the scope's gonna be. Now you should work in conjunction with your QSA to help determine the scope because, basically, we've we don't we do it a lot. We're familiar with this, and we can help you work through the scope. But, ultimately, you're responsible for what the scope is.

The best practice and I've I've readjusted my thinking on this with the new new supplement.

The best practice is to assume everything is in scope until verified otherwise.

So in the past, I would work it by starting with a small scope and then expanding the scope out to include other systems in the environment and determine if they were in scope.

In the future, I'm gonna do it by assuming everything's in scope and then saying, okay. Why isn't this segment in scope? And why isn't this segment in scope? And work them take them out rather than add them in. And I think that'll give a more thorough representation of what is in scope.

K.

Key principle is know your environment. Confirm the action of your scope at least annually and prior to your assessment. So and this needs to be a documented process.

So each year before your PCI assessment, go through your environment, verify the scope, write it down, and also write down how you verified that it's in scope. So, you know, determine that this system stored cardholder data. You determined that the antivirus server updated the in scope servers.

One important thing to remember is in in future assessments, there will be more things for QSAs to look at than in previous assessments.

As these as these connected two systems become more in scope, we will be looking at them in more depth.

In the past, we've focused primarily on the cardholder data environment, but now we'll expand that into the connected two systems and also more into the administrative systems.

K. Some principles of segmentation.

Why should you segment?

Well, it's not required to segment. You could just have your whole flat network in scope.

Segmentation may reduce your risk of breach.

It'll reduce your scope.

And with reduced scope, it'll reduce your PCI DSS assessment cost because we won't have to look at so much of your network, and it'll reduce potentially the cost and difficulty of implementing and maintaining PCI DSS controls because you won't have to apply some of those controls to the out of scope network.

Now my recommendation is always treat your whole network in scope or out of scope with the same level of security, but some of the controls such as, you know, IDS or file integrity monitoring may not need to be applied to systems out of scope.

Okay.

Segmentation principles.

So, again, remember, segmentation is no connectivity to the CDE, no administrator access to shared services from out of scope systems, meaning if you're you have a database server that's out of scope and you have it segmented, you can't RDP from that server to any system in scope or any connected to system. It has to be completely segmented.

I select isolation technologies that go be have and beyond those things required by PCS, PCIDSS, such as host based firewalls and things like that.

And a host based firewall is like Windows Firewall, one that runs on the system itself.

To be considered out of scope, a system component cannot have access to any system inside the CDE.

That's the key point of it.

Out of scope system component does not store, process, or transmit cardholder data.

It's not in the same network segment as systems that store, process, or transmit cardholder data because we know that the main definition of scope is a system that stores, process, or transmits cardholder data or any system in the same VLAN, so you can't be in the same VLAN. It cannot connect to any system in the cardholder data environment, and it does not meet any criteria describing connected to or security impacting systems. And, again, those are outlined in the in the the supplement that was released.

So verifying what systems are out of scope.

K. To be considered out of scope, controls must be in place to provide reasonable assurance that out of scope systems cannot be used to compromise an in scope system or component.

So some examples of systems that could be done that do that. Host based firewall and or intrusion detection and prevention system, IDS, IPS.

Some physical access controls, you know, lock cages, things like that. Logical access control, like your radius or your active directory. Multi factor authentication can be used.

Restricting administrative restrictions on your administrators.

And actively monitoring for a suspicious network, and actively monitoring for suspicious network for suspicious activity on the network.

So any one of those things could help segment or none of or none of them or all of them may apply.

And once once they've been reviewed by your QSA, you can, you know, consider those systems out of scope for PCI DSS, segmented in other words.

So while not required best practice is to implement PCI DSS controls on out of scope systems to prevent them from being used for malicious purposes. So make sure your antivirus is up to date.

Your firewall rules even for out of scope segments are reviewed quarterly, things like that.

So some examples, and this is kind of the meat of this presentation is examples of scope and the out of scope systems.

So here we have a a basic network layout.

We have the cardholder data environment. In this case, it's, you know, point of sale systems, but it could be, you know, a web server in a DMZ and a storage server. And one thing we didn't point out on these slides is your cardholder data environment.

If you store cardholder data, it should be segmented into two segments, but the same the same rules apply.

And then you have shared services like your active directory, your patching servers, your logging servers. You could have an antivirus server, an IDS, things like that. Then you have your corporate LAN, which you want to be out of scope entirely.

So we see here we have connections between the and I'm pointing to my screen that you can't see. But we have connections between directory services, patching, logging, admin workstation, and the in scope environment.

So those would all be connected to services at that point because they're all directly connecting to systems in the CDE.

And so they would all now be fully in scope for PCI. We'd have to apply every single applicable control to the shared services systems as we do to the fully in scope systems.

In the past, we've said, well, you know, we need to check logs, keep logs on those, maybe apply a few things that are in scope. But now as of this guidance, we need to apply all controls that are applicable to all systems that are connected to the environment.

And then we see some of these servers, like your active directory or your update servers or particularly your admin workstations, also need to connect to the corporate VLAN and those systems down there. So now the question is, have we brought those systems in the corporate LAN into scope because are they connected to? Because they're connecting to the admin workstation, which is connecting to the CDE.

And the answer to that is no. Basically, it's one step of connected two systems, except for one case I'll point out in a minute, as being considered connected two systems. So because your your domain controller manages the domains for both the CDE and the corporate LAN, that does not mean the corporate LAN's in scope.

But when we're doing an assessment, we wanna make sure the firewall rules are sufficient and the access is sufficient not to allow a compromise from the corporate LAN into the CDE.

And here we see on this slide, the added arrow, there can be no direct communication from the corporate LAN to the CDE.

So that's strictly not allowed.

If there was, as we've been through, that would suddenly make the corporate LAN connected to systems, and suddenly you have a flat network again for purposes of PCI.

K. Now the next the next example.

Same basic example, but now we moved an administrative workstation down into the corporate LAN.

So you have the same connected to system connectivity between the shared services and the CDE, and then you have the same connection to the corporate LAN with active directory and other controls.

The same no connection between the corporate LAN and the CDE.

But now you have an admin workstation there that's administering the whole network.

And what the guidance says is all these corporate PCs can have no access to that admin workstation.

So it needs to be treated as a separate VLAN even though it might be technically in the VLAN of the corporate network.

VLAN as well as the rest of the network, the CDE and the shared services.

If you if you read the supplement specifically, you might get the impression that you can't administer because it says there can't be two way communication, but it doesn't make sense to not allow your administrators to administer the network.

You don't have to create two separate admin VLANs to administer the network. You just can't allow communication into the workstation from the rest of that environment.

And then here, we see we've added the administrative workstation can administer the, shared services or the CDE.

In this example, we've added the jump box server, which means you'd go from the administrator workstation to the jump box and then from the jump box to the cardholder data environment.

So you'd think this is the example of two steps being out of scope or connected to. So the jump box is a directly connected to system, so it's in scope.

The admin workstation only connects to the jump box. And in the past, we've said, we don't really consider the admin workstation as being in scope or fully in scope.

Now if it goes through a jump box with two factor, now it is, and it spells it out specifically in the supplement that this admin workstation, even going through a jump box, is fully in scope.

And two factors still, of course, applies to all of this, including from your connected two systems into the CDE.

So my our recommendation is if you're gonna administer systems, create an ITV LAN so that all access is separate from the corporate LAN and separate from the other things, and then set up firewall rules allowing and disallowing the connections you need to administer the the network.

So some takeaways from this, scoping impact, systems that need to be fully assessed for PCI DSS are IT workstations or administrative workstations, shared systems, meaning connected to systems that admin that, control both the in scope and out of scope networks.

You need to do penetration testing, which will include segmentation checks, and there may be additional in future assessments, there may be additional perspectives to test.

Internal penetration testing, shared services may require additional testing perspectives.

And all segmentation controls now need to be fully tested.

Some other takeaways, you need to validate your scope at least annually and document the results.

You need to limit shared services.

You need to isolate your IT administrators and not let out of scope networks have access to the IT systems.

And your QSA may have additional may may have to examine additional systems as part of your upcoming PCI assessments.

Okay. So we've gotten a lot of questions. We're gonna address as many as we can. And, again, we'll try to address the more general ones and reach out to you more on an individual basis if you have questions about your specific environment.

We've received the question many times. I always reiterate, we will be sending out a recording of the presentation as well as a slide deck so you can see all these different examples. You should get that in your inbox in the next few days.

Joining Bruce for the q and a is Gary Glover, our VP of security assessments. He's been with Security Metrics for twelve years. So we're gonna dive into some of these different questions. Feel free to continue to chat them in, and like I said, we'll address as as many as we can.

So if a system is out of scope but is on the same VLAN as a connected to system, will that be considered in scope?

No. Yeah. One thing I didn't address, and that's a good point, is if you're in the VLAN with systems that store, process, or transmit, you are in scope. But if you're in the same VLAN as a system that's just a connected two system, like the domain controllers, you're not in scope. Now as part of the assessment, there's a lot of things we'll look at regarding that because a lot of security potential for security breaches come into play. But, no, technically, you're not in scope if you're in the same VLAN as connected two systems.

So and this is Gary. Can I let me add one thing to that? I think, for example, if if in your shared services zone that that, picture that that Bruce had up a little bit earlier, the the in between zone, We can even go back to it. Yeah. Maybe it'd be nice to just have that open.

You let's say let's say you had a mail server in that shared services, zone that had no connectivity or anything really to do with the CDE.

And you can you know, that mail server didn't have any authentication credentials or in any way could make a connection to the CDE and it wasn't being considered as a system that is, you know, being shared or providing any kind of services, then, yeah, that system can reside in that shared services VLAN and not be considered as something you have to apply PCI DSS, controls to as Bruce said. And so I think that's, a good question, and hopefully, we've clarified that one enough. So, that's all I have to say about that.

Great. And it looks like someone was a little confused about a statement made about connected two systems. Are they considered as one step into the CDE and not two? Can you guys kinda clarify that piece?

Yeah. Let me let me take that one. I I I wanted to make sure you know, Bruce was right in in and so I think at a point that we wanted to to to get across as it is very carefully discussed in the informational supplement when you read it, kind of this this concept of, you know, is it two steps away? Is it one step away? So stuff in the corporate land feels two steps away, and and however, they are accessing those shared services. So some people could probably say, well, wait. Why are they not connected to connected to?

And, I think the principle illustrated in the in the informational supplement is that there should be no authentication credentials or any kind of, access credentials that that a a system from the corporate LAN uses to access or use the shared services or vice versa from the shared services in the corporate LAN that those systems would be using to get into the CDE. So if somebody, you know, has access to look at or get data from an active directory controller or whatever in the shared services zone from the corporate land, they couldn't use those same, credentials or same rights to get into the through a hole in the c you know, into the CDE through their firewall.

So I suppose if if there was a system in the corporate land that really was connected to the same in the same way that a system is connected to into the CDE, a system is connected to a shared services the same way it connects into the CDE, a QSA would say, wait a minute. That may extend it into there. And then, therefore, you're not not really in a segmented land anymore. There really needs to be different authentication type credentials and different, rights there.

And it's sort of confusing, in the paper as well. Does that make sense, Bruce? Do you have any other comments you'd like to make there?

Yeah. That's actually something I as I was reviewing this this morning, I thought of bringing up and I didn't directly bring it up.

But the gist of it is if you have, say, a database administrator that admin administers your in scope database and your out scope out of scope database, make sure he has different credentials to log in to the in scope one and the out of scope one. And same for your IT administrators. Different credentials for in scope systems and out of scope systems.

And I think as far as connected to we had talked about Bruce had mentioned, does that mean the Internet is in scope? I mean, if you've got a DMZ and something is connected to your DMZ that is in the CDE, it doesn't necessarily mean that this this doesn't mean that every computer that connects into your web server that's doing ecommerce is in scope for PCI DSS. I mean, it really is talking about zones that are inside your edge firewall. You know? Otherwise, the whole world becomes in scope, and that's not what the intent is. We're really trying to as Bruce said earlier, prevent pivot type attacks is the main, you know, the main purpose of of some of these guidelines is to make sure that somebody doesn't mess around inside your back end network, and get into your CDE.

So Right.

So inside the Edge firewall and, also, if you have other service providers or customers that connect into your network, it still doesn't extend the scope beyond the edge firewall into their networks.

There are some things specific in PCI that address that, but this does not extend that scope to them.

They're responsible for their own scope.

Great. So we're getting a lot of questions that are pretty similar. I'm gonna try to ask it as general as possible, and then we can reach out to those chatting in on an individual basis to try to dive into more of your environment. But in general, if two factor authentication or multi factor authentication is used to access the CDE from an admin system, an IT system, will that put the admin or IT system still in PCI scope?

Sure. Can you add ask that again?

Yeah. So if they're using multifactor authentication to access the CDE from an admin or IT system, are those systems in scope even though they're using multi factor authentication?

Yes. In the past, we've said two factor will make the admin workstations out of scope. That's no longer the case.

Two two factor does not remove you from scope anymore.

And it's because and again, I think it's because the, again, the principles as as the years go by, we're trying to get more and more effective in our security. And and, you know, over the years, people could have could have interpreted thing different things different ways.

And I think the council is just trying to tighten up what they had always maybe thought for a long time.

And, it does it makes sense to me that that if you're using an administrator if you if you're an administrator, an IT administrator, in your laptop, then that laptop really needs to be treated as something that could materially affect the the security of the CDE. Therefore, there are some PCI controls, that probably ought to be applied there. And, you know, things like encryption of data doesn't because they're not getting data, but you should look through, improvement of of of the ways that, you know, that's of a raising of the bar and improvement of of of the ways that we as QSAs would would want to represent and look at those systems, during an assessment. So yeah.

Now one thing that just reminded me of another point I wanted to make and didn't.

So you'll notice on the slide I currently have up, we have no communication into the admin workstation from the corporate LAN, but you can communicate out to the corporate LAN for administrative purposes.

What if you're administering from home? So you're not on the corporate LAN anymore. You're in your home network with your Roku and your TV connected to the Internet and all those other things.

Do you need to worry about those communicating with your admin workstation?

And, Gary, can you correct me if I'm wrong? But in a conversation with the council, the answer is no. We're not considering your home network the corporate land.

Now that it doesn't mean that that home that that that administrator workstation shouldn't have an active firewall, you know, host based firewall on that remote on it. Because this is really we're kinda changing between, what's the word, mobile and non mobile admin workstations. I think the paper really kind of focused on on typically non mobile, not not laptops. They're kinda thinking, hey. This is an admin workstation sitting in the corporate LAN, you know, in an office. It's not being moved around. When you start moving systems around that that admins are using, you know, is it is it wise that you should just ignore everywhere that you may be?

No. It's wise that you should be careful about, protecting that laptop asset from other other potential, malware attacks or whatever. You should have an active firewall. You should still have antivirus or anti malware software running.

You should still be, monitoring some of those logs and stuff that if you needed to look at them later, you could probably be doing that. But I I think the point being is that is there a way to control every network as closely as you do your home network? And, hopefully, you're, you know, you're probably using your personal laptop, you know, your work laptop at work more than you're using it at home anyway. I don't know.

Those are some of the principles I think that lower the risk.

So, basically, you can administer it at home. It's not bringing your home network into scope, and we're not gonna do a seg check on your home network. But be mindful of security.

Right. Right. That's a good way to say that's a good way to summarize things.

Great.

So does this new supplement pertain more to level one merchants that are required to have an on-site audit and validation? Does it affect, you know, level three and four merchants still?

Just like any PCI DSS requirement, they apply across all classes of merchants and service providers.

There is no there's no, you know, respecter of persons to PCI.

Everything applies. Now based on whether you're a level one merchant different validation requirements. For example, if you're a level four merchant, you may validate as an SAQ, a self assessment questionnaire. And maybe based on your card transmission, your card, you know, functions, you may be at a c or an a or some other different kind of an SAQ.

However, it doesn't mean that you're all of a sudden excused from every other PCI guideline or PCI requirement.

So, Colin's question of does it apply to everybody? It absolutely does apply to everybody. And, I think the point that Bruce made earlier about about, hey. The merchant is or the service provider is really in charge of their scope.

QSAs are here to help, you know, guide people, but but if we can get everybody to be thinking about, you know, PCI DSS compliance as a security thing rather than a compliance thing, then everybody really should be thinking carefully and wanting to define their scope carefully and correctly and and have it be, all inclusive of of what things need to be considered. Because we're really just trying to protect the data. You're not just trying to be compliant. You're really trying to protect the data.

So, some of these concepts, you know, smaller merchants and smaller people that are, you know, smaller risk people. It's not necessarily you just say I don't have to do those things.

Great. So we've gotten this question again in different forms. But how does this new scoping supplement apply to p two p devices or encryption in general? Are they affected as much? Can you just kind of elaborate on maybe some of the impacts?

Sure. The the purpose of p two p e is to take segments of your network out of scope.

So if you have an environment where your POS devices are completely p two p e And validated as p two p e.

Yes. On the on the council's list of validated p two p e solutions, then that network is no longer in scope for the majority of the PCR requirements. Now physical requirements still apply To the to the hardware device. To the hardware devices and the and the call center they're in or the environment they're in.

But because your p two p e validated, all the other considerations are no longer applied, so you're out of scope for that.

Yeah. Because you're they're basically those things are making the data absolutely unusable as far as credit card data to anybody, post, the actual swipe device or the dip device.

So that is the scope of a PCI assessment when you're using a validated p two p solution is the device that's taking the credit card data, and that's it because it's making rendering the data unusable anywhere else. Now with that said, does it mean that you shouldn't take the best of the PCI DSS requirements and apply it to your network as a best practice? No. It doesn't. I mean, you still don't want people breaking into your network and defacing web pages or messing with things or denial of service or whatever. Any of those kind of, malicious uses of your network should still be something that as a corporation you would want to avoid.

Therefore, is it a good idea to use PCI DSS guidelines as basic security guidelines even in a p two p solutions?

I would say absolutely. It's a good a good idea to do that. However, an assessor may not be, examining all of those rules as part of an assessment.

Great.

Does the SIEM and VA scanner come into connected two systems? Is that involved in connected two systems or included in that?

Sounds I think is it so so that's that one.

Right. Yeah. That's a good question.

Well, the no. The best the the logging server, the SIM server, I think if you could affect the security of that server, then definitely it would be something that you could affect the security of the CD. So a SIM server locks through, yeah, it's it's in scope. It's gonna be one of those connected to system.

But did he ask if it's in scope? Yeah. So basically yeah. Like Gary said, they'd be in scope, and you would require to be required to do internal scanning in that segment that those connected two systems are in.

As well as if any of those had external connections to the Internet, you'd probably have to do ASV scanning on that IP address they're connect using. Right.

I mean, you're again, you're applying in the supplement. I think one thing that I it was really interesting for me to to get clarification on was for connected two systems, they use the same wording as far they being the council use the same wording as they do for a system in the CDE.

And that wording is apply all applicable or what is it? I can't remember what the exact wording is, but it's use all applicable PCI DSS, requirements.

So a connected to system or something that materially affects the security of the CDE is treated as if it kinda was in the CDE as far as doing an audit or filling out an SAQ or, you're really going to be applying all of those controls to it. And, and, here, the word is and and that's something that I think has been maybe just so fully in scope for all applicable PCI DSS requirements is the the term that's used for for connected to or security you know, materially affecting security of, the CDE.

And I think in the past, sometimes as QSAs, we'd go, well, hey. Look. This is connected to system, but we're gonna apply these five major things to that system because here are the things that we see are the major risks.

The council is basically clarifying, no. We don't want you to just pick and choose which ones you want to do. We want you to apply all, fully apply all applicable. In other words, if something's not storing credit card data, you don't apply you know, you don't don't apply storage of credit card data to that one or encryption.

But file integrity monitoring, scanning, you know, any of the other, you know, virus, you know, any of those other kind of things that are requirements in PCI need to be applied. So you need the auditor will be asking all of the audit questions for those systems. So going back to the original question, is a log server and a a VA scanner I mean, if that's the the virus scanner system that is the master for the whole group, storing logs, telling other systems when to do virus scanning, etcetera, that one should be in scope as well because somebody could change that, then now all of a sudden you're changing the security of systems that would be in the CDE, if that's the if that's what was meant by a VA scanner in the question.

Now one thing that I wanna point out that this kinda triggered in my memory is, remember in this supplement, these things are examples. And sometimes it's a little hard to tell what's an example and what's a requirement from PCI. And one thing that got us talking was data loss prevention tools.

It reads like you need data loss prevention tools. We had that clarified with the council that that's an example. Might be a good idea, but it's not a requirement. So DLP is not Right. Required, and you might read that in the thing. Right.

And that's and that's really important to know that when you read through the supplement, you're seeing all the things that they're saying.

They're not necessarily modifying the PCI DSS.

They're just they were trying to do their best at providing, you know, additional controls and other things that you might want to look at.

Great. So kind of a similar question based on these diagrams. Would the jump box server be in or out of scope? Definitely in.

K. Great. Great. Yeah.

And, again, required two factor from the jump box to the CDE.

Right.

And probably from your admin workstation to the jump box. Box.

Right. But the thing that we wanna be careful about here is is is this supplement saying now that the only way to administer a system in the CDE is via a jump box?

I think the answer is no. That's not what they're saying. This is just an example that they were using.

Right.

You don't have to work. This is not forcing everybody to use jump boxes. It's just now making sure that if you are using a jump box, that you're considering that thing as fully ins fully in scope for an auditor to assess all the PCI controls against.

Great. And what are the rules to remotely administer a CDE from home? So what computers can you use to remotely log in to CDE and shared services LAN?

What are the rules?

So multifactor authentication, obviously.

Multi factor authentication, and you should have a firewall. I mean, that's kind of a section one, PCI requirement that if you are if you're using a a a mobile computer to to administer, then a personal firewall needs to be active and and effective on that system and actively running.

You know, as far as, you know, there are two ways to do remote administration. You can either be a get a VLAN. You know, you're if you're doing a VPN, you're you may be sucked into the actual, IP range of the CDE, and therefore, that computer then becomes part of the CDE.

You know, you wanna be real careful with that. Other times, there are administration tools that that are, still using multifactor authentication, but maybe it's a different kind of administration of either a web interface or something like that. There may be differences in in how a QSA would evaluate those types of remote access methodologies, but but, multi factor authentication is the key for you know, and it's true. And there's and if you just if you notice and we'll be doing actually a webinar in the near future here on the new supplement that the council has just put out on multifactor authentication that came out in February.

So if you haven't read that, and you're interested in some of those principles, So let me go add a little bit to that.

So we've said the admin workstation the council said the admin workstation you're using to administer the network is in scope. So if that workstation is a home desktop PC, scope. So if that workstation is a home desktop PC I know I said your home network's out of scope, but that PC is now in scope because you're using it to administer the network. So if it's also the PC you used to, you know, play World of Warcraft and to download your BitTorrent movies, that's probably a bad idea because a key logger on that admin workstation would compromise your whole network.

Mhmm.

Great. Still be wise. In other words Yeah. PCI DSS is the floor, not the ceiling of security requirements.

Right. Yeah. You know, everybody needs to be wise as far as, boy, what should we really be doing? Should we really think about security?

Do I just only have to be PCI DSS compliant, or should I really just be thinking about security?

And I wish everybody would think about security more.

Definitely. PCI is a checklist, but it's a guideline more than just a checklist for good security.

Great. And just some clarification on the on the jump box server.

So is multifactor authentication required into the jump box and then from the jump box to the CDE as well.

We're still working on that.

Yeah. And I think I you know, it kinda depend a little bit, but is it a bad idea to do both? No.

So we could always say that would be that would be easy.

Yeah.

The real question is, you know, I and I think as far as does the admin workstation need two factor authentication from the corporate LAN to the shared services zone, You know, if, you know, the the one thing that and this might be a a thing that if somebody has specific questions, they can call us up and we can talk to them about their specific environment. It gets tough. But if the, username and password going from the admin workstation to the jump box server from the corporate LAN is different than the multifactor authentication that would be used to get into the CDE from the jump box server, That might be something that to be considered during an assessment.

So in other words, an admin guy can get to the jump box server but has no rights now to get to the CDE unless he goes through the proper, multifactor authentication from the jump box server into the CDE. But if you're using your same username and password from the admin workstation as you would to go from from the jump box the jump box server, then that's probably not wise.

Great. So to address something that Bruce mentioned during the presentation, I think you were talking about if you store credit card data that you should have two network expound on that and I mentioned why it's a word segment.

Right? Yeah.

Uh-huh. So the requirement in PCI, and this has always been the requirement that a VLAN that stores, process, or transmits cardholder data has to be firewalled separately from the DMZ where your web servers might exist.

So the council writes is as if you have a edge firewall and then a separate firewall to create the storage VLAN. The reality is most people use one firewall and create two zones with the appropriate rules in place. So PCI has always said a storage environment where card numbers are stored needs to be separate from the DMZ word database. They're only routable from the Internet directly. Yeah. Correct. You can't directly connect to the storage zone from the Internet.

Right. And the word segmented is often overloaded Yeah. In that conversation. So sometimes you use the term, you gotta segment your CDE, CVE, and that sort of just means, hey. We're we're we're making sure that you are creating these separate separate zones that are not are are not directly connected to the Internet for storage.

And, unfortunately, the word segmented is used there, but it's it's sort of different than the word segmented as far as scoping Yep.

Goes. And so it's hard for us to make sure we're using the right word there. So you might say separate or a distinct zone or an, you know, inside the CDE. There needs to be perhaps perhaps multiple zones within the CDE to be PCI compliant itself.

Yeah. Sorry about that. My my use of the word segment has been compromised by the council's new definition of the word segment. So sorry if that overlaps. But the segmented separated card storage zone can communicate with the web servers.

It doesn't need to be segmented with the new version of the word. Right. Right. Hope that's clear.

Great.

As mud. Yeah.

Yeah. And do all PCI requirements apply for an admin workstation, for example, having FIM, physical security requirements, etcetera?

Yes. Great.

And a question kind of about penetration testing being required for segmented networks, flat networks. Can you just give a brief overview of does the segmentation of a network affect whether it needs a penetration test or not? The blue one?

Yeah. So I think, you know, obviously, a segmentation check is done from a from and and that's the proof that there are no connectivity, as Bruce said during the presentation.

Needs to be done from a corporate zone looking towards a CDE zone to make sure there is absolutely no connectivity. That's always gonna apply. That's a a three dot o PCI DSS three dot o kind of requirement.

The new kind of guidelines from the council in this supplement do kind of imply, okay. Well, now that I've got for example, in the picture that Bruce has up here now, the admin workstation, is considered in scope. So do we have to do a segmentation check essentially from the corporate LAN perspective trying to get to the admin workstation to make sure you can't see it? Yeah.

You would. It seems like it's an interzone test, but what you're trying to do is prove that the controls that you have on the admin workstation are effective in isolating that if that's where you choose to put it. It may make sense to put admin workstations in a different zone and just do that on a corporate VLAN ACL rather than, having to do a whole bunch of individual things on each admin workstation that may be in the corporate zone. That's a a preference by the customer there.

But but, is a penetration test, as Bruce mentioned, now are these shared services systems, are they subject to penetration testing?

And I think the answer is is there is yes. If they are considered a connected to or, critical to the security of the system, then a penetration test perspective may need to be looked at.

If it's a mail server in that zone, maybe not. Just as we talked about before, maybe there is no penetration test perspective. But that's all I have to say about that.

Great. So similar to admin workstations, do all PCI controls apply to shared services? Yes.

Now, again, like I said in the presentation, as applicable. So if you have no data storage, and, of course, the requirements for encryption are not applicable.

But I think that, to be clear, that is that's the main point of this whole informational supplement that I took away from it was we are being we are being guided now to apply all pieces. In other words, an auditor, when he's looking at the shared services thing, you can envision that. You could visualize that as he's gonna open up his book, and he's gonna go through all twelve PCI DSS, areas and ask all of the questions that should apply to that system based on its function. So you're basically now conducting an audit, a full audit on those systems, that are in the shared or the connected to mode or in an in the admin workstation in that in that instance. So, yeah, it does in other words, I think the the point being, if we're following this guidance from the council this year, we would be looking at more systems than potentially a QSA may have been looking at last year.

And there's one word in the standard where they use the word, periodically.

It's like eleven dot something. Mhmm. So we were using that word periodically to say, well, you only look need to look at these connected two systems occasionally.

But with the new supplement, that periodically statement is out the window. I'm not sure what it did apply to anymore. But Yeah.

I'm not sure.

All all these connected two systems are now fully in scope for everything that's applicable to them on the same schedule as everything else.

Right.

So I think this is probably one of the last question we're gonna be able to get to. We we received a lot of questions, a lot of great questions, and many of them that are, as I've said, a little more specific to your environment that I think we'll be able to answer easier with a back and forth than trying to just address it in this q and a. So we will be reaching out to you in the next few days to try to address those.

So if an out of scope system accesses something in the CD using, you know, an API, would is that now in scope?

That's now a connected to system.

An API It means you'd have to have a port open.

Yeah. Absolutely. So that so that absolutely is in scope for pen testing and it's a connected to system, so it's in scope for Yeah. All PCI that are that's applicable.

Something that's not in scope, again, segmented has no ports open. Yep. So there would be if you did an Nmap scan, you would see no visible ports open. And if an API is using typically, they're a web API or something here. It has a port open. So that's definitely a hole into the CDE.

Great. And I'll I'll ask this last one as it's kind of a clarifying statement for a few of the different things we've covered recently with connected to shared services. So is there any difference between what's required for the CDE and connected systems as far as what's required by PCI?

Not anymore.

No.

So we're gonna be looking at them the same way if they're determined as one of those ins those connected two systems.

Yeah.

Great.

Again, we appreciate everyone attending today and the interaction. We, as I said, received a lot of great questions, which helped make this presentation what it was. We wanna thank Bruce and Gary for their time. As I've said, we will be sending out a recording of the webinar, and that will include the q and a so you can revisit some of these questions that did more of a deep dive.

We'll send the slide deck so you have access to these different examples, and we will have someone reach out to those who didn't have their questions answered or need more clarification. And please feel free to reach out to us if you have more questions or would like to discuss your specific environment. So we appreciate everyone's time. Everyone have a great rest of the day, and we'll be sending everything soon.

Thank you.