A system-specific policy is
|“||the body of rules and practices used to protect a particular information system. System-specific policy is limited to the system or systems affected and may change with changes in the system, its functionality, or its vulnerabilities.||”|
Agencies are likely to have multiple sets of system-specific policy relating to security, from the very general (e.g., access control rules about who may have user accounts) to the very particular (e.g., system permissions reflecting segregation of duties among employees involved in handling payroll). OMB Circular A-130, Appendix III requires system security plans incorporating such policies and implementation procedures, and NIST Special Publication 800-18 provides detailed guidance on developing them.
Because of the varying scope and specificity of this type of policy, it may be difficult to determine whether the existing body of system-specific policy is adequate to meeting information security goals. NIST suggests analyzing existing policies and formulating new ones using a two-step process:
- Define security objectives for the system, based on agency information security goals and system functional or mission requirements. These objectives should be achievable action statements. A security objective for availability might be: "Ensure 99 percent or better network availability 24 x 7 x 365 during the fiscal year." For confidentiality, an objective might be: "Reduce incidents of unauthorized access by employees, contractors, and service personnel to fewer than three per year."
- Write operational security rules to achieve security objectives. The degree of specificity of these rules will vary, as will their formality. Some may be implemented by setting automated system controls (for example, access control), but should be supplemented by written statements (for example, who is to be granted access privileges). Developing and implementing operational security rules will involve tradeoffs. Detailed, written policies may be clear and easy to enforce but create an administrative burden. Similarly, automated controls can make enforcement consistent but may be too rigid unless they permit an authorized manager to override them when an exception should be made.
- NIST Special Publication 800-18, at 33-34.
- "Overview: U.S. government" section: Practices for Securing Critical Information Assets, at 4-5.