“To be able to live of your creations - an informational folder on copyright” - to be distributed in Sweden’s schools.

Feels strange that my tax money is going to sommy lobbying organizations project, but it’s not all bad. It actually contains correct facts, and correctly identifies some laws that you break every day without trying.

However, some of the usual lies and misconceptions about filesharing and it’s effect on the artists are still there. Swedish politicians and government employees should once again do their homework.

Oh, did I mention the folder is now available on The Pirate Bay ?

PS. For those concerned, I’m not against copyright. I’m just against the current form of it (which just doesn’t provide anything positive at all). .DS

UPDATE: Information of this kind (lobbying/propaganda) is actually illegal to distribute in Swedish schools. All information delivered by the schools themselves need to be balanced, informational and unbiased. So once again the Government breaks the laws it has created. Apparently a member of parliament has asked, in writing, our “Minister of Education” Jan Björklund to explain why they’re doing this and how they will make it right. In other words, they might have to finance a pro-piracy folder in the coming months… Cheerios!

Found a great article where Bill Seiglein (on csoonline.com) discusses the differences of being compliant and being secure.

Favourite quote;

I use the analogy that there might be a requirement for a door and so we install a door. Unfortunately the door is pointless without a lock but the requirement did not ask for a lock and so we did not get one

Wonderful analogy, really hits the spot and identifies the problems that appear when you try to use a compliance sheet as a checklist. You might miss things that are quite basic, while over-investing in controls that doesn’t do much to overcome the real problems.

A good example of this, to tie into my previous standards posts, might be companies using WEP in older wireless implementations. Insecure as hell but it is still considered “compliant” when the audit goes down.

Read the full article here!

And remember, being compliant does not mean that you’re secure.

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.

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).

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).

I’m sitting here preparing for a meeting at which I will discuss our role in a clients PCI DSS project, and I thought it might do others good if I post what I’m thinking also.

First off, remember that all of this is from a perspective of a Panda AdminSecure/MalwareRadar point of view and it might not apply for other solutions.

Alright then. Which control objective’s and sub-objectives are we even directly responsible for when helping the client achieve compliance? By my thinking it should be:

Requirement 5: Use and regularly update anti-virus software or programs (all subs)

Even though the term anti-virus doesn’t really apply anymore, we can help with this

Those that we might be affected by/can help with are:

Requirement 6: Develop and maintain secure systems and applications
— 6.1 Ensure that all system components and software have the latest vendor supplied security patches installed. [...continued]

Requirement 11: Regularly test security systems and processes
— 11.2 Run internal and external network vulnerability scans at least quarterly [...continued]
— 11.4 Use network intrusion detection systems, host-based intrusion detection systems, and intrusion prevention systems [...continued]
— 11.5 Deploy file integrity monitoring software to alert personnel to unauthorized modification of critical system or content files [...continued]

and how can we do that? My notes on all mentioned subcomponents below…

The main ones:

5.1: This point discusses deployment of anti-virus protections. With Panda solutions, there’s no problem here. Deployment can be done by pushing (RPC) or setting login scripts from within the console and there is also .exe’s and .msi’s available for those that have bigger deployment solutions.

5.1.1: This point discusses verifying correct operation in the solution at hand and seeing to it that it also detects and removes other threats such as spyware or adware. The function verification is really up to the client, but of course we’ll help ‘em if they need help heh… And spyware/adware has been a part of our signature since 2004.

5.2: This point discusses the monitoring of the chosen solution to ensure that it is working, it is updated and capable of generating logs. All of this can be monitored from within the AdminSecure console and scheduled reports can be set up to inform admins of the current status. There is also the possibility of using other logging and notification services such as syslog and snmp, but one should be aware that these units need to be reachable from the client computers as the warnings will originate from them.

and then the others that we might be able to help with:

6.1: This point discusses the need to ensure that all computers have all security related patches applied. We can help with this by offering scans with MalwareRadar (distributed by pushing (RPC), .exe’s or .msi’s) which does both low-level scanning with a huge (too huge for on-access scanners) signature and patch inventory on scanned machines. MalwareRadar is a part of AdminSecure as of version 4.02.01 (beginning of 2008 I think).

11.2: This point discusses running vulnerability scans periodically or after significant network changes. MalwareRadar might be applicable here, but I would not really classify it as a vulnerability scanner. From marketing they will however probably say that it applies

