Security Policy
The security policy is the single most important security
work product by acting as a central repository for all
strategies and rules for ensuring proper security. A security
policy is typically developed at the organizational level
(e.g., business unit level), but is may also be developed for a
data or contact center or for a single software-intensive
system. It typically drives the development and content of
subsequent documents including detailed standards, procedures,
and guidelines
The
security policy is the
security work product that
formally and succinctly documents all strategies and rules for
ensuring proper security.
The typical objectives of the security policy is to:
- Formally document the organizational security policy for
its applications, data, communications, contact and data
centers, networks, and physical assets.
- Be the foundation on which a security program is
based.
- Provide a single source of all policies regarding
security.
- Demonstrate management support for, and commitment to,
security.
- Define what is expected of an organization and its staff
with regard to security.
- Document the endeavor’s approach to ensuring
security.
- Drive the development and content of:
- A system’s security requirements and
architecture.
- Associated security standards, procedures, and
guidelines.
- Provide the compliance criteria against which security
audits and quality certifications (e.g., ISO 9000, SEI CMM)
are performed.
- Provide a basis for:
- Enforcement including termination and legal
action.
- Settling both legal disputes and insurance claims.
- Minimize security risks by ensuring that all aspects of
security are properly addressed.
The typical benefits of the security policy are to:
- Minimize organizational risks due security violations
including loss of:
- Revenue through loss of service, loss of data, fraud,
etc.
- Privacy of confidential data and communications.
- Credibility and reputation with customers, users,
partners, shareholders, and other stakeholders.
- Ensure that each application, database, center, and
network has an appropriate level of security.
- Help human resources handle inappropriate employee
behavior.
- Help persecute security breaches.
The typical contents of the security policy are:
- Security Overview
- Importance Of Security
- Security Goals
- Security Principles
(including for example):
- Adversary Principle
Assume that assets will be attacked by
intelligent and malicious adversaries.
- Least Privilege Principle
Individuals should be granted the minimum amount
of access to perform their authorized tasks and no
more.
- Proportionality Principle
Security goals, requirements, and mechanisms
should be proportionate to the value of the asset
protected and threat to the asset.
- Policy Scope:
- Application Security
(including development, usage, maintenance, and
retirement)
- Data Security
(including development, classification, storage,
usage, transmission, and destruction)
- Call or Data Center Security
- Network Security
- Physical Security
- Security Responsibilities
(including implementation, evaluation, compliance,
communication, training, monitoring, and enforcement):
- Management Organization
(e.g., for identifying assets to protect, providing
staffing and funding to support security tasks, and
ensuring compliance with the security policy)
- Security Organization
(e.g., for developing the security policy, ensuring
that security requirements are consistent with the policy,
and performing primary security engineering tasks)
- Operations Organization
- Support Organization
- Vendors
- Security Policies:
- Identification (User Identifiers, Biometrics)
- Authentication (Password Usage, Digital Signitures,
Biometrics)
- Authorization (Access Control, Data Access,
Application Capability Usage)
- Immunity (Virus Detection, Prevention, and
Recovery)
- Integrity (Hash Codes, Backups)
- Intrusion Detection (Firewalls, Security Incident
Detection, Reporting, and Response)
- Nonrepudiation (Records Collection, Retention, and
Backup)
- Privacy (Crytography, Key Management)
- Security Auditing (Audit Scope and Schedule)
- System Maintenance Security (Major Upgrades,
Patches)
- Physical Security Mechanisms (Locks, Cameras,
Guards)
- Email Security
- Security Awareness Training
- Appendices:
- Applicable Regulations, Laws, Certifications and
Standards
(e.g., HIPPA, FDIC, ISO 9000, CPA WebTrust, and
Truste)
- Major Issues
- TBDs
- Assumptions
The typical stakeholders of the security policy are:
- Producer:
- Evaluators:
- Approvers:
- Maintainers:
- Users:
-
Requirements Team, which uses the security policy to
elicit standard security requirements.
-
Architecture Team, which uses the security policy to
architect standard security mechanisms.
-
Security Team, which uses the security policy as a
basis for producing associated standards, procedures, and
guidelines.
-
Development Organization, which must implement the
security policy.
-
Operations Organization, which must follow the
security policy.
- Human Resources Department
- Legal Department
The security policy typically can be started if the
following preconditions hold:
The security policy typically has the following inputs:
- Work Products:
- Stakeholders:
Guidelines
- Scope.
The scope of a security policy can be:
- A business unit
- A data or contact center
- An application
- A reusable component
- Any other system.
- Content.
A security policy should only document high-level
security goals, principles, and policies (e.g., business
rules), leaving lower-level details to other documents:
- Specific security requirements for individual
applications should be documented in the associated system
requirements specifications.
- Specific security mechanisms for individual
applications should be documented in the associated
architecture documents.
- Detailed standards and procedures should be documented
in separate standards and procedure documents.
- Although some security policies document detailed
security requirements and the security architecture
mechanisms by which these requirements are to be achieved
(i.e., countermeasures for protecting assets from the
threat of attack), such separation of security requirements
and architecture decisions from the requirements
specifications and architecture documents decreases the
likelihood that they will be implemented by
engineering.
- Characteristics.
A good security policy should have the following
characteristics:
- Documented.
Properly documented and distributed to its intended
readership.
- Enforced.
Be properly enforced by management.
- Feasibility:
- Economically feasible to implement.
- Procedurally tollerable to use.
- Implementable through standards, procedures, and
guidelines.
- Flexible.
Be flexible in the face of changing threats and
vulnerabilities.
- Protective.
Meet management’s security goals by providing
reasonable protection given the potential impact of
reasonable threats and vulnerabilities.
- Understandable.
Understandable to its intended audiences.
The security policy is typically constrained by the
following conventions:
-
Content and Format Standard
-
MS Word Template
-
XML DTD
-
Inspection Checklist