
Computer security policy
◦ Defines the goals and elements of an organization's
computer systems

Definition can be
◦ Highly formal
◦ Informal

Security policies are enforced by organizational
policies or security mechanisms


The technical implementation defines whether a
computer system is secure or insecure
The formal policy models can be categorized into
the core security principles of:
◦ Confidentiality
◦ Integrity
◦ Availability

For example:
◦ Bell-La Padula model
 A confidentiality policy model
◦ Biba model
 An integrity policy model


A document that outlines the rules, laws and
practices for computer and network access
Regulates how an organization will manage,
protect and distribute its sensitive
information
◦ Both corporate and client information

Lays the framework for the computernetwork-oriented security of the organization
From: http://www.webopedia.com/TERM/S/security_policy.html

Confidentiality
◦ Ensures the people who are authorized to have
access to information are able to do so when
needed
◦ Keeps valuable information only available to those
people who are intended to see it
 Prevents unauthorized access

Integrity
◦ Maintains the value and the state of information
  protected from unauthorized modification
 Information only has value if we know that it's correct
◦ Major objective of information security policies:
 Ensure that information is not modified or destroyed
or subverted in any way

Availability
◦ Ensuring that information and information systems
are available and operational when they are needed
◦ Major objective of an information security policy
must be to ensure that information is always
available to support critical business processing

Policies
◦ Rules or guidelines to ensure
 How to do
- or  Don't do something

Practices
◦ How the polices are done

Policies and practices together:
◦ What should be done
◦ How to do it




Management support
Structure to support it
Money to do it
Culture of security
Expand on each here



Military Model
Bell-LaPadula Model
Your own method

Levels of classification e.g.:
◦
◦
◦
◦

Secret
Confidential
Restricted
Unclassified
Each has its rules of access
◦ Who may access
◦ How it may be access
◦ Are copies permitted?

Basically simplified Military Model
◦ Relies on an ordering of access

Secret
◦ > Confidential
 > Restricted
 > Unclassified

What works for your organization
◦ Policies and procedures that match your
organizational needs
◦ Identify the needs
◦ Develop policies to meet the needs
◦ Develop procedures
 Implement the policies
 Enforce the policies
◦ (Monitor and update as needed)




Policies and their owners
Technical Guides
System owners
What does the Policy cover












Physical Security
Network Security
Access Control
Authentication
Encryption
Key Management
Compliance
Auditing and Review
Security Awareness
Incident Response & Disaster Contingency Plan
Acceptable Use Policy
Software Security

Private company
◦ Specializes in internet security training
◦ http://www.sans.org/security-resources/policies/#template

1.0 Purpose
◦

2.0 Scope
◦




Risk assessments can be conducted on any entity within <Company Name> or any outside entity that has
signed a Third Party Agreement with <Company Name>. RAs can be conducted on any information system,
to include applications, servers, and networks, and any process or procedure by which these systems are
administered and/or maintained.
3.0 Policy
◦

To empower InfoSec to perform periodic information security risk assessments (RAs) for the purpose of
determining areas of vulnerability, and to initiate appropriate remediation.
The execution, development and implementation of remediation programs is the joint responsibility of
InfoSec and the department responsible for the systems area being assessed. Employees are expected to
cooperate fully with any RA being conducted on systems for which they are held accountable. Employees are
further expected to work with the InfoSec Risk Assessment Team in the development of a remediation plan.
4.0 Risk Assessment Process
◦
For additional information, go to the Risk Assessment Process.
◦
Any employee found to have violated this policy may be subject to disciplinary action, up to and including
termination of employment.
5.0 Enforcement
6.0 Definitions
◦
◦
Terms
Entity
◦
Risk
Definitions
Any business unit, department, group, or third party, internal or external to <Company
Name>, responsible for maintaining <Company Name> assets.
Those factors that could affect confidentiality, availability, and integrity of <Company
Name>'s key information assets and systems. InfoSec is responsible for ensuring the
Integrity, confidentiality, and availability of critical information and computing assets, while
minimizing the impact of security procedures and policies upon business productivity.
7.0 Revision History

1.0 Purpose
◦

The purpose of this policy is to define web application security assessments within <ORGANIZATION>. Web
application assessments are performed to identify potential or realized weaknesses as a result of inadvertent
misconfiguration, weak authentication, insufficient error handling, sensitive information leakage, etc.
Discovery and subsequent mitigation of these issues will limit the attack surface of<ORGANIZATION>
services available both internally and externally as well as satisfy compliance with any relevant policies in
place.
2.0 Scope
◦
This policy covers all web application security assessments requested by any individual, group or department
for the purposes of maintaining the security posture, compliance, risk management, and change control of
technologies in use at <ORGANIZATION>. All web application security assessments will be performed by
delegated security personnel either employed or contracted by <ORGANIZATION>. All findings are
considered confidential and are to be distributed to persons on a “need to know” basis. Distribution of any
findings outside of<ORGANIZATION> is strictly prohibited unless approved by the Chief Information Officer.
Any relationships within multi-tiered applications found during the scoping phase will be included in the
assessment unless explicitly limited. Limitations and subsequent justification will be documented prior to
the start of the assessment.

