I was invited along to SC Media's roundtable on The Threat Landscape last week and they have written an article on it. I was also interviewed and appear in their video summary. The article and video can be found here:  https://www.scmagazineuk.com/roundtable-the-threat-landscape/article/635652/

Well, okay, it won't actually tell you whether they are secure or not and there are other questions you could ask, but the point is you can tell a lot about a company's security by how they answer security questions. I was recently at a security round table and the conversation turned to third parties and how you can assure yourself of their security. Some advocated scoring companies or certifications, while others advocated sending questionnaires. The argument against questionnaires is that they are a point in time view of the organisation. However, you can ask process and policy based questions and you can tell a lot from how they answer. So, what is the question that will reveal all? Well, as I said it's not one question as such, more a type of question. It should be about something basic, some security control you're sure they have because everyone does. For example: Why do you have a firewall? Probable answers: "because everyone has one"/"bec...

I have recently been speaking to many security professionals and asking them about black box and white box testing. I have used it as an interview question on many occasions as well. People's answers are varied and interesting, but I thought I would share my views briefly here. Firstly, what are black box testing and white box testing, or grey box testing for that matter? Simply put, a black box test is one where the tester has no knowledge of the internal structure or workings of the system and will usually test with security protections in place. They may not even be given credentials to a system that requires authentication. This would be equivalent to what a hacker would have access to. The opposite extreme is a white box test, where the tester has full knowledge of the system and access to the code, system settings and credentials for every role, including the administrator. The tester will likely be testing from inside the security perimeter. Grey box testi...

I presented on a panel today at the European Information Security Summit 2015, entitled 'Should you launch an internal cyber attack?' We only had 45 minutes and I thought I'd share some of my thoughts, and what I didn't get to say, here. Firstly, as we all know, the concept of a network perimeter is outdated and there is a real blurring of whether devices should be considered internal or external these days. It's not just about BYOD , but most organisations provide laptops for their employees. These laptops get connected at home, airports, hotels, etc. Any number of things could have happened to them during that time, so when they are reconnected to the network, they may have been compromised. For this reason, it should be every system for itself, to a certain extent, in the network, i.e. assume that the internal machines are compromised and try to provide reasonable levels of security anyway. Secondly, the user is the weakest link. It has been said many times t...

I was asked to provide details of the 'Penetration Testing Phase' for a particular project by someone who was putting together a Test Approach Document today. The categories I was asked to fill in were: Objective of the phase Responsibility & Authority Dependencies, risks & assumptions Entry & Exit criteria When discussing what they really wanted it became clear that they didn't know what a penetration test was or why we do them. The questions and document were set up expecting a deliverable from the pentest itself. The report was being treated as the deliverable without any thought of why a report was being produced or how it will be used. It was a tick in the box - "We require a pentest to be able to go live, so if we've had the report we can tick that box and move on." Pentesting is not an end in itself. Pentesting is a standard, finite snapshot of the security of a system, which, if taken in isolation as a goal, is fairly useless. Pent...

Security teams often attract antagonism from the business that they are supposed to serve, appearing as self-appointed policemen in a police state. This is unhelpful and not what we are or should be aiming for. Security departments should be providing a secure environment in which business users are free to do what they want. Obviously this environment will have boundaries, but they must be agreed with the business and not just imposed arbitrarily. Take an example from children's play areas, children should be safe within the confines of the soft play area and not too much harm will come to them. They can run around and play whatever game they like as long as they stay within the boundaries. Children can't wear shoes in a soft play area as they may hurt another child, but this doesn't stop them from doing what they want as the play area has been engineered so that they don't need shoes to stop them from hurting their feet or getting wet and dirty. The same principle...

When will people learn that compliance does NOT equal security? I blogged about this back in September 2009. Recently Global Payments has suffered a breach despite being PCI-DSS compliant (article from The Register ) Security standards, and being assessed against them, are like getting a driving license. Passing your driving test means that you have achieved a minimum standard of driving, but it doesn't mean that you are a good driver or that you will never have an accident. The same is true of compliance to a particular standard - it doesn't mean that you can be any less vigilant about security or that you will never be compromised, it just means that you have met an agreed minimum level. People forget that the PCI-DSS is only concerned about payment card data and won't necessarily look at all systems and processes. It is perfectly possible that a system is legitimately considered out of scope, but that the compromise that system allows a platform to attack a system t...