FEA Security and Privacy Profile, Version 2.0The Federal Enterprise Architecture Security and Privacy Profile (FEA SPP) is a scaleable and repeatable methodology for addressing information security and privacy from a business-centric enterprise perspective. It integrates the disparate perspectives of program, security, privacy, and capital planning into a coherent process, using an organization’s enterprise architecture efforts. Enterprise architecture provides a common language for discussing security and privacy in the context of agencies’ business and performance goals, enabling better coordination and integration of efforts and investments across organizational or business activity stovepipes.To support that endeavor, the FEA SPP methodology: * Promotes an understanding of an organization’s security and privacy requirements, its capability to meet those requirements, and the risks to its business associated with failures to meet requirements. * Helps program executives select the best solutions for meeting requirements and improving current capabilities, leveraging standards and services that are common to the enterprise or the Federal government as appropriate. * Improves agencies’ processes for incorporating privacy and security into major investments and selecting solutions most in keeping with enterprise needs.Federal Enterprise Architecture Program Management OfficeFEAPMO_6a2d751d-8bbe-4a5d-9903-4459274836b7Security ExpertsTarget Audience -- The FEA SPP is a cross-disciplinary methodology that requires support and participation of experts from security, privacy, enterprise architecture, capital planning, and organizational business functions. It is written at a high level to make it understandable to a wide audience. Success of the FEA SPP methodology hinges on understanding and sharing insights across each domain. Agencies should document those insights in the enterprise architecture and use them to promote the objectives of security and privacy across all enterprise activities and investments. The discussion in Chapter Two introduces basic concepts to facilitate a common understanding of those functional domains.Privacy ExpertsEnterprise Architecture ExpertsCapital Planning ExpertsBusiness Function ExpertsChief Information Officer (CIO)The CIO is responsible for information resource management and will be a natural stakeholder for the FEA SPP methodology.Senior Agency Official for SecurityThe senior agency official for security has primary responsibility for security in the agency and should be familiar with external and internal security requirements as well as the enterprise-level capabilities currently in place to satisfy those requirements. The senior agency official for security also contributes knowledge of the organization’s current security posture. More than one security official may be needed to support the FEA SPP methodology in agencies where security responsibilities are decentralized.Senior Agency Official for PrivacyThe senior agency official for privacy has primary responsibility for privacy in the agency and should be familiar with external and internal privacy requirements as well as the enterprise-level capabilities currently in place to satisfy these requirements. The senior agency official for privacy also contributes knowledge of the organization’s current privacy posture. Privacy may have several advocates within an agency.Chief Enterprise ArchitectThe Chief Enterprise Architect has primary responsibility for developing and promoting the operationalization of the enterprise architecture of an organization. In light of those responsibilities, the Architect may be the best person to lead FEA SPP activities and to capture outcomes.Chief Financial Officer (CFO)The CFO has responsibility for planning, proposing, and monitoring major agency investments. The CFO is also often the chair of agencies’ information technology investment review boards (ITIRB). The FEA SPP’s goal of promoting better-informed and more strategic investment decisions makes it important that the CFO participates in this process, especially with regard to Stage III’s activities. By following the guidance in the FEA SPP, an organization is more likely to effectively address security and privacy requirements in Exhibit 300 and Exhibit 53 submissions.Program OfficialsProgram officials are responsible for accomplishing the business of an agency. They drive decisions about investments and are responsible for planning and budgeting for security and privacy. While security and privacy officials will be knowledgeable about enterprise security and privacy requirements, program officials may have unique, programmatic requirements. Also, senior agency officials’ decisions in the course of developing the FEA SPP will impact the program-level as the program officials will implement many of the security and privacy decisions. Including program officials in the FEA SPP activities will ensure that decisions made will be practical and useful to everyone._36a6f58a-ee0d-11e1-8564-e27f7fb1eeb4To provide a methodology for addressing information security and privacy._36a70336-ee0d-11e1-8564-e27f7fb1eeb4SecurityGenerally, information security describes the activities that assure the confidentiality, integrity and availability of information and information systems.ConfidentialityConfidentiality refers to understanding which data may and may not be disclosed to which people and ensuring that only appropriate disclosures are made.IntegrityIntegrity is the assurance that information and information systems are protected against improper or accidental modification.AvailabilityAvailability is assurance of timely and reliable access to information and information systems by authorized persons.PrivacyEnterprise ArchitectureEnterprise architecture is a technique for documenting, evaluating, and planning an organization’s business objectives and the business activities, information, standards, and capabilities that support those objectives.IdentificationIdentify the appropriate set of controls._36a70728-ee0d-11e1-8564-e27f7fb1eeb4Stage IInformation Security OfficialsAgencies’ information security officials identify the appropriate set of controls from each control family through categorizing each information system; they categorize systems based on the potential impact of a loss based on the data they contain.Stage I is an identification of an agency’s business-supportive security and privacy requirements and the existing or planned capabilities that support security and privacy. As a result of Stage I activities an agency will be able to: * Fully identify program and enterprise-level security and privacy requirements, including previously unknown requirements. * Fully identify program and enterprise-level security and privacy capabilities, including current and planned future requirements. * Document requirements and capabilities in an agency’s enterprise architecture using a nomenclature that is common across the Federal government. To accomplish those goals, agencies may wish to evaluate three types of requirements: * Externally driven laws, regulations, and executive branch policies; * Internally driven policies, interagency agreements, contracts, market practices, and organizational preferences; and * Mission-centric drivers such as performance objectives and lines of business. Agencies may also wish to evaluate three types of capabilities: * Centralized security or privacy services and technologies, * Program or system-specific security or privacy services and technologies; and * Services or technologies with built-in security or privacy features... Stage I activities immediately enable agencies to improve operations by: * Analyzing gaps between requirements and capabilities to identify unmet requirements * Analyzing their portfolio of current capabilities (an as-is security and privacy architecture) to identify opportunities to increase interoperability and standardization, and reduce costs * Proposing future capabilities based on improved insights into the enterprise * Facilitating enterprise-level choices about the implication of security and privacy decisions and investments.ArchitectureHighlight security and privacy-related business processes in the agency’s business architecture._36a70890-ee0d-11e1-8564-e27f7fb1eeb4I.A.1Security and privacy-related business processes should be highlighted in the agency’s business architecture. System components providing security and privacy capabilities should be highlighted in the agency’s system architecture. A clear understanding of performance requirements is the first step toward risk-management and compliance. An understanding of security and privacy requirements can be derived from business-specific documents as well as from security and privacy-specific documents.Business RequirementsIdentify those laws, regulations, and executive branch policies that establish business requirements._36a7098a-ee0d-11e1-8564-e27f7fb1eeb4I.A.1.aSecurity & Privacy RequirementsIdentify those laws, regulations, and executive branch policies that establish security and privacy requirements._36a70ad4-ee0d-11e1-8564-e27f7fb1eeb4I.A..1.bi. Security examples include FISMA, OMB A-130, FIPS PUB 199, FIPS PUB 200, and others. Some privacy examples are cited in Appendix D. ii. Evaluate key requirements for system-level security and privacy. NIST captures system-level security requirements in the NIST SP 800-53 baseline security controls. Primary sources of enterprise requirements include sources such as FISMA, OMB A-130, FIPS PUB 199, and FIPS PUB 200.Business ArchitectureReflect insights into security and privacy needs and should in the enterprise business architecture._36a70bce-ee0d-11e1-8564-e27f7fb1eeb4I.A.2Insights into security and privacy needs and should be reflected explicitly in the enterprise business architecture. While many internal requirements are entered into voluntarily, it remains critical to be aware of and compliant with these requirements while they are in effect.Mission Statements & PoliciesIdentify security and privacy requirements established in agency or organizational mission statements and policies._36a70cd2-ee0d-11e1-8564-e27f7fb1eeb4I.A.2.aThe ability to link security and privacy capabilities to policy and strategy ensures alignment of security and privacy capabilities with the business mission.Roles & ResponsibilitiesDocument security and privacy roles and responsibilities in relevant policies and position descriptions. _36a70df4-ee0d-11e1-8564-e27f7fb1eeb4I.A.2.bEstablishing accountability reduces the risks regarding the appropriate and consistent application of security and privacy controls.CommitmentsIdentify security and privacy commitments established through inter and intra-agency trust agreements and contracts. _36a70eee-ee0d-11e1-8564-e27f7fb1eeb4I.A.2.cEvaluate whether those commitments have programmatic or enterprise-wide impact on security and privacy.Preferences & PracticesIdentify and document security and privacy practices driven by organizational preferences and market practices. _36a70ffc-ee0d-11e1-8564-e27f7fb1eeb4I.A.2.dEvaluate the criticality of non-mandatory practices in terms of risk and cost.Business RequirementsIdentify Business Requirements. _36a71128-ee0d-11e1-8564-e27f7fb1eeb4I.A.3These include performance, business, and data requirements.Performance ObjectivesAssess enterprise architecture descriptions of performance objectives to determine if they support measuring compliance. _36a71222-ee0d-11e1-8564-e27f7fb1eeb4I.A.3.aIn addition to compliance oversight, metrics should also assess adequacy of performance and support service-level agreements.Security & Privacy AttributesAssess enterprise architecture descriptions of lines of business, functions, and sub-functions to determine if they describe security and privacy attributes._36a71330-ee0d-11e1-8564-e27f7fb1eeb4I.A.3.bThe business architecture should highlight security and privacy-sensitive activities to each business function and sub-function to ensure that appropriate controls are developed and in place.Data DescriptionsEnsure that enterprise architecture descriptions of data incorporate security and privacy attributes._36a71448-ee0d-11e1-8564-e27f7fb1eeb4I.A.3.ci. information confidentiality, integrity, and availability. FIPS PUB 199 and NIST SP 800-60 describe the methodology for this activity. This guidance helps agencies map security impact levels in a consistent manner to types of information (e.g., privacy, medical, proprietary, financial, contractor sensitive, trade secret, investigation) and information system (mission critical, mission support, administrative). ii. subject to privacy legislation. Especially consider the Privacy Act, eGov Act, and HIPAA. iii. must be associated with a business purpose to properly assess associated risks.Security and Privacy CapabilitiesIdentify Security and Privacy Capabilities._36a7154c-ee0d-11e1-8564-e27f7fb1eeb4I.BDedicated ServicesIdentify processes and technologies that provide dedicated security or privacy services -- for example, processes for managing classified information, or a stand-alone Internet firewall or a web-based PIA tool._36a7166e-ee0d-11e1-8564-e27f7fb1eeb4I.B.1.aAncillary Processes & TechnologiesIdentify processes and technologies that are not security or privacy-centric but which accomplish security or privacy as an ancillary function -- for example, personnel management activities that require consideration for privacy, or a grants-management system that encrypts data._36a717ae-ee0d-11e1-8564-e27f7fb1eeb4I.B.1.bCapabilities MappingMap requirements to capabilities and identify gaps._36a718c6-ee0d-11e1-8564-e27f7fb1eeb4I.B.2by how it supports one or more of the 17 security and 17 privacy control families. The controls families will be used in Stage II to map requirements to capabilities and identify gaps. Incorporate information about security and privacy capabilities into the agency’s as-is architecture. Security and privacy-related business processes should be highlighted in the agency’s business architecture. System components providing security and privacy capabilities should be highlighted in the agency’s system architecture.AnalysisAnalyze business-supportive security and privacy requirements and the existing or planned capabilities that support security and privacy. _36a719ca-ee0d-11e1-8564-e27f7fb1eeb4Stage IIIn Stage II agencies analyze their business-supportive security and privacy requirements and the existing or planned capabilities that support security and privacy. Stage II’s three analyses help agencies: * Identify gaps between requirements and current or planned capabilities. * Identify opportunities to increase interoperability between or reduce costs of current or planned capabilities. * Propose solutions to address gaps or improve capabilities based on an informed trade-off analysis of alternatives.Gaps[Identify the gaps] between current requirements and the current or planned capabilities to meet those requirements._36a71b00-ee0d-11e1-8564-e27f7fb1eeb4II.A.1Unmet requirements are then assessed to verify if they must be met to appropriately manage security and privacy risks.Requirments & CapabilitiesIdentify the gap between requirements and capabilities._36a71c2c-ee0d-11e1-8564-e27f7fb1eeb4II.A.1.aControl MappingMap requirements and capabilities to the control families._36a71d58-ee0d-11e1-8564-e27f7fb1eeb4II.A.1.a.1FEA SPP Implementation Teamsecurity and 17 privacy control families. In Stage I, the FEA SPP implementation team maps requirements and capabilities to the control families. Conduct a family-by-family assessment to identify requirements that are not supported by a specific capability. Subsequent activities in Stage II address unmet requirements.Target ArchitectureDetermine if unmet requirements are addressed in the agency’s current future plans (through a review of the “target” architecture)._36a71eb6-ee0d-11e1-8564-e27f7fb1eeb4II.A.1.a.2Risk AssessmentAssess the risks associated with gaps between requirements and capabilities. _36a71fce-ee0d-11e1-8564-e27f7fb1eeb4II.A.1.bAn accounting of security and privacy features is necessary to justify investments in OMB business cases. i. unmet requirement can be mitigated or accepted. ii. enterprise. Determine whether currently funded security and privacy capabilities address residual risks. iii. be architecture. iii. Stage II.EA & POA&MDocument gaps in the enterprise architecture and FISMA Plan of Action & Milestones (POA&M)._36a72104-ee0d-11e1-8564-e27f7fb1eeb4II.A.1.cEnterprise-wide initiatives and/or critical security and privacy activities should be reflected in the agency’s enterprise architecture transition strategy.Capability AnalysisAnalyze Capabilities. _36a72258-ee0d-11e1-8564-e27f7fb1eeb4II.A.2Evaluate the overall capabilities portfolio to assess common risks, identifying opportunities for centralization and standardization.Assessment AggregationAggregate program and system-level security and privacy assessments such as FIPS PUB 199 security characterizations and Privacy Impact Assessments._36a7237a-ee0d-11e1-8564-e27f7fb1eeb4II.A.2.a* An agency with 100 systems may find that 50 are all subject to the Low/Low/Low security control baseline; another 25 may be subject to the High/High/Medium baseline; and the remaining 25 to an assortment of other combinations. * An agency may determine that 30 of their systems hold personally identifiable information subject to the Privacy Act, HIPAA, or other privacy law considerations.OpportunitiesIdentify opportunities to provide more effective and/or less expensive centralized security and privacy capabilities. _36a724b0-ee0d-11e1-8564-e27f7fb1eeb4II.A.2.a.iDetermine which controls are most complex or expensive to deploy at the system-level but which may be appropriate for an enterprise solution. * NIST SP 800-53 summarizes required security control baselines and enhancements. * Privacy laws and regulations establish a framework of appropriate privacy controls.Agency StandardsIdentify capabilities that are inconsistent with common agency standards. _36a72654-ee0d-11e1-8564-e27f7fb1eeb4II.A.2.a.iiDetermine if standardizing those inconsistent capabilities on an agency standard will reduce security and privacy risk, increase interoperability, or reduce costs. For example, consider operating systems with similar security and privacy requirements for implementation within the same or similarly configured infrastructure.Non-Specific CapabilitiesIdentify capabilities not driven by a specific requirements. _36a727b2-ee0d-11e1-8564-e27f7fb1eeb4II.A.2.a.iiiCapabilities may be identified through this assessment because their requirements have not been adequately captured in Stage I. If that is not the case, assess the need for the capability.Control EvaluationEvaluate the controls mandated for groups of systems. _36a728e8-ee0d-11e1-8564-e27f7fb1eeb4II.A.2.bUse Stage I’s mapping of requirements and capabilities to control families to assess current or planned capabilities.Alternative Analysis[Perform] alternative analyses on sufficiency of the solution and associated costs and benefits managed to expectations for functionality._36a72a6e-ee0d-11e1-8564-e27f7fb1eeb4II.B.1Informed risk-based decision making requires alternative analyses on sufficiency of the solution and associated costs and benefits managed to expectations for functionality. Criteria should include a review of all risk, benefit, and cost factors leading to selecting the most effective plan of action to address unsupported requirements.RiskEvaluate the extent to which each alternative will meet the applicable security and privacy requirements and the extent to which they leave the agency exposed to residual risks._36a72c30-ee0d-11e1-8564-e27f7fb1eeb4II.B.1.aLife Cycle CostsEvaluate life cycle costs required to fund the investment or modification. _36a72d8e-ee0d-11e1-8564-e27f7fb1eeb4II.B.1.bIf the alternative is already included in PO&AM, then use the costs from the POA&M in the analysis of the alternative. If not, then develop a cost estimate accounting for all life cycle costs associated with the alternative. All costs should also be risk-adjusted to account for foreseeable investment risks over the investment life cycle to facilitate comparison.InventoryEvaluate the agency’s inventory of approved technologies and services in the agency’s TRM or TRM-equivalent to identify the preferred standards. _36a72f14-ee0d-11e1-8564-e27f7fb1eeb4II.B.1.cSelect solutions consistent with the agency’s technical reference model. To reduce risks in the target environment, specific security and privacy investments may be needed in the technical and service infrastructures that are not addressed with the current security and privacy services and technologies.Gaps & ImprovementsEvaluate gaps or capabilities to be improved and prioritize one or more to be addressed through an investment of new funds or realignment of existing resources._36a73068-ee0d-11e1-8564-e27f7fb1eeb4II.B.2Whether addressing gaps at the programmatic or enterprise levels, ensure that enterprise needs are considered. Prioritize the selection based on: * Breadth of impact across the enterprise * Impact of the gap on the accomplishment of agency business * Relevance of the gap to outstanding POA&M items. Addressing these items is important because agencies must report the status of POA&M corrective actions to OMB along with associated risks.AlternativesEvaluate the technically viable alternatives._36a731c6-ee0d-11e1-8564-e27f7fb1eeb4II.B.2.aThe analysis of alternatives evaluates the technically viable alternatives through a systematic paring down of the potential alternatives to feasible ones to the most viable alternatives. Viable alternatives are established by examining: * The baseline environment and the requirements requiring attention * Potential alternatives – those alternatives theoretically possible of addressing requirement needs * Feasible alternatives – of the potential alternatives, those alternatives that can address the requirement needs given the constraints and limitations of the environment * Viable alternatives – of the feasible alternatives, those alternatives that can be realistically implementedCosts, Benefits & RisksAnalyze the costs, benefits, and risks of each viable alternative._36a73360-ee0d-11e1-8564-e27f7fb1eeb4II.B.2.bOnce feasible alternatives have been identified, an analysis of the costs, benefits, and risks of each viable alternative should be performed. OMB A-11 states that each prospective investment should include at least three alternatives (i.e., a baseline and at least two viable alternatives).InteractionConsider how cost, benefit, and risk interact._36a734dc-ee0d-11e1-8564-e27f7fb1eeb4II.B.2.cTo make sound investment decisions, decision-makers must consider how cost, benefit, and risk interact.Cash Flow Summary[Present] financial results in a time-based cash flow summary._36a73630-ee0d-11e1-8564-e27f7fb1eeb4II.B.2.dThe most useful financial results in an investment decision appear in a time-based cash flow summary. This summary is used to describe the alternative solutions considered for mitigating the capability gap that the investment is expected to address. Each alternative should provide comparisons of the costs over time for each alternative.Internally Deployed CapabilitiesAssess internally reusable capabilities._36a737d4-ee0d-11e1-8564-e27f7fb1eeb4II.B.3.a* Stage I activities promote the identifying security and privacy capabilities and mapping those capabilities to control families and the agency enterprise architecture. There are unlikely to be any applicable internally reusable capabilities when Stage II activities immediately follow the completion of Stage I. However, over time Stages I and II will become somewhat disconnected. A quick scan of the control families and agency enterprise architecture may yield unexpected solutions. * As part of this activity, evaluate the agency inventory of software licenses.Other Agencies' SolutionsResearch other agencies’ solutions._36a73932-ee0d-11e1-8564-e27f7fb1eeb4II.B.3.b[M]any agencies have similar security and privacy challenges and some have capabilities available for reuse centrally registered at http://www.core.gov/. Other capabilities may be found through inquiries to OMB or other Federal agencies.ISS LOBResearch opportunities for support through OMB’s Information Systems Security Line of Business._36a73a86-ee0d-11e1-8564-e27f7fb1eeb4II.B.3.cCommunities of PracticeJoin or establish relevant communities of practice around specific unmet requirements to facilitate the creation of capabilities that are broadly applicable across the Federal government._36a73dba-ee0d-11e1-8564-e27f7fb1eeb4II.B.3.dCOTSIdentify opportunities to obtain capabilities from the marketplace. (i.e., commercial off the shelf solutions) other agencies and evaluate the opportunities for cross-agency re-use._36a73f5e-ee0d-11e1-8564-e27f7fb1eeb4II.B.4Comparisonscomponents have been identified, comparisons can be made to the baseline and among the viable alternatives._36a740da-ee0d-11e1-8564-e27f7fb1eeb4II.B.5Gap & Legacygap analysis and legacy capabilities analysis._36a7429c-ee0d-11e1-8564-e27f7fb1eeb4II.C.1Formatsbusiness case formats._36a7440e-ee0d-11e1-8564-e27f7fb1eeb4II.C.2ITIRBITIRB._36a74576-ee0d-11e1-8564-e27f7fb1eeb4II.C.3SelectionSelect major investments._36a74724-ee0d-11e1-8564-e27f7fb1eeb4Stage IIICFOThe CFO and ITIRB begin by evaluating all proposals using consistent criteria. Ideally, the Stage II trade-off analysis is consistent with the evaluation criteria. The CFO and ITIRB are then merely enforcing expectations articulated in enterprise architecture principles and OMB Exhibit 300 budget justification criteria.ITIRBAgenciesAgencies should ... consider publicizing externally leveragable capabilities registered at http://www.core.gov or available through OMB’s Information Systems Security Line of Business (ISSLOB).Information Systems Security Line of Business (ISSLOB)The ISSLOB addresses four areas: training, FISMA reporting, situational awareness and incident response, and security solutions. ISSLOB centers of excellence may be able to provide needed security-related services.Stage III is an enterprise evaluation of the solutions proposed in Stage II and the selection of major investments. In Stage III the FEA SPP implementation team works with the CFO and ITIRB to integrate outputs from previous stages into the agency-wide capital planning process to ensure: * Evaluation of individual proposals so that each fully reflects the outputs of Stages I and II. * Selection of individual proposals that best support the business, security, and privacy needs of the organization. * Documentation of the updated to-be architecture and sharing of reusable components.FEA SPP[Consider] proposals in a manner consistent with FEA SPP activities and based on the adequacy of security and privacy considerations._36a748a0-ee0d-11e1-8564-e27f7fb1eeb4III.A.1Minimally Acceptable ProcessesDefine minimally acceptable processes for assessing proposals._36a74a12-ee0d-11e1-8564-e27f7fb1eeb4III.A.1.ai. the five enterprise architecture reference models. ii. the 17 security and 17 privacy control families. iii. the program selected the proposed option. The review of alternatives is an essential part of effective budget planning. Require program executives to incorporate the results of trade-off analyses into OMB and agency business cases to demonstrate informed risk-based decision-making and to comply with OMB and agency budget submission requirements. iv. Require compliance with OMB or agency business case criteria.26 This should include establishing an appropriate level of detail for security and privacy budget discussions.EvidenceDefine acceptable evidence to support those processes._36a74bd4-ee0d-11e1-8564-e27f7fb1eeb4III.A.1.bExitsting CapabilitiesExpress a preference for leveraging existing capabilities._36a74d50-ee0d-11e1-8564-e27f7fb1eeb4III.A.1.cConsistencyQuestion and closely examine justifications for deviations from the agency’s inventory of approved security and privacy-related technologies and services as described in the to-be architecture._36a74eea-ee0d-11e1-8564-e27f7fb1eeb4III.B.1.aSecurity and privacy controls that lay outside the current enterprise architecture are likely to be less effective, more expensive, and less interoperable. Consider whether the goals of such investments may be accomplished differently, within the context of the current enterprise architecture. Carefully weigh the implications of approving any deviation.NecessityEvaluate the need for new security and privacy capabilities._36a750ca-ee0d-11e1-8564-e27f7fb1eeb4III.B.1.bi. capability maps to one or more specific requirements and directly contributes to associated performance metrics. ii. new capability is necessary. New security and privacy capabilities should be designed to be leveragable beyond the immediate need.Enterprise RiskAssess risks accepted through the proposed investment. _36a7525a-ee0d-11e1-8564-e27f7fb1eeb4III.B.1.cDetermine the impact that security and privacy choices may have on the broader enterprise. i. aspects of proposed investments. Unaddressed security and privacy requirements may impact other parts of the enterprise and other interconnected organizations. ii. requirements. The IRB and program executives must understand risks associated with underfunding of security and privacy requirements. Lack of investment into mitigating identified risks will increase overall risk to an agency.CostAssess the adequacy of security and privacy-related budget lines._36a754e4-ee0d-11e1-8564-e27f7fb1eeb4III.B.1.dBudgetingEnsure that security and privacy are budgeting throughout the life cycle. _36a756ec-ee0d-11e1-8564-e27f7fb1eeb4III.B.1.d.iOMB budget preparation guidance requires specific budget allocation for security management.FundingEvaluate the adequacy of specific funding for functional and compliance activities across the 17 security and 17 privacy controls. _36a7587c-ee0d-11e1-8564-e27f7fb1eeb4III.B.1.d.iiFor example, do they include funding for mandated security and privacy assessments? Do they include funding to provide security and privacy awareness, training, and education?Other Initiatives, Technologies & ServicesDetermine if the agency can reduce costs by leveraging other initiatives or technologies and services used elsewhere in government, including leveraging specific services or the entire capability from other agencies._36a75a02-ee0d-11e1-8564-e27f7fb1eeb4III.B.1.d.iiiInvestments[Ensure that] all investments have corresponding security budgets._36a75c00-ee0d-11e1-8564-e27f7fb1eeb4III.B.2requires all investments to have corresponding security budgets included and explicitly indicated in the budget, unless they satisfy the security or privacy component through another budget line item. Highlight shared security and privacy investments to ensure that they are funded. Otherwise, investments that depend upon them will not have sufficient security and privacy and may not be compliant.CentralizationAssign highest priority to those proposed investments that provide central security and privacy capabilities._36a75da4-ee0d-11e1-8564-e27f7fb1eeb4III.B.2.aShared CapabilitiesAssign second highest priority to other IT investments that provide or leverage shared capabilities._36a75f52-ee0d-11e1-8564-e27f7fb1eeb4III.B.2.bUnique CapabilitiesAssign lowest priority to IT investments that do not provide shared capabilities._36a761aa-ee0d-11e1-8564-e27f7fb1eeb4III.B.2.cCost Reduction & Increase in Functionality & Interoperabilityopportunities to reduce cost, increase functionality, and increase interoperability._36a76362-ee0d-11e1-8564-e27f7fb1eeb4III.B.3CentralizationIdentify opportunities to centralize capabilities ... _36a76510-ee0d-11e1-8564-e27f7fb1eeb4III.B.3.aSenior Agency Official for Security[T]he senior agency officials for security and privacy should conduct a trade-off analysis to determine the best approach to centralizing capabilities.Senior Agency Official for PrivacyDiversity of StandardIdentify opportunities to appropriately reduce (but not eliminate) diversity of standards and approaches for accomplishing security and privacy objectives. _36a76736-ee0d-11e1-8564-e27f7fb1eeb4III.B.3.bSuch changes may have a positive impact on security, privacy, interoperability, and cost, but should not be undertaken without careful consideration of the up-front costs, and especially the impact on accomplishing agency business objectives. Periodically assess the inventory of approved technologies and services to determine their sufficiency for the target architecture and/or new investment proposals.BudgetHighlight residual risks associated with unfunded proposals._36a768ee-ee0d-11e1-8564-e27f7fb1eeb4III.B.4To-Be ArchitectureUpdate the to-be architecture after each budget cycle to reflect new investments and associated residual risks. _36a76a9c-ee0d-11e1-8564-e27f7fb1eeb4III.C.1.aThe to-be architecture should portray the security and privacy features of the enterprise’s mission and characterize its exposure to risks of the agency’s enterprise architecture components. i. (e.g., privacy, medical, proprietary, financial, contractor sensitive, trade secret, investigation); and ii) information systems (e.g., mission critical, mission support, administrative). ii. guidance in NIST SP 800-59, Guideline for Identifying an Information System as a National Security System. iii. categories in accordance with FIPS PUB 199 and NIST SP 800-60.Transition PlanUpdate the enterprise transition plan after each budget cycle to reflect activities supporting new investments._36a76c9a-ee0d-11e1-8564-e27f7fb1eeb4III.C.1.bRelate security and privacy funding request to agency Enterprise Architecture components including transition plans. Effective impact analyses to the enterprise as a whole will include architecture analyses. Investments are a component of the transition plan and may impact other ongoing or concurrent investment plans, as well as the ultimate target architecture. Ensure that the transition plan reflect risk mitigation for residual risks.ReportGenerate a report from the agency’s enterprise architecture summarizing security and privacy features across each architecture component or reference model._36a76e52-ee0d-11e1-8564-e27f7fb1eeb4III.C.1.cDrivers & Funded ElementsSummarize key security and privacy drivers and enumerate the elements of the transition strategy that are funded._36a7700a-ee0d-11e1-8564-e27f7fb1eeb4III.C.1.c.iThe report should summarize key security and privacy drivers (including trust agreements established with external entities exchanging information) and enumerate the elements of the transition strategy that are funded to manage the security and privacy risks associated with fulfilling the mission of the agency.BaselineUse the report and the agency’s enterprise architecture as a baseline for future FEA SPP iterations and with each update of the enterprise architecture and/or budget cycle._36a7724e-ee0d-11e1-8564-e27f7fb1eeb4III.C.1.c.iiInternal AwarenessEnsure internal awareness of major security and privacy capabilities._36a77410-ee0d-11e1-8564-e27f7fb1eeb4III.C.2.aThe enterprise should ensure internal awareness of major security and privacy capabilities. Document and publicize available shared security and privacy capabilities with program developers responsible for implementing and maintaining business processes and systems. This may begin as an artifact of the agency enterprise architecture system. Outreach and publicity may provide valuable assistance to programmatic trade-off analysis efforts.Promotion & SharingPromote and share security and privacy capabilities with other Federal agencies._36a775dc-ee0d-11e1-8564-e27f7fb1eeb4III.C.2.bFederal AgenciesThe agency should consider promoting and sharing security and privacy capabilities with other Federal agencies. Publish sharable security and privacy capabilities to http://www.core.gov.2006-06-012012-08-24http://www.cio.gov/documents/Security_and_Privacy_Profile_v2.pdfOwenAmburOwen.Ambur@verizon.net