Building a PCI DSS Information Security Program (PCI Resources Book 3) by Yves B. Desharnais

Author:Yves B. Desharnais [Desharnais, Yves B.]
Language: eng
Format: mobi, pdf
ISBN: 9780994837424
Published: 2015-09-24T00:00:00+00:00

Requirement 10.6.2 calls for the periodical review of other logs based on "the organization's annual risk assessment" (see section 3.5.2 for the risk assessment). A well known blogger requested clarification 59 through the FAQ process; he was answered in FAQ 1304 60 . The FAQ states that it " allows the organization to determine the log review frequency for all other in-scope events and systems that do not fall into those categories" (those in 10.6.1), so this gives flexibility to the organization. They also clarify that this requirement applies only to in-scope systems. See volume 2 for what constitutes in-scope systems versus out-of-scope ones.

Finally, the standard mentions that any any anomaly or suspicious activity detected must be adequately investigated (10.6.3), potentially instigating the incident management process (12.10.*).

Requirements 10.4.* mandate use of organizational time servers (using the Network Time Protocol, NTP) to ensure that log dates can easily be compared. An organization should maintain a few (but at least two for redundancy) central time servers that are synchronized from industry-accepted time sources (10.4.3) with their time data protected (10.4.2). These servers are sometimes core network switches, routers or Active Directory servers. All critical systems within the organization should be synchronized with these central servers (10.4.1). I would recommend that all (not just in-scope PCI DSS ones) organizational systems be synchronized as well using the same internal sources.

3.7.11 - Requirement 11 - Testing

Do you prefer finding that hole in your system yourself or would you prefer an attacker to do so? I certainly hope you prefer the former, and this is why testing is crucial.

Requirement 11 is all about proactively looking for vulnerabilities that often stem from a failure in IT processes. For example, did you forget to check a server that is also running XYZ software (which should be patched) and may have vulnerabilities? Your policies do mention that you can't connect an unauthorized device to the network right? Could somebody not have gotten that memo? Or not cared enough to read it?

3.7.11.1 Testing wireless networks

The first thing the standard asks us to test for is whether an unauthorized wireless network is connected to your network (11.1). This requires identifying all wireless networks and access points (AP) on a quarterly basis (I would recommend a more timely timeframe). Those wireless networks and APs are then compared to the list of authorized AP and networks that you must maintain (11.1.1). This applies even if there is no direct access from the wireless network to the CDE as we're also looking for networks that a user has connected to the internal network. In heavily populated areas, there can be many wireless networks that are not originating from the premises, but from across the street or another floor. Certain tools will help you pinpoint the location of the APs using signal strength so you can rule out false positives (wireless networks present but physically outside your premises and thus not connected to your network). Should you identify an unauthorized network, you should treat this as an incident (11.

Download

Copyright Disclaimer:
This site does not store any files on its server. We only index and link to content provided by other sites. Please contact the content providers to delete copyright contents if any and email us, we'll remove relevant links or contents immediately.