Project Security Plan

University of WashingtonProject Security PlanPrepared Office of the CISO 02/10Note: Italic font is used for instructions or helpful information for the author, reviewers, and approvers. Page 8Table of Contents1.Approval Cycle Project Security Plan12.Project Security Plan Purpose13.Business Overview23.1System(s) Description23.2Abstract34.Business Security Assessment34.1Business Sponsors Security Expectations34.2Technical Assets44.3Risk Control Explanations55.Controls65.1Control Questions65.2Control Explanations91. Approval Cycle Project Security PlanRoleNameSignatureDateAuthor:Executive Sponsor:Business Sponsor:Reviewer(s):Approver(s):System OwnerSystem Operator2. Project Security Plan PurposeThis document is used in conjunction with the overall project plan to: Facilitate security oversight; Describe the security plan as designed by the project team during the system or application design; Document the assets being protected; Document the exposures and threats to which those assets are, or may be, subjected; Document the controls that are installed to mitigate those exposures and threats and; Document the reasons that the installed controls provide the appropriate level of security or why the residual risk is acceptable.3. Business OverviewPurpose: This section contains a summary of the System, briefly describes what it does, and outlines how it works. This section also covers the Systems operating environment. This section does not cover the design to the level of the functional specification, but should include enough detail to evaluate the completeness and accuracy of the provided information. Typically, a diagram of all of the components will also be included in this section.3.1 System(s) DescriptionProject Description:Organization, college, or school:Department:Name of System:Name of System Owner2:Name of System Operator2:Highest classification of data processed by the System1:Type of confidential data (if System will process confidential data):Volume of data expected on System:Name of Data Trustee2:Name of Data Custodian2:1 Administrative Policy Statement 2.10 Minimum Data Security Standards2 Administrative Policy Statement 2.4 Information Security & Privacy Roles, Responsibilities, and Definitions3.2 AbstractThis section contains a concise summary of the: Business purpose of the System addressed by this project; Scope of the System; Level of effort to manage risks to an acceptable level; Assets or components that will be part of the System; Installation, implementation and maintenance expectations and; Use expectations.4. Business Security Assessment4.1 Business Sponsors Security ExpectationsIn this section, define the business sponsors expectations for the System. Also interview the System Owner to augment what is not already documented.Some questions to help you think about expectations: Who is responsible for System security and what is expected? Does the System depend upon any other systems for enforcing security controls (e.g., Active Directory)? Who will use the System (e.g. employee, volunteers, contractors, vendors, students) Is the System used internally to provide information to another department? Must the System be operational 24x7? Will the System have maintenance windows? Should different groups of people have different modes of access (e.g., user mode, administrator mode, maintenance mode)?4.2 Technical AssetsAsset: List the assets that are to be protected in the table below. Examples of assets include data, systems, processor time, disk storage space, network connections, and anything else that the business sponsor and system owner of this System values or manages. Common traits of assets to be protected include confidentiality, integrity, or availability.Exposure: If any of the assets being used to create the System, or that will be used to access or maintain the information asset, have any known exposures for which no fix is available, list those exposures. Do not trust the third party alone to answer this question. Check independent sources such as: BugTraq mailing list archive at Common Vulnerabilities and Exposures (CVE) at http:/www.cve.mitre.org Third party web sites, such as Microsoft at Threat: List all the ways that the assets of this system could be damaged, lost, or stolen in the Threats column. Common threats include: hackers, unauthorized users, theft, electrical/telecommunications failures, and natural disasters. A threat could affect a single asset or a group of assets.Control Measures: List the controls that will be in place as part of this project to protect the asset from the threats.Impact Level: Select the level of the worst-case outcome if an exposure were exploited or a threat were successful.Threat Probability: Determine probability level.Risk: This is derived from the residual risk. Document reasons for accepting residual risks that are HIGH or MEDIUM in the following sub section.#Asset NameExposureThreatControl MeasuresImpact Level(High, Med, Low)Threat Probability(High, Med, Low)Risk(High, Med, Low)1234564.3 Risk Control ExplanationsThis section consists of reasons to accept the business risk that correspond to either High or Medium Risk levels in the prior section. The first column should contain the Asset Number so that the reason corresponds to the assets in section 4.2.Asset #Reason to accept risk5. ControlsPurpose:Every security control must satisfy three important properties:1. The control must be tamperproof;2. The control must always be invoked and;3. The implementation of the control must be subject to testing and analysis.This is necessary in order to make visible the evidence that the asset is sufficiently protected. The department will need to ensure that systems are developed, acquired, and maintained with appropriate security controls. This section is concerned with how the System will meet policy requirements.5.1 Control QuestionsFor each question in this section, provide an answer (Y, N, or N/A). If the answer is “N” describe the mitigation plan in the Section 5.2 (Control Explanations). If the answer is “N/A”, describe why the control question is not applicable in Section 5.2 (Control Explanations). The name of the person validating the responses to the Control Questions and the Control Explanations will be provided in the last column.Item #Control Question:(If “N” or “N/A” explain item # in Section 3.2)YNN/AIndividualResponsible:Validatedby:1Is the data logically separated from any other departments data?2Have records retention and records destruction controls been implemented in accordance with the UW, business sponsor, and system owners requirements?3Have pre-production or testing controls been configured to production settings?4If resources/assets are being accessed via Internet facing systems and have confidential data, are multi-factor authentications being used?5If resources/assets are being administered remotely, are multi-factor authentications being used?6Are the transmission and storage of authenticators (e.g., passwords, PINs, digital certificates, and biometric templates) encrypted using unbroken algorithms?7Have the network requirements and architecture for this System been defined and documented?8Have only “business required” trusts been established between the networks, domains, and systems for this System?9Has the System been made attack resistant?10Have resource kit utilities and any other extra system utilities been removed from the Systems that reside in Internet facing networks?11Have appropriate user groups been created and populated to restrict user access to the system, application, and data based on the principle of least privilege and separation of duties?12Have event logs for this System been configured to record user and program access to confidential data?13Are the operating system patches, service packs, and application updates current to the business-required levels?14Have all systems and applications of this System been enrolled in the patch management process that ensures the timely installation of patches?15Are the assets and data for this System physically located within a data center? If not in a data center, does the physical location have equivalent controls?16Is the change management process documented and includes an approval process?17Are the transmissions of confidential data encrypted using unbroken algorithms? (For example, SSL or IP-SEC)18Is the storage of confidential data encrypted using unbroken algorithms?19If encryption is used for transmission of confidential data, has it been audited, sniffed, or monitored to verify its reliability from point-to-point and end-to-end?20Are approved malware protection products being used for clients and servers?21Have servers been included in the network backup process?22Have auditing controls been activated to meet the business sponsor and system owner requirements?23Have all of the business security requirements been documented and implemented to meet the business sponsor and system owner requirements? This will include elements such as password complexity, access control and management mechanisms, host firewall, etc.24If third parties will have access to the Systems data, has a Data Security Addendum been signed?25Have the security administration operational requirements been documented and implemented?26Have the security testing requirements been documented, successfully executed, and the test results been documented?27If confidential data is used, where possible has the confidential data been completely or partially redacted to limit risk?5.2 Control ExplanationsThis section consists of explanations that correspond to either “N” or “N/A” responses to the prior section questions. That is, an “N” response explanation should contain the reason why not and what, if any, action or system outside the scope of this project will address the lack of control. An “N/A” response explanation should fully detail why the control question does not apply in this case. The first column should contain the question number from Section 3.1 so that the explanations correspond to the questions.Control Question #Control Explanation