March 8th, 2010 by peter.bassill

Required Disclaimer – All views expressed within this site are the views of the author only and are in no way representative of the employers of the author.

I was recently presenting at the Information Security Executive Summit at a beautiful venue in the Forest of Arden. Following a very well facilitated event, a long 2 days with some other excellent speakers I felt suitable refreshed that many of my peers share the same views on security as myself.

So what was new, if anything? Well no much. It would appear that as much as I preach that you should love your audit and fear your attackers, many IS professionals still fear the audit more than the attacker. As hard as I try, I still find this a very difficult way to think.

Listening to Joshua Corman from The 451 Group (also from the Rugged Software initiative, your suppliers and your own code is Rugged right?)  I came to realise that much of what he said is very true. Many IS professionals will of course take the view that they “MAY get attacked, but WILL get fined”. Has Information Security turned a corner in its mission? Have we now become the last bastions of defence against a known known, the auditor or are we as an industry missing the point of our existence?

Different types of auditor?

In my experience, there are 3 kinds of auditor.

•  The fresh faced ones, those that came out of university and “did a course”.
• The disillusioned ones, those that left IT or IS after a few years to progress a career in a parallel fashion and “did a course”.
• The enlightened ones, those who reached a high level within an IT/IS/Engineering career (often military or government sector) and became an auditor to further the industry as well as themselves.

Why Fear the Auditor?

So you know you are going to get fined, what are you going to do about it? Let us look at PCI for a moment.

The standard is an interpreted standard. The requirements within the standard are well published and very well known and understood by IS professionals so why is it that many in the industry are having difficulty achieving compliance?

The fresh faced ones will read the letter of the standard and will often defer to a lead auditor. We should be helping these young souls to further their knowledge by showing them why we are doing what we are doing and how it works. Example: Do you really need AV on a read only BSD based web server with no interactive consoles or tools such as SH/KSH/BASH etc?

The disillusioned ones will often find an obscure method of complying with the letter of the standard and will not accept any reasons for not complying with their view.

The enlightened ones will listen to what you have done, will ask you to demonstrate how it works and will then offer advice on how to improve it. A word of warning though, these auditors knows their beans and will spot the wool before you try and pull it over their eyes!

We know the requirements and we understand that we will be audited against what the auditor THINKS the intent of the requirement is and many IS managers think that puts them at a disadvantage? In my mind, this shouldn’t be an issue.  We as IS professionals “should” be able to out think the auditors, using the standard as a minimum “baseline” of our own security. Approaching the standard from this direction will allow us to use the audit more as a validation tool that a cause of stress.

Of course this does not mean you leave it to the last minute. That would be foolish. Have your auditor do a full audit at least 3 months prior to your audit date. It increases the cost and means you do the audit twice, but there will be no nasty surprises when you come to the actual audit. When your auditor finds deficiencies (and they will, that is what you are paying them for remember!) challenge them. Ask them how they have seen the issue rectified within similar verticals. If the audit cannot answer that challenge, then you have the wrong auditor!

This approach works regardless of what audit it you are having done. 3 months worth of leg work before the audit is always cheaper that any amount of remediation / stress / capex requests after a failed audit.

Should we Fear the Attacker?

Again some very interesting views were expressed, ranging from the belief that people never get attacked to the belief that people only get attacked if they make themselves a target. One of the more interesting views was that insider threats can not be quantified. I agree that this is the case, but I firmly believe that to attack a business successfully, it is easier done from the inside. One only has to look at the recent data losses over the past 12 months and it is quickly apparent that the majority of losses are from insider threats.

But this brings on the question of what is an attack? Is it simply someone doing something malicious or should be also include someone doing something stupid? I am certainly more worried and more fearful of someone doing something stupid. As a general rule, IS professionals will know when someone does something malicious but monitoring and tracking the something stupid category is virtually impossible.

My View on the Future of IS in 2010?

2010 in many ways is progressing the same as 2009, I am seeing more compliance and regulatory pressure with a general move away from the “something malicious”. Pressure is finally mounting to deal with the “something stupid”, and 2010 is going to become a year of awareness. As budgets decrease  IS professionals will be doing more with less. Dealing with the 80% of security, the human aspect, is harder but there are more easy wins that can be achieved with less budget. Shiny metal with flashing lights will take a hit as more IS professionals will turn to virtualization to run internal services for detective and preventative controls and a lot of time will be spent convincing the businesses that data and asset classification is very necessary, especially when looking to move services into the cloud computing model.

February 18th, 2010 by peter.bassill

Do you use Splunk for logging your PCI environments? A very powerful tool and free to boot (up to 500mb of indexed logs a day).

Following repreated requests from people for PCI splunks, here is a taster. I will also be releasing on Splunkbase, very soon, my own PCI App for Splunk.

So, to start, lets search our webserver logs for non obfuscated card numbers (where ever card data is written, it is prefixed with CCNum)

