Eric Maxwell – Best Practices for Adopting DevSecOps Principles

Hello everyone and welcome to best practices for adopting devsecops. My name is Eric Maxwell and I'm a senior Business Solutions manager for digital operations. I've been a part of everbridge for about three years the previously I've been enrolls ranging from product management architect and sre-sre manager.

Well Working in those roles of worked on a variety of projects from on-premise tools to Cloud platforms. migrations from monolith applications to microservices architectures using container Technologies So what is defset cops traditionally development and operations roles are separated with little interaction except for handoffs at release security is most often a part of we're in partnership with operations. So major security thought doesn't usually happen in this scenario until right before and or after release.

Devops involves integrating development and operations into a collaborative process, but security is still often considered an afterthought to be inserted just before release. To many devsecops looks like this. But as with this diagram, there's still parts of the process that security is still not top of mind.

Having the forethought to integrate security throughout the process is what you should be imagining when speaking of deaf SEC Ops. So what is the value and why should deaf secops be imported to me? It comes down to two main goals reducing risk and creating Trust.

reducing risk focus on closing the gap between security business and it It's not just a set of rules, but a culture of practicing Security in all aspects that's planning and design development deployment and operations. It's an iterative approach dealing with high risk with no delay. As an example where this practice was not implemented.

This is an example from my past. I was working with a QA engineer and she wanted me to look at an issue that she was having. As she was showing me I noticed.

Some interaction in the testing tool that did not seem to follow our authentication best practices for API and as a talk to her about investigated we found that this had been deployed into production after some investigation. We've determined that if the this endpoint had not been accessed publicly by anyone in our production environment, but with further investigation, we found that this was added early in the process because of this testing tool that they were using it had a hard time with the Authentication. Methods that we were requiring on our endpoint and they had created this special endpoint just for this testing tool.

so Again, not following this reducing risk. In the beginning, right? It was this the forethought and on insecurity needs to be there through the whole with every team member and throughout the whole process, right?

And there's creating Trust. This is very much tied to client visibility. Visibly demonstrating and reduce impact through openness not holding so much close to the chest which is which can be counterintuitive or counterproductive to creating trust providing data protection plans and privacy policies with traceability.

As an example. com/trust page, you'll see all of our data protection policies privacy policies. All of our certifications are right there that you can view either the ones that can be publicly publishing.

If not, it gives you the procedures on how to acquire the information that you need. It's just an important to understand what deaf set cops is not so let's bust some this. It is not more layers of security with rules and policies that create additional toil.

It is not a dedicated security team but a collaboration of members and of other teams. It's not a big transformation project. But iterative risk-based approach similar to application improvements in Bucks.

It should not compromise your Roi it should add value. So an important basis for devops is the comps framework as put forward by just humble. Comms a plastic defect cops as much as it does to devops.

the culture of security inclusion automation of security and testing delivery and monitoring systems through observability. A lean approach to implementing security as part of a value stream and applying value stream management to incidents in critical event management. measurement through security scorecards and measuring risk sharing identified risk resolution and threats So all these things also apply to devsecops so we can vandalize this devops Monument to incorporate security.

So we have our devsecops. There are two headline principles we want we will adopt first is a proactive shift left approach. This means applying operations principles to the software delivery cycle.

In other words prevention will apply these principles using comps. Not leaving security to the last minute as previous Frameworks have done apply the principle that there are probably the principle that there is no such thing as non-functional requirements. We need to challenge delivery teams to early and apply security early have empathy for the end user and keep it simple.

Don't just think about your production think about non-production and your service delivery pipeline. We don't necessarily want to automate everything as to allow for innovation. The culture of inclusion also extends to automation for statistical and dynamic analysis security code coverage digital signatures on build repositories and automated penetration smoke testing.

Lane means ensuring that security is included. At all stages of the lifecycle not just at the end with service management. The sooner risk is discovered.

The sooner. It is remediated and waste is reduced. The second approach is a reactive shift left approach.

As you may may have guessed this is about applying engineering delivery printable principles into operations. This is about cure. We're detection and correction, right this requires a culture of acceptance that things will happen implementing security testing and production from Time Zero applying chaos engineering to non-prod as well as to production and automating as a standard.

Capturing data for post incident reports in real time. So nothing gets lost. Trading major Incident Management as a value stream where every second counts.

In an attack may also require pulling the plug to quarantine then ensuring your return to Value ASAP with the mitigated fix with the provision, of course for a full fixed prevent future risk and remove technical debt. In the previous lives. We spoke about culture Automation and lean.

measurement and sharing must be applied to but must be applied but are common to both approaches. To do this. We need to ensure that their owners of the security measurements and that they are correctly ascribed.

