You are looking for a job. I am looking for (the real) you.
by Wim Remes
Job interviews aren’t the core of my existense. If I’m going to be completely honest, I’d have to say I would love for someone else to conduct them instead. But, like most of the things I do, I want to do it to the best of my ability. It’s difficult. The best-case scenario is that we get locked in a room for 60 minutes. In that brief timeframe, I have to verify that your technical skills match the profile I’m looking for and that your personality is a good fit for our ‘culture’. In that same timeframe YOU need to assess whether this is the job you’re looking for and whether this is an environment you can thrive in. It is NOT easy !
First, let me set things straight. If we are sitting face to face, I have read your resume. You can call it laziness, but I’m already assuming that you KNOW what you have put on there. I may throw you some fish to assess your technical knowledge, but these rarely influence the image I have of you. Surprised? You shouldn’t be. There is no way I will be able to see if you have earned every single certification you mentioned on your resume by studying books or by experience. It may even be that I don’t have a clue what half of those TLAs mean. I’m sorry.
Then, where’s the beef? How can I really know whether you are the guy or gal I’m looking for ? Here are three questions I ask that give me a pretty good idea about you, the person I’m looking to have join the team. Because in the end it is all about you, as a person, adding value and allowing us to grow together.
What is the project or achievement you are most proud of?
On several occasions, I’ve thought about abandoning this question because you can’t imagine the number or people that just sit there with a blank stare on their face. I can’t eliminate it because your answer tells me so much about your passion for what you are doing or, even more, your passion for life. The catch is that, with this question, I don’t require you to answer with something work-related. Your work helping out at the local homeless shelter, your world trip after you graduated, or something you did at your kids school all fit the bill. However, if you can’t come up with even one thing you are proud of, things start to look grim. But you still have a chance.
If I went out to have a drink with two of your best friends, what would they tell me about you ?
Don’t answer this with, “Nick is a cool guy,” “Frank can drink 10 beers in an hour and still drive home,” or “I don’t have friends.” I want you to tell me how you think other people perceive you, as a person. Again, I frequently get lots of blank stares when I ask this question. The catch is that your answer tells me whether you are well-grounded and that you have a good perception of your strong and weak points and are not afraid to name them.
What do you do in your free time ?
This isn’t a question I always ask, but it does come up – and most often in interviews that are information security-related. Let me be clear: I don’t ask you to work evenings or weekends, and I don’t want your availability on a 24/7 on-call basis. Rather, I want you to spend time with your family and friends to recharge the batteries for when you come to work. So why this question? In my humble opinion you can only do this job with passion. The field of information security is so wide and so deep that there is very little chance that the paycheck will be enough to keep you motivated to stay on top of it. I want you to be 100% in love with what you are doing.
After those 60 minutes and these three questions, I will have a pretty good view of who you are and what you stand for. For your part, I do expect you to ask questions about me, our projects, and the company. I want you to engage in the conversation rather than just answer my questions. That also gives me a lot of information.
Then again, I read somewhere that the best decisions are made in the first few seconds. I might just as well have hired you after we shook hands and went to get our coffee 60 minutes ago.
R-e-s-p-e-c-t, what does that mean to you ?
by Wim Reimes
I often wonder whether it is me or ‘them’. It’s been too long that I’ve given ‘them’ the benefit of the doubt and, unfortunately, the day has come to fulminate against those who voluntarily or unknowingly abuse language.
Language, whichever is your mother tongue, is a gift. It has been created, improved, and nourished to enable human beings to communicate with each other. To make clear what cannot otherwise be understood, to transmit a message that cannot otherwise be transmitted.
It’s a given that English is not my primary language; in fact, it’s not even my second. This doesn’t hold me back, whenever I’m using it, to use it to the best of my ability. Yes, I might be somewhat of a perfectionist, but the main reason is that I have the utmost respect for the person who chooses to spend some of her valuable time to sit down and read my musings, much less listen to them. And that, my friends, is the crux of this message.
I admit that IT people usually don’t have a strong affinity for communication, but in my (extremely) humble opinion, the use of language is what sets apart the “better” from the “good”. Any poorly written offer, documentation, web page, customer testimonial, or e-mail shows your lack of interest in the person who will have to read it. It sends cold shivers down my spine.
Some tips to make your writing better:
The power of the written word is limitless. It can backfire just as hard …
(credit for the picture to Kriss Szkurlatowski.)
Two Dwarves Were Walking Through the Woods …
by Wim Remes
Once upon a time in the land of milk and honey, Jack and Charles, 2 hard-working dwarves, were strolling through the magic forest. They had been walking for a while now and they were getting tired, but Mike, their boss, had instructed them to bring home 10 stones and they had only found six. Jack, being the senior dwarf, carried the backpack with the stones and regularly sent Charles between the trees to retrieve a stone. Charles would diligently comply, and when he actually found a stone, he would put it in the backpack, quickly going back to searching for more stones.
What looked like an easy task turned out to be quite difficult: There’s more wood in a forest than there are stones, you know.
Jack was sweating heavily, his legs hurt, and he was slowing down. Charles, however, looked like he hadn’t done anything yet. He was dancing through the forest, quickly running left and right to look for stones. “Hey Jack, should I carry the backpack now?” he asked. “No, keep searching, it’s about time you found some stones” Jack replied. He was not amused with the situation, feeling the skin on his shoulders being ripped to tiny pieces.
As the sun was falling toward the horizon, Jack and Charles reached a river. Charles quickly picked up four stones and put them in the backpack. Jack was happy, and so was Charles. “Hey Charles,” Jack said “do you see that apple tree across the river?” Charles saw the shiny, juicy apples and he suddenly felt how hungry he actually was.
As Jack and Charles crossed the river together, Jack sank to the bottom and drowned. Charles didn’t look back and moved on to stuff himself with tasty apples. On his way back across the river, he slid the backpack off of Jacks already chilly shoulders. He walked home and delivered the stones to Mike who, of course, was very happy. He awarded Charles with an extra portion of porridge and Jack, well, nobody ever remembered who Jack really was.
Jack is a dead man! Why? Because he refused to share his knowledge (the stones) with Charles. He thought it was alright to boss Charles around, instructing him in exactly what to do. He also got angry at Charles because he thought Charles was better off. After all, it’s not as though Jack had to carry that backpack. Charles wanted to because he felt it was his responsibility, which it wasn’t. As the senior dwarf, it was his responsibility to get the both of them home safely, with 10 stones.
Do you ever behave like Jack ? What gets you, your team and your company forward is the fact that you are open to share experience, ideas and knowledge. Refusing to do that might have you end up on the bottom of a cold river. Rest assured that your seat will not be empty for long.
A case for compliance
by Wim Remes
This blogpost was triggered by something I experienced on the job, and a follow-up discussion I had with a few people. It even became more relevant as I discussed it with more people.
As Security professionals we tend not to believe in compliance. The reason is simple : compliance usually ends up with asking users to tick boxes periodically to stay compliant. Preferably at as low a cost as possible with the least of impact on the business.
Today, I think differently.
First off, you must realize that I don’t live in the United States. I’m European, Belgian if you want to narrow it down even further. The companies I deal with occasionally touch on PCI, and in rare cases SOX. For the majority of companies however, compliance is a choice (ISO, COBIT, SAS-70 and the like). In general there are two things we have to keep in mind and those are our national privacy law – protecting Personal Identifiable Information (PII) – and a collective labor agreement (which is largely based on the aforementioned law) protecting employee privacy. For banking and insurance companies there are additional regulations (largely based on BASEL II). Healthcare largely relies on the privacy law. To many that may sound like a good thing, until you come across a situation where you realize that regulatory requirements would help you to gain a higher level of security. Read on …
As we were reviewing an application that is used to handle PII, we saw some amazing stuff. A user needs to fill in a username and password and then has to select a few parameters for his connection before actually logging in. The parameters indicate where he is working (the site), for which department he will be working, and in what role. Much to our astonishment, the choice of parameters is limited solely based on the username entered (authentication happens at a later stage). Additionally, this application keeps a user cache and a workstation cache (in a database) that ensures that a user doesn’t have to fill in everything the next time he opens the application. Without getting too technical, it was possible to log in with a user using roles and responsibilities that wouldn’t be available under normal circumstances. As we were talking this through, it became clear that the vendor of the application didn’t care about this problem. The reason was obvious – there was no way that we could make him own the problem. It wasn’t his problem.
I’m clearly staying vague about the details of the situation, but in my humble opinion this is a situation where regulatory compliance requirements clearly would have helped a great deal. It would have forced this vendor to take security into consideration in his development lifecycle, and it would probably have even prevented this application from being released as it was. In such cases, compliance actually becomes an enabler for security. Because there are no regulations, the only thing a vendor has to worry about is keeping his cost as low as possible. Any investment in security lowers his margin. At that level, the choices the vendor made are understandable.
As an organisation, I believe you do your utmost to protect the information that is invaluable for you and your customers. As a consultant I do my best to provide top quality services to secure that information. I am convinced that most hardware and software vendors sincerely want to help us with quality products to achieve our goals. When it comes to rules and regulations, I now believe they can keep the “cowboys” in check. And that alone is a major achievement.
Stay Interested, Stay Alert
by Wim Remes
In tough economic times and on a low budget, it might prove difficult to keep your team on track. We all know IT people are a weird species; more than others constantly on the lookout for new and exciting things and staying on top (or in front) of the wave.
I’ve learned that getting your hands one bleeding edge technology is one thing, but really adding value to the business is something else. Instead of waiting for those new projects, this is the time to “squeeze the lemon” and take a look at what we can achieve with what is already in our hands. You might be amazed by the extra juice you can get out of it.
Preparing for tomorrow started yesterday, and it’s our responsibility to challenge our teams to make that extra effort. Here are three things you can do without huge initial investments.
Logging (+ analysis and reporting)
Every part of your infrastructure generates tons of interesting messages, but unfortunately this information is often forgotten. Start with the obvious ones like firewalls, wireless controllers, critical servers, core switches and routers. Gather whatever you can get in one place and start looking at it. Doing so allows you to identify what is important for your situation and what’s not. From there you can go on to define metrics and start reporting on them. This doesn’t require big SIEM implementations; you can start with a basic syslog server. The most interesting approach for me is to chop the infrastructure into small chunks and take them on one by one. You will grow into it and you’ll see that your infrastructure is trying to tell you stuff you never expected. To make analysis easier, I’d suggest you visit www.secviz.org; they have great tools and information on visualizing information.
Data classification
This is not a simple feat, and be aware that you will not be able to do this with IT people alone. The stuff you learn within your own department will allow you to steer the rest of the company in later iterations of the project. First look at what information is scattered over the network. You’ll be amazed with what you find. That desktop installation procedure from back in ‘99, containing the admin password ? Yes, that password that is still in use on your main router. First eliminate outdated information, then define ownership. Thus you are effectively aligning your information with the new processes and functions in your department. The owner of the information can then continue to define access requirements and how and when to backup the information. You’re catching the drift. This can bring major benefits to your department and your employer.
Access Management
Obviously, you’re not taking on a full-blown Identity and Access Management project but there is a lot you can do in this area. Go out to discover dead accounts, orphaned objects, historic access permissions, etc. Make an inventory of what you have and see if it still covers the bases. Get rid of excess groups and other objects. This also goes for login scripts and for those of you using Active Directory and group policies. Tackling these issues improves the control you have over your environment, preparing you for efficiently handling future projects.
There’s a lot more you can do. The underlying message is probably that there’s much more you can do with what you already have. Listening to the whispers and giving the screws that additional turn improve control over and knowledge about your environment, making it a ship that you can maneuver more easily.
How visual is your userbase ?
by Wim Remes
As I was rolling out a limited pilot group of users in an average-size Single Sign-On (SSO) project something struck me.
For these 10 users, we stood by their side while the application was installed and every user suffered from the same phenomenon, albeit one more than the other. Imagine this scenario :
1. User A is working in application B, she has logged on, there is no password save mechanism. She actually types in her password every day, maybe even several times per day (this is why we’re doing SSO after all).
2. The SSO software is installed. The computer restarts.
3. User A logs on to the computer and starts application B. When the logon screen is detected, an SSO dialog box pops up that requests her to enter the credentials for application B.
What happens ?
Normally this user would enter her password and go on with her day, but that wasn’t what we saw. Some users hesitated for a few seconds, others dug up a paper with passwords from their drawer, some asked their colleagues and some really had to call the service desk for a password reset. Each and every one of the users had to guess their user names two or more times !
It didn’t only show us what was wrong with the password policy …
At that particular moment, I was flabbergasted. How could it be that a change in the interface would blank out the memory of almost every user? Obviously, these users don’t just remember username/password combinations; subconciously, they must make a link between graphical elements of an interface and those credentials. When these graphical elements drastically change, the connection is lost and the related information is orphaned.
In the past few days I’ve given this a lot of thought. Obviously, this is behaviour we have seen from another angle before. Phishing e-mails contain graphical elements familiar to the user to invoke trust; rogue websites mimic the graphical layout of their real counterparts to do the same. Heck, Lotus Notes came with a changing on-screen visual when entering the password to counter shoulder-surfing. Interfaces, apart from being a layer to make boring information look pretty, are important parts of the security design of an application. It’s something I’ll take with me.
In the least it has proven again that, whatever size the project, you should always try to be as close to the end-user as possible and see how they react or how your solution changes their secure behaviour in a positive or negative way. You can learn as much from them as they can learn from you.
I will look into this behaviour further as the project continues and report back if there is more information.
Engage with Michael
-
Journey Into the Breach
