Finaly I got the blog set up. I just need to update Movable Type today and we gonna be up and running. Just as it's been said, the blog is gonna be mainly about security with some non-security-related stuff showing up from time to time.

As for the nearest future you can expect another section containing couple of my past projects to show up. Plus, of course, a lot of riffs on security. Stay tuned!

How often do you use checklists as a kind of a guide through a process of system hardening or risk assessment? As a matter of fact I could ask how often you use checklists for whatever purpose that needs making sure a lot of little places have been looked on.

I do almost all the time. Every time there is more then five things to take care of I prepare a checklist. It’s reusable and provided it’s good, you can relay on its completeness.

There’s only one “but” — checklists prevent you. They prevent you from missing things if they’re good, but they also prevent you from being creative and seeing things that are not on the list.

Conclusion? Checklists can make your life a lot easier, but they can also make it unnecessarily complicated if you don’t pay enough attention.

I happened to fly from Nottingham East Midlands airport lately and had an opportunity to see airport security in action. It's been shortly after British police discovered terrorist plans on attacking trans-Atlantic planes. The ban on taking anything but passport, ticket and absolutely necessary medicines on-board was no longer in force, but one still couldn't have a simple bottle of water on them when passing through a boarding gate.

The reason is pretty straightforward — the terrorists caught earlier were believed to plan on using liquid explosives, which they would have gotten on-board pretending to carry some perfectly legal at that time beverages.

One would have thought that the only reasonable way to react is to forbid carrying in any liquids on-board, which is exactly what's been done — until now one cannot pas through the boarding gate carrying a bottle of water.

Good, right?

To be honest, not really. It takes a really dumb suicide bomber to try the once discovered method of smuggling explosives on-board again. In fact in this situation every other method of blowing up a plane is better than the widely expected one. And this is a great example of situation when blind following a checklist doesn't pay off — one could probably get quite a lot of Semtex packed in some non-obvious places through, provided it's not bottle-shaped and not very liquid.

So, why do they do this? My bet is — for people to feel safe and taken care of or for airlines to lose as few customers as possible. Pick whichever explanation you like better.

The ideal situation would be if everybody were super-conscious about security, had knowledge about the latest threats discovered and knew how to avoid at least more popular security pitfalls. But the reality doesn't seem to look this way. In reality one can be happy if architects and developers are generally aware of such thing as security and bare in mind that they need to consult it in course of a design and development process.

There's a very simple cause to that — range of security issues out there is extremely wide and to be effective one has to go to very details and at the same time not loose any class of possible issues from sight. You simply can't expect this level of expertise and awareness from someone whose main goal and responsibility is to design functional solutions or develop a good code and deliver remarkable applications.

That's exactly why projects should be consulted with security people before anybody writes a single line of code. And that's also why written code should be security-assessed during a development process. To point people busy in providing functionality to places where they missed something vital from the security perspective.

It enables the business to decide how important the flaw is and if they wish to pay for it being fixed or are rather willing to accept the risk. Which in turn leads us straight to a profit. Well, at least to preventing losses, but still.

Asking questions is generally about getting answers, not pissing people off, isn’t it? If you think otherwise, just forget it, but if we agree on this it’s worth noting that sometimes to ask questions means more than to barely inform someone what you would like them to tell you and wait.

Usually it just doesn’t work like “fire and forget”. Why? Because people are busy with things of great importance and urgency (even if they just seem to be seating and picking their nose), with delivering results they’re being accounted for and probably with thousands of other better things to be occupied with than answering your endless lists of questions. So what can you do?

In most cases the trick is to convince your respondent to cooperate with you during the process of finding answers instead of flooding them with a list of 987987 detailed questions (half of which is relevant only if they answer positively some previous one) and expecting to get them answered.

Starting with a small list of general questions, which then can be detailed depending on received answers, seems to be quite a good idea. First of all it’s easier to get someone to answer a short list of questions for you (even if finally there’s gonna be like fifty of these short lists).

Also, what is kind of important too, you can avoid asking a lot of irrelevant questions and save a lot of your respondents’ time.

And yeah, it means you have to interact with your respondents, explain a lot and be patient. But, believe it or not, it pays off — it takes less time and, above all, pisses people off a little bit less.

I did say creativity and thinking out of the box is very important when assessing a risk. Turns out even creativity should have some limits.

Especially when we realize how many items already present in a “safe” part of an airport could be turned into a weapon by a creative convict.