tag::host=”pci” source=”/var/log/httpd/log/*” CCNum | regex _raw=”\s+<CCNum>(?<CCNum>[0-9]{4}[0-9]{8}[0-9]{4}|[0-9]{4}[0-9]{11}[0-9]{4})”

Next we are looking in our PHP Error logs for CC data:

tag::host=”pci” sourcetype=”php-error” | regex _raw=”^(?:4[0-9]{12}(?:[0-9]{3})? | 5[1-5][0-9]{14}|6(?:011|5[0-9][0-9])[0-9]{12}|3[47][0-9]{13}|3(?:0[0-5]|[68][0-9])[0-9]{11}|(?:2131|1800|35\d{3})\d{11})$”

Now we look for denied file writes:

tag::host=”pci” source=”/var/log/messages” denied write | top path limit=”1000″

and then a couple of simple alterations to look for denied read and denied execute:

tag::host=”pci” source=”/var/log/messages” denied read | top path limit=”1000″

tag::host=”pci” source=”/var/log/messages” denied execute | top path limit=”1000″

now we look for failed login attempts

tag::host=”pci” source=”/var/log/secure” “authentication failure” | top user limit=”10″

and while we are looking at logins, we could do with knowing whenever someone fails a sudo attempt:

tag::host=”pci” sourcetype=”syslog” sudo “authentication fails”

Of course, you will need to adjust these with the sourcetype and the paths but you should always tag all your PCI hosts to make your life a little easier. More soon, check out the “Splunking” page!

Pete

February 4th, 2010 by peter.bassill

Required Disclaimer – All views expressed within this site are the views of the author only and are in no way representative of the employers of the author.

This post is really just a review post for my HR team.

More posts shortly.

January 21st, 2010 by peter.bassill

Andrew W Morse, Founder, Digital Tsunami “Communications Evolution” recently asked the question; “With the increased complexity of polymorphic malware and the increased use of social platforms, do you have concerns for increased network intrusion via ever-increasing corporate cloud computing?” on Linkedin. It gave a fair amount to think about so I thought I would share my opinions with you all.

What a great question, thank you for asking it. Ok, do you have more or less security by renting a 1U server from a server farm in a datacenter? Do you have more or less security when rather than rent that server from a server farm you physically house it in your datacenter? There are a number of players out there in the market that would have you beleive that a server in the “cloud” is vulnerable to attack but the truth is that any server with a connection to a public facing network is going to be attacked at some point in time.

From my point of view, the biggest security concern is one I am not hearing about much and that is the disk. Say you rent a cloud server with 100gig and you then use this for some data processing and once you have finished, you close down your server and remove it from the system. That disk is still there.

In my opinion, it would be possible to rent a single cloud server and get this up and running. Once done, add a few cloud disks to it and run standard forensics recovery tools over the disks you have provisioned from the pool. What are the odds of successfully recovering someone’s information? During my research on this, 80% of disks I provisions I successfully recovered a previsous tenants data from.

Still worried about network intrusion? Have your admins build and secure your cloud servers properly and maintain a good patching program alongside good security practises for access control.

Worried about a disk recovery attack? Encyrpt your data in the cloud and then carry out a DoD standard 7 pass wipe of your data areas prior to deprovisioning your server.

January 13th, 2010 by peter.bassill

Disclaimer: All views expressed in this posting are mine and mine alone and do not represent those of my employers.

I recently heard the excellent phrase “Fear the Auditor more than the Attacker” (check out the podcast as csoonline.com) and it led me to some thinking. Do we really fear the auditor more than the attacker?

In an age where regulation and compliance rule almost everything we do in Information Security, have we lost sight of what our job really is? Surely we are here to protect the brand and the image of the businesses we work for, ensuring the continual cycle of business without interruption. Listening to the podcast, there was a lot of things I agreed with and a fair amount I disagreed with.

Today, it was sited, we have reached a completely unacceptable and unsustainable level of cost and complexity which is driven mainly from the frequency of constant and turbulent change within environments. There are five main drivers for change;

• threat evolution in the attacker space
• compliance & regulatory markets
• technology changes
• economic changes
• business needs

What interested me here is the order in which the speaker listed the drivers for change were listed. While I agree with the drivers, many organisations would almost reverse the list to;

• compliance & regulatory markets
• economic changes
• threat evolution in the attacker space
• business needs
• technology changes

While I would see the list as

• threat evolution in the attacker space
• business needs
• economic changes
• technology changes
• compliance & regulatory markets

While I agree that in many organisations, the main stay for change should be to keep up with the threat evolution from the attacker space, more and more time and valuable budget is being spent on ensuring tick box compliance is maintained, observing that the level required is the minimum for compliance. Again, I see compliance as the foundation level for good security, not a ceiling. Compliance is something to be used as a baseline, something to be surpassed, exceeded.  Compliance and regulation is a party to supporting the need for change, but it is not the reason for change. Change should occur to make the business better, to re-enforce the businesses underlying operation and to ensure it remains safe.

Last year, it was suggested, Information Security had around 4% of the IT budget while now being more around 13%. This is something I would rather take with some more context. Is it that the budget for Information Security has indeed increased or is it (more likely) that the budget for Information Security has remained the same while the overall IT budget had decreased? More and more I am seeing businesses sweat thier assets more aggressivley, looking for ways to use what already exists in a more productive way rather than bringing in new technologies to achieve what could be done with assets already in place. It was suggested that this change in budgeting has led to a view of “if it is mandated I will spend it, if its not I wont”. This then leads to an abandonment of the more logical risk led approach and the adoption of bad risk management.

So who is watching the attackers? Within the PCI-DSS standard, there is a requirement for centralised log management and daily log reviews. Many organisations, quite rightly, use automated tools such as Splunk or RSA Envision to carry out these daily log review functions, but who is looking at the output? In the ideal world, a human but in the real world are these outputs there purely for the auditor? After all, the auditor is a known known, something we know how to handle. The attacker is the known unknown, we know we know very little about them and that makes it harder to secure budget for mitigation. Would you be able to get budget to fix something you know is going to happen and can prove it? Or do you work in an organisation so dynamic and leading in its security that it allows budget to fix something you know is going to happen on day but can not prove it will happen anytime soon?

The podcast gave me a lot of things to think about and two of the best quotes I have heard to date:

Fear the Auditor more than the Attacker!

Security is reactionary, what we are up against is dynamic!