They know the rules and requirements such as gdpr. We are applying measurement not just production but to non-production as well. Where you're defiant security as a business value and part of our success criteria building Trust.

We're using security scorecards. We also remember responsibly of security is everyone so give people the freedom to identify and innovate around security. We can use things like twin team approach in an attack where we're working collaboratively.

We're security leads damage limitation and it leads resolution. We went to empower our teams to do what is necessary for example with red teams or security drills. I want to give a couple of examples but I want to emphasize that I don't I don't I do not have any knowledge into their security practices as I said before it's not a matter of if but when a security incident occurs how prepared are you to recognize mitigate and recover from it?

The first example is an incident a solarwinds had in early 2020 where where proactive shift left. Thinking would have prevented an issue correctly in Timely. Through an unrelated attack Vector hackers were able to add malicious code to their product using its delivery pipeline.

There are several security practices that could have been in place to mitigate this issue. But the point is that implementing deaf-secop's mindset and shifting security thought to the left could have prevented this in several ways. This is an example of if the issue was caught earlier further to the left the mitigation and Recovery would have been much less of an impact working on perfect prevention and not reaction.

The second example is an incident with British Airways had in 2018 where reactive shift right thinking would have detected and corrected an issue correctly and provided the Cure more timely. Hackers were able to take advantage of a well-known vulnerability in a third party package using their website together personally information of customers and staff. Other than the fact that vulnerability have been around for several years.

It was found that the response times after discovery were unacceptable in this example, if leaner more agile approach to the response would have minimized the impact. So are so far we've spoken a lot of theory, but there is practice to this. Let's break this into four components single source of Truth security by Design.

Security predictability is predict. It is predictability understanding your environment. Single source of Truth is not a single tool or platform.

There are many tools and platforms for various use cases all have their strengths. You should pick tools that best fit your process and objectives. But the information and functions from these systems.

Should should be Consolidated into a single source of Truth providing easier access to critical information. So teams are not jumping between tools to do analysis. This also opens broader analysis across all data using descriptive and predictive data mining machine learning simulation and optimization to produce additional insights.

The platform should also centralize not only data but orchestrate common functions across the organization like Incident Management and collaboration. The solution should also be flexible allowing your tool chain to evolve with the organization and with Technology Innovation. So when working on security by Design firewalls and Antivirus should not should be considered secondary security managers measures.

Think of them as you're building's physical security where you are allow certain people through designated doors. But what happens when someone tailgate someone in or finds a back door back door left open? You must also plan for internal structure to manage this as well as well by having other levels of detection and protection like internal cameras and doors to secure sensitive areas same with development.

We must embed security from the beginning and shift security thought to the left into application design and into development processes to prevent and mitigate these intrusions. A large portion of our application security must go into protecting the systems and processes that we use to build and develop our platforms making sure we are designing and developing following security best practices building traceability and verification into our development process like managing third-party libraries signing and verifying artifacts. Making sure the tools and systems we use to develop our applications our secure and up-to-date.

Security is predictable and implementing Dynamic systems like modern observability platforms that provide real-time data and alerts across the application stack and even development processes. They also use machine learning and AI apps that can detect anomalies that static Monitoring Solutions will not see. Combine this with orchestration platforms to remove slow manual Decisions by trigging automated processes to mitigate issues.

And when human intervention is required notifying the right people giving the information that they need up front automate as many manual processes as possible and allow them to make decisions and kick off kick off automated processes to speed up mitigation and resolution. Should be also as I mentioned before combined with collaboration. We also want to make sure we don't forget about Insider threats.

These can be intentional or unintentional as I mentioned with the open endpoint example. I talked about earlier. But we but we know it will happen.

So Monitor and plan for it. Understanding your environment is important because even automated processes still have a risk there aren't humans in the process but humans did build the process and tools so inherently in automated process still has security risks. We should routinely evaluate and even test the tools and systems we use in our automated process to mitigate the risk of a security intrusion.

Labeling systems and data based on risk can make the evaluation more efficient. What is the likelihood of a security intrusion and if there is how sensitive is the data or how will losing that system impact our organization or our customers? This way we can prioritize our efforts.

So we've reviewed the theory behind device epicops and some components of implementing and practice. This is far from comprehensive, but hopefully got you thinking about where to start and building a practice of cops in your organization. So I want to thank you for your time today.

Please join us at our booth for any follow-up discussions or questions. Also, you can test out our x-matters digital operations platform for free and your deaf secops stack. You can visit the X matters YouTube channel for demos and information as well as it is everbridge for all our products to help you protect.

What matters most to you? Thank you.