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.

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".

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.

Turns out there actually are people there thinking that security is about being safe and doesn't necessarily boil down to the on-board liquid ban.

Thanks to them people now neither actually are safe nor feel safe. Thank you U.S. government.

In case you were wandering, yes, I am being sarcastic.

Seth points out that being creative and actually thinking takes a lot more effort then blindly following a given set of rules. It's also easier to feel successful shouting at people who dare to have a bottle of water on them when going through a boarding gate... at least for certain type of people. It's no wonder then that usually people of this type just give up on thinking. And a result is pretty... disturbing.

How hard do you think it is to blow a plane apart with 3.3 ounces of liquid explosives of whatever kind? I'm willing to bet quite a lot that there's no difference between 3.3 ounces and 10 gallons, when we talk about such sensitive thing as a plane. It's just a matter of know-how.

So, the question is: why? Why does it make such a difference if it's less or more then 3.3 ounces? Surprise — it doesn't. So why? My guess is, to keep security staff paying attention. If there were no quantity limit, it automatically would be off the checklist. And if there is a limit, there is also a pretty good chance that security guys checking the exact capacity of a shaving creme can might pay some attention to it's actual content. Or at least the bad guys may be afraid of them doing so...

Tricky eh?

Think Internet Explorer. Still significantly more popular then other web browsers. Lets put aside its ifamous incompatibility with w3c standards and concentrate on its security. Or insecurity rather. A friend of mine got almost scammed lately by an online banking password harvesting trojan. Happened under IE and wouldn't happen under say Firefox or Opera... at least by now.

Unfortunately it's not very likely it has something to do with a more secure design or a better coding of the alternative browsers. The design of each browser gives a choice of virtually the same amount of potentially vulnerable places. Also the code is similarly big and complicated and thus bug prone. What is the difference then?

It seams like nothing more and nothing less, but the popularity.

Even if you had a perfectly exploitable flaw in say Firefox, it's times more profitable to find and exploit one in a lot more popular IE. So, just wait until the alternative web browsers gain more userbase and it's pretty likely we'll see the amount of attacks on them comparable to those aimed at IE.

The bottomline — the more popular something is, the more impact on security it can potentially have.

Usually it's pretty hard to appropriately protect a communication channel which uses couple of layers of really complicated software. Say we run an internet banking site through an ssl-ed http server. The client needs to have 1) a web browser of which there's couple quite popular ones and each of them once in a while turns out to be vulnerable to some kind of an attack, 2) an ssl library of which, again, there's couple of implementations and they already proved not being entirely bug free (not to mention the algorithm itself from time to time revealing its weaknesses) and finally 3) all this has to make use of an operating system of some kind and the most popular OSes tend to resemble a good Swiss cheese in terms of security.

There's of course a good deal of reason for all this to still be insecure. One of which being the amount of code which is not easy to be managed. And so on, and so on. But actually it doesn't matter what the reason is, the important thing is that we are not secure enough and we won't be in any near future (no, I don't think Vista is going to surprise us here — actually, judging from what it already shown, it's going to be even worse than it already is). So, instead of relying entirely on the one potentially unsafe channel it's better to use a totally independent additional channel to check and confirm the sanity of the primary one. Think SMS.

It's not totally impossible to take over the additional channel also, but it's difficult and expensive enough to render the whole thing totally not worth an effort. Of course it still relies on user awareness, but at least now there's something one can be pretty sure to be an accurate piece of information.

So, before typing out a money transfer confirmation code from an SMS received from your bank, please check if the account number in the SMS really matches the one you wanted your money to be sent to. You'll make scammers' lives harder and your money will be a wee bit more safe.

People are lazy, that's our nature. So, when constructing security procedures it's pretty well worth it to take this laziness into account and either enforce some rules by technical means or make the secure way the easiest. And frankly, it's better to organise it in the most convenient way, because it can turn out that the designer has seriously underestimated people's imagination and creativity in making life easier.

Example? Imagine there's an inconvenient and difficult procedure of getting a spare key card when you left one home by accident. Say involving talking to more then two people or filling-out some forms. Guess what will happen. My bet is no-one will care to follow the procedure and people will end up borrowing cards from each other or, behold, blocking self-closing door to some sensitive place, say with an extinguisher.

The thing is not about people doing something wrong on purpose and not giving a damn about security. It's all about convenience. There is always a limit of an effort someone is willing to make before trading security for convenience. The trick is to stay as far from this limit as possible when designing security solutions.

