DMZ security benchmark

Does anyone have a good benchmark/control checklist for a DMZ implementation and servers housed within? The only one I could find was by DoD but was PKI protected.
LVL 3
pma111Asked:
Who is Participating?
 
kevinhsiehCommented:
Well, a good place to start is keep everything patched, run only what you need, have anti-malware software installed, and only allow inbound and outbound traffic that you require. Beyond that, it really depends on YOUR requirements, and what your business needs are. A DMZ for a DNS server or mail relay is really different that an ecommerce site typing into an ERP backup and partner extranet.
0
 
btanExec ConsultantCommented:
One way is looking other policy, it does not differ in broad sense. Yet to drill further but this may be useful
 http://www.doc-txt.com/DMZ-Security-Best-Practices.pdf

But overall hardening server will be taken as separate agenda check. Importantly the enforcement of the traffic flow into and out of dmz to and fro external and internal network is critical. That is the purpose for dmz to isolate the exposed service available. The secure remote access like ssl vpn and ipsec for site to site will be another consideration to factor in securing the process of implementation.
0
 
CoccoBillCommented:
Also depends on the operating system you're running, for example Microsoft provides separate guidance for hardening "bastion hosts" in their security guides, such as the Windows Server 2008 Security Guide:

http://www.microsoft.com/download/en/details.aspx?id=17606
0
Ultimate Tool Kit for Technology Solution Provider

Broken down into practical pointers and step-by-step instructions, the IT Service Excellence Tool Kit delivers expert advice for technology solution providers. Get your free copy now.

 
pma111Author Commented:
SO basically you can split the audit into 2 levels:

Operating System
Applications (running on top of that application shared to the outside)

Where OS would constitute "local vulnerabilities"
And app would constitute "remote vulnerabilities"

??
0
 
CoccoBillCommented:
If we're talking about an audit, I would have 3 levels:

- Operating system/network level, consisting of OS hardening, hardening of server applications (databases, web servers, frameworks etc.), network configuration and architecture, network device hardening
- Application level, that is, technical testing of any custom applications and web services and interfaces, possible code reviews
- Management level, including patch management, change management, configuration management, business continuity and disaster recovery planning and incident management.
0
 
pma111Author Commented:
Bill, thanks. Good advice as ever, re:

Management level: Do you have any sort of audit benchmarks or checklists for patch management, change management, configuration management.

I.e "what you'd expect to see"? Or some baseline that you could audit their processes against?
0
 
pma111Author Commented:
That could extend to as whether you also have any checklists/benchmarks for:

"business continuity and disaster recovery planning and incident management"
0
 
CoccoBillCommented:
If you don't have a standard or a framework to follow or adhere to (SOX, PCI DSS, COBIT, ISO27001 etc) I would propably pick up the latest PCI DSS and use it's requirements as sort of a best practice approach to audit against. The standard can be downloaded from here:

https://www.pcisecuritystandards.org/security_standards/documents.php?document=pci_dss_v2-0#pci_dss_v2-0

Patch management is covered in requirements 6.1-6.2, change management in 6.4 and configuration management is briefly covered in 1.1, 1.2, 2.1 and 2.2.
0
 
pma111Author Commented:
Ok Bill I will check this out.

When I can review the document, can I ask, does it also cover your other pointers:

business continuity and disaster recovery planning and incident management

?? If you are familiar with the document can you share the points that cover these areas?
0
 
CoccoBillCommented:
PCI DSS covers incident management in requirement 12, but it barely touches business continuity. The PCI DSS (Payment Card Industry Data Security Standard) is meant for protecting sensitive credit card information, and it doesn't really care about continuity. From the credit card company's perspective the data is safe if your systems are down. :) While PCI is great for ensuring data confidentiality and integrity, it's good to keep in mind other controls are needed for availability. I'm a PCI auditor so I'm fairly familiar with the document.

For business continuity, I'd look into maybe either The business Continuity Institute, COBIT, ISF's SoGP or ISO27001, although none of them (except the older version of COBIT) is free:

http://www.thebci.org/
http://www.isaca.org/Knowledge-Center/COBIT/Pages/Overview.aspx
https://www.securityforum.org/?page=2011sogppublicorder
http://www.iso.org/iso/catalogue_detail?csnumber=42103
0
 
pma111Author Commented:
It would be very interesting to see if you could scope out a bit more on what your area of focus around these 2 areas - specific to remote access:

network configuration and architecture, network device hardening

Would be?

Thanks!
0
 
CoccoBillCommented:
Good pointers for network architecture are in PCI requirements 1.2 and 1.3. For network device hardening, check out the Center for Internet Security Benchmarks (free downloads but require registration):

http://benchmarks.cisecurity.org/en-us/?route=downloads.benchmarks
0
 
pma111Author Commented:
Ok cheers Bill
0
 
btanExec ConsultantCommented:
good discussion, moving the checks from Layer 1 (raw physical) to Layer 7 (appl).
SANS actually has checklist templates if you readily want some quick doc to work with.
http://www.sans.org/security-resources/policies/internet.php
0
 
pma111Author Commented:
Thanks breadtan, they seem more policies as opposed control/config checklists though, was that your understanding?
0
 
btanExec ConsultantCommented:
Yap more policy objectives in directly. Just seeing that the check can be derived revolving those objectives to state explicitly the related controls needed. The reason I see this critical is because we tend to be too focus on checklist items and may miss out the objectives that we trying to comply ultimately. Not to overdo it or downplay related security checks. Striking to justify why the checklist is in accordance and not overwhelming too.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.