crowmoor.se

There is a rather mean and hard to detect infection spreading on different linux servers. Finjan have released a pressrelease regarding this issue. One thing that it states is that the infecton constatly renames and changes itself to keep it from detection of anti-malware applications. It have been known for quite some time that the easiest way to create an undetectable trojan is to compilate it in a new compiler. This is the first time I have read about an automated version of this.

There is still a big discussion regarding how the infection spreads and I will keep a close eye on this. One important tool for security architecture is patch management processes but how do you handle patch managment when there are no patches to secure your system?

In the last days an interesting story has been published in a swedish newspaper regarding a site that has been hacked and lost the whole account database. A lot of passwords and connected emailadresses was later posted in a forum and that was when the bad things started to happend. In a following article a girls describes how she have lost control of he email, sites where she have used her creditcard number and onlineshops. In still one article a police officer describes how secret investigation material has been lost becuase he used same password at the hacked site as in his gmail account.

What does this show us? Password is not enough anymore. If you trust your user to create their own password they will use those passwords on other places on internet and if they are hacked the integrity of your systems could be at stake. From a security architecture perspective you have involentary included the internet sites in your trusted computing base through your users. To mitigate this threat you need to implement two factor authentication like certificates or pinpads. What have happend is just an example of a riskanalysis that have showed to actually happend.

Lets see what next year means for us. Most probably it will be Anti Money Laundring and PCI DSS for the full year but one never know.

C U all next year!

Jesper

Susan Bradley, a Microsoft Small Business Server MVP, wrote a blogentry regarding if you could get a SBS server compliant. She concludes that it is more or less impossible due to requirment 2.2.1 Implement only one primary function per server (for example, web servers, database servers, and DNS should be implemented on separate servers) and gives a good solution that is true not only for SBS servers: Keep your servers out of scope by letting someone else handle the payment.

That said it is not always possible for a company to solve the problem this way. What are then the possibilites to be PCI DSS compliant and still use a SBS-server? The reason for requirement 2.1.1. is to minimise the surface that could be attacked. If this is not possible then a compensating control has to be created. PCI DSS should be seen from a risk perspective so to handle the possible risk the first thing to do is to solve all other requirements. When everything is patched, proctected by antivirus, all processes are in place and so forth we focus on the compensating control. First thing is to divide all user accounts so that one account could not affect another. This could be handled within Active Directory and extensive monitoring should be implemented on user account creation, change and you should also implement safe guarding of administration account by letting them only login on the console and only by using multifactor authentication.

You should make sure that least privilage is implemented for all services. No service should have administration rights or run as local system. As for logging on to the SQL server where the data most possibly is saved you should not use an AD-account but a SQL Server account. All AD-accounts should be removed from SQL Server.

This goes for a starter. The rest has to be discussed with the auditor and througly tested. You should of course use the hardening guides from NSA to make sure your system is always up do date. It could be tough to be compliant but sometimes this is the only way.

In a swedish newspaper a police has vented his thoughts regarding the easy way to commit identity fraud in sweden. The fraud was commited in a very simple way. A person had registered a mobile phone number in another persons name and then applied for SMS-loans that should be transfered to any bank account. The bill sooner or later hits the persons registered on the mobile contract a week later or so.

The main issue is that the companies giving out loans do not check for the identity in such a way as they should. It is way to easy to get such a lone and the identity check is very rudimentary. In sweden we have a rather low rate of identity theft due to easienss for companies to actually check the identity of a person. Today sadly the identity of a person is not owned by local tax authorities as in many other contries but by the banks. By this I mean that the electronic ID is created and distributed by the banks creating several different standards with different security demands. Part from using for the bank business it is also used for handling identiy realtaed issues like applying for paternity leave and report that you have moved.

A central solutions could both set specific demands on waittimes for SMS-loans as it could check the actual identity of a person to a much higher degree. Identity fraud is a fact for manu people around the world and when it becames harder for a person to hide on internet identity theft will increase and frame other people instead. “When you cannot hide push someone else in front of you.”

