Psychological Screening

The fallout from the recent spate of wikileaks revelations seems to have brought about a sharper focus on the role of the employee in an organisation, and the fact that there is a risk of data breech or theft by the individuals you employ. Two recent articles focus on the need for pre-screening, and ongoing monitoring of psychological issues. A seminar last year from an internal threat analyst at a large UK bank provided a fascinating insight into the factors that can result in an employee being tempted to steal information. Factors include personal financial problems, and so on. It also looks like the federal government are screening for psychological factors such as despondence and grumpiness. If these are actual detection points, then I think I need to install some monitoring software on my system to ensure that I don't steal anything...

The psychological factors are important, but only when allied with appropriate monitoring and controls. One example being the lack of architecture testing that can lead to individuals gaining access rights where none should exist. Proper testing and change control needs to be implemented, but when we consider the number of applications multiplied by the number of users multiplied by the number of permissions, factor in lack of proper monitoring and evaluation of actual permission needs, employees leaving and so on, then we start to get into real difficulty when it comes to this form of assurance.

Thunder Struck

Security experts have managed to DDoS systems with a $6 investment, and the use of their Thunder Clap program. I am surprised that it has taken somebody so long to do this in an official capacity.

I wonder when stolen credit card details will be used to create EC2 accounts, and do something far more devastating.

Continuous Monitoring and an 85% drop in Risk

This Article reminds me of the presentation I saw by Allen Paller at Infosec last year. Alan Paller is the director of Research at SANS. He presented a testimonial of his work within the State Department to congress. He highlighted the development and use of a continuous monitoring methodology, which has led to an 85% drop in measured risk. In part this was achieved by using a continuous monitoring approach which was an IT-driven system and replaced the existing paper-based reporting system. What made this approach effective was the usage of the metrics that were Comparative, Numeric, Reliable and Authoritative. At infosec Paller went into a little more detail about these aspects.

Comparative: Comparative monitoring needs to be something that can be used to show the relative quality between the effort undertaken by different teams. This creates a healthy climate of competition and motivation

Numeric: Existing FISMA standards dictate that the reporting systems should produce a risk report every few months or quarter. This is a terrific delay in terms of response time, and ability to gain instant situational awareness. One important factor in ensuring success was to automate the measurement of these controls. Without it, the overhead would have been a barrier to it being effective. The monitoring period was reduced to 72 hours thus having the effect of allowing a better response time, as well as illustrating gains being made.

Reliability: Based on repeatable tests, two or more evaluators would get the same results.

Authoritative: By getting a consensus from an acknowledged group of experts allows you to get buy-in from the very individuals who will be assessed by the measurements.

It is an interesting approach as it advocates a far more scientific methodology to monitoring . However, Paller also highlighted the fact that the human element needed to be considered as equally as important. Therefore, be fair when measuring metrics. If a team cannot change or effect something, it is not fair to measure it. Finally celebrate success and make progress visible.

MESP and EaaS

I've just watched a fascinating documentary about the Rolls Royce jet engine company. I had always thought of them as a Plain Old Engine Company. To my surprise and delight, it turns out that they're an EaaS and an MESP.

As part of their offering, they provide a service package with each engine. The Airline companies are guaranteed an engine, no matter what, and only pay for the miles they clock up. This is, rather wonderfully, Engine as a Service (EaaS).

In addition, each serviced engine has a near real-time monitoring system (approx 90 sec delay), which allows engineering staff located at a operations centre to follow and respond to any particular issues flagged by the monitoring system. Any reported problems are then dealt with by ground crews at the appropriate airport at which the plane will land. The data sent in to the operations centre is analysed, and deviations from the norm are flagged and followed up. This, of course, sounds exactly like the Managed Security Service Provider (MSSP) model that has expanded a great deal in recent years. However, this instance should probably be called a Managed Engine Service Provider (MESP).

What fascinates me about this model is the emphasis on an engineering approach from the testing, build and deployment of each engine component, right through to the assembly, commissioning, and even in-air monitoring of the system. I wonder how this impacts on the false positive metrics that the operation centre employees must deal with, and whether there is as large a problem as it is with an MSSP engineer monitoring the voluminous output from a computer system.

There's an old(ish) debate within the software engineering community that states there's not enough emphasis on the engineering side. Lack of engineering approaches has led to code defects, and therefore the abundance of security issues that need to be dealt with. Combine that with the fact that we look for security events in stupendous volumes of data that is highly unlikely to yield useful information, and is often not fit-for-purpose, then you've got a serious problem when trying to hunt down serious problems. Not all security problems are based on defects caused by lack of standards, but it would be interesting to see how a modern MSSP would look if we had an operating system equivalent of Rolls Royce.

