Questions regarding restructuring IT Dept. for room for InfoSec group.

My company has decided to add two people within our IT dept. to head a security department. Our duties will be to provide checks and balances between groups within the company and be an impartial "auditor" of security actions that arise (employess visiting bad sites, reading each others emails, violating confidentiality agreements). Another dutie that we will uphold is ensuring the security of our web clusters that take customers orders and hold customer information. Lastly we will uphold the responsibility of ensuring MS vulnerabilities are patched and assess new hotfixes and patches offered by MS. Our infrastructure currently consists of two DHCP controllers running win 2k server. We have just migrated to AD and are days away from phasing our exch. 5.5 and being 100% exch. 2000. We have a GNATBox Firewall made by GTA in front and behind our two Data T1's. We have also recently implimented MS ISA server (waiting to be impressed with ISA) that maintains internet security for all end users.
Currently we know that there are many cracks in our armor, and it will be our job to idenitfy those cracks and patch them up. We know that we also have an issue with Packets that contain customer information being easily picked up within the internal network.
I have read the FAQ's and they seem to best serve someone on an individual basis. The items that I am looking for advice on contrast greatly.
1. Is there anyone out there that knows of Guidelines for creating an InfoSec department within an IT dept. within a corporate company. These will obviously be custom policy guidelines, but a template that another company uses will get us off to a good start.
2. What are some nice tools out there to analyze protocol layers and packets. We need an app (preferably for purchase) that will allow us to capture packets. One thing that we will need in case we run into resistance in creating this group (Long Story. Battle of Director of IT to keep as many techs under him as possible to maintain his current income level) is actual packet data to show the upper management that there is a data security concern.

I am actually a Telecom Analyst with a degree in Computer Systems/Networking Technology. The other technician that will be heading this group with me is a Sr. Network Engineer. Some of these questions may seem elementary to many of you and some may not have enough age or experience in the corporate world to know the how delicate this chance is. Any help will be greatly appreciated.

In my corporate environment I use ethtereal for packet sniffing, and started with ISO17799 (BS7799 in UK) as the starting point for considering what Security Policies I wanted to initially define. I would look around in the SANS Reading Room and at some of the NIST documents.

The first thing that sticks out in this post is:

Quote:

---

Battle of Director of IT to keep as many techs under him as possible to maintain his current income level

---

Without high-level corporate support, the success of this endeavor is already in jeopardy.

As for looking for good information on Security (structure, policies, etc.) I have always thought SANS was pretty good.

Good Luck

Cheers:

We currently have the support of the individual that owns the company.
SANS I will check on.

Why can't the security dept. work under the IT director, after all he is the IT director? SANS was already metioned as a great resource. In fact they have many canned policy templates. Another resource I used when this whole industry was gettting started is "Information Security Policies Made Easy" It was a pre-year2k book that I bought when there was not much info on the subject available. It was expesive because you bought copywrite to use anything in the book within your organization. Meaning you could publish and reproduce anything you wanted.

One major step I would suggest first is to define operational and security resonsibilities and guidlines. For instance, security administrators should not have access to operational systems and operations administrators should not have access to security systems... etc.

Meaning a security person shall not have to ability to create, delete or perform transactions on operational systems and vice versa.

Then break both major areas into smaller funtional groups and set policies based on them, to do that effectivly you must have "in hand" a detailed and accurate organizational chart to structure your policies. Gotta run, hope that helps muddy things a bit :)

Because the IT directors job is to keep the rest of the company happy with the computer systems regaurdless of securit. Head of network security needs to be on par with director of IT so that the director cannot over rule security decisions. Remember most CIO and CTO's come from programming and not network admin/network security backgrounds and see security as a annoyance that is somewhat nesicary insted of a nesesity of life, they come from a time when computers where not connected 24/7 to the net.

I would also sugest SANS as a great resource, I will talk to the head of my security department tomarrow.