Just a quick thought — why exactly do we care about rules? Is it because we are so law-abiding, or maybe it's just about being afraid of the punishment? If you didn't know there's anything like traffic police, how often would you care not to speed?

So, how much do you think user cares about the security policy if they have no idea there's someone watching?

Conclusion? Inform your users about the security measures and auditing facilities implemented. It lets people realise they can actually get caught doing something illegal. Which in turn may sometimes make them think twice before trying to do it.

Been a while — if I said it's been a very busy end of the year, would you possibly believe that? Anyways, I'm here again, so stay tuned!

Imagine a fire alarm. How much would it take to trigger one in your building? Use an alarm button? Trick like three smoke sensors at a time? Make a small campfire of your own maybe?

Of course, in case of fire, all occupants need to leave the building. And they need to do this immediately. They will obviously crowd in tight staircases, halls and doorways. There is going to be really lots of them. Way to many to notice if everyone has their ID card on them. Not to mention, in a hurry it’s so easy to lose one.

To let people safely leave the building, all the doors need to get unlocked. No-one gets in, but everyone has to get out.

Doesn’t it sound ridiculously easy for a cleaning person to leave the building with the CEO’s laptop full of confidential data and just vanish once they’re out?

So, maybe it’s worth having a closer look at emergency situations that lower the physical security level? Worth not less, then the information that may be stolen when the emergency situation is abused.

Why is SOX your friend during an assessment? For the same reason as every established set of rules or requirements — it leaves as little space for interpretation as possible and gives an assessor a foundation on which they can rely. Of course, such a strict set of guidelines cuts both ways, just like every checklist. But what it can do for you is change your trouble gathering information into business owner’s trouble providing it.

It simply serves as an excellent excuse for insisting on being provided certain evidence of appropriate security controls being in place. And an evidence in this case really means evidence, meaning an admin going “It’s there man. For real. Got my word for that” is not enough no matter how much you happen to like him and believe his words. It’s official, everybody knows that and there is no place for discussion — either evidence is provided or the SOX gap is reported.

And it is in the best interest of a Business Owner to have as little SOX gaps as possible, obviously.

Maybe you noticed, maybe not, the site got defaced yesterday for couple of hours. Terrible, isn’t it? Actually, not very much.

The old boring index files had been replaced by a fancy-Turkish-something for a little while, that's all what happened. A rumour has it that especially the tune played by the replacement site was nice. By now you probably wonder what the hell happened. Guess what, turns out the Movable Type 3.33 has some minor (yet, as you can see sufficient) vulnerabilities, which served the very purpose of defacing the blog. And guess what, the version 3.34, where all these identified flaws are fixed, released Jan 17, didn't make it to the blog yet.

But. In case any harm was done to the data, I would have it back again from an off-site backup in no time. And now, the administrative interface is accessible only from trusted IPs — learn something every day, they say.

Lessons learned: 1) patching the software immediately after patches are released (following the change management procedure though) usually pays off; 2) having an off-site up-to-date backup of all sensitive information buys you peace of mind (for a fairly low price); 3) it's always good to separate administrative interface from the publicly available content — the lower level the separation is done on, the more bulletproof the solution is.

And as a bonus, some problems with user input sanitation in a contact form code (not part of MT) found.

It's not anything near a good idea to migrate any sensitive environment to Vista just now, that's for certain. Too much of the code has been rewritten to not introduce some very exciting vulnerabilities.

But it's pretty interesting to have a look at what's going on in there. And it seems there is at least couple of entirely new and revolutionary concepts in there. Well, maybe it's neither revolutionary nor new, but at least it's screwed up in a really refreshing and admirable way.

But to the point. There is two major flaws in Microsoft's design of the so called User Account Control (UAC) mechanism: 1) it, hell knows why, assumes that all setup executables need administrator privileges when being run and 2) there is no assumption that using an administrative account user does it deliberately and consciously.

While the first flaw is pretty straight forward and just defeats the whole purpose of using a restricted account, the second one is a little bit more sophisticated. Microsoft decided the well known model of securing high privileged accounts using a per task login mechanism (like sudo) is not good enough for Vista users and designed their own solution. Behold!

There are two possibilities: 1) if you don't have administrative privileges and for whatever reason you need to elevate them, you will be prompted for a password along with the information that the action is potentially dangerous (nothing special by now) or 2) if you do have the administrative privileges, you will just be prompted to confirm that you are aware of trouble that you may possibly run into when proceeding with whatever you were to do (cool, ehh?). Not that bad, as you expected?

