Security for Modern Engineering Information Security & Risk Management
Download 132.18 Kb.
|
- Navigate this page:
- 4A closer look at the challenges
- 4.2DevOps and security
- 4.2.1.1Manual security assessments
- 4.2.1.2Security compliance/Attestation processes
- 4.3Additional requirements
- 4.3.1Continuous assurance
- 4.3.2Intelligent automation
3.4Our journeyThe 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. 4A closer look at the challenges4.1DevOps cultureAn 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 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.
Figure Components of DevOps Enabling faster feedback loops from customers which can result in application features and bug fixes.  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: 4.2.1.1Manual security assessmentsTypical 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.2Security compliance/Attestation processesAny 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.3Additional requirementsWhen 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.1Continuous assuranceWith 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, point-in-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. 4.3.2Intelligent automationIt'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:
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.
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. Directory: download download -> Performance Tuning Guidelines for Windows Server 2008 May 20, 2009 Abstract download -> Northern England’s set-jetting locations download -> Bbc archives: Beyond the programme download download -> Occupational health and safety download -> Dynatest 3031 lwd light Weight Deflectometer download -> Forth coming competitive exams download -> English Olympiad Tasks: 10 th form Аудіювання, 10 клас. Текст download -> Brush High School Morning Announcements Friday, September 05, 2014 all school download -> Year 9 The Arts — Music download -> Years 7 and 8 standard elaborations — Australian Curriculum: Music draft Download 132.18 Kb. Share with your friends:
|