Security For Modern Engineering - .microsoft

maintain development infrastructure that support continuous integration/continuous delivery (CI/CD). 3.3.1 The modern engineer Engineers in the modern engineering world must play multiple roles. Everything from gathering customer feedback and requirements, design, coding, testing, deploying to production, and even support, are all under the purview of a modern engineer. Just as the SDL is agnostic to any specific development methodology, practice, or tool, the concepts in this showcase whitepaper apply to this modern engineering world, broadly speaking. Our goal is to empower modern engineers with a set of tools, guidance, and processes to empower them to write, deliver, and maintain more secure applications and services. 3.3.2 The Microsoft IT model Microsoft IT has been on a journey to adopt a modern engineering model. Because business customers are demanding faster and faster turnaround on solutions and feature requests, gone are the days when a business waited for a quarter or longer for new features, solutions, or bugs fixed in their applications. To respond to this growing need for efficiency and quicker delivery, Microsoft IT has been transitioning to a modern engineering model. This transition includes merging development and operations roles (DevOps) and using agile development principles, practices, and tools to shorten release cycles. With an agile methodology, Microsoft IT provides the flexibility and speed with which solutions are released in as short a time as operationally feasible. Agile teams are receiving faster customer feedback though an iterative design and feature approach, and mature agile teams often release every day or even multiple times a day. While this is great for business enablement, this poses a huge challenge for security in terms of how to effectively and efficiently drive security and privacy in these CI/CD scenarios. For example, consider a security process that takes two weeks to complete sign off on a release. This model plainly fails when applied to an agile application which may take, for example, a single week to ideate, create, and be ready for release. Additionally, the more traditional security approach – to review every application release – worked well when release cycles spanned months, but this approach is highly inefficient against modern engineering practices where schedules are much more condensed. Given the ubiquity of customer data and critical data, security and privacy are of utmost importance to consumers. For example, would you feel comfortable using a banking application on your mobile phone if security and privacy aspects were overlooked by the engineers? Security can be friction, but it can’t be completely ignored either. 9

So, this is our challenge: “How can we make security low friction (efficient) while maintaining its effectiveness in this new world of modern engineering?” This challenge demands that the security culture and approach are modernized and adapted for shorter release cycles and sprints. Security teams must support decentralized security processes, but they must also drive greater automation and move beyond point-in-time assessment practices. Under these modern engineering challenges, they need to adopt a solution that can scale and that can provide continuous assurance. 3.4 Our journey The ISRM team has been on a journey to evolve and enhance our approach to the SDL so that we are more aligned to DevOps and to modern engineering practices. The intent of this whitepaper is to share some of our lessons learned to date and to hopefully spark a dialogue in the security community. We recognize that there is no perfect solution – every business has its own unique circumstances and factors that impact its security requirements. The journey to align to this changing engineering culture keeps us motivated to address the challenges it throws our way. We will also discuss some of the key trends we see in application security that have started to redefine not just how we look at application security but how application security processes such as the SDL are completely re-scoped. For example, with development roles merging with operations, application security processes also need to evolve to effectively secure the Ops in DevOps. Finally, we’ll close by sharing some of the lessons we learned in this journey of driving security into modern engineering practices. 4 A closer look at the challenges 4.1 DevOps culture An emerging aspect of IT culture, DevOps is defined in several ways across the industry. The following is one example: Gartner “DevOps represents a change in IT culture, focusing on rapid IT service delivery through the adoption of agile, lean practices in the context of a system-oriented approach. DevOps emphasizes people (and culture), and seeks to improve collaboration between operations and development teams. DevOps implementations utilize technology — especially automation tools that can leverage an increasingly programmable and dynamic infrastructure from a life cycle perspective.” We don't want to single out DevOps, or say that the concepts discussed in this whitepaper work only with DevOps, because it can be difficult to identify a common definition of DevOps. For the 10

purpose of this discussion, the important aspect of the DevOps movement is to recognize certain fundamental principles that define for us what we consider “Modern Engineering.” For more information, see Appendix A. The principle focus is around people and culture. Development roles and operational roles have merged, and the expectation from a service or software engineer is not just to develop and test code, but also to be able to deploy and operate the code effectively. Engineers have full control over the runtime environment so they can build with predictability. This avoids the "throw it over the wall" mentality that can occur when development hands off to operations. 4.2 DevOps and security One of the single biggest reasons teams adopt a DevOps model is to enable CI/CD to address business demand. The key principles of focus are: Speeding up the pace of innovation by shortening the release cycles using agile methodology, and maintaining control over the entire technology stack (from code through to the infrastructure and operational practices.) Enabling faster feedback loops from customers which can result in application features and bug fixes. FIGURE 1 COMPONENTS OF D EVO PS Considering these principles as key components of modern engineering, anything that gets in the way of this process is friction. More traditional approaches to software security assurance, that rely on gates, are seen as friction in modern engineering practices. Here are a few examples: 11

