This preview shows page 1. Sign up to view the full content.
Unformatted text preview: maximum of 30 days for low priority patches.
This activity should be primarily conducted by support and operations staff, but routine
meetings with development should also be conducted to keep the whole project abreast of
past changes and scheduled upgrades.
Additionally, development staff should share a list of third-party components upon which the
software project internally depends so that support and operations staff can monitor those
as well to cue development teams on when an upgrade is required. Add’l Costs
✦✦Ongoing organization overhead from
patch management and monitoring
✦✦Buildout or license of infrastructure
monitoring tools Add’l Personnel
✦✦Architects (1-2 days/yr)
✦✦Developers (1-2 days/yr)
✦✦Business Owners (1-2 days/yr)
✦✦Managers (1-2 days/yr)
✦✦Support/Operators (3-4 days/yr) Related Levels SAMM / The Security Practices - v1.0 ✦✦ 76 B. Monitor baseline environment configuration status
Given the complexity of monitoring and managing patches alone across the variety of components composing the infrastructure for a software project, automation tools should be
utilized to automatically monitor systems for soundness of configuration.
There are both commercial and open-source tools available to provide this type of functionality, so project teams should select a solution based on appropriateness to the organization’s
needs. Typical selection criteria includes ease of deployment and customization, applicability
to the organization’s platforms and technology stacks, built-in features for change management and alerting, metrics collection and trend tracking etc.
In addition to host and platform checks, monitoring automation should be customized to
perform application-specific health checks and configuration verifications. Support and operations personnel should work with architects and developers to determine the optimal
amount of monitoring for a given software project.
Ultimately, after a solution is deployed for monitoring the environment’s configuration status,
unexpected alerts or configuration changes should be collected and regularly reviewed by
project stakeholders as often as weekly but at least once per quarter. Environment Hardening EH 3 Validate application health and status of operational environment against known best practices 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-bas...
View Full Document
- Spring '14