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 - Policy & Compliance - 2
|
For the latest project news and information, join the mailing list and visit the OpenSAMM website. |
|
|
|
Policy & Compliance - 2
| Objective: Establish security and compliance baseline and understand per-project risks |
Results
- Awareness for project teams regarding expectations for both security and compliance
- Business owners that better understand specific compliance risks in their product lines
- Optimized approach for efficiently meeting compliance with opportunistic security improvement
Add’l Success Metrics
- >75% of staff briefed on policies and standards in past 6 months
- >80% stakeholders aware of compliance status against policies and standards
Add’l Costs
- Internal standards buildout or license
- Per-project overhead from compliance with internal standards and audit
Add’l Personnel
- Architects (1 days/yr)
- Managers (1 days/yr)
- Security Auditors (2 days/project/yr)
Related Levels
- Education & Guidance - 1 & 3
- Strategy & Metrics - 2
- Security Requirements - 1 & 3
- Secure Architecture - 3
- Code Review - 3
- Design Review - 3
- Environment Hardening - 3
Activities
A. Build policies and standards for security and compliance
Beginning with a current compliance guidelines, review regulatory standards and note any optional or recommended security requirements. Also, the organization should conduct a small amount of research to discover any potential future changes in compliance requirements that are relevant.
Augment the list with any additional requirements based on known business drivers for security. Often it is simplest to consult existing guidance being provided to development staff and gather a set of best practices.
Group common/similar requirements and rewrite each group as more generalized/simplified statements that meet all the compliance drivers as well as provide some additional security value. Work through this process for each grouping with the goal of building a set of internal policies and standards that can be directly mapped back to compliance drivers and best practices.
It is important for the set of policies and standards to not contain requirements that are too difficult or excessively costly for project teams to comply. A useful heuristic is that approximately 80% of projects should be able to comply with minimal disruption. This requires a good communications program being set up to advertise the new policies/standards and assist teams with compliance if needed.
B. Establish project audit practice
Create a simple audit process for project teams to request and receive an audit against internal standards. Audits are typically performed by security auditors but can also be conducted by security-savvy staff as long as they are knowledgeable about the internal standards.
Based upon any known business risk indicators, projects can be prioritized concurrently with audit queue triage such that high-risk software is assessed sooner or more frequently. Additionally, low-risk projects can have internal audit requirements loosened to make the audit practice more cost-effective.
Overall, each active project should undergo an audit at least biannually. Generally, subsequent audits after the initial will be simpler to perform if sufficient audit information about the application is retained.
Advertise this service to business owners and other stakeholders so that they may request an audit for their projects. Detailed pass/fail results per requirement from the internal standards should be delivered to project stakeholders for evaluation. Where practical, audit results should also contain explanations of impact and remediation recommendations.
