|
Penetration Testing
PCI Compliance Scope Nov 12 2009 03:27PM Danux (danuxx gmail com) (4 replies) RE: PCI Compliance Scope Nov 12 2009 09:52PM Bakshi, Narinder (FIN) (Narinder Bakshi ontario ca) (1 replies) RE: PCI Compliance Scope Nov 12 2009 07:13PM Erin Carroll (amoeba amoebazone com) (2 replies) Re: PCI Compliance Scope Nov 12 2009 09:32PM David Glosser (david glosser gmail com) (1 replies) Re: PCI Compliance Scope Nov 12 2009 08:42PM Eric Milam (emilam coretechsg com) (1 replies) Re: PCI Compliance Scope Nov 12 2009 09:30PM Tracy Reed (treed ultraviolet org) (1 replies) Re: PCI Compliance Scope Nov 12 2009 09:34PM Eric Milam (emilam coretechsg com) (1 replies) Re: PCI Compliance Scope Nov 12 2009 10:18PM Danux (danuxx gmail com) (5 replies) |
|
|
Privacy Statement |
Definitely the log management should be within the scope even it holds
a sensitive-free information.
the PCI is not only caring about getting or stealing card holder
information, but it also cares to know how,when and who are able to
access these information in case of compromised.
Removing the log management from the scope means ignoring a whole PCI
requirement ( req. 10 ).
However, you should know that adding this server within the scope
doesn't require adding all the other 300 devices to the same scope,
but I would recommend creating a good access list scenario on the log
management system to only allow the pci scope logs to be seen by
special groups and this will isolate your staff and create a
segmentation between them according to the need to know concept.
On 11/13/09, Danux <danuxx (at) gmail (dot) com [email concealed]> wrote:
> Thanks all for your feedback,
>
> I will clarify the most common questions you asked:
>
> a) The Log Management server is a receiver so it is not able to reach
> PCI Assets.
> b) The Log Management server does not store PII/CC data.
>
> It seems like 80% of the audience thinks that if I am not storing
> PII/CC data in the Log Server and not direct access (push) to PCI
> assets then it should be out of scope.
>
> I asked the PCI Auditor that in my opinion the PCI goal was to
> protect CC data and since my Log Server is not able to reach PCI
> assets then it was out of scope.
> The PCI Auditor said exactly what David Glosser mentioned above, The
> goal in this point is to protect the Log Server from tampering.
>
> I totally disagree with that because I think PCI goal is to protect CC
> data and if no PII/CC is store in log server then it does not matter
> if someone is tampering it.
> Someone can tell me whether by getting usernames from log files you
> are gonna be able to bypass firewall to connect to PCI assets and or
> get passwords automatically and or steal/decrypt CC data? All this
> requires extra effort, usernames are not even considered PII since is
> something PUBLIC.
>
> Now, if the goal is to protect Log files then as i mentioned at the
> beginning of this conversation, all assets pushing info to Log server
> are in scope too!! because each one can reach it and therefore try to
> compromise it.
>
> CONCLUSION:
>
> Lets think as Auditors, if I want to convince PCI Auditor about
> putting my Log Server out of scope, I need trust resources. Do you
> have any documentation from trusted sources like NIST, Garner, so on
> where explains how to deal with this Scenario?
>
> Thanks all once again.
>
> I promise to let you all know the result of this point to know the
> real way in a PCI perspective to deal with.
>
> On Thu, Nov 12, 2009 at 3:34 PM, Eric Milam <emilam (at) coretechsg (dot) com [email concealed]> wrote:
>> Its not my decision, last I checked I don't think the PCI Council allowed
>> it
>> as the only form of separation.
>>
>>
>>
>>
>> Tracy Reed wrote:
>>>
>>> On Thu, Nov 12, 2009 at 12:42:35PM -0800, Eric Milam spake thusly:
>>>
>>>>
>>>> Basically the fear are base camps from which to launch an attack.
>>>> As Erin stated below, if there are measures in place (not just
>>>> vlans) to prevent access from the log machine to the Card Holder
>>>> data environment then it may be that the device will be out of
>>>> scope.
>>>>
>>>
>>> Why not just VLANs? Do we not trust VLANs or are we worried about VLAN
>>> misconfiguration? Or switch compromise? Cisco commissioned a study by
>>> @Stake (IIRC) which made a pretty good case for VLAN security. Of
>>> course, that may just be Cisco getting the results it paid for. But it
>>> seemed reasonable to me.
>>>
>>>
>>
>>
>
>
>
> --
> Daniel Regalado aka Danux
> Hacker Wanna Be from Nezahualcoyotl
>
> www.macula-group.com
>
> ------------------------------------------------------------------------
> This list is sponsored by: Information Assurance Certification Review Board
>
> Prove to peers and potential employers without a doubt that you can actually
> do a proper penetration test. IACRB CPT and CEPT certs require a full
> practical examination in order to become certified.
>
> http://www.iacertification.org
> ------------------------------------------------------------------------
>
>
--
Sent from my mobile device
Sent from my Personal GMail Account,,,
Mohamed Farid ,,
m.farid.shawara (at) gmail (dot) com [email concealed]
------------------------------------------------------------------------
This list is sponsored by: Information Assurance Certification Review Board
Prove to peers and potential employers without a doubt that you can actually do a proper penetration test. IACRB CPT and CEPT certs require a full practical examination in order to become certified.
http://www.iacertification.org
------------------------------------------------------------------------
[ reply ]