4.2.1.1 Manual security assessments Typical white box code or black box security assessments last anywhere from few days to few weeks depending on the size and complexity of the application. With application development sprint cycles shrinking to days, just engaging security teams and scheduling code reviews is a challenge, let alone reviewing anything on time. This time-consuming process is counterproductive for the needs of business and engineering teams because it is clearly a speed bump for fast-paced release cycles. 4.2.1.2 Security compliance/Attestation processes Any security attestation processes with lengthy questionnaires may seem complete, but they can also be seen as merely a compliance checkbox exercise with little or no impact on the security of the system being engineered. This not only adds friction but adds limited value to the engineering teams, especially if the process mandates attestation for every release. At the very least, self-attestations help convey a set of baseline expectations and drive awareness. However, self-attestation for every release is not an effective security control within the fast pace of modern engineering release cycles. To better understand this challenge within Microsoft, we decided to do multiple feedback sessions with our engineering teams. We did this through Voice of Customer (VoC) sessions to understand the pain points and challenges the engineering teams experienced. 4.3 Additional requirements When you look a little deeper at these more traditional software security practices that require manual review and at the demands of modern engineering, two fundamental requirements emerge: continuous assurance and intelligent automation. Continuous assurance is needed to maintain a secure posture and intelligent automation can help scale and keep pace with faster release cycles. 4.3.1 Continuous assurance With old protracted development lifecycles, doing point-in-time assessments to help define a security assurance level of software may have been sufficient, especially when a software application went through infrequent changes in production. But with continuous releases, pointin-time assessments don't work as effectively. We have to provide continuous assurance that is embedded in the process. Software can be viewed as a living entity that requires continuous assurance after release, particularly in light of CI/CD. DevOps and security cannot be disparate silos any longer (a fact now understood in the industry and coined as DevSecOps.) We need to start thinking about DevOps as a culture that is not only about merging development and operations, but also about how security responsibilities are merged and shared over time. Security teams will become the provider of these continuous assurance services ranging from network, host, and application security that engineering teams will consume to maintain secure applications. 12

4.3.2 Intelligent automation It's natural for any security team to look at some of the challenges articulated thus far and assume that automation is the solution. It’s correct that automation is a big part of any solution. However, automation is very easy to get wrong and very hard to get right. A common response is for security teams to find a wide range of automation tools and “throw them over the wall” at engineers. In our experience, this doesn't always work for two primary reasons: Running tools isn’t enough If tools are pushed as a quick fix, using them can turn into a compliance activity rather than a way to reduce risk. Teams may run the tools, but perform little action based on the output of the tools. Thus, we’ve lost the end goal of automation. To do it right, it’s important to carefully drive selected metrics to help engineers take action effectively. The tools alone aren’t a quick fix, but should instead be a part of a well-thought-through solution to advance security goals. Tool fatigue is common The feedback we received from VoC sessions revealed that engineers can start to experience tool fatigue if too many tools are thrown at them for compliance. Careful planning and deployment of tools is key to ensure this does not become a pain point. It’s important to understand that the solution to the challenge of maintaining CI/CD and security compliance is not just automation. We needed intelligent automation that can yield the kind of information that engineers can act on to drive positive impact. 5 Our approach Our approach to the challenges is itself an agile one in which we are evolving the solution through incremental feedback and updates. We are on this journey to evolve and to enhance how we integrate security with modern engineering and how we enable our engineering teams to succeed. The following are the four core tenets around which we are building our solution: FIGURE 2 FOUR CORE T ENETS 13

5.1 Knowledge management Having a sound knowledge management process is one of the key aspects of any effective security solution. Underneath any SDL process are the requirements, which we call Technical Control Procedures (TCPs). Defining clear technical requirements for engineering teams is the foundation of an SDL program, and over the years our Control Assessment Library and Methodology (CALM) board has continuously refined our requirements. 5.1.1 CALM board A successful knowledge management solution ensures that there is a governance process to constantly refine and refresh the requirement set. We do this by keeping our TCPs up-to-date through our CALM board. Subject matter experts (SMEs) from across the security teams sit on this board. The CALM board meets monthly and makes updates to specific TCPs so that engineers have the most up-to-date controls. They continuously evolve the library, and they make sure controls are relevant with the changing security landscape. 5.1.2 Technical Control Procedures TCPs are the actionable security controls that engineering teams must implement during the development of applications. TCPs are the minimum bar for security standards that all LOB applications must meet. TCPs are technical or process-oriented and are defined to be agnostic of technology. The following are a few examples of areas these requirements cover: 14

FIGURE 3 AREAS OF COVERAGE FOR TCPS TCPs are built around positive instead of negative attributes and are focused towards engineering teams. We identify what the known positive controls are that a system should implement to be secure. In our taxonomy of a TCP, we define (among other attributes): How to implement Implement the control or safeguard in an application. How to verify Verify the technical control procedure to measure if it is correctly implemented or needs improvement. Why to implement Align to company security standard(s) and policy for compliance measurements. The following are few example categories from the TCP library and their underlying procedures: 15

TABLE 1 TCP CATEGORIES TCPs are the backbone of everything we drive with the engineering teams. The following are areas of the SDL to which TCPs are integral: Core guidance to our development engineers TCPs are the avenue by which we deliver core guidance to our engineers about how controls must be implemented and about their applicability. TCPs are the super set of security controls, and we hold our engineering teams accountable to them through the SDL process. Security control assessment criteria When an application is selected for a security assessment, all the applicable TCPs based on the

build security into the process while staying true to the discipline of the acclaimed Microsoft Security Development Lifecycle (SDL). By teaming with us in HPE Security Fortify, Microsoft has enabled effective, unobtrusive application security automation at scale that provably secures their applications and saves time and money during development.