Pau Lo
asked on
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.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
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.
- 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.
ASKER
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?
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?
ASKER
That could extend to as whether you also have any checklists/benchmarks for:
"business continuity and disaster recovery planning and incident management"
"business continuity and disaster recovery planning and incident management"
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.
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.
ASKER
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?
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?
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
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
ASKER
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!
network configuration and architecture, network device hardening
Would be?
Thanks!
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
http://benchmarks.cisecurity.org/en-us/?route=downloads.benchmarks
ASKER
Ok cheers Bill
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
SANS actually has checklist templates if you readily want some quick doc to work with.
http://www.sans.org/security-resources/policies/internet.php
ASKER
Thanks breadtan, they seem more policies as opposed control/config checklists though, was that your understanding?
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.
ASKER
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"
??