Printable View
Our group has been working on building a security policy and we are doing it in segments. This is one that I just finished. I am looking for some feedback and also feel free to use it should you like it.
This component is: Vulnerability Assessment.
Hope this helps someone :) !
It is a good start. As a general rule though, you should not share the details of your security policy as it is a very easy place for anybody else to determine where your weaknesses are... Here are some things to consider...
1) You should not actually try to use exploits on your business machines because it can crash them, and then you might open up a bigger bag of worms. Say for instance you want to check to see if a flaw exists that allows you to cause a system to reboot. You run this ona SQL server and the server crashes. That server crash then causes the database to not be shutdown properly, which leads to data corruption, and an extended outage. Or dataloss if you do not have a good backup procedure. Instead, a better check is to identify the file properties(time/date, file size, version, etc..) of the files that are known to fix the problem. Then you simply have the admin run a script to tell you if it has all the proper patches. There is software on the market that works in the fashion. Enterprise Security Manager by symantec is one of them(also known as axent).
2) Quarterly checks are not enough. We are required to run scans on our servers weekly. This is a lot of work, so it requires automation. However, I feel that automation is better at this task as it always runs the same, and gives the same type of results. It is to easy for the human eye to miss something if you are doing manual scans.
3) You should require that system administrators disclose what applications are running on their servers, why, version levels etc... Relying on scanning tools can lead to things being missed. Axent is good in this regard as it is a service that runs on the machine, so you can determine software versions better than if you are using a network scanner. Having all of this information in a central place is also good in cases of worms such as slammer. You can then determine which servers needs to be patched pretty quickly, and you have contact info assigned to servers. Of course, keep in mind that if this is a central database, and a hacker gets it, you just gave them the keys to your network. So it either needs to be highly secure, or not stored as digital content(ie., locked up in a filing cabinet)...
4) You need to specify how someone can get around the policy. Even though you want to say that security is concern #1, it is not, doing business, whatever that may be, is priority #1... So if for some reason your policy is going to negatively impact your business, you need to allow the policy to be circumvented. This should not be an easy process, but it needs to exist.
5) Your management needs to give the security manager some type of power. For example, they need to be able to suspend administrators if they don't follow the edicts set forward in your policy. Without this power, you policy is unenforcable. Your policy should lay out very clearly what administrative actions will be taken if the policies are not followed, and you need to make sure that management agrees to those actions, and that they are enforced. Otherwise you end up in situations where the security manager is telling people to do stuff, and his/her commands are not being followed because there is nothing the security manager can do about it.
6) Make sure that your policy, or your company in general has strict controls around changes, all changes. This is very important because it is all to common that a security person says you need to install fix A. The admin then runs right out, and installs Fix A, and then the application that runs on that system is no longer functioning. You are now no longer doing business, and your management thinks that all of this concern about security is negatively impacting your ability to do business. Good change controls consist, of testing, documentation, and communication. Search through my previous posts to see a good idea of how change control policy should be implemented.
mohaughn,
Thanks. This is exactly the kind of feedback that I wanted.
thehorse- I guess somebody didn't like my comments... It is a shame that some people are so spiteful that they have to carry something from one conversation over to another.
If you need for any other portions of your policy to be reviewed for commments you can PM it to me.
I don't think posting it here is too bad as it's totally anonymous and there is no way for anyone to find out what company he works for (unless he tells them of course). Also, I think you should run exploits but only after applying a patch. That way you know that the patch works and that it's installed properly (for example, there were a few MS patches that didn't solve the problem they were meant to address). Of course, backing up is a must if you're going to do anything that may damage the system.Quote:
As a general rule though, you should not share the details of your security policy as it is a very easy place for anybody else to determine where your weaknesses are... Here are some things to consider...
Cheers,
cgkanchi
If you really want to get serious about policy, and you want to save some time doing it, I cannot recommend highly enough the book Infomation Security Policies Made Easy Version 9 by Charles Crisson Wood. It's put out by NetIQ, but you can buy it off of Amazon.com, Borders, etc.
The $800 dollar price tag is quite steep, but you get over 1300 ISO 1799 compliant policies, all of them on CD as well. The price tag ensures you have a license to modify them as you wish, and all are on the CD in word and flat ASCII text. It also has a key word search engine on the cd to look for specific policy. I justified it to my boss by demonstrating that it didn't really have to save that much time (compared to my pay) before it payed for itself. Seriously worth every penny.
All true. On the exploit side I guess I was moreso thinking about not running code that could actually cause a system to crash. Running a program that tests for the vulnerability, however would be even more effective than what I described.Quote:
Originally posted here by cgkanchi
I don't think posting it here is too bad as it's totally anonymous and there is no way for anyone to find out what company he works for (unless he tells them of course). Also, I think you should run exploits but only after applying a patch. That way you know that the patch works and that it's installed properly (for example, there were a few MS patches that didn't solve the problem they were meant to address). Of course, backing up is a must if you're going to do anything that may damage the system.
Cheers,
cgkanchi
mohaughn,
I had no idea that you got nixed for your comments. I wanted all kinds of feedback on this sub section. I purposely sanitized the doc so that no one could figure out where it came from. The document is a draft at this point and far from approval. I agree with your comments on posting a doc that may expose you. I will post my sanitized versions just as I have here and I will PM you for your comments as I thought they were excellent. I did give you some greenies for the comments in case you didn't check.
Regards and thanks to everyone who gave me feedback.
I will post the next section when the draft is complete.
TheHorse13