3.0 Policy
◦
Web applications are subject to security assessments based on the following criteria:

New or Major Application Release – will be subject to a full assessment prior to approval of the change
control documentation and/or release into the live environment.

Third Party or Acquired Web Application – Will be subject to full assessment after which it will be bound
to policy requirements.

Point Releases – will be subject to an appropriate assessment level based on the risk of the changes in
the application functionality and/or architecture.

Patch Releases – will be subject to an appropriate assessment level based on the risk of the changes to
the application functionality and/or architecture.

Emergency Releases – An emergency release will be allowed to forgo security assessments and carry the
assumed risk until such time that a proper assessment can be carried out. Emergency releases will be
designated as such by the Chief Information Officer or an appropriate manager who has been delegated
this authority.

3.1 Risk
◦ Security issues that are discovered during assessments will be mitigated based upon
the following risk levels. Risk rating will be based on the OWASP Risk Rating
Methodology
 High

Any high risk issue must be fixed immediately or other mitigation strategies must be put in
place to limit exposure before deployment.

Applications with high risk issues are subject to being taken off-line or denied release into the
live environment.
 Medium

Medium risk issues should be reviewed to determine what is required to mitigate and
scheduled accordingly.

Applications with medium risk issues may be taken off-line or denied release into the live
environment based on the number of issues and if multiple issues increase the risk to an
unacceptable level. Issues should be fixed in a patch/point release unless other mitigation
strategies will limit exposure.
 Low

Issue should be reviewed to determine what is required to correct the issue and scheduled
accordingly.

Remediation validation testing will be required to validate fix and/or mitigation strategies for any
discovered issues of Medium risk level or greater.

3.2 Tools
◦ The current approved web application security assessment tools in use which will be
used for testing are:
 <Tool/Application 1>
 <Tool/Application 2>
 …
◦ Other tools and/or techniques may be used depending upon what is found in the
default assessment and the need to determine validity and risk are subject to the
discretion of the Security Engineering team.

3.3 Security Assessment Level
◦ Full
 A full assessment is comprised of tests for all known web application
vulnerabilities using both automated and manual tools based on the OWASP
Testing Guide.

A full assessment will use manual penetration testing techniques to validate discovered
vulnerabilities to determine the overall risk of any and all discovered.
◦ Quick
 A quick assessment will consist of a (typically) automated scan of an application
for the OWASP Top Ten web application security risks at a minimum.
◦ Targeted
 A targeted assessment is performed to verify vulnerability remediation changes or
new application functionality.

3.4 Duration
◦ The default duration of a web application assessment will be <X> days
time for the purpose of project planning and will be modified accordingly
based upon the size and scope of the application functionality.

3.5 Exemptions
◦ Exemptions to the need for a security assessment will be made by the
Chief Information Officer or delegated manager based on risk and
criticality of needed application changes/functionality/architecture.
Exemptions will assume the associated risk and will be documented as
required by the change control policies.

4.0 Responsibilities

5.0 Enforcement

6.0 Definitions
◦ Security Engineering will be responsible for web application scoping, assessment,
determination of discovered issue risk, and reporting to Project Management and
application stakeholders. Project Management and application stakeholders will be
responsible for the appropriate assessment scheduling and remediation efforts based
upon assessment findings and Security Engineering recommendations.
◦ Web application assessments are a requirement of the change control process and
are required to adhere to this policy unless found to be exempt. All application
releases must pass through the change control process. Any web applications that do
not adhere to this policy may be taken offline until such time that a formal
assessment can be performed at the discretion of the Chief Information Officer.
◦ Web Application

Any service that accepts and processes HTTP/HTTPS protocols.

A significant application software update/code change such as a new interface design
programming platform change, etc.
◦ Major Release
◦ Point Release

An application software update/code change as part of the application lifecycle.

An application software update/code change that addresses a bug or flaw.
◦ Patch Release

7.0 References
◦ OWASP Top Ten Project:
 http://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project
◦ OWASP Testing Guide:
 http://www.owasp.org/images/5/56/OWASP_Testing_Guide_v3.pdf
◦ OWASP Risk Rating Methodology:
 http://www.owasp.org/index.php/OWASP_Risk_Rating_Methodology

8.0 Revision History
◦ Version 1.0 – John Hally 1/4/11

Must be monitored
◦ Are they being used/enforced?
◦ Are they sufficient?

Must be updated
◦ Every time a gap or lack is found

At the least:
◦ CYA
 Shows due diligence in protecting assets
 Gives some legal protections

Ideally:
◦ Prevent successful attacks
◦ Saves $$$
 Cost of attack
 Cost of implementing this same security later
Prevent
Detect
Improve
Respond