Well, it's seriously worse than it may seem, because from a user perspective there is no difference, besides when they work as Administrator, they don't need to type in that wacky password every now and then. But they're equally prompted that the action may be potentially dangerous, etc. each time privileges are to be effectively elevated. So, from the average user's perspective what is the exact difference between administrative account and the normal one? Besides it's easier to work as Administrator not being prompted for the password all the time? Close to none?

It's even worse, because the information displayed when elevating privileges may become so annoying as to cause a serious temptation to turn the whole contraption off. And even if not, it will get into a habit to just automatically discard the message a moment it jumps out.

Conclusion? Putting in a lot of popups saying "Hey, what you gonna do may blow your system apart... or not. The only way to find out is to proceed. So. What do you say?" is not the best idea one can imagine. Because those who already know this, don't need this. And those, who don't know this, should not be using an administrative account. The way better idea is to, along with implementing the mechanism of per task privileges elevation (as it's been done), promote a policy of not using an administrative account for day-to-day activities.

It's all about user awareness of the concept of using privileges based on the "need to have" principle. One does not need effective administrative privileges to run minesweeper, so don't give it to them. Why not to entirely block the ability to login onto the administrative accounts interactively (as opposite to a per task login)? If it's any trouble to login interactively, people won't do it unless they realy need it.

Seems like it's all about the defaults and laziness...

Enforcing desired level of confidentiality of specific data takes preventing unauthorised people from tampering with the data. It boils down to separating sensitive assets from people who have not been granted access to them. The proper separation needs actions on both, assets and people.

The assets should be divided depending on their sensitivity (particularly confidentiality). And by divided I mean physically separated, so no-one with no proper clearance is allowed to access the location.

Equally important is to properly manage staff's access rights. Clearances should be given only to people properly screened before, so trustworthy enough (it's hard to put it less precise, I know) and only on the "need to know" or "need to have" basis.

And to complete the picture special emergency (fire, etc.) procedures for restricted zones should be developed, so that neither unauthorised people are able to access sensitive locations nor people evacuating from restricted areas are able to mix with them. It considerably improves both, access control and user accountability.

Pretty obvious, but... you know how it is.

What do you think about securing an inter-application communication channels with an SSL-like solution? Or any solution that takes crypto certificate management procedures to be introduced? Well, yes, I also think it’s great even in fairly complex environments, provided it’s done right. And unfortunately, usually it isn’t.

Why? Because doing it right costs money and a lot of it. The amount seriously depends on the size of the infrastructure and its architecture. It’s also not all the same if we maintain the CA ourselves or we buy each and every certificate from some external CA.

To be sure our communication channels are secured we need to properly manage our certificates' lifecycle — we need to generate them or buy when we need to set up a new secured link, we need to make sure private keys are stored securely and if we suspect their security might have been compromised, we need to revoke them from usage and regenerate new ones. And finally, once the expiration date comes, we need to renew them — the never-ending, or close, validity period should be considered insecure by its very nature.

Often it’s crucial that we manage to renew the certificate before its validity period finishes, else the so-very-important-business-process gets stuck and we’re sooo gonna get it. And that’s precisely why the expensive certificate and keys management procedures, underlying management software and staff that knows how to operate it are pretty useful to have.

Needless to say, the in-house CA adds a lot of trouble and effort to the already not that great situation. And since trouble and effort equals money, the best way to go is as usual up to the cost/benefit analysis. And, as usual, it may prove worthwhile to actually check if the links really need crypto protection, which in turn is up to the risk analysis.

And just for the record, passwords are so much worse of an option and so much more trouble that I decided to not even mention it… oh, damnit…

Always wanted to play an information security auditor? Here is your chance. For now all of it is in Polish, but guys promise that the competition will be held both in Polish and English. Hope they will come up with an English version of the site soon.

A short answer to WTFs: first there is an internet round, lasts five days and if you perform well enough in this stage (no idea what are the criteria, but hope we’ll find out soon), you go to Katowice and play the hard ball with the best.

Although it’s not entirely clear what the competition is actually about, it’s said that one needs to show agility in either web apps security or ISO/IEC 17799/27001 compliance (or both, of course).

Just letting you know — it may prove worthwhile to see what comes out of it…

