In relentless pursuit of automation and velocity, DevOps teams can reduce the software development cycle and ensure that their products are responsive to client feedback. However, this quest for perfection may compromise security, leaving room for vulnerabilities or misconfigurations that can create huge problems later on.
Ensuring security integration throughout the life cycle while retaining agility and speed is necessary to avoid DevOps security risks.
How can this be achieved? The short answer is understanding the human needs of the security team and realizing the limitations in the workflow.
DevOps is Trending
Given the following trends, experts are predicting that DevOps adoption will reach its peak this year.
Firms have been showing a rising interest in adopting DevOps-related practices and technologies. Between 2017 to 2018, there has been a 7% spike in DevOps adoption, according to Statista.
Notably, the DevOps software market is projected to rise to $6.6 billion in 2022 from $2.9 billion in 2017.
Unsecured credentials: Intellectual property, such as a company’s source code, can be destroyed if attackers find a way to take advantage of unsecured credentials in a DevOps environment.
Overworked team: Since DevOps calls on the software developers to take on multiple roles and discharge a great variety of challenging responsibilities simultaneously, becoming overworked is a strong possibility.
Easy-to-access admin credentials: Controlling administrative credentials is difficult in the DevOps model, as everyone can administer systems and debug production issues. Inadequate security may allow hackers to gain complete control over a firm’s IT architecture.
Lack of business acumen among security professionals: Owing to the rapid rise in cybersecurity concerns, professionals must be well-versed in business fundamentals to realize how their firm’s threat management strategy is linked to the overall business goals. However, there is a skills gap in the cybersecurity field, which might pose issues for IT companies.
Key Security Practices to Follow During the DevOps Process
Having a successful and secure DevOps process requires the company to integrate security practices into each step of the process, from inception to maintenance. A few of these practices are:
Providing training to employees from the hackers’ perspective, teaching them how the attacker will take advantage of coding and configuration mistakes or architectural weaknesses, and giving proper DevOps security tools will go a long way in ensuring safety.
One of the best DevOps security practices involves regularly updating IT protocols and governance policies. It is worth noting that transparency is a must with DevOps security policy, as it allows employees to feel safe while reporting suspicious internal behavior.
Ensure that the engineers behave the way you intend by clearly specifying DevOps security and compliance metrics they must follow.
Performing threat modeling in a structured manner is also crucial for a safe development process.
Easy to use tools that are integrated into the CI/CD pipeline and intelligent automation solutions can also help achieve security goals without overloading the engineers.
Continuously learning and monitoring your applications, infrastructure and network utilizing advanced analytics tools can bolster security measures.
Adopting a DevSecOps model will enable you to embed code review, identity and access management, configuration and vulnerability management. Although there will be DevSecOps challenges, such as a clash of tools and reluctance to integrate by the employees, these are minor compared to the security benefits.
Bottom Line
Implementing security in DevOps is riddled with challenges. Overcoming application vulnerabilities and data breaches during software releases with the above-discussed security practices can help keep DevOps processes, data and teams more secure.
In March of this year, how employees worked (if they were fortunate enough to be able to continue to work), changed dramatically following state-led shelter-in-place orders. At first, it was hoped the shift would be a matter of weeks. But as the pandemic continued and weeks stretched to months—and now with more organizations extending their work-from-home (WFH) policies well into 2021, there’s currently no real end in sight.
What’s the impact of WFH been on security? Security firm Malwarebytes recently completed a report, “Enduring from Home: COVID-19’s Impact on Business Security,” that looks at precisely this issue. The report examines Malwarebytes’ malware data and a survey of 200 technology and information security decision-makers among large and small organizations.
The survey found that organizations are confident in their ability to transition to an increasingly remote workforce successfully. Essentially, 73% rated their organization as a high or higher in their WFH preparedness. For those organizations with fewer than 700 staffers, 84% said they moved more than half of their employees to remote work. However, 84% of larger organizations, those with 700 employees or more, said they’d moved almost all their workforce home.
Disappointingly, despite the profound changes to staff working situations, 45% of those surveyed did not conduct either security or online privacy analyses of their software tools.
Since the beginning of the pandemic, 20% of respondents said they witnessed security breaches as a result of a remote worker, and 24% said remote worker security breaches created unexpected security expenses. Further, 28% said that they now use personal devices for work more than they did previously, and 61% of those surveyed said that their employers didn’t recommend staff install anti-malware on their personal endpoints.
Not surprisingly, criminals are adapting to the new worker landscape, adjusting techniques to target poorly configured virtual private networks, cloud services and email. “There has also been a surge in phishing emails that use COVID-19 as a lure to cover up malicious activity. These emails contain commercial malware, such as AveMaria and NetWiredRC, which allow for remote desktop access, webcam control, password theft and more,” Malwarebytes said in a statement.
The study also found that AveMaria malware increased by more than 1,200% from January to April. This malware targeted primarily large enterprises, the company found. In contrast, Malwarebytes detected a near-doubling in infections from NetWiredRC, which targets small and medium-sized organizations.
What’s most concerning with these findings isn’t that criminals have shifted tactics due to a change in how staffers work; that’s to be expected and enterprises don’t have control over what attackers will do. But enterprises do have control over how they defend themselves. And as enterprises increasingly turned to cloud and collaboration platforms to make their WFH situations work, they should have updated their threat models to reflect the new reality. As this new reality continues, one can hope organizations better evaluate their current environments and adjust their security posture accordingly.
GitLab today at its GitLab Commit Virtual event pledged to make securing its open source continuous integration/continuous delivery (CI/CD) platform a more collaborative effort.
Cindy Blake, senior security evangelist for GitLab, said the company is committed to sharing a road map developed in collaboration with DevOps teams that lets organizations see what cybersecurity issues will be addressed when.
Rather than merely sharing DevSecOps marketing collateral, Blake said the goal is to encourage engineers to participate in a feedback loop that will help prioritize what issues need to be addressed across a shared DevSecOps agenda.
The next priority is to enable organizations to construct DevSecOps workflows spanning DevOps and cybersecurity teams, said Blake, noting it will be easier to construct workflows at scale using a CI/CD platform that tightly integrates all the tools required.
In time, GitLab plans to extend those efforts to include machine learning algorithms that will be trained to identify and remediate cybersecurity issues, she added.
As a founding member of the Open Source Security Foundation, GitLab is also committed to working with the rest of the open source community to better secure software, Blake said.
There’s naturally a lot more focus these days on application security. A recent Global DevSecOps Survey conducted by GitLab finds developers are exercising more control over security—more than 25% of developers reported feeling solely responsible for security, compared to 33% of security team members who say they own security. A total of 29% of respondents said they believe everyone should be responsible for security.
However, cybercriminals are also making a concerted effort to compromise software supply chains by inserting malware into DevOps workflows constructed on CI/CD platforms. The challenge with securing open source platforms, of course, is the code employed to build these platforms is accessible to anyone including, of course, cybercriminals.
It’s too early to say to what degree cybersecurity concerns are influencing the selection of CI/CD platforms. However, as cybersecurity professionals become more involved in application development, it’s only a matter of time before issues involving the security of the platforms used to build applications become a higher concern.
In the meantime, the line is blurring between application development and cybersecurity. The challenge for each organization will be determining just how far left they want to shift responsibility for cybersecurity to the individuals who build their applications versus a cybersecurity team that has a less vested interest in accelerating the rate at which code is promoted into a production environment.
In this interview for TechStrong TV, I am joined by strongDM CEO Elizabeth Zalman and mParticle CISO Dave Anderson. Dave shares with us how mParticle uses strongDM proxy services to rapidly enable the expanding mParticle team to access infrastructure, assets and applications necessary for mParticle to fulfill its mission to its customers.
With the rapid growth of mParticle, the company needed a solution that would allow it to onboard its new employees and locations seamlessly. strongDM gives mParticle this capability. Have a watch of the video and follow along with the transcript to find out more.
Transcript
Alan Shimel: Hey, everyone—back here for another segment on TechStrong TV. I am joined once again by my friend Liz Zalman at strongDM. Hey, Liz, how are you?
Elizabeth Zalman: Hi, Alan. I’m well, thank you.
Shimel: Good to have you back on. And joining Liz and I today, another guest, is Dave Anderson. Dave is the CISO at mParticle. Hey, Dave—welcome to TechStrong TV.
Dave Anderson: How’s it going?
Shimel: Going great. Not as great as you are. Dave’s coming at us from a sailboat today and we’re all stuck in our homes and offices, but hey, the life of a CISO—and you guys complain.
Anderson:[Laughter]
Shimel: Anyway. You know what, we—yeah, I don’t know, it’s hard to make that less glamorous, Dave, but we’ll give you the pass. Liz, for those who haven’t seen some of our previous interviews with you and the strongDM team and some of the customers, why don’t we start off, give our audience a quick background, who’s strongDM, what you guys do?
Zalman: Sure. Strong is a proxy and it lets people manage and audit access to any firewalled infrastructure—servers, databases, Kubernetes clusters, RDP, firewalled web apps, HTTP endpoints. So, essentially, instead of managing keys and creds, you give people access to strong, and then it talks to the target systems on your behalf, so you get access control and then auditing through the proxy itself.
Shimel: Everything you expect from your proxy—great.
Zalman:[Laughter]
Shimel: And it’s sort of proxy as a service, if you will, yeah?
Zalman: Yeah, there’s a portion of it that is hosted, the control plan itself, and then the rest goes through your own hardware.
Shimel: Got it. And Dave—
Zalman: Or whatever your virtual hardware is these days.
Shimel: Well, yeah—no one uses hardware. Through your own infrastructure, how’s that?
Dave, talk to us about mParticle.
Anderson: Yeah, so, mParticle is a customer data platform. So, what that means is, our customers are able to use our platform to ingest pretty much anything, any data about their customers, about the activity that’s going on on their websites and mobile apps into the mParticle platform, and then we’re able to give our customers the full control of being able to fan that out to any of our different integration partners. So, there’s that, as well as being able to do things like data quality, match identity resolution, figure out where a particular user is, what sort of ways you want—like, how they’re interacting with their particular application or whatnot.
To be honest, we have customers, like, in a bunch of different verticals, and they all use the product a little differently, and it’s—we’re continuing to grow and innovate and figure out different ways of kind of helping our customers along with their data journey.
Shimel: Excellent. And, you know, that kinda mission is just so attuned with what I think companies are looking for today, right, which is—you know, there’s so much data out there. There’s so much—you know, do you want it all, what are you gonna do with it all, what makes sense, what doesn’t make sense? But the idea of being able to access that, analyze it—hopefully, with as much automation as possible—is what it’s all about.
Of course, it also creates—as a CISO, you know this—it creates tremendous responsibilities and potential pitfalls from a security, data, access, compliance point of view. But it also, you know, to the strongDM mission of proxying through firewall to assets, whether those assets are remote workers who have to access, you know, data in the cloud or on-prem or wherever or just whether they’re remote or not, access incorporate assets, which, in your case are, in some cases, I’m gonna assume, a lot of PII kind of data.
Dave Anderson, mParticle
Anderson: Exactly.
Shimel: This is a potential security nightmare. This is what keeps CISOs up at night on their boats. So, talk to us, Dave, what is—you know, how does strongDM help you sleep better?
Anderson: So, naturally, we’re a data collection—data collection and distribution company. So, we have a lot of data, a lot of data split up into a lot of different databases, and we have to have very tight access controls for those databases. So, one of the things that strongDM gives us the capability of doing for—when any sort of support people or operations people need access to a particular database or data set within the kinda mParticle back-end, we’re able to utilize strongDM to give us the ability to have secure access to that, that is able to be tied back to the individual who’s doing the work, everything is audited, everything’s logged, we’re able to generate reports for compliance.
So, it gives us the capabilities of not having to give our, like a support person, for example, give them a direct access to the database. They have, like, a nice tool they can use, everything is integrated nicely on the desktop, and everything is integrated well with all of our identity management platforms as well.
Shimel: Excellent, excellent. So, Dave, I think we—you know, we get what you’re doing there, we get what the potential risk is. And we’ve done a few interviews—in full disclosure, we’ve done a few interviews with some of the strongDM clients in fintech and other verticals. What we haven’t done is kinda peeled back what was—I mean, using a proxy, I think a lot of our audience has probably used a proxy one way or another.
But I want to peel back now, in the case of mParticle, walk us through how you guys sort of say, “Okay, we’re gonna use strongDM.” How did you set it up? How did you deploy? How do you manage it, right? How does it give you the warm fuzzy feeling you need to know that you can sleep well at night?
Anderson: Well, to be perfectly transparent, I was—I’m pretty new at mParticle, so, I wasn’t here when—
Shimel: So, you inherited it?
Anderson: Yeah, so, I inherited it. But I actually am a pretty early strongDM customer from my last job at Greenhouse Software, and so, I’m very familiar with that aspect of it. We used it for similar purposes back then. Back at Greenhouse, we had a lot of support personnel that were—and kinda data quality engineers that were using the strongDM platform to access our databases within AWS. And similar here, we want to have—we try to keep as much, the access as restricted as possible. We believe in the principle to release privilege, and separation of duties.
Shimel: Sure.
Anderson: So, with that, we need to have our networks deeply, deeply isolated. The databases live kinda deep into the network, not even having access to the outside world. And with that, the only way to give somebody in support access to that database traditionally would have been giving them VPN into that environment and then them having to actually install the different tools and having to manage authentication and access control. And even then, what would happen is, we would also lose visibility into what they did on that database. Like, what queries did they run, what data did they see? Because it’s not even necessarily a kinda everyday type of thing for someone to have access to the data itself. We tightly, tightly control who has access to what data, and using a tool like strongDM is pretty much a requirement for that.
Shimel: Yeah. I mean, look—and I’ll try to put it in layman’s terms for our audience who maybe aren’t as familiar with this stuff. When you’re using a VPN, they call it a tunnel, right, a tunneling tool. Because really, what you’re doing is, you’re punching a tunnel through, whether it’s your firewall in your infrastructure, and it’s an encrypted tunnel at that, right? So, everything that takes place within that tunnel is encrypted.
And so, when I connected to a database via a VPN, you may see that I did connect—oh, yeah, that’s Alan’s client and he connected to the database. But in terms of what data was in that tunnel and what—you know, you really don’t, you don’t have visibility there, by its very definition, right? On purpose. It’s not a byproduct, that’s how it’s supposed to be. And you don’t—you know, you can…it’s just, that’s how it was designed.
And so, that doesn’t really play well, you know, in the areas of DLP and you wanna make sure data’s not ________, you know, taken out. It’s a problem. So, now, strongDM helps you solve that, is what you’re telling me, because now we can see, you know, it’s a proxy, but on the backside of the proxy, that goes into the firewall and into the trusted network as we used to call it 100 years ago when I was in security, right? When you go through that into the trusted network, you can still see where Liz went or Alan went or Dave went, because it’s not that tunneled, right? It’s not that encrypted tunnel through there, it’s more of the proxy. I remember when we were NAT-ing firewalls, right, a long time ago, and it was that same thing—at least I could match up this IP to that IP, the behind the firewall versus the public IP, you know, private IP, public IP. And so, you had some of that then.
Then, on top of it—look, giving people a VPN, with everything going on in COVID and remote workers, you know, and all we’re hitting, and of course they’re not just hitting your database, there’s also SaaS apps that they need to hit and everything. A VPN is—I’m not a big fan of VPNs in today’s world, if you can’t tell, okay? I just—it don’t make sense. I mean, and then, and the whole idea of VPN-ing back into a central kinda office to go back into the cloud also kinda, I mean… You know, a friend of mine, I know a guy named Jay Chaudhry who is, of course, the CEO and Founder of Zscaler—he used to rail from the very time the cloud-first started coming on the scene big, 2006-’07, he was saying back then that VPNs were, you know, the time has come, but here we are, 2020—same thing.
But, Dave, how easy was it to set up the strongDM proxy, and what kind of visibility is it giving you?
Anderson: I mean, setting up strongDM is really easy. There’s a couple of pieces of infrastructure that you put into your environment, and that would all depend on how you deploy your infrastructure. So, there’s—I’m trying to remember the exact terminology. Like, a gateway and a—what was that?
Shimel: Liz, can you help him here?
Anderson: Yeah.
Zalman: What?
Shimel: Can you help him out, here?
Zalman: I ________. I would never leave my friend hanging—never. [Cross talk]
Anderson:[Laughter] Yeah, so, you deploy that infrastructure that, basically, that sits in your network and you have, and then it talks back to the strongDM portal and so, the strongDM clients actually know who to talk to, like, what IP addresses and what databases it has access to. You go through the strongDM UI or you can use their API, depending on your preference to set up different databases and set up the credentials in there and all the users and what users have access to what databases and what roles within those databases they have access to. And then there’s a client that runs on the person’s laptop, and that client, they’re like, you’re talking locally to that client and it’s magically on the strongDM back end, like, routing everything around to the right place and makes it extremely streamlined for the end user, because they just have this little control panel down there, like, in the bottom of their screen that lets them connect to the particular database, and it’s really, really ridiculously easy to use.
Shimel: Very cool. Now, as part of the role in CISO, you’ve always gotta be thinking not if, but when we have an incident, right? I’ve gotta be able to do forensics, I’ve gotta have an audit trail, right, I’ve gotta be able to figure out, what the heck—I have to show people what happened here, did we take reasonable steps, right, and stuff like that.
What is it, in terms of audit trail and forensics, how does strongDM help you there?
Anderson: So, it shows us who connected to what resource when, how long they were connected, what they did, what sort of careers they were in, what sort of other kinda SQL comments or whatever the database may be, and be able to produce that in near real-time, as well as have logs to go back to if there was an incident that we would know what data was accessed by a particular individual.
Shimel: So, that’s kinda the control plane that sits in the cloud, Liz, or that’s local to the client?
Zalman: The auditing happens through the gateway. So, when the request hits the gateway, it actually deconstructs it in order to provide the audit trail—so, that stays resident in Dave’s network, yeah.
Shimel: Excellent. So, we don’t have to worry about access to strangers to that.
Zalman: Yeah, no, it’s his data. We don’t wanna touch it. [Laughter]
Anderson: Yeah, that’s one of the most attractive things, actually, was the fact that the data stays in our network. strongDM operates the, how things actually get connected, but as far as, like, once you’re in that network, it’s, everything stays within there.
Zalman: Cool. Alright, sounds great. Dave, one other question. With COVID and everybody working remote, I know—look, I mean, strongDM, from what I’ve seen, has built a…not built, but while there are plenty of people, obviously, suffering as a result of COVID and my heart goes out, I’m sure as you guys, too, to people who have lost loved ones and are sick and have lost jobs and money and all of the bad things that are happening with this. The fact is, you know, with remote workers being more and more common, solutions like a strongDM are thriving, right? Are being rapidly adopted. Not because they’re nice to have, because you gotta have something like that, right? So, I’m wondering, what are you guys seeing at mParticle and a similar kind of thing as you’re going remote?
Anderson: Yeah. I mean, thankfully, we were really well-equipped for going remote. A lot of the engineering team is distributed to begin with. We had people in Seattle, Florida, Texas, and New York, of course. But we were able to transition to it pretty seamlessly. We just spend a lot more time on Zoom.
Shimel: Don’t we all?
Anderson: Yeah. [Laughter] Yes, but having the technology in place for being able to securely connect to remote networks, remote resources is definitely, it’s a requirement nowadays. I mean, especially with—you can’t, you don’t have a perimeter anymore. There isn’t that network, the whole concept of having that network firewall that was sitting there and protecting everything is kinda dead now, especially with, since everybody’s working from home. I mean, and VPNs, as we were talking about before, only give you so much. There’s only so much flexibility you have with how you can protect your network and segment your network to make a VPN be as flexible as a platform like strongDM.
Shimel: Look, I thought network firewalls were dead in 2007, right? I remember the first time I saw a Jericho—I don’t know if you remember this, Dave, but do you remember the Jericho project? Did you ever hear of that? That, you know, they were the first ones to talk about the de-perimeterization of security and micro-perimeters and personal perimeter and all that stuff. That whole moat and castle setup that the network firewall played in and the VPN was sort of a bastardized child of, you know, that disappeared when we got mobile devices and people started going mobile. Sounds like a Who song—“Going mobile, mobile”—anyway. But yeah, I don’t disagree with you.
Liz, let me ask you. I mean, mParticle, is this sort of the—it seems like it’s right in the sweet spot for what you guys are doing, then, right? This is the mission.
Zalman: This is the mission, yeah, and it’s, and actually, Dave, shifting from—I mean, what do you call Greenhouse, ATS?
Anderson: Yeah.
Zalman: It’s a form of data management, actually, shifting into customer data. It’s a vertical that I hold dear, because I actually started my career in ad tech, and what he’s describing is what I wanted a decade ago. So, like, I personally love the fact that mParticle is a customer. [Laughter] There is simply no place to store that stuff and then to link it across various touchpoints—it never came to fruition.
But yeah, a company that is distributed, that isn’t hyper-growth, it has large corporate clients who have, I’m guessing—Dave, tell me if I’m wrong—contractual requirements with respect to security and pen testing in various attestations.
Anderson: Of course, yeah.
Zalman: Yeah. [Laughter] Yeah, we do a good business in that area, and it hits all those things.
Shimel: Very cool. Guys, we’re about out of time. Dave, I appreciate you taking time out of your busy day on the boat to join us here. [Laughter] All kidding aside, man, it actually is a very great socially distanced way to get work done.
Anderson: Yeah.
Shimel: Truth be told, I’m supposed to be on a boat tomorrow and I canceled, because I had some stuff come up, and [Cross talk].
Zalman: Alan, it’s not that strongDM helps Dave sleep better at night, it’s those waves in the harbor, too. [Laughter]
Anderson:[Laughter]
Shimel: Yeah, well, that—right, they’ll help you sleep, either way. They’ll help you sleep well, as well.
Anderson: Yeah.
Shimel: I’m not gonna go there, though, Liz. You know, leave Dave alone.
Anderson: It’s also my alarm clock in the morning. [Laughter]
Zalman:[Laughter]
Shimel: Yeah, that’s exactly it. You know what, alright, the guy’s on a boat, there’s worse things. It doesn’t make him a spoiled person. I don’t wanna get—you know what, but for all those people who say CISOs are underworked and overpaid, as Dave’s living here on the boat, that’s not true. CISOs are overworked and underpaid.
But anyway—Liz, thanks for joining us.
Zalman: Thanks, Alan.
Shimel: We’ll hopefully have another interview with you soon, maybe.
Zalman: I think we have one on Friday.
Shimel: Very cool. Dave, thank you for joining us—great, continued success with mParticle. Sounds like a great business and a great use case here for strongDM, and enjoy—enjoy your time. Stay safe and stay well.
Zalman: Thank you for having me.
Shimel: Thank you. Hey, this is Alan Shimel. You just watched another TechStrong TV segment. We’re gonna be right back with another guest.
In today’s world, DevOps and compliance teams need to work together, not separately
Imagine this: You organized a dinner party weeks ago, promptly forgot about it and just realized tonight’s the night! You have two hours to whip up a gourmet meal for 10 friends. Instead of panicking, you get smart and enlist your kids to form an assembly line. One starts on sides, the other maps out dessert and you begin marinating steaks. All goes well—until the Brussel sprouts burn. Glancing at your watch, you sigh in relief—there’s just enough time to make another batch.
At that moment, your spouse walks in and assesses the situation. The meat is a tad underdone, the veggies could be crispier and the cake is lopsided. You can’t serve this meal! But now your guests are knocking. What do you do?
And more importantly, how does this scenario translate into a genuine business imperative?
The DevOps PoV: Sure, we had a few hiccups along the way, but the end result smells and tastes amazing. Best of all, it’s hot, plated and ready on time for everyone to eat.
The Compliance PoV: Yes, but the steak is 144°F. It needs to be 145°F to be considered safe. Boiling the veggies instead of steaming them depletes important vitamins from the meal. And both layers of the cake need to be exactly 2 inches tall.
Why the great divide? For starters, their reasons for being are at odds. The DevOps philosophy combines people, processes and tools to empower software developers and speed the delivery of high-quality applications, all while cutting costs. It’s also flexible, iterative and imperfect—experimentation is embraced. Imagine someone saying, “We’ll improve it in the next sprint.”
In contrast, compliance is all about order and uniformity; there aren’t any gray areas. Compliance teams are in place to make sure an organization’s security controls are implemented and monitored consistently. They adhere to a set of rules, mandated by a security framework, government body or customer contractual terms.
Yet in today’s world, these teams need to “cook” together—not separately. And that’s not easy.
Can’t Have One Without the Other
Compliance is a business imperative. Adhering to external regulations and the demands of your customers is of the utmost importance. If you think compliance is extraneous or expensive, try non-compliance. And it’s not just about avoiding millions (or even billions) of dollars in fines. It’s about maintaining trust. According to an IBM study, 53% of consumers say how well businesses protect their data from a cyberattack is “extremely important,” while 64% have opted not to work with a business due to concerns about whether they could keep their data secure. A company’s internal rules and controls are also implemented for good reasons, from instilling accountability to meeting customer requirements. They are not optional.
But neither is DevOps. It’s proven to boost competitive advantage by speeding up software delivery. In fact, high-performing IT teams that implement DevOps practices are more agile, deploying software and changes 46x more frequently with 440x faster lead times than their lower-performing peers. DevOps is also driving digital transformation by streamlining operations, cutting costs, accelerating agility and response, breaking down silos, challenging long-held mindsets, encouraging experimentation and cultivating collaboration, productivity and overall job satisfaction.
2 Cooks in the Kitchen: 5 Steps for Making it Work
So, how can two diametrically opposed “chefs” work in concert to create masterpieces? It’s a question that many CISOs and compliance officers are grappling with …
How do I do my job without standing in the way of DevOps?
To find the answer, they must ask another, broader question …
How do I get complete and continuous visibility of the risks impacting my business?
The only way to do this is to embed automated, transparent risk management into the entire DevOps process. Here’s how to get started:
Open Up. Compliance and security teams need to be clear about what’s required of DevOps teams. Effective, ongoing communication and granular details will ensure DevOps teams understand their responsibilities and are empowered to do their part. This open line should flow both ways. DevOps teams should be transparent with compliance about their processes, ask lots of questions and understand how their actions will impact the business.
Get Leadership On Board. Widespread change across people, processes and tools requires support from the top. Executive teams have to believe in it and back it. This will help your organization push through the tough times, convince the cynics and ensure sustained success.
Make Training a Two-Way Street. Train security teams in DevOps processes—it’s easier to protect what you can understand. And involve security in developer training, from attack “post-mortems” to sharing source code repositories.
Embed Security from the Start. Most organizations have multiple security scanning tools in place to identify vulnerabilities at different points in the DevOps process. But this often leads to alert overload, security gaps and more questions than answers. Consistent security scanning should be integrated across the software development life cycle and issues should be monitored in a consistent, centralized manner.
Embrace Automation. This helps organizations understand where vulnerabilities repeat themselves and which ones present the most risk, empowering developers to address real issues quickly so they can get back to business.
Just like perfecting a signature dish, bringing DevOps, security and compliance into alignment takes time. It takes cooperation and patience. All significant organizational shifts do. But by following these steps, you will pave the way for DevSecOps—the holy grail of modern security—to strengthen customer trust and business endurance. Turns out, working together makes things safer and more enjoyable in both the culinary arts and application security.
While talking about DevSecOps has become a hot trend, it is clear that many organizations claiming to follow such methodologies are actually mired in traditional waterfall development. Let’s figure out if you’re really ready to implement DevSecOps.
In a world that relies heavily on distributed computing and third-party services, security is paramount for those who want to remain competitive. From open source applications to operating systems developed, deploying, delivering and correcting application vulnerabilities must occur rapidly before breaches or compromises occur.
Here’s the good news: If your company practices authentic agile development and uses highly modular design patterns such as service-oriented architecture, you are well-positioned to achieve DevSecOps success. Why? Because you are already using key strategies that provide solid foundations for secure computing solutions, so you can immediately start experiencing the benefits that come from doing DevSecOps right.
Follow the Exact Recipe: Don’t Cherry-Pick Ingredients
DevSecOps emerged from people realizing that DevOps did not adequately highlight security concerns and security should be shifted farther left in the software development life cycle. You should think of DevSecOps as sweetening the existing “recipe” of DevOps by baking security in from the beginning without slowing down the development and release cycles. It may sound obvious, but increasing velocity while reducing risks will guarantee the release of better products because they are built with potential risks in mind (for instance, more and better error handling). This approach results in happier customers and repeat business, which will positively impact your bottom line.
DevSecOps Requires a Shift in Culture and Mindset
Let’s face it, the days of successfully deploying applications designed to meet business demands without embedding security controls early in the development life cycle are gone. Effective DevSecOps spans culture, practices and tools that break down silos, orchestrate integrated processes with automated tasks and simplifies security by bringing it out into the open. Instead of “security through obscurity,” boundaries and channels are clearly defined and narrowly focused.
The benefits of DevSecOps are many and include:
Automating security review and application testing.
Increasing the speed of delivery enhances product quality.
Enhancing compliance with continuous monitoring and auditing.
Fostering transparent and open cultures.
Reducing costs, development church and application attacks.
Delivering increased security and confidence.
A methodology that uses communication and collaboration to allow for dynamic development and deployment is crucial for responding to change and needs rapidly. When done right, this new mindset will make everyone in your organization accountable for security with a simultaneous mind and talent shift.
Putting DevSecOps Into Practice: A Checklist
An efficient DevSecOps program will require continuous management and developer education and process improvement through open collaboration, proactive monitoring and informed feedback. Here’s a short checklist to ensure you’re on the right path.
Build an Environment Conducive to DevSecOps: Engage leaders with a new mentality that makes it incumbent on leadership to understand engineering practices, so they know when things need shorting up. Deeply integrate management, so they support the necessary investments in tools and training while encouraging teams throughout the entire development life cycle.
Ensure Open Communication and Active Training: Promote collaboration and ongoing learning that leads to continuous improvement across the organization. Do this well by providing developers with the training and tools they need. Enable failing fast, early and often so you learn from it and create something useful.
Adopt a Security-Conscious Culture: The driving force behind DevSecOps requires security to be defined at the beginning of a project for repeatable, consistent use. This practice will help you respond to security needs and changes quickly while increasing team collaboration.
Implement Infrastructure as Code (IaC): Without relying on manual processes, IaC helps manage and provision infrastructure automatically. This approach allows code to automatically be rolled out in a repeatable and consistent manner through a version-control system instead of relying on installation gurus and “component owners.”
Use Genuine Agile: Instead of cherry-picking from the agile approach and using your own form of agile-flavored waterfall—focus on practicing “Pure Agile.” This method includes detailed and frequent stakeholder involvement, “fail fast” practices and processes, a “meet the requirements” values and principles mindset and technical excellence.
Adhere to Modular Design Patterns Closely: While object-oriented design (OOD) and service-oriented architecture (SOA) mean different things to different people, the commonly understood key is decomposing large business problems into small business problems that can be addressed by discrete services through boundaryless information-flow sharing. When done correctly, OOD and SOA will help your applications scale quickly while decreasing costs.
Favor Resource Management over Pride of Ownership: There is a now-famous analogy about thinking of software components more like cattle than like pets. While grim, the point is a salient one: When something fails, you should be able to quickly replace it with a new or improved component instead of trying to nurse the ailing component back to health. This mindset better promotes modularity and discreteness of purpose, which, in turn, leads to faster fix and restoration times.
As virtual environments and cloud usage grow, the need for DevSecOps to be done “the right way” is growing right along with it. But the sense of urgency to implement DevSecOps practices “the right way” hasn’t quite caught up yet. The challenge is to embrace all aspects of DevSecOps day in and day out, instead of just going through the motions of the select practices you adopted.
The call to action is clear: Now is the time for organizations to move the speed of delivery and secure code out of the textbooks and manifestos into the mainstream.
The point of DevOps is to make IT more responsive (and hopefully more stable, but we have evidence that is not always the case). The point of DevSecOps (so far) is to make security more responsive and to build security right into the stack. These are both worthy goals. As we all have pointed out repeatedly, an already overworked security team needs DevSecOps to keep up with the increased rate of change that a more responsive IT department represents.
And yet, while we’re automating and simplifying things, the security end of DevOps is doing little for end users. Automating protection of App X is good for the App X team and good for the company, but it means little to the ultimate users of security. We all know security is a burden that users bear in the hopes of protecting the company, but no one is a fan. So maybe you didn’t have self-service password management, and now you do. Great! That helps end users. But most of us were already implementing self-service in an attempt to lift some of the load off of the security and help desk teams by the time DevOps took hold.
Maybe you’ve implemented SSO as a result of DevOps. Again, good move! Employees spend less time remembering passwords and more time being productive. There’s less stress, too. But again, that was already well along, DevOps or not. And you know what? Employees are still making passwords they can remember, writing down passwords, re-using the same complex password, etc. To make it more difficult to hack, IT has come up with all sorts of strange rules such as, “Password digits, when summed, must be divisible by the square root of pi …” but that does little if the same password is used for LinkedIn (because it is “work-related”) and LinkedIn gets hacked again. And don’t fool yourselves, I know tech-savvy people who do this. Non-technical people are doing it a lot if techies are doing it.
Which brings us to my suggestion: Your DevSecOps plan should include a password manager budget. There are a ton of them available, they’re cheap enough no matter which one you choose and they will generate complex passwords and then remember them for the user. Give employees password managers, train them a bit on their use, and reduce the chances that their password is the same as the one they used at pleasehackme.com. The investment is small—a few dollars per user for most managers—and choices include vaults that are local or hosted and the ability to set password-generation parameters.
The only problem with a service-based password manager is ownership of the account after the employee leaves the company, but a policy can clearly delineate when responsibility transfers to the user and arrange for removing them from systems at the same time.
More secure, less user hassle (true single sign-on, since they only need to know the password to the password management tool) and low cost—this is the heart of DevSecOps. And the investment is small. A bit of cash, a bit of training. What’s not to love?
In addition, Terrascan is now available as a GitHub Action and is included in the popular Super-Linter GitHub Action. It can be installed as a pre-commit hook to help detect issues before code is pushed into a repository as part of a DevOps workflow.
Cesar Rodriguez, head of developer advocacy at Accurics, said the latest version of Terrascan has also been rewritten in the Go programming language to improve overall performance.
Terrascan analyzes the code created to manage infrastructure as code for vulnerabilities as well as indicators of drift. It then creates a threat model for cloud application workloads and, if necessary, will share data with third-party tools to automatically roll back cloud settings to their last known approved state. Once the model is constructed, Accurics monitors the application workload for changes that introduce risks and generates a topology for each workload in real-time to identify any potential indicators of drift.
A recent report based on an analysis of cloud services published by Accurics finds misconfigured cloud storage services are commonplace in a stunning 93% of the cloud deployments analyzed, with most also having at least one network exposure in which a security group was left wide open.
The report also finds hardcoded private keys turned up in 72% of the deployments analyzed. Unprotected credentials stored in container configuration files were found in half of these deployments. A total of 41% of the organizations had high privileges associated with hardcoded keys. In 100% of deployments, an altered routing rule exposed a private subnet containing sensitive resources such as databases to the internet.
Overall, the report suggests that only 6% of cloud configuration issues are being addressed using manual remediation processes.
Ideally, developers should be implementing cybersecurity and compliance controls as they deploy applications in the cloud. The challenge is that while developers have ready access to tools to automate the configuration of those services, not many of them have tools to verify whether those services have been implemented properly.
IT organizations will still need to scan for vulnerabilities in runtime environments. However, tools such as Terrascan will enable IT teams to advance the adoption of best DevSecOps practices by providing developers with access to scanning tools that can be incorporated easily with a continuous integration (CI) workflow.
Of course, the biggest DevSecOps issue remains culture. However, most developers don’t intentionally want to deploy insecure cloud applications. If given access to the right tools, most developers will do the right thing as long as it feels like a natural extension of an existing workflow rather than an unnatural act that was defined by a cybersecurity team that has little to no idea how applications are actually constructed.
Are service meshes overhyped, or do they solve a real puzzle for enterprise IT systems? Service meshes are a relatively new technology, and many people have found it challenging to fit them into predefined tooling categories. That’s because service meshes have a wide variety of functionality, from load balancing to securing traffic. But service meshes do more than securing your traffic via mTLS, and they can be very important security tools for your enterprise.
Service meshes help organizations improve their security posture, working to both proactively prevent attacks through encryption and access control as well as to provide visibility into anomalous behavior when security incidents do happen. Service meshes can be a strong addition to organizations’ security tooling and are especially important for securing applications that have both cloud-native and legacy components.
In the past, controlling the perimeter of the network was considered “good enough” when it came to network security. There are two problems with this: First of all, even in legacy systems getting through the firewall was often not that hard and, once in, attackers could access the entire system. Just as importantly, this approach simply does not work for distributed, cloud-native applications that don’t even have a clear perimeter to protect. A service mesh makes it possible to tighten control over traffic inside the virtual network, so even if a malicious actor gets in, its presence is easier to detect and the extent of the damage can be limited.
Service Mesh and Security
Here’s why services meshes should be considered security tools—and how they work to secure modern enterprise applications.
Central Control Over Communications
Modern engineering organizations need to give individual developers the freedom to choose what components they use in applications as well as how to manage their own workflows. At the same time, enterprises need to ensure that there are consistent ways to manage how all of the parts of an application communicate inside the app as well as with external dependencies.
A service mesh provides a uniform interface between services. Because it’s attached as a sidecar acting as a micro-dataplane for every component within the service mesh, it can add encryption and access controls to communication to and from services, even if neither are natively supported by that service.
Just as importantly, the service mesh can be configured and controlled centrally. Individual developers don’t have to set up encryption or configure access controls; security teams can establish organization-wide security policies and enforce them automatically with the service mesh.
Developers get to use whatever components they need and aren’t slowed down by security considerations. Security teams can make sure encryption and access controls are configured appropriately, without depending on developers at all.
Cross-environment Microsegmentation
The ability to control access to different parts of the infrastructure is a key part of any organization’s security posture. But in most modern enterprises, each business unit will have applications running both on-premises and in the cloud—potentially in multiple clouds.
With an agnostic service mesh to bridge environments, organizations can segment networks in a way that still creates a seamless experience for users and doesn’t become too complex for security teams to manage effectively.
Inside each segment, the service mesh can be used to create attribute-based access controls (ABAC), role-based access controls (RBAC) or even next-gen access controls (NGAC). A service mesh allows organizations to tune this access control very granularly, including inside individual network segments and across different deployment environments.
Detailed Telemetry
In addition to providing consistent encryption and access controls, service meshes can also provide the telemetry that organizations need to identify potential security incidents and respond appropriately to anomalies.
Because all traffic moves through the service mesh, the mesh is able to collect and display granular information about network traffic. This includes the ability to track the origin and destination of every request sent through the mesh, which is important both for security as well as for passing compliance audits.
With a service mesh that connects both legacy and cloud-native environments, detailed traffic information is available for the entire system. Security teams can use a single dashboard to see how traffic is moving through the system and to correlate signals to users, IP addresses and content as it moves from one environment to another. Having all the information in one place reduces the risk of miscommunications or miscorrelations as traffic moves between environments, either obscuring a real security risk or raising red flags unnecessarily.
Consistent Cross-environment Security Postures
Most modern enterprises have a hybrid/multicloud IT system that includes legacy monoliths in data centers, cloud-native infrastructure in private clouds as well as workloads running in at least one public cloud. There are legitimate business reasons for all of these infrastructure choices, but organizations need to have a strong, consistent security posture across all of them. Service mesh technology allows organizations to connect all of the services, applications and components in the system, regardless of environment, and ensure encryption, access controls and visibility into traffic flows extend throughout the entire system.
Conclusion
Adding a service mesh to your security toolkit is a way to ensure consistency and compliance across the entire, heterogeneous system, no matter what kind of environments and deployment architectures you have. Ultimately, your security posture is only as strong as your most vulnerable deployment. A service mesh is the best way to ensure that every part of your infrastructure complies with your internal security policies.
With embedded software likely to become more complex, now is the time to start thinking about functional safety
As the world has become increasingly more dependent on embedded systems in functional safety markets—such as rail, automotive, aerospace and medical—ensuring the safety of the software in those systems has become even more imperative. That assurance must begin with software development.
As we all know, software development is the point at which many vulnerabilities are introduced, potentially leading to future performance, security and safety issues. The challenge for many embedded software developers is that they are often dealing with highly complex environments. In general, these complex environments are built using C and C++ programming languages.
While C and C++ provide developers with the flexibility and scope for the innovation that embedded environments demand, they also introduce risk. Code can have undefined or unspecified behavior, or may not behave the same way when run on different hardware. Even the most skilled developer may make decisions that inadvertently lead to errors.
Embedded Systems and Functional Safety: Cultural Appreciation
There are ways to reduce software development risks. From a cultural perspective, safety and security need to be baked into the software development process, right from the very start and continuing throughout the entire DevOps life cycle. Of course, this is a practice that should be happening across all software markets, not just within embedded design.
At the same time, there needs to be a greater focus on enforcing compliance with functional safety standards. This practice requires strategies to ensure the safety and security of systems. In some industries, such as rail and automotive, the use of these standards is mandated as part of approval and compliance processes.
Functional Safety Standards
Functional safety standards require performing a hazard analysis and risk assessment of the system. Based on the results, safety functions are then implemented to reduce the risk to an acceptable level. Functional safety standards set out appropriate software development and verification actions to mitigate known risks.
Some of the main functional safety standards in use today include IEC 61508, which covers electrical, electronic and programmable electronic safety systems. First published more than 20 years ago, IEC 61508 is also the basis for several other functional safety standards including ISO 26262 for automotive, EN 50128 for rail, IEC 62304 for medical devices and ISO 25119 for agricultural machinery.
Similar to other standards, functional safety standards do not always receive a warm reception because there is a perception that they require additional work and cost. In fact, by requiring consistent, high-quality coding practices, functional safety standards can reduce time-to-market and cost because they introduce best practice efficiencies into the development process.
Coding Standards
Most functional safety standards require or recommend the use of coding guidelines. For example, in the automotive industry, ISO 26262 mandates the use of coding guidelines and highlights specific areas that must be covered, such as the use of a safe language subset and naming conventions.
Typically, a coding standard is made up of the collective knowledge of many people and organizations, such as manufacturers, consultants and industry associations. This collective knowledge is then used to provide developers with a set of rules to ensure that the code they are developing is safe, secure and compliant. Coding standards also engender better quality coding practices by making code more consistent, readable and understandable within a team.
Depending on the project, organizations often choose to implement an external coding standard either fully or partially. They may also decide to create their own in-house coding standard based on an external standard or their own experience.
While MISRA C and MISRA C++ were originally created for the automotive industry, the coding standards are now widely used across multiple industries. AUTOSAR C++14 Coding Guidelines were developed to address the requirements of modern C++ development environments, including autonomous vehicles and in the future will be used as the basis of a new MISRA C++ standard.
Another popular coding standard used across multiple markets is CERT (coordinated by the CERT division of the Software Institute at Carnegie Mellon University), which focuses on security. With increasing awareness of cybersecurity risks, the use of CERT in embedded software development is likely to increase.
Successful Implementation
Regardless of the approach, successful implementation of coding standards depends on several factors. As there may be resistance to the implementation, teams need to be involved in the selection process of a coding standard and supporting tools. By being included in the decision process, it helps the team to understand why the requirement is critical.
In addition, while it is possible to carry out manual code reviews against a coding standard, any project of significant size will need an automated static code analysis tool.
Static code analysis tools can detect thousands of defects quickly and accurately, which frees up the developers to consider the implementation of the design. These tools work by both analyzing an individual developer’s code changes before they are committed and then scanning throughout the entire project as part of continuous integration (CI). For that reason, static code analyzers harmonize well within DevOps-led development environments.
With embedded software likely to become more complex—especially against a backdrop of AI, ML and IoT—now is a good time to start thinking about putting in place an effective functional safety strategy, which includes tools such as static code analyzers and coding guidelines.
