Hi,
Me again. I attended a very interesting seminar this week on Infrastructure qualification and it's brought up a few questions as to how we approach security (both physically and logically).
At our site, we have physically seperate switches/firewalls/networks/PCs for our 'internal' network and a seperate network with its own set of switches / firewalls / PCs / Servers for Internet Access. Yes, complicated, expensive, but in a way does give you 'peace of mind'. Wireless networks are not used or allowed in our buildings.
Of course, nearly all of our floor points are plugged into our Nortel switch stacks regardless of whether they are being used or not, which now could pose a risk - a visitor could come in, plug in a laptop or other device and be handed an IP address which would then allow him to do what he wants. Our physical security prevents him from doing this, as visitors are normally always accompanied, but if one had to look at the fact that most hacks come from people inside the organisation, then we need to look at this in a different light.
So now that we think about it, we have thought about 3 ways in which to secure this aspect. Each of course has its limitations with regards to admin time, etc.
1) We validate all equipment on the network (maybe outside the server room) and then define those MAC addresses which we populate into the Switch stacks and only they are allowed to connect to the network. But this would probably equate to nearly 1300 MAC addresses being loaded into switch stacks - can the 5510 switch stacks handle this kind of load?
2) Do the same thing with MAC address, but somehow use DHCP to do a similar thing - but this may not be possible as that's too many reservations to create.
3) Other ideas include removing patch leads plugged into floor ports and then also from the patch points to nortel switchs for all 'dead' ports and if someone joins or leaves the company only then do we patch in those cables.
All of them or a blended implementation of all three will entail us changing our methods, but are they feasible and is there a better idea that you have?
Me again. I attended a very interesting seminar this week on Infrastructure qualification and it's brought up a few questions as to how we approach security (both physically and logically).
At our site, we have physically seperate switches/firewalls/networks/PCs for our 'internal' network and a seperate network with its own set of switches / firewalls / PCs / Servers for Internet Access. Yes, complicated, expensive, but in a way does give you 'peace of mind'. Wireless networks are not used or allowed in our buildings.
Of course, nearly all of our floor points are plugged into our Nortel switch stacks regardless of whether they are being used or not, which now could pose a risk - a visitor could come in, plug in a laptop or other device and be handed an IP address which would then allow him to do what he wants. Our physical security prevents him from doing this, as visitors are normally always accompanied, but if one had to look at the fact that most hacks come from people inside the organisation, then we need to look at this in a different light.
So now that we think about it, we have thought about 3 ways in which to secure this aspect. Each of course has its limitations with regards to admin time, etc.
1) We validate all equipment on the network (maybe outside the server room) and then define those MAC addresses which we populate into the Switch stacks and only they are allowed to connect to the network. But this would probably equate to nearly 1300 MAC addresses being loaded into switch stacks - can the 5510 switch stacks handle this kind of load?
2) Do the same thing with MAC address, but somehow use DHCP to do a similar thing - but this may not be possible as that's too many reservations to create.
3) Other ideas include removing patch leads plugged into floor ports and then also from the patch points to nortel switchs for all 'dead' ports and if someone joins or leaves the company only then do we patch in those cables.
All of them or a blended implementation of all three will entail us changing our methods, but are they feasible and is there a better idea that you have?
