This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org
SAMM - Environment Hardening - 3
|
For the latest project news and information, join the mailing list and visit the OpenSAMM website. |
|
|
|
Environment Hardening - 3
| Objective: Validate application health and status of operational environment against known best practices |
Results
- Reinforced operational environment with layered checks for security
- Established and measured goals for operational maintenance and performance
- Reduced likelihood of successful attack via flaws in external dependencies
Add’l Success Metrics
- >80% of stakeholders briefed on relevant operations protection tools in past 6 months
- >75% of projects passing infrastructure audits in past 6 months
Add’l Costs
- Research and selection of operations protection solutions
- Buildout or license of operations protections tools
- Ongoing operations overhead from maintenance of protection tools
- Ongoing project overhead from infrastructure-related audits
Add’l Personnel
- Business Owners (1 day/yr)
- Managers (1-2 days/yr)
- Support/Operators (3-4 days)
Related Levels
- Policy & Compliance - 2
Activities
A. Identify and deploy relevant operations protection tools
In order to build a better assurance case for software in its operating environment, additional tools can be used to enhance the security posture of the overall system. Operational environments can vary dramatically, thus the appropriateness of given protection technology should be considered in the project context.
Commonly used protections tools include web application firewalls, XML security gateways for web services, anti-tamper and obfuscation packages for client/embedded systems, network intrusion detection/prevention systems for legacy infrastructure, forensic log aggregation tools, host-based integrity verification tools, etc.
Based on the organization and project-specific knowledge, technical stakeholders should work with support and operations staff to identify and recommend selected operations protection tools to business stakeholders. If deemed a valuable investment in terms of risk-reduction versus cost of implementation, stakeholders should agree on plans for a pilot, widespread rollout, and ongoing maintenance.
B. Expand audit program for environment configuration
When conducting routine project-level audits, expand the review to include inspection of artifacts related to hardening the operating environment. Beyond an up-to-date specification for the operational environment, audits should inspect current patch status and historic data since the previous audit. By tapping into monitoring tools, audits can also verify key factors about application configuration management and historic changes. Audits should also inspect the usage of operations protections tools against those available for the software’s architecture type.
Audits for infrastructure can occur at any point after a project’s initial release and deployment, but should occur at least every 6 months. For legacy systems or projects without active development, infrastructure audits should still be conducted and reviewed by business stakeholders. An exception process should be created to allow special-case projects to continue operations, but with an explicitly assigned timeframe for mitigation of findings. Exceptions should be limited to no more that 20% of all projects.
