Anyone working in the world of cloud-based, Software-as-a-Service (SaaS) applications has undoubtedly heard mention of shifting left, basically focusing on security requirements earlier in the Software Development Lifecycle (SDLC). Fortunately, it’s getting easier to do so. With the recent wave of developer-friendly solutions that enable end-to-end automation of Continuous Integration/Continuous Delivery (CI/CD) pipelines and NIST’s Open Security Controls Assessment Language (OSCAL) automation framework, there is even less reason to ignore bringing development, security, and testing together early in the SDLC.
Why is Shift Left so important?
As systems become more complex and more cloud solutions are adopted, defending against cyberthreats while meeting business needs of the organization can seem like a challenging balancing act. Here are four reasons why shifting left is key to ensuring security doesn’t remain an afterthought:
-
Security matters. There is really no world anymore where security doesn’t matter, regardless of the use case and purpose of a software application. Adversaries look for the weakest link to gain access to an organization’s crown jewels – and applications make for good launch pads. All SDLCs are a version of a Define-Design-Build-Test-Deploy-Operate-Monitor process. At each step, and throughout the process, security and compliance considerations should be weighed.
-
Compliance matters. An application may need to support multiple regulations, depending on the type of data processed and maintained and whether financial transactions are processed. Not only do regulatory standards and frameworks change over time, they can conflict, overlap in scope, and be difficult to manage together. Addressing an application’s security and privacy risks earlier in the development cycle simplifies the complexity of complying with multiple frameworks.
-
User experience matters. User experience (UX) architecture, like security, should not and at times cannot effectively be addressed as an afterthought. These are two things that are overwhelmingly significant to all applications but are routinely pushed to the right. All too often they are largely ignored during the define, design, and, sometimes, build phases where they needed to have been considered. Both need to be baked in rather than bolted on after-the-fact.
-
Keeping up with the pace of change matters. Development teams are under constant pressure to extend functionality and improve the performance of systems and applications. When developers are forced to compromise between speed and security, security runs the risk of becoming an afterthought. If you don’t take the time to do it right, you WILL be forced to do it over. Shift left is all about doing it correctly right out of the gate… to prevent expensive and time-consuming rip-and-replace efforts that will inevitably be required down the road.
5 Ways to Shift Left
Just as it doesn’t do to leave a dragon out of your calculations if you live near one, it doesn’t do to leave best practices out of the mix as you move security sooner in the development process. Here are five considerations to take into account as you shift security left:
-
Definition and planning: Include a Security Categorization Analysis, guided by NIST’s Standards for Security Categorization of Federal Information and Information Systems (FIPS 199), as a part of the define step. FIPS 199 provides guidance based on the confidentiality, integrity, and availability of an information system and the data it processes. Understanding the types of data, and the impact of a breach that would reveal that data, matters. Just like you need to know your users and their use cases before building an application, you need to understand the risk posture your solution will likely possess, the sensitivity of the data to be processed in your application, and the risk tolerance of your target customer base.
-
Solution architecture and design: Involve a person with cybersecurity compliance experience (an assessor, ISSM, or ISSO) during solution architecture and design. In cybersecurity, the implementation boundary is critical, as it provides known constraints that make an application more easily defensible. The boundary will matter when trying to obtain a compliance certification. There are many decisions that impact the ability to meet future security compliance baselines – decisions about access control; identity management; multi-tenancy; encryption for data collection, data transport, and data storage; and the use of external services and libraries – all of which may come back to haunt a team when they are faced with requirements around security controls.
-
User story and test plan success criteria: Include security compliance criteria as a part of each user story’s success criteria and ultimately as a standard part of test planning and execution. In the evolution of “requirements,” development has already evolved from relying solely on system specifications to incorporating user stories – with the goal of bringing the UX and benefit to the user front and center as a guiding factor for any product feature. Why not do the same for security by defining expected security and compliance outcomes? NIST’s OSCAL is an automation framework designed to automate the implementation, assessment, and monitoring of cybersecurity controls compliance. The OSCAL framework could be leveraged to develop tools that automate cybersecurity compliance assessments at multiple points along the SDLC in a highly standardized manner, to validate the effective implementation of incorporated controls as well as inform the team of control gaps. While this type of automation won’t cover all types of controls, it would make a big dent in those controls that guide technical (machine-measurable) configurations.
-
Sprint and release backlog management: Involve a person with security assessment, ISSM, or ISSO skills in sprint planning, user story reviews, and feature consideration. While developers and product owners focus on user requirements, someone needs to be focused on the potential security impact of every application update decision. Again, this shouldn’t be an after-thought. The idea of iterative and continuous analysis of the impact application updates have on security needs to become the norm.
-
Application testing approach: Introduce the right application code testing along the way. This includes vulnerability scanning early and often throughout development, leveraging tools such as:
- White-box “from the inside” Static Application Security Testing (SAST) to identify and inform defect correction early in the development lifecycle.
- Black-box “from the outside” Dynamic Application Security Testing (DAST) to provide assessments of the application without requiring access to the raw code.
- Operational testing through Interactive Application Security Testing (IAST) for analysis of operational applications.
- And finally, production-environment Runtime Application Self-Protection (RASP) to identify and address issues and attacks happening real-time in a production environment.
With the rapid proliferation of cloud-based applications and accelerated DevOps processes, the traditional software development process has become a thing of the past. It’s time to shift left. By identifying cybersecurity needs and probable governance, risk, and compliance requirements early in the life of an application, teams can save time, money, and headaches by building to those requirements from the start.
Speed of delivery doesn’t need to be compromised by adding security to the mix. Constellation GovCloud accelerates compliance efforts for Software-as-a-Service (SaaS) providers wanting to serve federal, state and local government customers. By removing the friction legacy approaches create between development, security, and operations teams, your cloud service offering will be ahead of the curve in its journey to federal.