How often do you happen to meet up via a phone? I did quite a lot of late — normal thing — you call a virtual conference room number, type in a preset password and start falling asleep while someone tries to bore you to death with their ramblings. This lasts like for ever… you switch your ears when receiver-induced pain starts getting unbearable… play whatever flash game is your favourite with one hand or type a short email to a friend putting a receiver between your had and your shoulder… yawn… try to not saw the wood and subconsciously scan the conversation trying to catch your name. Bored to death you occasionally mimic line-induced cracking sounds and ask other participants to repeat themselves and refuse to go any further before every word gets to you. Sounds familiar? Very likely, as this is what we do — we communicate.

But. When did the password to the phone conference room change last time? And how about a phone number? Is it by any chance a shared number that your whole team uses and to which everyone can dial in, provided they know the number and the never-changing password?

Riiiight. And how often does someone dial in mistakenly and it turns out they’re not at the conference they intended to, not at the right time, or not the same time zone? Imagine that, for a change, some serious matter is discussed, confidential maybe. Picture the situation when the discussion is so super-important that someone actually intends to eavesdrop on it. Would it be possible at your environment? How much of the effort would it take to get into such conference unnoticed? Wiretapping exec’s conference this way is not that easy and leaves trails, sure. But the key point here is that it’s usually not that difficult for an insider, as we would like it to be.

Of course, again, we trade the security for the convenience and usability here. Agreed that changing a password per conference might be a pain in the neck, but it’s good to at least know how this impacts security of the conference and be able to elevate security level whenever necessary.

It’s always your choice, but it’s best when it’s a good choice.

About two months ago FBI announced that they have charged or arrested three, as they like to call them, bot-herders. They are accused of being in control of botnets, infecting user PCs, sending spam, and issuing DDoS attacks. We’ll see what comes out of it and if they are found guilty or not, but what’s interesting about it, is how did the FBI get to them in the first place?

The traditional way of commandeering the botnet is to have all bots to connect to an IRC channel and to issue commands to this channel. The main idea behind it is that it allows all the bots to listen without a herder directly connecting to them. Also, the tricky part hear is that it’s nearly impossible to tell the master and the puppets apart, before the commands are issued (i.e. when bots are just reporting whatever they have to report).

On the other hand, when commands are being issued, it gets fairly clear who is the actual boss. It may take a lot of effort to reverse engineer the code of the bot, but it’s doable and one may finally work out which machine on the IRC channel is giving orders.

But. Knowing which user it is, does not necessarily give us much in terms of who the person really is. There is like a gazillion ideas about how to anonymise yourself in the net, especially when you control like a couple of thousands of hosts (or hundreds of thousands as it appears to be the case sometimes). You can bounce the communication back and forth, make it appear to originate from innocent hosts, when possible communicate using connectionless protocols spoofing IPs, making sure the communication goes through many different countries (hostile to each other preferably) and so on. Like you name it, the list goes on and on. And once you commandeer a botnet all of it is pretty easy to do.

And I didn’t even mention the easiest possible solution. Nearly free as in money and effort, wrapped in a nice shiny cellophane and home delivered — TOR (The Onion Routing).

The idea behind the TOR is to allow average users to maintain a reasonable level of anonymity when surfing the web and performing other privacy-sensitive operations on the net. Like, well, say ircing, as there are IRC networks trying to provide normal access for the torified clients.

OK, it may not give a military-grade privacy, but sure enough adds to anonymity and would make it harder to track a bot-herder down. So, something to think about — is it more likely that FBI have gone beyond anonymity improving solution like this, or maybe it’s that they’ve caught these guys, because they didn’t take care about enough anonymity when issuing commands to their botnets.

I guess we’ll find out soon enough.

Doesn’t DRM piss you off? Not being able to share the music you bought with your kids, parents or wife? Sure you may avoid DRM-ed content whenever you can, but sometimes you just can’t, simply because what you want isn’t available in a DRM-free flavour. How about not being able to make a backup copy of your legally-purchased music CD? Wanting your purchased music to be digestible to a portable jukebox of choice anyone? Be it mp3 player or whatever else…

Alright, I guess we agree it is annoying, especially in the way it is widely forced on us by major players of the industry. But, besides some moves in a good direction some time ago, Palm has a very nice solution for quite some time that they use to protect books they sell. It is a DRM, but lacks almost all the burdens of the rest of the breed. It works in a fairly simple way — when a customer buys a book, a unique file is generated for them, and them only, that has beforehand been wrapped in some crypto using buyer’s name and their credit card number, provided in order to purchase the book, as keying material. In other words, in order to read the obtained copy of the book one needs to know the purchaser’s name and their credit card number.

