I have been unsatisfied with some work-related issues for a long time. This weekend I have made some hard decisions and have approached the employer, giving them a last chance to do something about the most pressing issue.
Don't get me wrong, for the most part the company is a great place to work in and there are cool things there. Some important things just aren't right and if you can't change it for the better, you have to decide what you want to do in the future.
Now I've reached that milestone and waiting for the response. If they can fix it, I will be happy, but most probably they can't fix the issue and I have to begin looking for new work. Sucks, but maybe it is time to move forward.
December 21, 2008
December 10, 2008
December 6, 2008
Java updates and tongue-in-cheek maxims
I wish Java updates would have the default option to remove older installations of the same branch. This would remove the vulnerable versions from the host. For example "We recommend for security reasons that you remove old versions of this Java installation. If you depend on software which works only on specific version of the branch, click No to enter selection tab". In the selection tab you can select the version(s) you want to keep... Current update routines leave the vulnerable versions on your system.
I received a quite funny link from a co-worked last month. It is about maxims that are cynical and tongue-in-cheek written but still sound very accurate. Forewords:
"The following maxims are somewhat cynical and tongue-in-cheek. Nevertheless they say important things about physical security, and are essentially correct 80-90% of the time (unfortunately)."
Click here to read the maxims.
I received a quite funny link from a co-worked last month. It is about maxims that are cynical and tongue-in-cheek written but still sound very accurate. Forewords:
"The following maxims are somewhat cynical and tongue-in-cheek. Nevertheless they say important things about physical security, and are essentially correct 80-90% of the time (unfortunately)."
Click here to read the maxims.
December 4, 2008
Responding to...
Does anyone need to be their family and relative IT support?
I need to. Sometimes it is enjoyable, sometimes not. It is not very enjoyable in cases where you need to give instructions over the phone when you can't really *see* what the problem is. You need to try to remember what the menus are in a different language and you need to know where this-and-that is when you're currently using Linux instead of XP and so on. Most of your valuable free time go into waiting until the other end gets the "AHA!" moment when they finally find what you mean.
Luckily this IT support doesn't happen very often but last friday I got a neighbor with his computer at my house while I received a IT support phone call at the same time. I simply had to quit the call when I was so distracted by peeking into this computer. HEH, talk about timing!
If the topic would be security-related then I'd rather be there looking at the screen myself. For example my little sister was over a week without messenger and other online goodies when she spammed me with a MSN worm. That is the price to pay for "free support" ;)
In business environments it is different. If the company has multiple offices in the same city, it might work. If it has multiple offices in the same country, it gets difficult. If it has multiple offices in different regions, no way you're going to pull that off unless you have remote desktop capabilities or similar in use.
In companies that are located in different cities or countries most probably have some kind of IT support. They definitely know their way around the most arcane IT problems and also antivirus related problems. When it gets into security issues that are not solved by installing most recent antivirus definitions and security patches, things might get a little bit difficult.
If the support people notice that there is something wrong security-wise with the system, they should have a clear procedure to follow. Same is required for server administrators when they notice something out of order with their systems. Whether it is an unknown process, binary or network connection, it should be investigated.
Best way to handle this kind of situation is to have a incident response plan in place for the admins, here is an example. What I would like to add to this guide is a ready-made package which is run by the admin either remotely or locally on the system, using either removable media (USB stick) or a network share to store the information to. It should be such that it touches the system as little as possible as long as it retrieves all the necessary data. Such a package should be built for each platform used in the company.
For example Helix provides some statically linked binaries for Windows, Solaris and Linux. When I tested the Linux binaries I noticed that some of them did not work. This might be because of the used kernel version. I built some of the tools statically in a 2.6.x kernel enabled Linux and some these did work with older 2.6 kernels, even thought the distribution was not the same. Some, on the other hand, did not work on the older hosts. The situation was vice versa, older versions worked fine with the more recent version and this seemed to be because of GLIBC libraries.
Pay attention to your incident response packages and ensure these work for the systems that are used in your network. Also consider creating a script for collecting the relevant information, it will save time for the admin and you.
I need to. Sometimes it is enjoyable, sometimes not. It is not very enjoyable in cases where you need to give instructions over the phone when you can't really *see* what the problem is. You need to try to remember what the menus are in a different language and you need to know where this-and-that is when you're currently using Linux instead of XP and so on. Most of your valuable free time go into waiting until the other end gets the "AHA!" moment when they finally find what you mean.
Luckily this IT support doesn't happen very often but last friday I got a neighbor with his computer at my house while I received a IT support phone call at the same time. I simply had to quit the call when I was so distracted by peeking into this computer. HEH, talk about timing!
If the topic would be security-related then I'd rather be there looking at the screen myself. For example my little sister was over a week without messenger and other online goodies when she spammed me with a MSN worm. That is the price to pay for "free support" ;)
In business environments it is different. If the company has multiple offices in the same city, it might work. If it has multiple offices in the same country, it gets difficult. If it has multiple offices in different regions, no way you're going to pull that off unless you have remote desktop capabilities or similar in use.
In companies that are located in different cities or countries most probably have some kind of IT support. They definitely know their way around the most arcane IT problems and also antivirus related problems. When it gets into security issues that are not solved by installing most recent antivirus definitions and security patches, things might get a little bit difficult.
If the support people notice that there is something wrong security-wise with the system, they should have a clear procedure to follow. Same is required for server administrators when they notice something out of order with their systems. Whether it is an unknown process, binary or network connection, it should be investigated.
Best way to handle this kind of situation is to have a incident response plan in place for the admins, here is an example. What I would like to add to this guide is a ready-made package which is run by the admin either remotely or locally on the system, using either removable media (USB stick) or a network share to store the information to. It should be such that it touches the system as little as possible as long as it retrieves all the necessary data. Such a package should be built for each platform used in the company.
For example Helix provides some statically linked binaries for Windows, Solaris and Linux. When I tested the Linux binaries I noticed that some of them did not work. This might be because of the used kernel version. I built some of the tools statically in a 2.6.x kernel enabled Linux and some these did work with older 2.6 kernels, even thought the distribution was not the same. Some, on the other hand, did not work on the older hosts. The situation was vice versa, older versions worked fine with the more recent version and this seemed to be because of GLIBC libraries.
Pay attention to your incident response packages and ensure these work for the systems that are used in your network. Also consider creating a script for collecting the relevant information, it will save time for the admin and you.
Subscribe to:
Posts (Atom)