Summary

The GeoScout Security Engineering and Architecture team has insufficient resources (both in number and capability) to ensure the successful, timely, and well-documented deployment of a secure GIMS. The team’s original placement under SE&A activities constrained its scope to the design phase, whereas the security discipline is required throughout the system development lifecycle. Funding for Security Engineering has been cut drastically as the architecture reaches maturity, yet the Development and IV&T phases have ongoing security needs that now are in jeopardy. Recommendation is to establish a core Security Architecture Team of 6 FTE with specific, well-defined security skill sets to adequately address the myriad continuing security issues on schedule, and establish ‘security liaisons’ within key elements and products to facilitate communication with Subject Matter Experts.

Background

The Security Engineering and Architecture team is responsible for a range of GIMS deliverables and responsibilities. The deliverables include the Security CONOPS, Security Requirements Traceability Matrices, Security Composite View, Data Owner’s Guide, and Security Policy Appendix. Other equally-extensive responsibilities revolve around the mandate to ensure security controls and services are implemented across all 5 program elements and 19 products, as well as in interfaces with external customers, Legacy / Heritage systems, and GIMS-associated ECP, ROM, & RFC.
Following the 50%-DAA event, the Security Architecture and Security Engineering teams together stood at 10 FTE. In addition, an internal-facing Chief Security Architect (1 FTE) addressed security issues at programmatic level, and an external-facing Chief Information Security Officer (1 FTE) coordinated with NGA and Intelligence Community customers. This scope ensured the security presence spanned the depth of the program. Presently, the program Chief Security Architect position has been eliminated, and the post-milestone consolidated Security Engineering and Architecture team has been reduced to 3.5 FTE from 10 FTE. However, the daily workload and program responsibilities of the Security team have not appreciably declined.

Furthermore, the scope of GIMS necessitates a security team with technical expertise in each of several areas: Computer Network Defense, Network Communications and Encryption, Identity Management, Web Services and SOA, Application Security, Platform Security, Data Security, and Security Requirements & Governance. The current FTE levels supporting these activities are insufficient to adequately meet schedule and program requirements. This lack of resources will result in frequent adjustment and re-prioritization of tasks and deliverables to favor each day’s ‘emergency’ issues. Schedules and deliverables will be forced to slip—as is currently happening with work on the Security Policy Appendix—and milestone achievement will be put at risk.

Recommendation

Organize the Security Engineering and Architecture team within the program so that it is not dependent on SE&A funding and can span the System-Development Lifecycle. Expand the size of the team as necessary (6 FTE, minimum) to ensure each technical area is covered by at least one team member (more in critical areas such as Identity Management, Web Services, and Network / Infrastructure Security). Assign one engineer from each program element, and from each product team with critical impact, to be a designated liaison to the Security Architecture team.
Approach: Aspiration Software has prepared an initial integrated work plan that matches existing team requirements with program milestones, ensuring technically-fluent deliverables are produced on schedule and product teams are given expert guidance implementing security controls.

The work plan identifies Security Engineering tasks over the next several months, the FTE required and currently available for each, and the time period over which the work is performed. Detailed work descriptions are listed for each work stream, and benefits of inclusion and risks of exclusion for each are identified to underscore the consequences of not providing critical, required services. The tasks are grouped so that they can be individually selected on a line-item basis, and necessary FTE easily determined to match available funding levels.