The White House is currently spearheading two separate but equally essential multibillion-dollar tech initiatives on cybersecurity and federal IT modernization.

On one hand, the White House is implementing a $3.1 billion initiative that emphasizes the increased use of agile software development — a flexible approach that was born in the private sector but is quickly being adopted as the de facto standard for the public sector. Simply stated, agile, lean and DevOps represent modern, IT-based applications of proven quality management approaches with the goal of expediting the delivery of high-quality systems. The foundation for these methods is built on a cultural mindset of continuous improvement, process automation, performance measurement, data-driven decisions, and collaboration and sharing among multidisciplinary teams.

In coordination with this initiative, the White House is driving agencies and their industry partners to advance the state of cybersecurity and data privacy in its IT systems through implementation of the Cybersecurity National Action Plan. This plan takes a multidimensional approach toward tackling the nation's cyber challenges by, among other activities, establishing a federal chief information security officer role, establishing coordinated cyberattack response plans, investing more in cybersecurity education across the federal workforce, and improving governance models to ensure cybersecurity practices are implemented and reinforced as a part of development and maintenance activities. 

The catch? Neither will succeed until it's made clear that these topics are inexorably linked.

Yes, many federal government agencies need to modify their software development life cycles to allow for the adoption of modern agile and DevOps practices; but, if done improperly, that could leave its systems even more exposed to cyberthreats than before. So how does an agency actually integrate security into emerging, lean development methods?

There is a crucial need to approach agile with an eye toward building security into the software development process. While the government can optimize the way it buys, deploys, and maintains technology, doing so cannot be at the expense of software assurance or data privacy.

This means a new strategy specialized for federal government environments that we'll call Secure Agile Development. To make Secure Agile Development a reality, here's a checklist of what federal leaders need: 

1. A "Security Intelligent" Delivery Team

The intersection of security and mission has to be transparent to the entire team. Each team member – from business analyst to architect to developer – must be security intelligent. Integrating an information security engineer into the team's activities is absolutely required at key junctures of the development process (e.g. release planning, architecture reviews), but having a dedicated security professional embedded within each scrum team throughout the entire development process can be challenging from a scale perspective. For that reason, the development team needs to be trained on the current and impending regulatory security requirements (e.g. Risk Management Framework, ICD 503, DISA STIG), and how those compliance and security controls will affect the design, validation and deployment of the system under development. They should also be fluent in agency-specific systems development life cycle governance models (e.g. VA's Veteran Integration Process, DoD 5000), and how modern methods and tooling can be leveraged to meet these requirements with agility. The development team can then address these non-functional security and compliance requirements as technical stories, apply them to the backlog, and implement as a part of its normal lifecycle.    

2. Technical Acumen and Continuous Automation

Agile methods and DevOps practices provide a continuously broadening landscape of tools and utilities to automate and expedite the construction, validation, deployment and monitoring of systems under development. The challenge is understanding how best to harness these tools so security controls are addressed as a part of the delivery process. Agile teams should conduct iterative threat modeling as a part of architectural sprints, developers should include secure development techniques — such as the OWASP Top 10 Proactive Controls — as a part of their coding practices, and automated security scans and unit tests should be included as a part of continuous integration for each code commit so a transparent, real-time view of the system's security posture is always available. Integrating automated security test scripts to verify security features, such as authorization, authentication, field level validation, and PII/PHI compliance as a part of continuous integration and continuous delivery activities is a great example of how modern development methods are helping to advance the state of secure development.

Secure agility obviously doesn't stop at the application layer — your security strategy must address the entire technology stack to include secure containers, network, firewalls and operating systems, some of which can be made easier with emerging container scanning and "compliance as code" utilities.

And as part of the DevOps process, dynamic and continuous network monitoring should be put in place to actively discover vulnerabilities or active attacks. What is secure today may not be tomorrow; a secure DevOps approach will address emerging and creative new attacks and threats.

3.  A "Secure First" Culture

Adoption of agile and DevOps methods is a "team sport" — and so is the integration of security controls. What we're seeing is that organizations can learn some of the standard development practices for efficiency, but then run into historically common barriers when attempting to deploy production code on a more frequent basis.

The "waterfall model" of deploying systems to the authorization and accreditation (A&A) team, and waiting extended periods for an authority to operate (ATO) can be optimized to meet an agency's goals for expedited delivery of secure, high quality code. Incorporating representation from the branch's or agency's information assurance or A&A body into the story elicitation and prioritization process reinforces a shared understanding of the requirements which need to be satisfied to achieve an ATO, and iteratively validating compliance against those controls throughout the development lifecycle, has been shown to reduce the time to the ATO, allowing for more frequent delivery of secure and compliant capability.

4. The Tools and Mindset for Change 

The importance of change management can't be understated. Similar to how modern software systems are developed, it's best to take an incremental approach toward this organizational transformation by starting small, inspecting, adapting, and changing throughout this journey.

For example, a team can pilot new "compliance as code" practices on a system one module or service at a time, until it becomes the de facto approach for all developers, or start to include the agency's information security representative in release planning activities to review the threat modeling approach for upcoming release.  Test the use of a wiki-based platform to iteratively generate and collaborate on security-based documentation, as opposed to creating a voluminous standard document. The key is to provide constant feedback, measurement, and reevaluation of your secure software development practices so they can ultimately be institutionalized.

Employing "agile coaches" — experts in the agile mindset and implementation techniques — to drive organizational or project level change management is a proven transformation approach. Other change management activities typically include:

  • Organizational training on agile and security standards starting at the executive level;
  • Establishment of a leadership sponsor who is responsible for the institutionalization of the new processes;
  • Reinforcement and governance on the use of secure design and coding standards, automated security testing utilities, and lean processes; and
  • Collection and internal communication of agile success stories and metrics to evangelize the adoption of lean development processes.

A deliberate plan for change, led by experienced professionals is required to transform an agency’s delivery model — this is the difference between "doing agile" and actually "being agile."

A Look Ahead

As the federal government continuously seeks to modernize its IT systems, development teams will need to know how to build security into modern architectures, development methods, and deployment practices (e.g. microservices, infrastructure as code, containerization). The Cybersecurity National Action Plan is a significant step by the federal government toward partnering private and government industry to address the cybersecurity threat. Additionally, the government issued a new FAR regulation (48 C.F.R. Part 4.19) this past June that establishes minimum safeguarding information system requirements for federal contractors.

Going forward, organizations will need to be able to quickly stand up their systems in compliant, secure cloud hosting environments and the guidance above will give organizations the tools to do so efficiently and effectively.

Gary Labovich is an executive vice president at Booz Allen Hamilton leading the firm's Systems Delivery Group where he is responsible for supporting the capture, execution and delivery of the firm's $1B+ software development business. Labovich leads a team of technology experts in promoting software development best practices, promulgating standards and processes, and engaging in large, complex proposals.

Share:
In Other News
Load More