Neat, isn’t it? The benefits seem quite obvious — when the protected content is tied to user’s vital confidential information, by caring for the information to remain confidential they also protect the purchased content from getting out of the trusted hands. Literally, the access to the content is limited only to people to whom the customer feels comfortable entrusting their credit card number. It effectively limits co-readers of the copy to family and closest friends. Very fair by me.

When will it fail? Obviously, when the credit card expires, the customer doesn’t care anymore, so the protection period is up. But, is it really that bad? In average cases, when the purchase is made some years before the credit card expires, well… after those couple of years it’s not hot stuff anymore… so, well… I guess merchants can live with such a book leaking after those years.

The only thing a user could find themself concerned about is “exactly how safe are my billing details once used for the content locking?” And well… the answer is “hell knows”. In general, it’s perfectly possible to make the keying material (billing details in this case) so hard to be pulled out of the crypted content that with contemporary knowledge and computational power it is not even worth starting… But, how has this been done in case of Palm protected e-books remains a mystery. Nevertheless, the general idea is undoubtedly clever.

A URL, if it contains any non-ASCII characters, should always be presented to a user in an ACE (ASCII Compatible Encoding) form (looking something like this: xn--t-zfa.com) in sake of preventing any visual spoofing (a situation, when two different URLs happen to look so alike, using given font, that one might be mistaken for the other — for examples see Unicode Security Considerations).

It appears though, that certain Unicode-encoded diacritics, when appended to certain ASCII characters, still tend to escape this rule in the latest versions of some mainstream web browsers.

It was a great experience! Hope you all enjoyed it just as I did. While waiting for the slides and videos to show up officially on the SecureCON website, feel free to check out the slides to the presentation I gave on the first day.

See you on the next SecureCON!

You are not going to believe this! It appears that IE7 implements the IDN support and the Unicode to ASCII conversion following the spec (thanks to Michel Suignard for pointing this out). Yeah, I was surprised too. Apparently Firefox approaches the problem creatively and gets... well... over-secured (is that even a word?). How so?

Lately I've been asked to take a look at the latest (by then ;-) Hagin9 issue and to share my thoughts on a blog. Well, I thought why not — after all it may save you guys some cash or maybe get you running to the nearest newsstand. Literally running, because it took me some time to get into this. But hey, you still have like four days to the end of the month...

OK. Before we start, the important thing is that you shouldn't treat all this as me telling you what's worth reading and what's not — I think it really depends on what you are into. Instead try to think of it as of a short and unbiased *cough* *cough* glance between the covers. Honestly, I have no idea if it'll work for you or not. So, if you care, just give me a shout.

And, as a final note before we get to the meat — unfortunately, this short review concerns the Polish edition of the magazine, so it's best if you actually read Polish.

ISSA (Information Systems Security Association) is an international organisation that, among many others things, helps information security practitioners (probably very much like yourself) to learn, to share knowledge, to communicate with their peers and, above all, to expand their horizons. One of the events that facilitate all the above are monthly meetings that feature presentations, lectures, discussions, etc. As you can imagine, such meetings make up an excellent opportunity to broaden and deepen your knowledge and to meet up with other security people from your area.

And here comes a good news for all of you located near Wrocław area in Poland – we are going to have monthly ISSA Polska meetings in Wrocław very soon. All is just being buttoned up, so you can expect the exact news regarding a place and date any time now.

Be sure to come and bring all your IT-Sec friends with you! The more of us meets up, the more knowledge and experience there is to share. The meetings are going to be open for anyone, so stay tuned and see you there soon!

If you’re from Wroclaw or from nearby, be sure to show up at the first meeting of ISSA Polska held in Wroclaw. We’ll be talking about web application security, analysing case studies of vulnerable web applications and arguing which web application firewall is the best. Sounds like fun? Don’t miss the meeting!

When? Jan 9, 2008 at 6pm.

Where? At BZ WBK Wroclaw HQ, Rynek 9/11 (second door if you look from the pl. Solny direction).

An important note: you need to register for the meeting before Jan 6, 2008, 9pm at the latest. In order to register, please use the following link.

We did it again! About 30 people came to the second ISSA meeting in Wroclaw (thank you guys!), we had two talks and a really nice discussion afterwards. And this time we even had a full-blown catering! :) A big thanks goes to BZ WBK for hosting the meeting again and to ISSA Polska for sponsoring coffee and the snacks for the meeting.

It was really nice meeting all of you guys! Thanks a lot and hope to see you next month!

And for all of you who didn’t make it to the meeting, here are the slides.