One of the requirements states that if you hash the PAN it is regarded as destroyed (safe). This was true before but with the rise of rainbowtables for breaking password hashes ordinary hashing could not be regarded as safe anymore. With ordinary I mean using a hash algorithm is unreversible and produces the same result everytime. This has formerly been regarded as the right way to go if you want to use PAN as data for your marketing but today it is very easy to produce rainvbow tables that makes the hash useless as an protection.

If you salt the hash you mitigates the problem of reversing the PAN:s but you loose the posibility to use hashed PAN:s for marketing unless you choose a something that is always the same for that specific PAN. I am not a cryptologist but I am sure there are some smart solutions on this. The most important part is that when the vendor says it is safe because the data is hashed be sure to ask what was used for a salt. No good answer = no good product.

During my years working in this field I have seen all different kinds of approaches to compliance and more specific the auditor. More or less all ways could be beneficial but one. Never ever try to fool or trick the auditor. The best way to get stuff past the auditor is to be transparant and give as much information that is possible regarding how you have reasoned and the possible risk you have thought of.

Several times I have been asked to not tell the auditor if something has come up that was not beneficial for the assignment, lets say an IDS was not installed and configured as it should be. I could have taken easy road and not tell the auditor about it and the get it past the audit. But what would then happen? In the end of an audit the customer has to sign an agreement that the sample the auditor has seen is representative for the whole company. If no security problems was found, then no security problems shall exist. What happends if you sign such an agreement and are aware of a misconfiguration. Well, noncompliance and most possibly a full investigation if something ever happends. The most important part is: You are not in any way covered by the auditors responsibilities as an auditor. If you are not honest you have everything to loose.

As a CISSP I have to adhere to several ethical standards. Here are some those most important to me:
Capgeminis values
CISSP

A customer asked me today how they should argument with their auditor to make them compliant even if they do not have firewalls. It is a very intriguing question due to the fact that firewalls are regarded as the only thing that actually hinders every system from beeing included as System Components. But where there is a will there is a way.

How should this be solved then? From a compliance point of view there is no way to get around requirement 1 regarding firewalls and we also has to look at how to contain the creditcard information. That said there of course is a loophole. If there is a loophole it is my job to find it 😉 and the loophole is of course compensating controls. It is stated that compensating controls should only be used when business needs or old legacy products that you cannot replace hinders you from beeing compliant with a requirement. It is also stated that the compensating control should be equal or better that the requirement. Also the auditors I often work with says that the most important thing is to reduce or remove the risk.

That said lets take a look on what the compensating control for this has to do. A firewall blocks all traffic but the allowed to a segmented network. It also logs a lot of information and is possibly capable of handling users rights. From my point of view if you separate your networks with packetfiltering routers and add additional security by only letting specified computers communicate into the secure network throough a jumpstation that has user authentication included, as a terminal server of some sort you have created something that more or less handles the requirements of a fierewall. Still, to have it approved as a compensating control you have to go beyond the original control. By adding IP filtering and exhaustive logging this could be a possible way.

On a swedish economy news site an article regarding fines for a bank not complying with AML (Anti Money Laundring) was published. It is quite interesting to know that the fines are rather substantional. According to the article the fines will be around 100 000€. With fines of that magnitude banks have to start working with AML rather fast. Without big fines the legislation would be rather useless. The article in swedish could be found here.

In the same article and point as in my previous entry risk management is mentioned. This is a very important function in any kind of security architecture. Without sound risk analysis you cannot produce any kind of security due to the fact that you do not know what the risks are. The directive in this case is a bit unclear in its scope. It is stated that “those arrangements, procedures and mechanisms shall be comprehensive and proportionate to the nature, scale and complexity of the payment services provided by the payment institution.”

This of course is very different for different organizations. But there are of course some risks that are generic regarding the industry and that are those that are dependent on the setup of an infrastructure. Other risk are those that exist due to the type of business you are in. Robbery has of moved from the actually robbery of a bank to become fraud on the payment transactions instead. This of course is a obvious risk for the payment industry.

I would say that the most importent part is to map the identified risk to the security controls, monitoring and reporting that is done. This really puts the need for a sound security architecture on the frontline.