Lately I came across a PENTAdrive PINCode+ device. Basically it's just a USB flash storage like any other pendrive, the only difference being a pin pad built into it. The idea is to have your data PIN-protected and inaccessible for anyone who gets your pendrive in their hands. The statement on a box says the device is probably the safest place for your data.

But is it really?

First of all, there's not even a word about the way data are secured. Judging from the guts of it, it could be able to perform encryption of some kind, but somehow I don't believe it actually encrypts anything. Why? Because marketers being marketers wouldn't have neglected to mention it on a box in reasonably big caps.

Anyways, even if it does encrypt data before storing them, there's no information what algorithm is used and above all one couldn't be sure it's implemented flawlessly and is reliable.

The other thing I spotted after ten minutes of testing is that device locks down after five unsuccessful PIN inputs... provided it's not disconnected from a USB port in between the attempts. When unplugged, the device forgets about all previous unsuccessful trials. So, to perform a brute force attack on the device, all one needs is to unplug it from the power supply (which in this case is a USB port) once every four PIN inputs. Using some simple device to automate the task one can brute force it really fast. Provided the device is able to test say four combinations a second, testing of all possible four-digit PINs takes less then an hour. It makes an average time needed to access the data less than half an hour. Not very safe, is it?

What is the worst, is the false impression of security. One can believe that their data are safe on this contraption, but they're not. It's not that easy to access the data for someone getting access to the device by accident and thus it's great to keep your shopping list there, but god forbid one puts any sensitive confidential data there.

The bottom line is — for important data, loss of which will cost you a lot of money, use proven and tested technology, always.

Imagine you've got a small team responsible for a project. Say like ten people. They're basically taking care of the whole project, meaning they design, develop and deploy the application and do the O/S, database and infrastructure administration. And here's the question: how do you exactly enforce segregation of duties in such environment?

When you can afford expanding a team or having some interdepartmental administration/infrastructure/deployment/etc. teams, that's great. But sometimes the environment is too isolated and you just can't do that. In such case insisting on having a separate Tape Librarian person in a team is quite extravagant, if not stupid. So what should you do? Reasonably figure out what roles' separation is really important and try to enforce it. You will at least have some better arguments for it than just a usual "because that's the way it's supposed to be".

Say you asked questions. And say you were smart enough to actually get some answers back. Perfect, right?

Not necessarily. Especially when you realize there are answers, sure, but not quite to what you thought you asked. Well, seams you didn't ask what you thought.

Remember the saying that there are no stupid questions? Got a bad news — there are. At least inappropriately asked if not stupid per se. Provided your respondent gets you wrong or has to ponder a lot to figure out what you actually meant (and face it, he won't spend a minute to solve your riddles), it means the question is not a very good one. In fact it fails to fulfill its very purpose — get you an answer.

What to do? Try to beta test your questions with your peers. Try to pick on some trickier details yourself. Try to think like your respondent. And finally, whenever it turns out something wasn't as clear as you thought — fix it.

And believe me, you would be really surprised how people can misunderstand the simplest and straightforward question.

I happen to live on a guarded estate for almost two months already and I've noticed one thing — guards try to be invisible to people who live there. In fact nobody checks if people walking into the buildings are actually entitled to do this. Provided they look and behave as legitimate residents or guests, everything is all right. Otherwise the security would reacts. At least I like to think that seeing someone running away with a TV they would do something.

This security approach works as an anomaly detector. Legitimate activity is not affected at all, but any suspicious or obviously malicious behavior raises an alarm.

So, whether you rob an apartment on a guarded estate or try to slip through an IPS or an IDS in a corporate network, what you need to do is to pretend to be a legitimate person (be it a resident or a user) for as long as you can. In other words, let yourself, your activities, traffic that you generate and whatnot blend into the background. It's as easy as that.

Oh, and kids, don't do this at home.

What do you think security is mostly about? Is it about feeling safe or actually being safe?

The answer is pretty straightforward and obvious, right? If so, why then so often it seams like what's really important is a warm and fuzzy feeling that everything is fine and everyone is properly taken care of and shouldn't worry about anything? It's the same thing with a bouncer in a bar as with a big-green-button-meaning-everything-is-super-fine automatic firewall — it's all about making your customer believe that paying you ensures their safety.

And hey, if something bad happens you can always say it's been unpredictable and consequently inevitable. If you manage to get them to believe you, your marketing guys probably deserve a raise, but it's not entirely impossible, history shows.

It's sad and may sound wrong, but people don't seam to care about how something really is, instead they tend to care about how they believe it is. That's why it's important to know what you're exactly expected to provide — security or just a warm and fuzzy feeling.