I appreciate all opinions and advice. Obviously I should not have stated the issue with the Director. This guy is in the process of being stripped down and phased out by the owners because of many inter-company issues that need not be discussed here.

We have our responsiblities broken down into.
1. operations and support of distributions systems.
2. operations and support of order processing systems.
3. operations and support of administration
4. operations and support of data infrastructure systems.

We also have a development team that is a completely seperate entity although they are in house.

I can't say that we are that worried about the trust relationships between the groups. This is in place. We are more worried about the way that many servers and workstations and security impliments are configured.

Quote:

---

Because the IT directors job is to keep the rest of the company happy with the computer systems regaurdless of securit.

---

If that is the case in a company, I would agree and formulate a different entity. But that may cause more problems in the future because of power stuggles etc. If an IT director can't get the funds to secure a new service he shouldn't approve it. After all it's his ass on the line, not the telecommuter's or whomever. I lose some battles but they know they are in for a fight when they want something.... but they also knoe I am fair and have the company interest in mind. :D Call me "company man" (pre-happy hour humor)

Fellow AO subscribers..............please forgive my stupidity, if such, but I feel that we are being dragged into a corporate political battle?...this is NOT about best practice (AO's principles), but "who is in charge", with the motor, expense account etc.......................there are loads of very expensive consultants out there....hire them....................WE SHOULD NOT GET INVOLVED

I agree with you on that one road closed. That is on of the biggest reasons for addressing internal security issues at hand because many products have been bought and implimented without being documented or made secure. This seems to be a problem in many companies that grow fast. Always time to buy and impliment, but not time to secure and harden.

OK washing my hands of company politics....

It's good that you and this team are taking steps to work out your problems. That effect you described is inherent in any company that grows quickly. Even within companies new frontiers are launched that have the same effect. Keeps ya on yer toes.

It's not my intent to discuss corporate hiearchy or politcs.......

I have reviewed the guideline templates on SANS.org. This is the type of information we are looking for and I thank those of you so far that have helped me along today.

Fraggin.......I have been fired several times......being right.......does not make you "right" in their eyes................if there is a problem...look at what the payoff for you is...you have you & yours to look after.....DO NOT TRUST ANYTHING FROM HUMAN RESOURCES.....they are scum................been there!

Good Luck

To answer your first question, you may find helpful a white paper by Cisco on
best security practices at http://www.cisco.com/en/US/tech/tk86...8014f945.shtml

and for your second question, Network associates SnifferPro is the best protocol analyzer (IMHO) out there..Snifferpro is the GUI version of the old and well know Network general Sniffer..

Good Luck

Thanks for the link Gunit. I think that it is excellent that Cisco felt the obligation to host that document. That certainly helps analyze the risk factors of our hardware infrastructure. I've used Network Assoicates only for hosting DNS, I was not aware of their sniffer. I'll have to check that our (considering we are thinking about the same Network Associates.)

And Nihil,
I hate to hear that you have been fired several times, but on the same token, I guess you live and learn eh? I've been canned a couple of times myself in the early days of getting my career started. I know the perils of HR. Some HR depts. may as well be called the "get along dept." Some HR reps take the easiest route in solving a problem and generally hate to go against the grain. I know what you are saying there. However, this Idea has been approved and is being reviewed above these ranks (for confidential reasons within and outside the co.) so I should not have too much to worry about there. But once again, I hate to litter this post with CORPORATE POLITICS, so I'll try to tone it down from here on out. Thanks for the heads up guys.

Not that I'm apt to follow up my own replys. (Such would be a direct indication of Pshcitzophrenia I would assume) However, I have found a site that list the top 50 security tools by user votes. The page can be found at http://www.insecure.org/tools2000.html

The major sugestion I got form my head of security (besides check SANS) was to make sure some one on security understood code. Then make sure all inhouse progrmas are run through a security minded code review before they are allowed to g ointo production