11.4: This point discusses and encourages the use of NIDS, NIPS, HIDS and HIPS. In this section we can help with the HIPS part via TruPrevent. Truprevent is more than just a HIPS but it has all feature’s of one. This component was released in late 2004 and has been optimized since for both capabilities and performance. Installs by default on both clients and servers. Read more here, here and here.

11.5: This point discusses the use of file integrity monitoring software. This is being done in part by our client protection with TruPrevent (see point above) on some critical system files and behaviours. It could however be locked down even further by customizing the ruleset. For a simple example, one may not modify the “hosts” file in certain ways. TruPrevent is not the answer to this point 100% though, as what they are really after is a checksum monitor like Tripwire.

Ok, that’s about it.

If anyone think I’m totally of target or if they have other ways of looking at this, please let me know!

From ComputerWeekly.com:

Reports say Geeks.com sent out a letter at the weekend to its customers, admitting that customer information, including names, addresses, telephone numbers, e-mail addresses, credit card numbers, expiration dates, and card verification numbers, may have fallen into the wrong hands.

As a comment in this article mentions, this incident once again highlights the issue of encrypting customer data. Not “only” to secure the customers creditcards but also to stay clear of lawsuits and other liability issues.

I think I read somewhere about this being a requirement for this kind of vendor/merchant:

3.2.2 Do not store the card-validation code or value (three-digit or four-digit number printed on the front or back of a payment card) used to verify card-not-present transactions

Well well, this is yet another wake up call for those that are not yet handling their data the correct (secure) way.

Cheers,

so did a lot of serious security incidents.

During last week, we saw…

- The largest newspaper in Sweden get their e-mail systems hacked

Apparently, the intrusion was made by initally hacking the newspapers intranet (which was connected to the internet!) and once the attackers had access to the intranet users names and passwords, they just tried those against their webmail system. Apparently people use the same passwords in different systems The group claiming the hack was “Vuxna Förbannade Hackare” (In english: Mature Pissed-Off Hackers) and apparently it was motivated by the fact that the newspaper did not have any coverage of their previous attack on the TV channel TV3’s website.

During the past week the hackers has been releasing more and more internal details from Aftonbladet such as e-mails and user details for partner websites etc. and they have stated that they will continue until the newspaper admits that they have been hacked on the front page of the website.

- The Largest ISP in Sweden looses 2 weeks worth of e-mail for 300 000 customers

This was an OMFG experience. Apparently, according to the information now available, there had been no backups taken (or they had been corrupt), monitoring or maintenance of the affected systems since the 14 December. Telia are now offering 20£ vouchers (only usable in Telia stores) to all affected customers and are also going to handle more serious data losses on a case-by-case basis.

And why did this happen? Well, apparently the guy that was monitoring the systems quit. (Period.)

Nice way to follow routines and policies guys…

- A USB stick containing hundreds of pages of US NATO reports left in a library

Some of the material found had the classification “secret“, but this has not been verified by the newspaper reporting.

Apparently this information was left in one of Stockholms largest libraries on an unencrypted USB stick.. heh.. I mean, encrypted USB sticks are soooo hard to come by these days, so why use them?

This has also been reported on by “The Register“:

According to Swedish daily Aftonbladet, the stick contained material on NATO’s ISAF peace-keeping force in Afghanistan, as well as an intelligence report on the attempted assassination of Lebanon’s defense minister and the murder of Sri Lanka’s foreign minister.

Word of advise, do not trust anyone else with your data people

Cheers and good luck in this 20£ corporate voucher world!

I did a quick post about it here after reading about it at Bruce Schneier’s blog.

The problem is that NSA submitted an elliptic curve algorithm for inclusion in a new NIST standard for random number generation which contains certain constant values whose origin is unknown. Might not sound as something important but as discovered earlier this could open up the possibility for a “secret key” which could allow for unlocking of encrypted data. The fact that NSA submitted this (much slower than the others) algorithm also helps stir up the crypto community.

Not much has since been reported on the issue, until yesterday (by Schneier again).

The big news is that the flawed PRNG is to be shipped with SP1 for Windows Vista. It is not going to be the default PRNG, but it is still going to be included as an option to developers.

Why is this a problem? Well,

First, you are damn sure going to have to look real close at any application you employ to secure your data as you are in the hands of the developers of the applications. More or less, you will have to request the source code if you really want to be sure, and even then it can be a real hassle to find any references to the offending algorithm.