Top 10 reasons your security sucks

There's a great post over at infosec-island, commenting on the cultural, procedural and technical problems that appear to be still present in infosec environments.

All of the reasons are pretty much spot-on, but the following stuck out from our technology perspective:

6. The tools you use are ineffective (they don’t really work) and inefficient (they cost way too much)

5. Your security vendor is lying to you and why shouldn’t they, you believe them

2. Your dealing with the exact same problems you dealt with a decade ago, only it seems so much worse today then back then

It seems to me that reasons 2, 5 and 6 are interlinked. After speaking with someone we know at a local data centre, as well as folks at a local MSSP, it's clear that the lack of innovation in this domain is stark to say the least. As Niladri highlights, all of the trade shows he's been to in the past, in his other life in other industries, have had some form of innovation. Information Security? Nope. Nada. Nothing. The path that most of these guys are on is BIGGER FASTER MORE of the same old stuff that's becoming increasingly obsolete.

Centre of Excellence Launch

We have been invited to speak at the Symposium on Security and Cybercrime, which will also see the launch of the Centre of Excellence for Security and Cybercrime. The purpose of the Centre is to bring together business, law enforcement and academia in order to educate, inform and disseminate best practice through knowledge transfer and other such placement activities. The Centre is an exciting prospect for Scotland, and we're very much looking forward to being part of it. We'll be talking about some of the threats facing the virtualisation technology being used to power to cloud.

The event is being held at Edinburgh Napier University's Craiglochart campus, and is free to register at:

http://www.coe-security-and-cybercrime.net/register.html

Cloud Insecurity

After a disappointing perspective on Cloud Security form InfoSec this year , where statements like "Cloud is Outsourcing Mach 2" were made, I saw a ray of light at the e-crime Cloud Security Forum. It was the first conference this year that seemed not to be influenced by the economic benefits of moving to the Cloud (fast!).

My Neighbour is a Hacker

The real dire consequences of not covering angles like multi tenancy and cloud cleansing where highlighted. If I knew that my next door neighbour was a serial killer I probably wont sleep at night. The same goes for the public Cloud , I share my resources with my neighbour , how many attack vectors does that open! How can I be sure that instance of VM that I created and then discarded was actually cleaned properly in the slack memory. Verizons answer to this is dedicated blades on demand , how scalable or easy to use will this be? we would have to wait and find out.

Logs? What Logs?

If you share resources with your neighbours surely you share logs too! how do we audit logs that have intermingled entries from you neighbour. Surely this affects data protection and privacy laws. This simple fact also affects every single SIM and SIEM tool out there. These tools already promise too much and deliver too little , this added handicap will make them totally inapplicable to the cloud as these tools primarily rely on logs.

Relying on logs to provide security and control never seemed right to me. Logs should only be for Operations and maintenance really. I am sure with enough duct tape we would still be able rely on logs for security , but do we really want to repeat mistakes for the Cloud?

IDS? What IDS?

Traditional NIDS cannot be applied in the cloud , hey you share the same connection! Network Virtualisation is something that is not considered by your Cloud Provider or is outright uneconomically . How can you apply IDS to shared traffic ? you cant ! The way forward is host based real time and distributed intrusion detection systems harnessing the power of the cloud. Why not?

Micheal Clark from Verizon stressed this point , the need for a HIDS and File integrity monitoring is far higher than Anti-Viruses when it comes to the Cloud.

Real Time

I really enjoyed Verizon's forensic perspective to the cloud infrastructure. The inadequacies of existing forensics techniques were demonstrated e.g. how do you image a cloud , is it economically viable? no its not, all the economic benefits of moving to the cloud will be negated if it needed to be done in a forensically sound manner. Moreover the cloud is dynamic , at one moment a server is there the next its gone! The only way to be forensically ready is to track the cloud in real time in all its dynamic glory.

The Super Super Users

One of the unsolvable corner cases of security has always been the super user how do you control the admin accounts? No simple way with existing tools really ! Internal fraud has always been the most expensive for companies and one of the hardest to control.

With cloud this problem will increase many folds as the super user will now be external. I call these users THE SUPER SUPER USERS employed by the Cloud Service Providers. They are like super heroes ( or villains) who can do anything( to the servers running your VM). Not only that but blame your neighbour for it and get away with it.

Security By Design

A major paradigm shift is required to deal with the Cloud Insecurity. This is our opportunity to have security by design and not by necessity . Stop reliance on logs and design other real time events that are designed with security in mind , agnostic of the platform . Let not design patchy-duct-taped-together-security this time round! can we? Please!!!