A DevOps mindset benefits many professions

The ethos underpinning DevOps has the capacity to respond to the business challenges of UX, machine learning, and security.

Table Of Contents

• Continous Security and DevSecOps
• Best practices for Continuous Security inspired by DevOps
• Is it time for DesignOps?
• MLOps: What data scientists can learn from DevOps
• Are you interested in DevOps and Cybersecurity?

Many workplaces have begun to view their work through a DevOps framework, looking at the benefits of small, incremental steps, fast delivery, and a mindset that embraces microservices and serverless architecture. While

Continous Security and DevSecOps

Kim van Wilgen, Customer Director at Schuberg Philis, spoke at last year’s Codemotion Amsterdam about how delivering small and fast means we are more frequently introducing new vulnerabilities. Traditional cycles of pen tests and code reviews are not keeping up.

The move to the cloud further accelerates security challenges. She gave the example of a security software vendor that previously had on-premise applications.

“Every one of the thousand customers had 1000 of Holland’s whole customer base in their databases. And then we said, we’re going to collect them all and put them at single spots on AWS. That meant that almost every person in Holland was in the databases on one spot. That’s far more attractive for them for a hacker to actually proceed on an attack because it’s just more to gain.”

Enter DevSecOps, which focuses on integrating Continuous Security in dev processes and teams. Kim defines Continous Security as: “a set of practices and principles in software engineering aimed at designing, developing, testing, and running software more surely. They help reduce the cost, time, and risk of delivering integrity. availability and confidentiality to applications in production.” She asserts, “Continous Security is essential for delivering Continous Delivery.”

You’ll want to watch the whole video below to see how DevOps can benefit security:

[jwp-video n=”1"]

Best practices for Continuous Security inspired by DevOps

Have security champions

Shared responsibility is no responsibility. “You need a person who sees what’s developing out outside, what is happening. Are we at risk? Do we advance on the right topics? Do we make the right improvements? Are we at the step where we need to be?”

Kim’s workplace has a person in every team in the role of lead security: SecLeads or SecBuddies. “They connect with the security managers to rubber duck or to ask for expertise because these folks really know their thing. But the important thing that the importance of security is shared within individual teams instead of in a silo.”

Don’t try to eliminate all risk

“If you eliminate all the risk, you’re not pushing anything out to production anymore.”

Alignment of security and business value is integral to DevOps

Kim contends, “Our main focus is delivering functionality. Security should support delivering value and should not compromise delivering failure. don’t eliminate all the risk.”

Be DevOps driven

DevOps is a mindset. It’s about making sure we’re delivering value with all the competencies in one team to do that. And security is definitely a part of this. “It’s vital to consider what things we can do early in our pipeline to make sure that we reduce the cost of adding security because if we fixed all the things at the latest stages will be very expensive. So and instead of throwing it over the fence and hoping that it will be right, just talk to each other and pair with the security expert early in the process to see what do we really need to address what has to be in there? What’s the MVP on security?”

Integrate into the pipelines

If you automate security, you will learn a range of concepts including:

SAST: a Static Analysis Security Testing tool which means you’re checking your source code against vulnerabilities. Kim recommends many tools including Checkmarx, Veracode, Appscan, fortify, PR application inspector, and covarity. “These tools are very good at checking your source code and seeing if it has vulnerabilities for SQL injections or stuff like that.”

DAST: Dynamic application security testing. This testing simulates attacks against an application or state. (These are typically web-enabled applications and services). It then analyzes results and determines whether it is vulnerable. Helpful tools include Fortify, AppScan, ZAP, Qualys, and Rapid7A.

Identify and remove: start small.

Kim recommends that you start by doing, detailing when her company introduced SonarQube “I’ve added over a 100 security rules in SonarQube and sent the top X screwups to the team. They are more aware and will solve their own issues.” They also set up an internal learning platform to practice attacks and grow awareness and knowledge of security.

Learn and adapt first before you break the build.

While Kim suggests people jump into security practices with enthusiasm, she stresses, “If you start by breaking the build, nobody gets any value to production. Nobody can comply with customer agreements because you decided it was a good plan to improve security policy. That’s not a good thing to do. You won’t be the most likable person from that moment on.”

Fix your vulnerabilities

Kim stresses that while you make a lot of effort finding all the vulnerabilities in your software, don’t forget that somebody has actually to take time to fix them.” If you skip this, you achieve nothing.”

Immutable infrastructure

Immutability is difficult in legacy environments. However, one of the benefits of using containers (especially in microservices-based applications) is that they make it easier to secure applications. Kim also stresses an immutable infrastructure mindset where:

• Patches are code changes and follow the pipeline
• Use systematic workload re-provisioning -difficult to persist across rebuilds
• Scan infrastructure scripts against the security policy
• Apply pervasive visibility

Is it time for DesignOps?

At Codemotion Rome in 2019, we heard a fascinating presentation by people from the design company Sketchin, Federico Rivera, Design Director, and Matteo Petrani, Technology Director. They shared how they overcame operational inefficiencies through the implementation of DevOps principles which they rebrand as DesignOps principles, employing a UX Engineer.

[jwp-video n=”2"]

The UX engineer has two faces: to see the code side of a project and see the design phase of a project. “What’s important here is that it’s not a designer who can code and neither a coder that knows how to design something. But it’s more someone that grew up in the middle of these two areas, trying to cause something trying to design something else. And what’s important here is not the hard skills. But the sensibility that these folks can bring to the table.”

As Federico elaborates, “We try to find people that can judge design decision as well as coding and development decisions. These are people who can bring the user’s values as well as the feasibility of a project to the same table throughout the design process. They can be there for the end to end creation of products or services.”

MLOps: What data scientists can learn from DevOps

Over the years, we have witnessed the birth and consolidation of practices and tools designed to encourage conversation between all the team’s different components (product, development, operations). Enter a data scientist, and the team meets someone with a new voice that, by custom, is molded to work differently.

Thiago De Faria, Head of Solutions Engineering at LINKIT, talked at Codemotion Amsterdam last year, where he asks:

“Do you have a team building an ML model? How far are they from the IT team? Do they know how to deploy and serve that? Testing? And sharing what they have done?”

Thiago notes that data scientists and machine learning engineers are usually masters students or Ph.D. students that come into work into the field. They are used to writing models to send to publications and traditionally spent six months working in one model.

[jwp-video n=”3"]

“And now you come to them and say like, can you build something in two weeks? They go insane; they start to work locally, not to show their failures for the other people. I’ve seen many data scientists who had a GitHub or Bitbucket, or Gitlab, whatever, that they only have one commit in three months. Because when they’re doing that, they feel that there I am not going to show people this model that is 30% accurate. I’m just going to show when I get to 80% or 90%.”

That’s where a DevOps mindset comes in: reduce the batch size, continuous-everything, and a culture of failure/experimentation are vital for your data team.

Are you interested in DevOps and Cybersecurity?

If you are working in Cybersecurity and interested in DevOps, don’t miss the opportunity to attend our upcoming Codemotion Online Tech Conference, which will be held on October 2020: there is still room for attending, and free tickets are available! Check this website for more information.

You can read the orginal version of this article at Codemotion.com, where you will find more related contents. https://www.codemotion.com/magazine/dev-hub/big-data-analyst/devops-mindset/