Tag: implementing DevSecOps

  • DevSecOps Practices Gap Assessment

    DevSecOps Practices Gap Assessment

    DevSecOps practices are essential to deliver software safely and securely withinDevOps value streams.

    To get the maximum security protection from DevSecOps, it is important to use recommended best practices, inclusive of people, processes and technologies. A gap assessment is a great way to efficiently evaluate an organization’s practices for DevSecOps and determine a strategy for improvement. Gap analysis provides valuable inputs for formulating a strategy and roadmap to improve a topic including DevSecOps.

    My SlideShare Gap Survey, Assessment and Analysis For DevSecOps explains how my 9 Pillars Gap Assessment Tool greatly speeds up the gap survey, gap assessment and gap analysis process for DevSecOps.

    It is important to clarify a few definitions for these purposes, because I have found that different people and organizations use these terms differently. In this blog, and in my consulting work, I use the following definitions:

    • Gap survey is discovery tool used to collect information about the current state of practices for a topic.
    • Gap assessment is a process to determine differences (gaps) between current practices and recommended practices for a topic. Gap assessment is also used to refer to the entire collection of activities in this list.
    • Gap assessment workshop is a meeting in which the gap assessment is validated prior to gap analysis.
    • Gap analysis is the process of determining priorities for reducing the gaps found during a gap assessment.
    • Gap assessment tool is software that helps perform gap surveys, gap assessments and gap analysis.

    For those that want to dig deeper on this topic, additional definitions and contextual information related to the way I do gap assessments are clarified in my book Engineering DevOps.

    I define a seven step process for gap assessments. The steps are as follows:

    1. Pick a topic to analyze. The same processes and tools can be applied equally well to almost any topic.
    2. Determine recommended practices for the topic. Something that is worth doing a gap assessment for, such as DevSecOps, will normally be fairly complex with tens, if not hundreds, of practices. Categorize the practices into groupings (I call the groups “pillars”) to make the list of practices more understandable and meaningful. Doing this will require some research and work. For example, I have a database of practices and pillars for DevOps, continuous testing, DevSecOps and SRE and some other topics such as containers.
    3. Enter the chosen practices into a gap assessment tool. The tool can be a simple survey tool you create, a commercial survey tool or something custom-made.
    4. Determine who needs to be included in the gap survey.
    5. Collect data using the gap survey.
    6. Perform a gap assessment.
    7. Perform a gap analysis.

    Let’s take a look at the above seven steps for DevSecOps.

    Step 1: Pick a Topic to Analyze

    For our purposes here, the topic is DevSecOps.

    Step 2: Determine Recommended Practices for DevSecOps

    For an example DevSecOps assessment, I used the practices under nine practices categories described in a blog that I co-authored called 9 Pillars of Continuous Security Best Practices. The nine practice category pillars are:

    • Leadership
    • Collaborative culture
    • Design for DevOps
    • Continuous integration
    • Continuous testing
    • Continuous monitoring
    • Elastic infrastructure
    • Continuous delivery
    • Continuous security

    Step 3: Enter the Selected Practices into a Gap Assessment Tool

    You can find and download a free gap assessment tool, pre-loaded with a sample of DevSecOps practices in a file called DevSecOps Assessment, from one of the resource pages found on my website, EngineeringDevOps. You can edit the practices categories and add/delete practices from each category if you prefer to make changes.

    Step 4: Determine Who to Include in the Gap Survey

    For the gap analysis to be comprehensive, people in roles that are affected by container practices need to be surveyed, or at least represented, to ensure their perspectives are included. Some example roles that are typically included:

    • Business leaders – because leaders influence culture and budgets for DevSecOps.
    • Developers – because developers need to design in accordance with DevSecOps practices.
    • Project owners – because they influence product work priorities.
    • QA testers – because they need to test in accordance with DevSecOps practices.
    • Ops – because DevSecOps practices affect operations.
    • Security – because DevSecOps practices affect security practices.

    The survey can be conducted for an individual application, a group of applications or all the applications in the enterprise. However, it is important that the gap assessment and gap analysis be performed on the organizational segment that is being targeted for improvement.

    Step 5: Collect Data Using the Gap Survey

    A gap survey should allow each surveyed person to enter an “Importance Level” score, a “Practice Level” score and comments for each practice. All this information is essential for the gap assessment and gap analysis. In the gap survey included in in my gap assessment tool, survey respondents are asked to score the importance of each practice as one of 0=not relevant, 1=not important, 2=nice to have, 3=important, 4=very important or 5=critical. Practice-level choices are 0=not sure, 1=rarely, if ever, 2= sometimes, 3=most of the time, 4=always or 5=we are good at this. Comments that are relevant to qualify or explain the scores entered for each practice should also be entered, especially if there is any doubt or ambiguity.

    Step 6: Perform a Gap Assessment

    The gap assessment process requires all the practices scores collected from the surveys to be collected and assembled to calculate an aggregate set of scores. Gap scores are calculated using a formula that weights each practice level score with the corresponding importance level score. A visual representation helps to identify practices areas and individual practices that have the highest, most important gaps.

    No matter how professionally written the practices and score definitions are, it is not unusual for some people to misunderstand and to enter scores that they would not have otherwise. For this reason, it is important to ensure that the data collected is validated before conducting the gap analysis. The preferred approach is to conduct a gap assessment workshop with key representatives from each role that participated in the survey. During the workshop, the scores for each practice that have a high deviation between survey responses are discussed and, if necessary, adjusted.

    Step 7: Perform a Gap Analysis

    The gap analysis process involves extracting the high gap practices and tagging and ranking each of them against solution categories that are determined by a consultant or topic expert.

    The result of the gap analysis indicates where solution strategies and implementation roadmaps need to be focused to reduce the most important gaps.

    What This Means

    While is it clear that DevOps offers immense value for software deployment, the adherence to best practices for DevSecOps is essential to reduce risk and assure security. Each organization is different, and has different security postures. The specific practices, security tools and metrics that are appropriate may vary according to a risk assessment for each organization. This blog explained a gap assessment approach, which uses my nine pillars of best practices for DevSecOps. My free DevSecOps assessment tool facilitates a gap analysis for DevSecOps and priorities to improve DevSecOps practices for an organization.

  • How to Turn Your DevSecOps Shift into Your ‘Pixar Moment’

    How to Turn Your DevSecOps Shift into Your ‘Pixar Moment’

    If you have worked in security as long as I have, you have seen that vulnerabilities persist, despite years of attempts to fix them without changing how the organization operates. One of my all-time favorite leadership quotes comes from the first stockholder meeting after Robert Iger, the CEO of Disney, bought Pixar. “The riskiest thing we can do is just maintain the status quo,” he said. This quote has stuck with me and I feel that the shift to DevSecOps can be many teams’ “Pixar moment.”

    In recent years, there has been a push to shift to a DevSecOps model that has the potential to make a drastic change in the way an organization operates. But unless these shifts are planned well, they often fall apart without having made a meaningful impact.

    The root cause is often the inability or unwillingness to do the in-depth planning and testing required to make sure everything will move to a DevSecOps smoothly. The failure to plan leads to underwhelming returns and low morale with the organization will slowly slide back to the old “status quo.”

    Moving to DevSecOps is often more about changing an organization’s cultural identity than any technical changes. I’ve have seen it happen successfully in several places. Here’s what they had in common:

    They Defined, Discussed and Documented the Old and New Build Process

    A successful move to an end-to-end CI/CD system normally starts with one thing: a whiteboard. Organizations bring representatives from every existing team (systems, networking, security, development) to form the new DevSecOps team and build an end-to-end diagram of what it takes to build and maintain the system immediately. For many, this meeting is often the first time they have seen a true end-to-end view of the system.

    Then the new team commits resources to discuss the standards and policies they need and want the new system to be built to. They discuss methodologies, deployment schedules, SLAs, business requirements and overall system architecture and security. This is where the team must come to an agreement on the right way to build and where the security team is likely to see their first big win on improving the “status quo.”

    This round ends with something that no one on the new team will likely enjoy, but is crucial to the shift moving forward: a document of all of the decisions made that can be easily shared within their organization.

    They Built a Strong Team and Platform

    The next step is normally everyone’s favorite part—at least at the start. The team gets to walk into a greenfield environment and move one application to their new DevSecOps flow. Essentially, each team member has the opportunity to bring their ideas and thoughts about modern security, architecture and deployment processes and see if they can apply them. However, the honeymoon period of this process often ends quickly and becomes the most challenging segment of the whole process. The switch from theory to practice isn’t as clear as many DevSecOps teams think, and it’s common for teams to struggle while working with new products with which they likely have not had much organizational experience.

    Buy-in from leadership is critically important here and without it, these projects can quickly go awry. I have heard executives complain that their DevSecOps team is “just playing around,” “wasting company resources” or “learning skills that will just let them get a better job somewhere” when a new system seems to take longer to be built than originally expected. Supporting this team throughout the build process is one of the most important leadership roles in a move to DevSecOps and plays a crucial part in aiding this team and reinforcing its culture within your company.

    Continual Incremental Improvements

    Once you have your first DevSecOps flow created, it is important to remember that you are not done, as you would be in a traditional build model. Of course, you want to celebrate this success, but you also need to start answering these questions:

    • What can we do to increase the deployment frequency and speed?
    • Can we do anything to lower the failure rate of the new releases?
    • Are there any steps that could be more automated?

    If you continually ask and answer these questions, you will never be done, but you will continue to make incremental improvements that will help your organization become more agile over time.

    Rinse and Repeat

    Once you have built your first DevSecOps workflow, you now have a good baseline on what to do (and not to do) when you move your next application to this model. Hopefully, you’ll be ready to move the DevSecOp culture that has taken hold in your organization to the next team.

    — Jerry Gamblin