Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

Being responsible for security in a university computer science department is no fun at all. And I explain: It is often the case that I get a request for installation of new hw systems or software systems that are really so experimental that I would not dare put them even in the DMZ. If I can avoid it and force an installation in a restricted inside VLAN that is fine but occasionally I get requests that need access to the outside world. And actually it makes sense to have such systems have access to the world for testing purposes.

Here is the latest request: A newly developed system that uses SIP is in the final stages of development. This system will enable communication with outside users (that is its purpose and the research proposal), actually hospital patients not so well aware of technology. So it makes sense to open it to the rest of the world. What I am looking for is anyone who has experience with dealing with such highly experimental systems that need wide outside network access. How do you secure the rest of the network and systems from this security nightmare without hindering research? Is placement in the DMZ enough? Any extra precautions? Any other options, methodologies?

share|improve this question
    
What if you used a gateway host and opened specific ports / forwards for each 'experimental' system? –  ethrbunny Sep 14 '12 at 15:08
    
if security is a priority for you, get a consultant to help you, don't be asking in free forum's. –  The Unix Janitor Sep 14 '12 at 16:50
2  
It's not an either/or proposition. This site's intent is to be a place for knowledge dissemination. –  mfinni Sep 14 '12 at 17:32
1  
I'll just say that if a DMZ is not secure enough for this purpose, assuming it's the sole device in that DMZ, then your DMZ security needs urgent attention. –  John Gardeniers Sep 14 '12 at 21:06
    
Appreciate all comments.I am well aware what a DMZ can do and cannot do.I left my objective above quite broad in order to gather suggestions from administrators that have experience with this kind of problem unique to the academic environment.The problem is that newly created research systems are usually programmed by students. They are known to have no notion of security. Professors leading the research efforts are very anxious to show progress. They are also known to have no notions of proper security. DMZ or not DMZ the ball is in my hands to see that things work smoothly. –  ank Sep 17 '12 at 8:47

4 Answers 4

up vote 7 down vote accepted

This is entirely dependent on the "experimental system" in question -- Security is not something that comes in a box: it needs to be custom-tailored to every specific site, scenario, and application.

If you're talking about stuff written by students (who are pretty well notorious for having ZERO practical grasp of IT security), I would say that each project needs to be segregated into its own universe.
That means:

  • Placed in its own (appropriate-sized) subnet, with its own router
    (it should go without saying that it should be in its own vLAN as well)
  • Placed behind its own firewall, which should:
    • Restrict inbound access as much as practical
      (i.e. only the ports that the application needs to accept connections on)
    • Restrict outbound connections where sensible
    • Be completely separate from the rest of the university & department infrastructure
      (your externally exposed apps should not, for example, be able to find a way through your defenses to talk to the campus AD servers)
  • Internal topology should follow best practices for containment of breaches
    This one is hard because it requires the software to be designed well, but where possible you want to set things up so if someone breaches a front-end system (like a web server) your back-end systems (like databases) may still be safe.
    If the software is designed for segmentation, for example something having an APP layer, a DBI layer, and a DB layer you can theoretically separate that into three internal networks. APP can talk to DBI, DBI can talk to DB, but APP can't talk to DB unless DBI handles the request.

If you're using good Cisco hardware this isn't hard to do (FWSM "PIX Blades" for the independent firewalls, some basic vLANs, and dropping a router into each subnet).

General Best Practices obviously apply as well - you should have everything documented (What needs to be open and why? What special network configuration (if any) is applied? etc.), and if you have an IDS/IPS in place you should look for ways to make sure these isolated environments are covered.

share|improve this answer

Compartmentalization all the way. Create a new DMZ for it that is treated as an external network by all other networks, DMZs, etc.

In a University environment, there are lots of areas where research and testing can end up being higher priorities than full security. Treating those circumstances as random Internet hosts is probably the best you can do for isolation. It would also be wise to drop an IDS onto any of these isolated network segments that you create.

share|improve this answer

Not knowing your policies or regulatory requirements, we can't tell you what's "enough." A properly firewalled and monitored subnet generally suffices, as long as you

  1. know what you're allowing
  2. document it
  3. ensure that this matches any security policies you have
  4. and can justify it to your boss, his boss, the government, or a PCI auditor or whatever applies to your organization.
share|improve this answer

I'd certainly consider investing in some kind of intrusion detection system. The only problem here is that it's a bit of a minefield, with a number of companies pushing their products. Speak to a reputable vendor-agnostic security company. I've had very positive dealings with NGS Secure (part of the NCC group).

I'd also consider virtualising your test labs, giving you the ability to create multiple virtual networks, each tied to a given vLAN. The big benefit here is recovery from any potential attack (regular VM snapshots, giving multiple point-in-time recovery points).

share|improve this answer
    
The problem with intrusion detection systems is that they detect intrusions and intrusion attempts. The better way is to prevent them in the first place. The IDS is not enough. –  John Gardeniers Sep 14 '12 at 21:09

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.