spacecadet2010
MIS
The timeline for hackers to take advantage of vulnerabilities is shrinking. As a System Engineer I am having to constantly fight the battle to get my systems patched. It is a struggle with application support and devlopers and my customers.
AD guys are afraid of the patch screwing with their application. Customers are scared silly about patches because the AD guys feed them with the same information he feeds you. What can you do? Rather than do what would normally come natural to an SE, patch the system anyways and reboot the system behind AD's back, we need to educate AD and Client. Here's some information you could give them and some things that I think would help.
Here is a list of vulnerabilites and the ammount of days it took to hack.
Nimda 331 days
SQL Slammer 180 days
Welchia/Nachi 151 days
Blaster 25 days
Sasser 14 days
***Zero Day Exploit*** our nightmare.
Application Developers truly need to understand that if we are to keep our systems secure we will need to have a plan of attack, not just on the system OS, but on the application support side. We need to go hand and hand, have a plan that both of us can agree to.
The time-line of a vulnerability
1. The Product shipped.
2. The Vulnerability discovered.
3. The Vulnerability disclosed.
4. Update is made available***
Most attacks occur 2-3 months after update is available.
5. Patch or update deployed.
Keep up to date on vulnerabilites.
Take the time to at the least visit these sites weekly if not daily. You can even be put on a mailing list that will notify you of vulnerabilities.
1. 2. 3. 4. Restrict local admin rights.
5. Don't browse web on server(duh)
6. Have 2 user accounts. 1- non-admin account. 2- admin account to be used only with "RUN-AS".
Some things you could do that would not require a patch update.
1. Implement a firewall. XP sp2 firewall on all clients machines. And if you are not using XP sp2(why aren't you???) then install client end-user firewall software.
2. Lock down servers.
3. Use Encryption on laptops just in case they get stolen without the encryption key.
4. When returning servers to lessor, Don't just format your drives, use a tool either from the hard drive vendor or, the one I use, Seagates Disk Wizard. This cool boot app allows you to write 0's all over the drive twice. Hacker proof!
5. Backup your servers and have a restore strategy. Monitor your backups and change your tapes.
6. UPDATE UPDATE UPDATE!
Now, if your a unix admin and your laughing your head off at us poor Windows saps because you 'think' your system is secure. You are sadly mistaken. You actually have more to worry about because most of your application patches can not be put in an easy package. So you have to keep an out for updates on EVERY system patch out there. Have fun.
Simply put, it's important to be secure, you don't want to be exposed. There's nothing we hate more than R.G.E's(Resume Generating Events).
I know there's a bunch more that can be added. This is just my short list, and believe me I have a long one. Maybe I'll publish that one later.
Please Feel free to add on, and keep your flames to yourself!
Space!
I have no problems, only challenges.
AD guys are afraid of the patch screwing with their application. Customers are scared silly about patches because the AD guys feed them with the same information he feeds you. What can you do? Rather than do what would normally come natural to an SE, patch the system anyways and reboot the system behind AD's back, we need to educate AD and Client. Here's some information you could give them and some things that I think would help.
Here is a list of vulnerabilites and the ammount of days it took to hack.
Nimda 331 days
SQL Slammer 180 days
Welchia/Nachi 151 days
Blaster 25 days
Sasser 14 days
***Zero Day Exploit*** our nightmare.
Application Developers truly need to understand that if we are to keep our systems secure we will need to have a plan of attack, not just on the system OS, but on the application support side. We need to go hand and hand, have a plan that both of us can agree to.
The time-line of a vulnerability
1. The Product shipped.
2. The Vulnerability discovered.
3. The Vulnerability disclosed.
4. Update is made available***
Most attacks occur 2-3 months after update is available.
5. Patch or update deployed.
Keep up to date on vulnerabilites.
Take the time to at the least visit these sites weekly if not daily. You can even be put on a mailing list that will notify you of vulnerabilities.
1. 2. 3. 4. Restrict local admin rights.
5. Don't browse web on server(duh)
6. Have 2 user accounts. 1- non-admin account. 2- admin account to be used only with "RUN-AS".
Some things you could do that would not require a patch update.
1. Implement a firewall. XP sp2 firewall on all clients machines. And if you are not using XP sp2(why aren't you???) then install client end-user firewall software.
2. Lock down servers.
3. Use Encryption on laptops just in case they get stolen without the encryption key.
4. When returning servers to lessor, Don't just format your drives, use a tool either from the hard drive vendor or, the one I use, Seagates Disk Wizard. This cool boot app allows you to write 0's all over the drive twice. Hacker proof!
5. Backup your servers and have a restore strategy. Monitor your backups and change your tapes.
6. UPDATE UPDATE UPDATE!
Now, if your a unix admin and your laughing your head off at us poor Windows saps because you 'think' your system is secure. You are sadly mistaken. You actually have more to worry about because most of your application patches can not be put in an easy package. So you have to keep an out for updates on EVERY system patch out there. Have fun.
Simply put, it's important to be secure, you don't want to be exposed. There's nothing we hate more than R.G.E's(Resume Generating Events).
I know there's a bunch more that can be added. This is just my short list, and believe me I have a long one. Maybe I'll publish that one later.
Please Feel free to add on, and keep your flames to yourself!
Space!
I have no problems, only challenges.