Second. Why did they implement a flawed algorithm found by their own analysts? Yes, Dan Shumow and Niels Ferguson is employed by Microsoft. Specially as they have been urgently patching other PRNG flaws in their OS’s recently. Some say this is to meet the whole NIST standard, but come on, who would implement a crypto technology that is flawed. I mean, that kind of breaks the whole idea of cryptography in the first place.

Third, what if Microsoft issues a patch or security update which silently sets Dual_EC_DRBG to the default PRNG ? Then all your data could be read by “someone”. Do you trust MS? This leads me to the…

Final point. Who has the skeleton key? NSA? Microsoft? Someone else?

PCI DSS stands for “Payment Card Industry Data Security Standard” and it was created by the larger players in the credit card business to ensure that those little 1’s and 0’s, that usually reside on your physical magnetic-strip card, does not end up in the hands of a criminal.The first version of the standard was developed and agreed upon in late 2004 and was (still is) intended to provide guidance for organizations that transfer, store or process credit card information in computer security related issues. The first standard was revised in 2006 to make it more up-to-date and more relevant to the current situation.The use of the word “Guidance” is used a bit freely in the description according to me, as if a requirement in the standard is not met by the merchant he might lose his right to handle the kind of data described in the standard, effectively shutting down their business (this is not a bad thing, btw).Before the PCI DSS was widely agreed upon, many of the CC companies had their own standards and recommendations regarding data security, such as: CISP/AIS (Visa), SDP (MasterCard), DSOP (AmEx), I&C (Discover) and DSP (JSB). The above mentioned was also the primary participants in the discussion that later led to the standard. Most of these financial actors still have their own security programs but they have aligned them so that they all have the same objective, help merchants become PCI DSS standard compliant.

The PCI Data Security Standard consists of 12 topics in 6 different categories. These are called “control objectives” and are:

• Build and maintain a Secure Network
  • Requirement 1: Install and maintain a firewall configuration to protect cardholder data
  • Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters
• Protect Cardholder Data
  • Requirement 3: Protect stored cardholder data
  • Requirement 4: Encrypt transmission of cardholder data across open, public networks
• Maintain a Vulnerability Management Program
  • Requirement 5: Use and regularly update anti-virus software
  • Requirement 6: Develop and maintain secure systems and applications
• Implement Strong Access Control Measures
  • Requirement 7: Restrict access to cardholder data by business need-to-know
  • Requirement 8: Assign a unique ID to each person with computer access
  • Requirement 9: Restrict physical access to cardholder data
• Regularly Monitor and Test Networks
  • Requirement 10: Track and monitor all access to network resources and cardholder data
  • Requirement 11: Regularly test security systems and processes
• Maintain an Information Security Policy
  • Requirement 12: Maintain a policy that addresses information security

In order to verify whether or not the merchants/service providers are really compliant they have to undergo self-assessments, quarterly PCI Security Scans and possibly PCI Security Audits (Depending on the size and amount of sensitive information handled).

The PCI Security Scans are to be performed by a ASV (or, Approved Scanning Vendor) and is non-intrusive in their nature. This means that the scans should not interrupt day-to-day business or cause any damage to the systems evaluated. After one of these scans the ASV compiles a report detailing the different issues found, the associated risk (you will need a CISSP for this ) and also provide some guidance on how to remedy the issues. Every weakness found should also be categorised in a scale from one to five, five being worst case scenario. The PCI DSS considers level 3 to 5 as a failure to comply and a direct danger to cardholder data. This type of scans was the topic of discussion in the webinar that I based my previous related post on.

If you are a large merchant or service provider you might also be the subject of a PCI Security Audit which consists of a review of internal policies & documentation, internal penetration-testing & security evaluation and also interviews of selected personnel. This is done to actually verify that all guidelines in the PCI DSS has been implemented as they should.

One very interesting document regarding both types of audits was written in late 2006 by consultants from the German security company SRC. In that document (which contains a lot of good info) they listed the top 10 types of vulnerabilities found for both methods (internal/external). What’s very serious about the ones they listed are that they are very old. For example, I used one of them to compromise a network in 2002! This kind of vulnerability should not be present in any company that seriously tries to be secure. No matter the size. They are easily scanned for and can be exploited in under one minute. You can find the whole document here.

Other references on this subject:

PCI Security Standards

PCI Answers - This post was very interesting.

PCI Answers PCI Forum

PCI DSS News and Information

IT Governance PCI DSS information

Google…

That’s it for me now. If I’m mistaken about something or if someone has any questions please drop me a comment or an e-mail!

Cheers,