You are currently browsing articles tagged 1.2.
Tags: 1.2, keith dsouza, plugin, wordpress automatic upgrade
PciAnswers.com (Aegenis Group) posted today on the differences in PCI DSS version 1.1 and 1.2.
For me personally as a consumer, I appreciated seeing deadlines being set for WEP usage.
* New implementations of WEP are not allowed after March 31, 2009
* Current implementations must discontinue use of WEP after June 30, 2010
WEP is seriously dead and dangerous technology and should not be used in or within reach of a network containing cardholder data. Remember some years ago, when people used to sit outside WalMart and sniff CC-data?
The deadlines seem to be a bit too far into the future though, but my guess is that the time is needed for the larger merchants in order to change legacy devices. On the other hand, this should already have been done years ago.
When it comes to Requirement 5, the anti-virus one, they note something I discarded in earlier posts:
* At first glance it appears that version 1.2 reverts to an older form of the standard by mandating “anti-virus software applies to all operating system types” but it quickly clarifies the intent still as those systems “commonly affected by malicious software.” Although the reference to UNIX is removed, it does state that companies should deploy on such systems “if applicable anti-virus technology exists.”
Requirement 10 has also been modified and now mandates that you retain your logs for at least one year, with the last three months available for immediate analysis. In other words you can rotate away your logs to an archiving facility after three months and just keep the current data in your live logservers.
For me, and all Panda Security business & enterprise customers, this means modifying the variables for the built-in log retention even further. Previously we’ve extended the period only to three months to prevent excessive information in the console (which makes it sluggish) together with syslog logging which has been rotated according to the company at hand’s internal routines.
A lot of more news was presented and is available in an easily readable format at pcianswers.com.
Tags: 1.2, changes, news, PCI DSS, pcianswers.com
From Branden Williams (Verisign):
“[...] Seriously though, are you ready? Version 1.1 has been around for over two years now (birthday was September 7, 2006), and by now you should have been able to validate as compliant to that version of the standard. If you are still struggling with 1.1, there is good news along with the bad. [...]“
Linked to it before but here is is again, PCI DSS 1.2 summary of changes.
For us in the AV business, the primary news are:
Requirement 5: Use and regularly update anti-virus software
- Clarified that requirement for use of anti-virus software applies to all operating system types
- Clarified that anti-virus software must address all known types of malicious software
Feels nice that they declare more directly that anti-virus (incorrect terms according to me) should be able to detect all types of malicious software. That is, they have to be Anti-Malware products (which is the “correct” term).
Photo: The Joy Of The Mundane on Flickr.
I was browsing the intertubes using an open WLAN when i stumbled on this article on Bakmans blog. The entry itself is a bit outdated but it got my brain working a bit.
Engaged in a search for more information on the subject and eventually found this paper (PDF – Aegis PCI DSS Wireless FAQ) through a pcianswers.com post.
One interesting, if not obvious, thing mentioned is that objective 11.1 require you to audit your sites for wireless networks even though you aren’t running any. This requirement comes from the possibility of rouge Access Points placed in the network(s) that handle card transactions, or a net that is trusted by it. You are not permitted to allow any rouge AP’s if you want to be or stay compliant.
Requirement 11.1 reads:
11.1 Test security controls, limitations, network connections, and restrictions annually to assure the ability to adequately identify and to stop any unauthorized access attempts. Use a wireless analyzer at least quarterly to identify all wireless devices in use.
And this control objective is applicable to all organizations that are aiming at PCI DSS compliance. The paper mentioned above has some of Aegis frequently asked questions on this listed and before you start asking expensive consultants, give it a read 
The other control objectives discussed in the paper (including FAQs) in relation to wireless networking are:
4.1.1 For wireless networks transmitting cardholder data, encrypt the transmissions by using WiFi protected access (WPA or WPA2) technology, IPSEC VPN, or SSL/TLS. Never rely exclusively on wired equivalent privacy (WEP) to protect confidentiality and access to a wireless LAN. If WEP is used, do the following:
• Use with a minimum 104-bit encryption key and 24 bit-initialization value
• Use ONLY in conjunction with WiFi protected access (WPA or WPA2) technology, VPN, or SSL/TLS
• Rotate shared WEP keys quarterly (or automatically if the technology permits)
• Rotate shared WEP keys whenever there are changes in personnel with access to keys
• Restrict access based on media access code (MAC) address.
[...]
10.5.4 Copy logs for wireless networks onto a log server on the internal LAN.
[...]
1.3.8 Installing perimeter firewalls between any wireless networks and the cardholder data environment, and configuring these firewalls to deny any traffic from the wireless environment or from controlling any traffic (if such traffic is necessary for business purposes)
[...]
2.1.1 For wireless environments, change wireless vendor defaults, including but not limited to, wired equivalent privacy (WEP) keys, default service set identifier (SSID), passwords, and SNMP community strings. Disable SSID broadcasts. Enable WiFi protected access (WPA and WPA2) technology for encryption and authentication when WPA-capable.
[...]
9.1.3 Restrict physical access to wireless access points, gateways, and handheld devices.
[...]
11.4 Use network intrusion detection systems, host-based intrusion detection systems, and intrusion prevention systems to monitor all network traffic and alert personnel to suspected compromises. Keep all intrusion detection and prevention engines up-to-date.
[...]
12.3 Develop usage policies for critical employee-facing technologies (such as modems and wireless) to define proper use of these technologies for all employees and contractors. Ensure these usage
policies require the following:
12.3.1 Explicit management approval
12.3.2 Authentication for use of the technology
12.3.3 List of all such devices and personnel with access
12.3.4 Labeling of devices with owner, contact information, and purpose
12.3.5 Acceptable uses of the technologies
12.3.6 Acceptable network locations for the technologies
12.3.7 List of company-approved products
12.3.8 Automatic disconnect of modem sessions after a specific period of inactivity
12.3.9 Activation of modems for vendors only when needed by vendors, with immediate deactivation after use
12.3.10 When accessing cardholder data remotely via modem, prohibition of storage of cardholder data onto local hard drives, floppy disks, or other external media. Prohibition of cut-and-paste and print functions during remote access.
The above text was copied from the standard document and to fully grasp the implications involved I would, as I did above, recommend you to read Aegis PCI DSS Wireless Security FAQ.
Also, version 1.2 of PCI DSS is to be “released” in the beginning of October and you can find the document of changes here (PDF).
Posting tweet...
övervakning 1.2 16 September 2009 a1 acer anti-malware aspire one censorship censur christmas conficker copyright eu fascism fra infection integrity internetdagarna ipred1 linpus linux malware massavlyssning mass surveillance microsoft music Panda Panda Security panda security days party PCI DSS piratpartiet qp security stockholm surveillance sweden telecom telecoms package the pirate bay tpb trial tweets vista
