devopsy.kinsta.cloud

Category: IT as Code

  • IBM Unveils Simulation Tool for Attacking SCM Platforms

    IBM Unveils Simulation Tool for Attacking SCM Platforms

    At the Black Hat USA 2022 conference, IBM today revealed it is making available a toolkit for launching simulated attacks against source code management (SCM) platforms. The toolkit was launched as a proof-of-concept.

    Brett Hawkins, head of adversary simulation for the X-Force Red arm of IBM Security, said the SCMKit takes advantage of the REST application programming interface (API) functionality in most SCM platforms to launch various types of attack modules using validated SCM platform credentials. IBM also described a series of attack scenarios that the simulation tool can be used to launch.

    The SCMKit can currently launch simulated attacks against GitHub Enterprise, GitLab Enterprise and Bitbucket Server. The kit can support reconnaissance, privilege escalation and persistence attack module capabilities for creating personal access tokens or secure socket shell (SSH) keys. The SCMKit is based on a modular framework that makes it possible to add additional modules in the future, added Hawkins.

    IBM created the SCMKit to focus more attention on an attack vector that can be exploited to compromise a software supply chain, said Hawkins. In the wake of a series of high-profile security breaches, the Biden administration issued an executive order that required federal agencies to review the security of their software supply chains. While there is more awareness of the issue than ever, Hawkins noted there has not been nearly as much focus on identifying specific attack vectors against SCM platforms that cybercriminals are able to exploit.

    It’s not clear to what degree organizations are launching penetration tests against their preferred SCM platform as they work to secure software supply chains. However, it won’t be long before testing the security integrity of those platforms becomes more commonplace. In some instances, organizations will launch those tests themselves. In other cases, third-party IT services firms will be tasked with launching those tests.

    Of course, the challenge is that penetration testing techniques are also often used by cybercriminals to conduct reconnaissance. The SCMKit doesn’t uncover any new techniques, but it does provide cybercriminals with a guide for launching attacks against SCM platforms. As such, IT organizations should assume these types of attacks will increase in frequency in the months ahead.

    Regardless of the tool employed, it’s clear that cybercriminals have come to appreciate the fact that software supply chains are the soft underbelly of IT. Organizations today have typically focused most of their security efforts on production environments. However, malware inserted into, say, a software repository could easily find its way into multiple downstream applications. At some future date, the malware then reaches out to a command-and-control system that then enables cybercriminals to, for example, launch a ransomware attack or simply exfiltrate data. That malware could also move laterally across an application environment to wreak additional havoc.

    It may be a while before the full extent of the threat to application security is fully appreciated, but as more organizations embrace DevSecOps best practices to secure their software supply chain, it’s all but certain that penetration testing will become much more pervasive in DevOps environments.

  • Tech Workers Struggle With Hybrid IT Complexity

    Tech Workers Struggle With Hybrid IT Complexity

    Confidence levels among IT workers have plummeted as tech teams’ jobs have become more complex. The reasons behind IT worker angst are unprecedented, signaling a shift paralleling other post-pandemic industries. Running applications across cloud and on-premises infrastructure, hybrid office environments with distributed workforces and the accelerated adoption of new and automated technologies have all contributed to increased IT complexity.

    In our recently-released SolarWinds IT Trends Report 2022—Getting IT Right: Managing Hybrid IT Complexity, we examined the current state of IT along with areas of opportunity for technology professionals who must manage this increased complexity as hybrid IT accelerates. “The continued shift to hybrid IT drives increased levels of IT management complexity, but tech pros feel a lack of confidence in how to best manage it,” according to the report.

    Manage Hybrid IT Complexity

    Solutions are necessary, as the research shows only 8% of tech pros surveyed for the IT trends report feel “extremely confident” in their ability to manage increasingly complex networks. More than half of the tech pros interviewed said their organization manages hybrid IT complexity by training staff and adopting IT monitoring/management tools. However, budgeting, time constraints and hybrid work environments exacerbate this challenge. These responses point to a need for intervention and assessment, as IT professionals’ work is more business-critical now than ever. Strong IT infrastructure is necessary for fundamental processes across all industries and business environments.

    Half Lack Visibility

    According to a report by market intelligence firm IDC, as more mission-critical workloads move to connected cloud architectures spanning public, private, hybrid and multi-cloud environments, enterprises recognize the need to invest in the tools which will help them ensure consistent policies and performance, despite budget and observability implementation issues. The SolarWinds IT Trends report revealed nearly half of respondents lack visibility into the majority of their organization’s apps and infrastructure.

    Indeed, visibility is increasingly becoming the clear answer for tech pros charged with managing greater levels of complexity in these diverse and distributed environments. To develop their teams and business for long-term success, organizations must set aside time and resources to upskill and train tech pros to help them properly implement observability strategies and manage hybrid IT realities more effectively.

    Effectiveness Lost Off-Site

    But some aspects of the remote revolution, including training IT workers for increasingly complex network management, brainstorming sessions, providing sensitive feedback and onboarding new employees, lose their effectiveness when done off-site. For those who’ve made the switch to teleworking, most have found more work-life balance but less connection with co-workers or consistent support from leadership, according to a Pew Research Center study.

    Software company Culdesac announced it’s moving workers online and closing its San Francisco offices. Over 14,000 Google workers worldwide moved to a new office or went fully remote during the pandemic. Other companies, like Microsoft, have said employees who want to work more than 50% of the time remotely must have their schedules approved by their managers.

    Things are quickly shifting as we enter the era of post-pandemic IT infrastructure existence.

    Standards for Automated Network Management

    Solutions are growing in availability. The Internet Engineering Task Force (IETF), an international community of network designers, operators, vendors and researchers, is working on standards for automated network management, which aim to improve and make the management of networks more efficient as they continue to increase in size and complexity.

    While organizations also lack insight into their network’s impact on ROI due to increased hybrid IT complexity, looking forward, they must re-examine their investments from the past few years. Part of this requires companies to have visibility into their IT environments to understand what’s working and not working.

    Economic Growth for Those Willing to Adapt

    Technological change could bring about economic growth and opportunity, but only for those willing to adapt. IT infrastructure is so much deeper than most businesses understand, and as the existing data confirms (and most experts in the field agree), investing in IT infrastructure is necessary. A business’ network—and its speed and security—can be the difference between satisfied or frustrated employees and customers.

    As hybrid IT acceleration has increased network complexity and lowered tech pros’ network management confidence, these post-pandemic problems are a chance for organizations to evolve. “The healthy thing to do is to look ahead, accept the reality, and start getting ready for the transition,” said Chirag Shah, an associate professor at the University of Washington Information School. “So instead of feeling the anxiety and being defensive, think of this as an opportunity for advancement.”

  • Learn Something New Every (Cloud-Native) Day

    Learn Something New Every (Cloud-Native) Day

    Being the new guy at Techstrong Group, the first couple of weeks was spent trying to find things. Like the bathroom when I’m at HQ in Boca Raton or the login to the SurveyMonkey account so I could check on the status of our various in-flight research projects. 

    I also realize I have to learn the vernacular, especially around DevOps and this cloud-native stuff. To be clear, I’ve been researching DevOps and how to integrate security into the process (yes, DevSecOps) for a while. But this cloud-native terminology is something I need to learn more about.

    You’re probably a bit confused about why I’m perplexed by the term ‘cloud-native.’ My work in cloud security for the past 10 years gave me some opinions about vernacular. When I say “cloud-native,” I’m typically referring to the native services you use in your cloud provider. Like AWS Fargate or Azure Container Registry. Those services are “native to the cloud (provider).” 

    But I’m realizing that native cloud services are only a portion of the larger cloud-native revolution. Like DevOps, cloud-native is a state of mind, not a service you buy from a cloud provider. It’s about openness. It’s about portability. It’s about agility. It’s also humbling as I realize I have a lot more to learn.

    That’s why I’m looking forward to our CloudNativeDay event on August 10, 2022. I get an opportunity to dig in and learn about some topics germane to my new coverage areas. For instance, the session on cloud-native challenges in traditional enterprises caught my eye. I’ve been involved in born-in-the-cloud companies, so we didn’t have any installed base to consider. But how would you embrace new and disruptive technology when your company has extensive legacy infrastructure? I can’t wait to hear about those more traditional enterprises’ opinions and experiences.

    Observability is also high on my list of things to learn more about. I’ve been working with customers on advanced security monitoring strategies for decades, but looking at the application layer and associated infrastructure is a different animal. I suspect there will be some technical similarities (collect data, analyze data, alert on data, etc.), but the use cases are fundamentally different. 

    I’m also excited for the last keynote of the day. However, I’m a little biased since it involves an excellent conversation Mitch Ashley and I had with Donald Lutz of Taos (an IBM company), where we dug into some of the enterprise migration challenges he’s seen in the field. 

    They say that when you’re young, you know everything. But as you get older, you realize you don’t know anything. I’m definitely in the latter camp, which is why I’m not going to squander a great opportunity to learn—and neither should you. Register and check out the event. I’ll see you there.

  • Orgs Struggle to Get App Modernization Right

    Orgs Struggle to Get App Modernization Right

    A survey published today found 93% of IT leader respondents admitted that application modernization efforts are either extremely or somewhat challenging.

    The survey, which polled 150 IT leaders at organizations with at least 1,000 employees, was conducted by Asperitas, an IT services provider. The survey found the primary issues respondents identified were identifying the right tools and technologies (30%) followed by finding staff with the right experience (20%), choosing the right external partner (18%), getting users trained on new systems (17%) and securing the support of management (11%).

    More than three-quarters of respondents (78%) said the top priority for organizations taking on application modernization should be “getting it right.”

    The definition of application modernization is, like many things, in the eye of the beholder. One-third of respondents defined modernization as the use of cloud-based infrastructure while 32% said it was moving legacy systems to the cloud. Another 22% defined it as using cloud-based tools.

    More than half of respondents (54%) said employing microservices meant that they were modernizing, while 59% said the use of any cloud-native services indicates as much.

    Scott Wheeler, practice lead at Asperitas, said that while there are a lot of definitions of application modernization, it’s clear that the lift-and-shift era of moving applications to the cloud is coming to an end. Organizations are instead preferring to build and deploy applications using a wide range of cloud-native platforms and platform-as-a-service (PaaS) environments they don’t have to manage.

    The challenge is many of these applications are being built and deployed on multiple clouds. More than a quarter (27%) said the biggest multi-cloud challenge was securing applications, followed closely by integration with on-premises systems and other cloud platforms (26%). Another 20% identified ensuring portability between platforms as the biggest challenge.

    A total of 80% also noted upskilling of internal staff and making improvements to antiquated processes were extremely important to application modernization. In fact, one of the major issues that organizations still need to address is the degree to which “bad DevOps” practices are being applied to modern application environments, said Wheeler. Much of that issue stems from the simple fact that many IT teams still don’t know how to effectively manage cloud computing platforms, he added.

    Well over a third (36%) said that a key application modernization best practice was giving yourself ample time to complete the project while an equal percentage identified avoiding shortcuts, distractions and/or partners that over-promise. Another 34% said the most important lesson was choosing the best tool for the job, while nearly a quarter (24%) identified waiting too long to modernize a system that’s clearly in need of modernization.

    A full 100% of respondents said application modernization was very or somewhat important to their business, with 45% reporting the applications they had chosen to modernize were critical. A little more than a quarter (28%) also noted modernization has enabled them to innovate faster and scale more rapidly, while 25% said it could improve end user productivity and 11% said it might make their company more attractive to employees and customers.

    Regardless of the motivation for modernizing applications, just about every organization is engaged in these efforts to varying degrees. The issue doesn’t seem to be the willingness to start these projects as much as it is making sure they are completed quickly enough to be relevant to the business.

  • Palo Alto Networks Extends Checkov Tool for Securing Infrastructure

    Palo Alto Networks Extends Checkov Tool for Securing Infrastructure

    Palo Alto Networks has added support for GitHub Actions, GitLab Runners, CircleCI and Argo Workflows to Checkov, an open source tool that scans programmatically provisioned infrastructure for misconfigurations.

    Guy Eisenkot, senior director of product at Bridgecrew by Prisma Cloud at Palo Alto Networks, said the goal is to make it easier to secure configurations created using infrastructure-as-code (IaC) tools such as Terraform.

    Those additions are now available as part of a Checkov library of policies, including graph-based checks, that provide a context-aware way of identifying risks within infrastructure and application code within a DevSecOps workflow using a tool that enables IT teams to manage policy-as-code, he noted.

    Misconfigurations of cloud infrastructure have become a major issue. Typically, that infrastructure is programmatically provisioned by developers that have little to no cybersecurity expertise. As a result, cybercriminals are now more aggressively scanning for misconfigurations that they can exploit to, for example, exfiltrate data or illicitly access services via application programming interfaces (APIs). Checkov makes it easier to identify those potential security issues within the context of a DevOps workflow before cloud infrastructure is provisioned, noted Eisenkot.

    There is a lot more focus on securing software supply chains in the wake of a series of high-profile breaches. The Biden administration last year even went so far as to issue an executive order requiring federal agencies to review the security of their software supply chains. The challenge is that most organizations have yet to implement a truly developer-centric approach to ensuring application security, said Eisenkot.

    In general, cloud platforms are more secure than on-premises IT environments; however, the processes used to build and deploy cloud applications today are clearly problematic. A chronic shortage of cybersecurity staff further aggravates the issue, because most organizations are not able to keep pace with the rate at which workloads are being deployed in the cloud.

    As more organizations are also starting to embrace DevSecOps best practices, the overall state of cybersecurity should improve. The challenge is that no matter how much time and effort is made to educate developers, there will always be mistakes a cybercriminal can exploit. Policy-as-code tools like Chekhov make it much less likely those mistakes will carry over into a production environment.

    In the meantime, organizations need to work on work on bridging the long-standing divide between application development and cybersecurity teams. Historically, cybersecurity teams would aggregate vulnerabilities they discovered in spreadsheets that developers would then be asked to remediate. The issue is not only the lack of time to address those vulnerabilities but also the lack of context provided. Many of those vulnerabilities often turn out to not be applicable to the way an application is deployed. Over time, application developers start to ignore many of those requests in favor of focusing their efforts on writing additional code. Of course, the more code that is written the greater the number of vulnerabilities that need to theoretically be remediated until a vicious cycle is created.

    Of course, it’s only a matter of time before one vulnerability winds up being a critical exploit and becomes the exception to that rule.

  • Techstrong TV: The Future of Cloud Security

    Techstrong TV: The Future of Cloud Security

     

    Check Point Software has announced the acquisition of Spectral, an Israeli start up specialized in automated code security. This further reinforces Check Point’s commitment to cloud security. The video is above and a transcript of the conversation is below.

     

    Interviewer:                Hey everyone, welcome to another segment here on Techstrong TV. I’m really happy to have as our guest on this segment TJ Gonen, and hoping I pronounce that right, from Check Point. Hey TJ, welcome to Techstrong TV.

     

    Interviewee:                Yeah, and thank you very much for having us.

     

    Interviewer:                It’s a pleasure. Is that the right way to pronounce your name?

     

    Interviewee:                No, Gonen is the right way. Yeah. TJ is the name that they changed so no one butchers it.

     

    Interviewer:                Well I hear you. It happens sometimes. Hey I really, as I mentioned to you earlier I like the 49ers, especially in a week where they had a tough game. LA, the Rams are going to the Super Bowl in LA and still it’s close.

     

    Interviewee:                Yeah, they almost made it, almost made it.

     

    Interviewer:                It was close, a lot closer than my team, so who am I to say anything. But yeah I know, good for them. Anyway we didn’t bring you on to talk football unfortunately.

     

    Interviewee:                Of course.

     

    Interviewer:                We’re going to talk security, and maybe that’s better off anyway. TJ, why don’t we start though. Why don’t you kind of give our audience a little bit of who you are, a little introduction. What you do at Check Point, stuff like t hat.

     

    Interviewee:                Yeah, sure. So TJ, originally from Israel. That’s a little bit of the accent, now in the US. I am the Vice President for Call Security at Check Point. So I run the Call Security business for Check Point, and been with Check Point for two years. Actually exactly two years since my company was acquired by Check Point a couple of years ago in the cloud security space.

     

    Interviewer:                Yeah, what company was that?

     

    Interviewee:                So we need to talk about another acquisition so it’s an interesting time.

     

    Interviewer:                Well it’s the circle of life. Right?

     

    Interviewee:                Yeah.

     

    Interviewer:                What was the company that was acquired two years ago, your company?

     

    Interviewee:                Ortega Labs. We were in the servalice security space, yeah.

     

    Interviewer:                Absolutely, and of course servalice is a huge, huge kind of growth area right now. But that was two years ago, as you said TJ, and congratulations to you on that. But we have a new Check Point act, so it’s the way of the world. We have a new Check Point acquisition to announce or talk about today. Why don’t you share with our audience a little bit?

     

    Interviewee:                Yeah, so we just a few days ago we announced the acquisition of a company called Spectral in the code security space, and it’s really our move into the developer first security world, and we’ve been very busy in the code security space for the last four years, Check Point through a series of acquisitions.

     

    Actually to call security business at Check Point started with one acquisition, a company called o9 ______ _____ ______ [crosstalk].

     

    Interviewer:                Sure. I know that 09, who was the founder of o9? Not _______.

     

    Interviewee:                Zor.

     

    Interviewer:                Zor. Yeah, I knew him when he started o9.

     

    Interviewee:                There you go, yeah. So awesome company. So that sort of started the journey, then a few acquisitions later including my company and now Spectral, that’s the fifth acquisition we’re actually doing in the code security space.

     

    So I think one of the things that we found out relatively early is that cloud security is almost trying to reinvent all of security. Reinvent it for the cloud and trying to do 30 years of security in 4 years, and it’s very hard to move without acquisitions.

     

    Interviewer:                Yes it is, and look, quite frankly my background is security, so I’ve been in security 25 plus years.

     

    Interviewee:                Yeah.  

     

    Interviewer:                It’s the reason I started devopsy.kinsta.cloud. It’s the reason I got so attracted to the whole DevOps thing, which was I really felt like it was a fresh chance for us to kind of right some past wrongs. Right?

     

    Interviewee:                Right. Yeah.

     

    Interviewer:                A new beginning, if you will. Now it’s funny, I remember in 2005 or from the first time I heard the term cloud security. The Cloud Security Alliance and Chris Hoff and a bunch of folks at RSI were doing a meeting. And back then we found that cloud security is very sort of one dimensional. Right.

     

    Interviewee:                Mm-mmm.

     

    Interviewer:                And but what we see now is it’s infinite in its variety. There is so many different aspects to securing cloud.

     

    Interviewee:                Very much.

     

    Interviewer:                And it’s important. You know, I was on with I think it was the Palo Alto folks yesterday with their latest cloud, Native Survey. For the first time their respondents, and keep in mind when you’re a hammer everything looks like a nail, TJ. Right? So their respondents are probably people in Cloud Native, because it was a Cloud Native survey.

     

    Interviewee:                Right. Right.

     

    Interviewer:                But they said 50 percent of their infrastructure – at least 50 percent was in the cloud.

     

    Interviewee:                Yeah.

     

    Interviewer:                That’s a big threshold.

     

    Interviewee:                It is a big, yeah.

     

    Interviewer:                Right. When you say okay, half of organizations’ infrastructure is in the cloud today, well cloud security really damn important then.

     

    Interviewee:                Yeah, it is very important. Yeah.

     

    Interviewer:                Yeah, and so it’s part, you know, there is reasons for it to be complicated. This acquisition is a little different than o9 or yours.

     

    Interviewee:                Yeah, it is.

     

    Interviewer:                Why is it different?

     

    Interviewee:                Yeah, so the biggest difference I say is the user, and one of the things that we found out over the last two, three years is there is a few trends that are coming down together. One of them is the shift left turn, which is very clear. That shift left is more of a security initiative. Right.

     

    A security initiative that says hey, if I can fix something, prevent vulnerabilities before they hit the ______ department I should do that. Okay. So now if you want to shift left then you are living – your tools are living inside the pipeline, the development pipeline, and they’re supposed to be suddenly used not by security people, but by developers or DevOps people.

     

    Interviewer:                Yeah, yeah, yeah.

     

    Interviewee:                So these suddenly developed tools that are supposed to be used by people first, not to insure that security is their first priority. That’s number one. Actually it’s probably not their first priority. Even if they care it’s not their first priority. Then number two they just are totally used to different environments.

     

    And you find out that the security company definitely like Check Point that’s been doing security for 30 years and yourself and myself who are older than 10 years old as you can see, at least on my side, is that we know how to develop products for security people.

     

    And to develop  products – security products for developers and DevOps people is just a different genetics. It’s a different DNA.

     

    Interviewer:                No, that it’s a different animal, man.

     

    Interviewee:                It’s a different animal. So we were looking at that and said okay, so one, we think that developer first cloud security is a real thing. I mean it’s very important and it’s going to be a very big part exactly to your point there, of the future of cloud security.

     

    So there is always going to be cloud security – security for security people, which is their own time environment, checking out their actual cloud infrastructure. Making sure that the facts are being blocked and all that good stuff. But when you are talking about developer first cloud security you’re going to have a different type of user. You’re going to need to integrate into different types of tool sets. You need to have different types of genetics.

     

    So that’s what you wanted to sell to Spectral is exactly that. So these guys, you know, I met them first time and I said literally I had a, you know, probably a moment where I said okay, that’s it. These guys just get it. They’ve built a product that developers love. They built a product that developers understand how to use.

     

    Just like the one of their customers told me. They said, you know, I ask him why do you like Spectral compared to the other alternatives like Sneak and maybe a couple of others? And he literally said with Spectral the first time I take the connect to this thing first it took me five minutes.

     

    The second thing, I started to use it, everything was exactly where I expected it to be. And he actually used the metaphor in iPhone, and I totally related to that. Where with IOS everything is you don’t know why, but everything is exactly where you want it to be. You don’t need to think.

     

    So they nailed down the developer experience, and it’s not just the user experience and they integrate with tens of tools right out of the gate. They integrate into the IT environment. It’s also one of the things that we as security people who develop products for security people take for granted that you cannot take for granted in developer world.

     

    I’ll give you just a very simple example. Because we assume we’re selling to security people we assume that they’re going to be okay with us screwing up once in a while. For example, false positives. Something will take a bit more time. It’s okay, because they’re security. That’s their job. I mean they don’t have anything else to do except waiting for you to do your job.

     

    When you are talking with developers and you are going to scan code for example, which is what Spectral does. They started the first was scanning for secrets, hard coded secrets inside code, whether it’s in the I keys and W S keys, fast ______, huge problem. I mean developers who aren’t really fast, they forget keys and secrets inside code. They find an attacker that’s easiest way in.

     

    So now you have tens of repos, hundreds of repos. _______ repositories, S stream buckets, so secrets can be everywhere. If I’m a developer and I’m pushing code and I’m waiting for you to scan, and it’s going to take two minutes I’m going crazy over it. Two minutes I’m going crazy. Five minutes I’m killing someone. Ten minutes I’m out of this.

     

    Interviewer:                I’m not doing it.

     

    Interviewee:                And finding a way to go around this.

     

    Interviewer:                Yeah, yeah, I’m not doing it no more. Yeah.

     

    Interviewer:                So this Spectral technology, that was really their core tech, which is really interesting. So they, it’s like keeping it really, really simple. They have the ability to scan huge amounts of code for problems. Now a problem can be secrets. A problem can be mis-configurations in infrastructure as code templates like _______ can be a bunch of missed spaces, but they can do that really fast.

     

    Literally we scan, when we do the due diligence we scan their entire – our entire repo, the checkpoint repo in seven seconds.

     

    Interviewer:                Wow.

     

    Interviewee:                The entire repo, 30 years worth of repo.

     

    Interviewer:                Oh shit. Oh.

     

    Interviewee:                Seven seconds.

     

    Interviewer:                Holy mackerel.

     

    Interviewee:                I know it’s an oh shit. I had an oh shit moment also. It’s so, and it’s not like that. And they were saying okay, something here is happening. Now and it was also super accurate and they found very interesting things.

     

    So once they nail down the user experience or the developer experience you understand how they work and integrated the tools. Then you solve a real, real problem, because that is a real problem and you solve it really fast. That’s why we totally like them.

     

    So we really looking at them and just to make it even more interesting to the point that we started with how different of a DNA it is. Because it’s such a different DNA we’re acting inside my unit, inside the cloud security unit we are leaving them independent. We are not touching them.

     

    I don’t want them to start talking security to security people. You guys get the developers. You understand how they work. You go,  you do you. Just keep on doing that thing. I don’t want to dirty them.

     

    Interviewer:                I got to tell you, I’m sitting here, you know the word kvelling? Have you ever heard that word in your life?

     

    Interviewee:                Yeah, I – yea.

     

    Interviewer:                Because so I started devopsy.kinsta.cloud in 2013. Right. And RSA I think 20, maybe it was 2015 RSA. I started what we call the DevSecOps Event within RSA. It was Monday of RSA week. Right.

     

    Interviewee:                Right.

     

    Interviewer:                And the idea behind it was to bring the security, the cyber whatever you want to call it, the security community together with the DevOps try with the developers. And I got to tell you the aggravation I had, you know, eight years ago. Security people, they don’t care about security, they’ll never care about security.

     

    Interviewee:                Exactly. Yeah.

     

    Interviewer:                They’re stupid. They’re this.

     

    Interviewee:                They’re the enemy. Yeah.

     

    Interviewer:                Right. And you know what the developers are. All they do is say no, they slow us down. They are a pain in the ass.

     

    Interviewee:                Exactly. Totally.

     

    Interviewer:                It was like this. It took me seven years of build, because I believed – I believed that no, security may never be their number one priority, but no developer I ever met raises their hand and says I want to develop in secure code.

     

    Interviewee:                They don’t care, no. Right. No.

     

    Interviewer:                I like crappy quality. I’m a crappy quality developer. You know what I mean? No one says that.

     

    Interviewee:                Right. Right.

     

    Interviewer:                They all, they have pride in what they do.

     

    Interviewee:                Yes, exactly.

     

    Interviewer:                The problem was, is we weren’t giving them tools that they could use.

     

    Interviewee:                Yeah.

     

    Interviewer:                They’re not CISSPs. They’re not ______ or scanning _______.

     

    Interviewee:                No, no, there were security incidents and try to do for _______.

     

    Interviewer:                No, they’re not compliance experts.

     

    Interviewee:                Yeah, exactly. You found the problem, tell me how to fix it. Be very specific. Don’t tell me how to fix it –

     

    Interviewer:                Don’t fix it because I want the quality. I want the quality. Yeah.

     

    Interviewee:                Exactly. And I think you are touching now on a very interesting point, because when you start to bundle these things or unwrap it actually let’s say, one is you’re right, it’s a new user so we talk about it. I actually think that security people today, and I can tell you now product group, that’s exactly how we think.

     

    We think about the developer and the DevOps guy and the ______ guy as a new type of user. He is a user to the security side. I need to think, I need to cater to his needs. Now what does he need? To your point earlier, he is not going to read forensic reports. He is not going to read the tax batchers. That is not his job.

     

    His job is to write quality code that is not vulnerable as much as possible. Now if you find the problem in what he does tell him how to fix it and tell him in his language. In his language. His language is not a dashboard with a search. It is not his language. It is not just a piece of code telling that piece of code is problematic. If you replace it with that piece of code you are good to go.

     

    Interviewer:                Done.

     

    Interviewee:                It’s such a different mindset. It’s like you all are security people. You’ve been around, I’ve been around. We immediately show dashboards and must moves. Who cares? The Spectral ops guys where they showed us a demo and it’s like your heart attack for any normal security person, because what do they show? A CLI.

     

    Interviewer:                Yeah.

     

    Interviewee:                They open the CLI. It’s like everything black screen CLI. Anyone from a security will say I don’t understand what they are doing, but their customers, that’s exactly what they appreciate. To integrate immediately. You are talking with the ex, that everything is API first.

     

    Yeah, there is a report somewhere that you can see in the background if you need, but everything works inside the development environment.

     

    Interviewer:                But this also goes TJ, and we’re probably over time. I apologize.

     

    Interviewee:                That is okay.

     

    Interviewer:                But this also goes that we need to redefine the relationship between the security team and the DevOps developers and the people who use this kind of tool, because what happens is look, it’s going to be the developer. Maybe the DevOps or the SRE, but it’s going to be those people who are instituting the changes to close down a vulnerability or fix something.

     

    Interviewee:                Right.

     

    Interviewer:                That doesn’t absolve the security team of responsibility. No one is saying hey security team, you’re out of a job. Or hey security team, you don’t got to worry about it anymore.

     

    Interviewee:                ______ no.

     

    Interviewer:                The security team still needs that report.

     

    Interviewee:                Exactly.

     

    Interviewer:                That forensics trail if you will, to say hey, yes this was found, this was fixed and this is how it was fixed. And that again is yet another kind of special talent to make a tool that’s easy enough or is in the DNA of the developer, but still gives the security team, the compliance team what they need to sleep well at night.

     

    Interviewee:                That’s why one of the best sentences I like and we used it also when we announced the acquisition is would invent it, people use it before, it’s security tools that developers love and security people trust. That’s the theme. Right. That is so true.

     

    Interviewer:                I may steal that from you.

     

    Interviewee:                Steal it, _______ it. It’s like ten cents a use, and I know it’s in the –

     

    Interviewer:                Okay. We’ll put you down. We’ll put you down. No, but it’s true.

     

    Interviewee:                That’s what you want. Right. That’s really where you want, because and you just described the part that what does it mean for me as a security person to trust the tool that you’re using, and to trust the work that you are doing with it. And I think it’s a very different – it’s very interesting.

     

    I’m thinking the future by the Allan, and I think you are sitting with devopsy.kinsta.cloud, just right on the money. Because the future of security looks like this. You’re going to have security people. They are going to more and more, that’s where it’s going to go. It’s not tomorrow, but that’s where it’s going to go.

     

    The traditional security people I call it the sandwich model. The traditional security people is going to be at the beginning in defining what is secure, or what does it mean to be? Is going to be at the end validating that security actually happened. The sandwich in the middle is going to be more than ever what in the future, more than today by far developers. It’s going to be cool.

     

    Security is code. Computer security people are going to define what’s needed. They are going to make sure that they are going to validate that it happened. These people in the middle are going to be more and more code people.

     

    Interviewer:                People who make it happen.

     

    Interviewee:                Code people. That’s the new security engineer. The new security engineer knows how to code. And that’s why we acquired Spectral and that’s why we are going to let them lead our developer first spot security initiatives, and we’re super excited about it.

     

    Interviewer:                I’m excited for you, and I’m glad to see Check Point coming out with this. It’s great. Hey, for people who want to get information on Spectral where do they go?

     

    Interviewer:                ______.com website. You are going to find immediately on the homepage a link to the information around the acquisition and you can also go and check out spectralops.io, the website of the company.

     

    Interviewer:                I love it. TJ, man thanks for coming on and talking with us.

     

    Interviewee:                You are welcome.

     

    Interviewer:                It was a great acquisition. We’re going to be watching others go. I think a smart move by Check Point. Hey, we’re going to take a break here on Techstrong TV. We’ll be right back with some more interviews and news and information. TJ, thanks very much.

     

    Interviewee:                Thank you very much. Thanks.

     

    [End of Audio]  

  • What Are the Seven Layers of the OSI Model?

    What Are the Seven Layers of the OSI Model?

    Working in the software field, it’s not uncommon for engineers to refer to different “layers.” Perhaps you’re working with protocols at the “networking layer” or evaluating a solution that sits at “Layer 4” or “Layer 7.” Although these concepts are obvious to some, not everyone knows what these layers refer to. To get you up to speed, below, we’ll define the seven layers of the OSI Model.

    What Is the OSI Model?

    The Open Systems Interconnection model (OSI model) is a conceptual model to help visualize a computerized network. Made up of seven layers, it represents the distinct levels that make up an end-to-end computing system. In the spirit of promoting open interoperability, the model is intended to represent a universal standard that’s agnostic to a specific technology or vendor.

    The OSI Model was co-conceived by International Organization for Standardization (ISO) and Internet Engineering Task Force (IETF) and first published in 1984. It has since been redefined as ISO/IEC 7498-1:1994. Although the OSI Model has been around for decades, it’s still referenced quite often.

    The Seven OSI Model Layers

    The OSI Model is split into seven abstraction layers: Physical, data link, network, transport, session, presentation and application. You can think of the bottom one, Layer 1 (the physical layer), as the closest to the most rudimentary electrical connections. The farther up you rise, the closer you get to Layer 7 (application layer), which is the most user-facing category.

    1. Physical Layer

    The physical layer, Layer 1, represents the lowest level of data transmission. This category refers to raw unstructured data bits—and the process of converting them into electrical signals for a device to read. “Physical” hardware like network hubs, modems, adapters, cabling and network controllers work in this layer. Bluetooth, Ethernet and USB describe physical layer specifications.

    The data link layer deals with data packaged into frames. Technologies in this layer assist in node-to-node data transfer, and the protocols here describe how to establish and terminate a connection and how the connection should flow. The data link layer is further divided into two sublayers: Media access control (MAC), responsible for how nodes connect with one another, and logical link control (LLC), which checks for errors and orchestrates the frame flow and synchronization. An example data link layer protocol is Point-to-Point Protocol (PPP). MACsec also can work to apply encryption at this layer.

    3. Network Layer

    The network layer is responsible for sending and receiving data frames structured in packets. Technologies in the networking layer use routers to send packets to nodes on different networks. The network layer might split or fragment the message if it exceeds the maximum network packet sizes. You’re probably familiar with the network layer if you’ve looked up your IP address—the network layer uses the IP protocol (or other logical protocols) to find locations. Such protocols specify a message along with the address of the intended recipient node.

    4. Transport Layer

    The transport layer deals with the transmission of data segments, which are sequences of data at variable lengths. The goal of the transport layer is to optimize data transmission by performing data segmentation and adjusting the size of the package or the rate of transmission. Transport layer protocols include TCP and UDP. Tunneling protocols also operate at the transport layer. The OSI Model also defines five classes of the connection-mode transport protocol.

    5. Session Layer

    The session layer handles the communications between two or more computers. Protocols here are used to create a “session” between entities, which is common in applications that use remote procedure calls. The session layer handles the connection and authentication between a client or server, including actions like logon, look up, log off or session termination. DNS, along with name resolution protocols, operate in the session layer.

    6. Presentation Layer

    The presentation layer is about data translation and formatting. In this layer, protocols handle things like encryption, decryption, compression and decompression. The goal of the presentation layer is to transform data in such a way that it can be sent over a network in syntax that fits the constructs specified by the application layer. For example, technologies that serialize data structures to XML or JSON can be thought of as working for the presentation layer. This sort of data translates into what is graphically displayed for the end-user.

    7. Application Layer

    The application layer is the top layer of the OSI Model and sits closest to the end-user application. User-facing software directly interacts with the application layer through functions like file sharing, message handling or database access. High-level protocols such as HTTP and FTP are used in this layer to share resources. Web browsers and email clients are examples of applications that interact with the application layer.

    The OSI Models: A Helpful Taxonomy

    There you have it—a primer or refresher of all seven OSI Model layers. It’s important to note that the model does not intend to serve as an implementation specification itself—it’s purely a conceptual framework. But it does help provide context into where tools operate and how they interact with elements of a distributed computing system.

    In the context of DevOps technologies, Envoy-based service mesh is often described as working on Layer 4 (the transport layer) and Layer 7 (the application layer). Or, since eBPF filters network frames, it can be said to work at Layer 2 of the OSI Model.

  • A Guide to Cloud Migration Trends and Strategies

    A Guide to Cloud Migration Trends and Strategies

    For several years, we have witnessed widescale cloud adoption as a software infrastructure growth and maintenance strategy. Spending on cloud application services (SaaS) continues to grow as monolithic applications are replaced by microservices-based apps and monoliths become relics of the past. In 2021 alone, companies spent $410.9 billion on public cloud services, and Gartner expects this number to rise by 20.4% in 2022 to reach $494.7 billion. But as this movement continues to evolve, engineering leaders preparing their cloud migration strategy must be up to speed on the latest key trends.

    Is Migrating to the Cloud Cost-Effective?

    For companies migrating to the cloud now, the process is no longer a simple transition from on-premises to remotely hosted servers. Cloud service providers now offer a wide variety of options, and companies run the risk of overspending in the cloud marketplace.

    A lack of clarity of their business and product needs or submission to shiny object syndrome can drive companies to spend on non-essential services, especially during migration. It is easy to fall into this trap; companies only realize it after they have committed and try to undo the damage by reversing the process.

    Although many public cloud providers offer pay-as-you-go pricing, companies often purchase more services than they use. When companies are unclear about their objectives, such expenditure is more extravagant than the utility. This awareness of cloud spending has encouraged companies to take stock of their needs and expenses, and when they do not add up, to consider partly shifting back to on-premises.

    But Isn’t On-Premises a Thing of the Past?

    Not yet, but gone are the days of mindlessly unloading entire infrastructures into the cloud. Increasingly, companies are aware of the costs of pulling their data from the cloud.

    For many, security and control concerns motivate them to keep data on-premises. The public cloud has its benefits, but private storage has its place, too, especially for some components of your software. All in all, on-premises is here to stay, as companies continue to acknowledge and appreciate its value despite their reliance on public cloud environments.

    Why Do Companies Choose Cloud Migration in 2022?

    Cloud technologies can potentially deliver faster and better-performing experiences to end users, while innovations are giving rise to new services that cloud vendors can capitalize on. Various use cases are surfacing as companies understand the cloud better and see its potential. They are pushing the boundaries on how they can use the cloud, and cloud service providers are keeping track of the changing nature of the demand.

    For example, cloud-based gaming platforms like Amazon Luna are seeing significant growth. The cloud is also of great value to artificial intelligence and machine learning efforts, and these are often intertwined.

    The Great Resignation phenomenon also drives some companies towards the cloud. Although some knowledge is needed when moving to the cloud, cloud services offer automation and require less employee supervision in the long term.

    The COVID-19 pandemic has also been a catalyst for accelerating cloud adoption, making resiliency a priority. Companies can stay afloat in an emergency if their workloads are moved to the cloud. It comes at a cost, sure, but allows companies to outsource time-consuming responsibilities and focus resources elsewhere. While this was most significant in 2020 and 2021, this logic remains relevant.

    Cloud computing is also helping companies improve performance, efficiency and scalability. In addition to AI, the cloud will be instrumental in the development of more powerful augmented and virtual reality apps.

    Approaches Defining Cloud Migration Today

    The possibility of these approaches or facilities also motivates companies to migrate to the cloud:

    Containerization: The process of compiling and storing a service, along with its dependencies, in a container. Due to their small size, multiple containerized applications can run on a server, allowing for easier and cheaper shipping of the service. According to CNCF’s 2021 Annual Survey, containerization is now a mainstream practice, and Kubernetes, for instance, is a heavyweight in this domain, with 96% of companies employing or evaluating it.

    Security: In Q1 of 2022 alone, 90% of data breaches had their origins in cyberattacks. Mindful of this alarming trend, companies are factoring security concerns into their cloud adoption strategies. We are also witnessing a shift in businesses’ approach to security via DevSecOps: Incorporating security as a continuous practice from the beginning of the software development life cycle instead of relegating it to the back-burner until the last moment. Additionally, frameworks like secure access service edge (SASE) and customized cloud disaster recovery strategies are becoming essential elements of cloud adoption.

    Sustainability: Sustainability is becoming a key component in most business models. Companies are eager to adopt practices and models that reduce their carbon footprint. This impetus is also emerging from business partners and investors who are beginning to employ sustainability as a critical factor when deciding which companies to work with. When a cloud migration is planned carefully, chances are that you will retire certain services in your infrastructure and make decisions about what to migrate and what to retain. By optimizing your migration strategy, you are likely to only run and pay for the services you need, ensuring that your energy expenditure is under control.

    Edge computing: Edge computing, a $176 billion market in 2022, emphasizes the importance of building data centers locally; i.e., closer to where they are needed for storage and computational purposes. It solves any bandwidth and latency issues. Improved security is another added benefit of this practice. Edge computing has a bright future as it attempts to compensate for some of the pitfalls of using centralized servers in the cloud.

    Cloud-native applications: Cloud-native applications are easier to work with on the cloud, as they are designed and built on the cloud itself, not rearchitected to ensure compatibility with cloud services. When compatibility is not a concern, they can leverage various benefits offered by cloud services. As a result, scalability, flexibility and resilience are built into these applications. With cloud adoption, companies are increasingly in favor of cloud-native applications. This subsequently informs their migration strategy as they decide which services to retire, rearchitect or build anew once the actual migration is complete.

    How Does the Hybrid Cloud Fit In?

    Hybrid computing is on the rise as it leverages the public and the private cloud to deliver maximum benefit to companies with little to no compromise. The public cloud offers scalability, flexibility and speed, while the private cloud provides cost-effectiveness, security and compliance with regulations. While sensitive data can rest on the private cloud, frequently accessed data can be stored in public servers like AWS and Google Cloud. Investing in a hybrid cloud strategy from the point of migration itself can go a long way in giving companies access to the best of both worlds.

    Similar to a hybrid cloud environment, a multi-cloud strategy where companies distribute workloads across multiple clouds put some control into the company’s hands and ensures additional flexibility. By working across cloud services, companies can pick and choose which services are most compatible with their application’s components. These can include services offered by different cloud providers.

    Cloud Providers Seeing Growth, and What They are Doing Differently

    Serverless cloud environments: Cloud vendors like Amazon, Microsoft and IBM are pushing serverless cloud services. Although these continue to rely on servers (despite the name), companies don’t rent servers or pay fixed charges. Instead, the storage and bandwidth infrastructure scales with the software as and when it requires it. Companies do not need to concern themselves with technicalities and can focus on innovation and improving their existing applications. An added advantage is the provision of safe testing environments that encourage developers to tinker with cloud services and develop solutions for potential failures or outages. Serverless cloud solutions are also beneficial for smaller companies that need not invest large amounts of capital to ensure growth.

    Partnerships: To meet the soaring demand for cloud services, partnerships among cloud providers are also on the rise. By partnering with other service providers, companies can offer more services by leveraging the resources and reputations of one another while strengthening their competitive edge in the cloud market.

    Industry optimization: Cloud adoption is not limited to software companies. Businesses across industries like healthcare, finance and retail are migrating their infrastructures to the cloud. This variety in demand has encouraged providers to customize their services to meet the specific requirements of each industry. Often, these include regulatory compliance needs in these sectors.

    The cloud is only getting bigger and better. You can develop a well-curated transition strategy with the knowledge of current cloud migration trends. Additionally, identifying your requirements at an early stage will go a long way in leveraging the cloud to your advantage.

  • API Gateway Vs. Service Mesh: What’s the Difference?

    API Gateway Vs. Service Mesh: What’s the Difference?

    In the average microservices architecture, app programs trade the stability and rigidity a call stack offers for the network’s flexibility. Consequently, latency, security and traceability issues that were previously absent become a service call concern. 

    Service mesh is the resulting solution to eliminate these issues and allow developers to focus on more important business solutions. The caveat is the functionality overlap that exists between a service mesh and an API gateway. But while the two are similar, there are also key differences between both options. Here’s what you need to know.

    Defining a Service Mesh

    A service mesh is a comprehensive architectural pattern set designed to deal with enterprise concerns like instability, debugging and security. These concerns arise when a team moves from a call stack to network calls. 

    For instance, a function call via a call stack recognizes the constant availability of the requested function. On the other end of the equation, a network call doesn’t offer this functionality. 

    A service mesh is the preferred option because it assists the system’s client endpoint in managing network instability. The primary method for solving this network instability is frontrunning retries transparent from the client app’s viewpoint. 

    The service mesh also assists the server’s endpoint by rerouting incoming requests to the server node that’s best able to deal with the incoming request. The choice of server node is a function of previously determined policies for routing incoming traffic.

    The ideal service mesh is installed with two layers: The control plane and the data plane. The latter is a proxy for any connection’s server and client endpoints. 

    The data plane also enforces policies from the former while running operation metrics to a monitoring tool. Conversely, the control plane layer manages all attending service policies alongside the data plane’s operation. 

    service mesh

    Image Source

    Key Features of a Service Mesh

    The average service mesh has a number of primary features. 

    But there are a few things that bear mentioning. Say your app development team is working on a small business phone system. This particular service implementation doesn’t need every feature listed below. It depends on your team’s specific needs and traffic setup.

    Traffic Routing

    This feature enables the service mesh to route requests based on preset configuration or a predetermined policy. The system may prioritize traffic from specific client applications. Alternatively, a service mesh can re-route traffic to different service versions for:

    • A/B testing
    • Canary release
    • Service versioning

    Observability

    Service mesh implementations feature proxies that record service calls for individual clients and services. This feature takes the manual burden of the call-logging process away from the developers. 

    Plus, teams can leverage downstream analysis and monitoring tools to report on system availability and overall performance. These monitoring tools also provide a framework for basic tracing across all call chains. 

    The observability capabilities of a service mesh extend beyond the above. For example, some coding work can allow developers to improve call chain monitoring to allow for accurate tracing for enterprise business transactions.  

    Common service mesh observability features include: 

    • Latency, error rate and throughput alerts
    • On-demand service dashboards and graphs depicting the connection between individual services
    • Tracing the journey a business transaction or request makes through the service mesh

    Image Source

    Security Policies

    An application with multiple independent services has a huge attack surface. Essentially, each independent service is a vulnerable entry point that requires protection. A service mesh has proxies on both the server and client endpoints to secure any communication between both terminals. 

    A service mesh also improves security by eliminating the dependence on developers to manually program security into every service. Instead, the server proxies will handle authorization, authentication and encryption for each independent service. The resultant effect is a zero-trust security framework.  

    Identity

    A service mesh manages who can access individual services. It also maintains a real-time log of stakeholders accessing each service and when they did so. The system validates identity through JSON Web Tokens (JWTs) while allowing authorization depending on the requesting service and the stakeholder. 

    Encryption

    Compliance, security and data protection are key considerations. Well, communication between all services in a service mesh is fully encrypted. The control plane is responsible for certificate management functionality including certificate rotation and generation. 

    Furthermore, a service mesh uses mutual TLS where both server and client endpoints whitelist the certificates that can operate on the other side of any connection. A service mesh provides robust mutual TLS authentication, allowing for seamless system authentication and encryption. 

    Resilience

    This feature defines the ability of a service mesh to insulate developers in scenarios where the principal service function goes offline. In some instances, the proxy may follow an alternative service path or switch to a backup framework. 

    For illustration, streaming giant Netflix has a personalized user recommendation feature that suggests titles to its users. If this service goes offline, a service mesh system can ensure a switch to a default recommendation feature with zero personalization. Only when this backup fails will the system return an error code. 

    A service mesh assures developers that when a service fails, the proxy has done all it can to manage communication errors. In some cases, the mesh can ensure optimal performance by switching to a different service with the lowest latency.

    Examples of configurable resilience patterns for a service mesh include 

    • Circuit breaker patterns
    • Rate limiting
    • Retry policies

    Another illustration of a service mesh’s resilience is the ability to build chaos engineering capabilities. The service mesh can inject itself into the endpoints within the network, providing the observability required to monitor a chaos test. 

    Image Source

    What an API Gateway Entails

    Whether the team is working on contract management software for small business or an expense calculator app, the choice of API can determine the results of your team’s app development efforts. But more than the choice of API, proper management is another crucial talking point. The best results come with a system that identifies incoming calls, directing them to the appropriate resource. 

    API gateway is the future of DevOps and is the solution to that need. It’s the technology framework for routing API client calls to the ideal application. It also processes the call, forwarding resulting responses to the client’s network.

    At the technical level, an API gateway isn’t a must-have. Find a developer with a digital business card, hire them, and they can always program an embedded code responsible for call request routing. The only caveat to this alternative is the manpower and resources necessary to program and insert codes for individual call requests. As such, it’s always better to have an API gateway to handle this task. 

    An API gateway is a more innovative solution because extensive coding always holds the possibility of risks and errors. Furthermore, these errors can complicate app development stages like maintenance, bug fixing and application testing. 

    The API gateway ensures all API requests reach their intended destination with zero diversion. Plus, it also offers the following added functionalities:

    • API request monitoring
    • Shifting API requests between individual nodes
    • Request balancing for multiple instance situations

    The Major Differences Between API Gateway and Service Mesh

    An important digital workplace definition that differentiates both frameworks is the placement location. The API gateway is necessarily present on public-facing systems. Other key areas where an API gateway and service mesh differ include:

    Observability

    Observing the performance of the average API gateway is a more concrete task. The framework can provide actionable data insights like how long the API takes to respond to requests, problematic features, and their impact on network traffic. 

    With the service mesh, the ability to spot performance issues is a given. However, the system can’t ascertain any effects of performance lags on end-user response and experience. Therefore, while troubleshooting is easy, gauging the extent of the problem’s impact is more complicated. 

    The Communications They Handle

    Both frameworks manage different communication nodes—one handles internal discussions and the other external ones. The API gateway is the component responsible for routing external communications. For example, the API gateway handles chatbot connections, purchase orders and visits to specific pages. 

    Conversely, the service mesh is responsible for internal communications in the system. For illustration, a discussion between multiple microservices under the same app environment will fall under the service mesh’s purview. 

    In other words, the API gateway manages client-server discussions. Meanwhile, service-service communications are for the service mesh. 

    Management

    Both frameworks may have some areas of overlap, but the amount of management each one requires isn’t one of them. API gateways are simpler to manage and develop. As such, they’re easier for your app development team to manage. 

    The deployment for an API gateway happens just once, regardless of the service app. Plus, post-deployment centralization and monitoring are easy tasks. 

    In contrast, a service mesh is more complicated and tedious to manage. Your app development team must deploy the service mesh function for individual app systems. 

    Compatible Tools

    Most API gateway tools and software resources are highly expensive. Plus, they’re compatible with every popular app architecture. 

    The other end of the equation offers more accessibility. There are countless service mesh tools and resources for varied functionality. Plus, the majority of these support tools come at zero cost because they are open source.  For example, there’s Envoy and Istio, both of which are free and open source. 

    However, you shouldn’t expect to enjoy cross-platform compatibility across these service mesh tools. For example, Istio is only compatible with Google. On the other hand, AWS App Mesh—another service mesh tool—is compatible with AWS Cloud. 

    Image Source

     

    Difference  API Gateway  Service Mesh
    Existing Functionalities
    • Useful for API requests between the client and server
    • Compatible with external API requests and internal calls. 
    • Handles internal communications 
    • Best for improving the portability of service-to-service calls 
    Digital Transformation Functionality
    • Longer app delivery cycles 
    • Zero security risks
    • Useful for effective microservices management 
    • Speeds up the network’s delivery cycle 
    • Security risks due to open loopholes when the program runs alone
    Operations Reroutes API calls present outside of the given application environment  Works within the application architecture 
    Maturity Level API gateway is mature technology. It has been a core developer tool for several years now Service mesh is still a relatively new technology and requires more research and development
    Security Processing Automated security protocol Manual security systems 
    Usage Complexity Application complexity remains constant with endpoints remaining unchanged  Business scalability can be complex as each update comes with new endpoints 

    Can Service Mesh and an API Gateway Be Used Together?

    The unlikeliest of brands often form marketing partnerships. In the same way, there are instances where using both a service mesh and an API gateway is a logical and feasible idea. 

    While differences exist between an API gateway and a service mesh, it’s not an “either/or” situation.

    Cloud contact center teams looking to streamline communications at both the internal and external levels are already leveraging both technologies. And you can also leverage both systems to achieve the following:

    Improved Innovation

    Effective API use, especially during external interactions, requires internal resource optimization, which is better when teams deploy a service mesh alongside an API gateway. 

     

    Image Source

    Accelerated Digital Transformation

    Leveraging both resources improves enterprise digital transformation rates. Plus, any application with both technologies will enjoy a unified API gateway for internal service mesh management. If there are any linked applications, the unified API makes them simpler to handle.

    Increased Security Scalability

    Scalable container security is achievable when you deploy a service mesh and API gateway together. The service mech will boost the system’s interservice connectivity while the API gateway acts as a central point for all client-server requests. 

    The API gateway also provides the much-needed technical support for increased proxy security. It also fosters quick threat detection and resolution at the proxy level. 

    API Gateway and Service Mesh are Different

    Both the API gateway and service mesh are designed to simplify communication while also reducing any coding responsibility on the app development team. While both systems can ensure network calls through an enterprise contact center reach the target destination, they’re structurally different.

    Above, we’ve highlighted the key differences between both frameworks. But despite these differences, both systems are compatible and can work together for improved app development. We recommend leveraging a service mesh and an API gateway together for better security, innovation and app scalability.

  • JFrog Aligns With AWS to Improve Cloud Application Security

    JFrog Aligns With AWS to Improve Cloud Application Security

    At the AWS re:Inforce event this week, JFrog announced it integrated its JFrog Xray software composition analysis tool with AWS Security Hub, a cloud security posture management (CSPM) service that alerts IT teams whenever a security issue is detected.

    In addition, JFrog also announced it is participating in a preview of an AWS Marketplace Vendor Insights tool. AWS created Marketplace Vendor Insights to provide cybersecurity and compliance risk assessments of the third-party software made available on the AWS marketplace.

    Steve Bohac, partner marketing manager for JFrog, said the integration of JFrog Xray with AWS Security Hub will streamline the flow of cybersecurity alerts an IT team receives by centralizing the delivery via AWS Security Hub. AWS this week similarly moved to integrate the Amazon GuardDuty Malware Protection service with AWS Security Hub.

    Collectively, security services accessed via AWS Security Hub are intended to make it simpler for IT teams that have deployed application workloads on the AWS cloud to embrace DevSecOps best practices. JFrog Xray, for example, is designed to be deployed using the AWS Lambda serverless computing framework, noted Bohac.

    The arrival of these services comes at a time when the focus on cloud security, as part of a larger effort to better secure software supply chains, is rising in the wake of a series of high-profile application breaches. In general, cloud platforms are more secure than on-premises IT environments; however, the processes used to build and deploy cloud applications are often problematic in that mistakes are frequently made. Developers routinely use open source tools like Terraform to provision cloud infrastructure and accelerate application development. Most of those developers have limited cybersecurity expertise so, inevitably, there are misconfigurations that cybercriminals have become more adept at finding and exploiting.

    The ongoing chronic shortage of cybersecurity professionals means most organizations are not able to keep pace with the rate at which workloads are being deployed in the cloud.

    Fortunately, more organizations are also starting to embrace DevSecOps best practices to make software supply chains more secure. The challenge is that no matter how much time and effort is made to educate developers, there will always be a development team that makes a mistake. Tools such as JFrog Xray make it feasible to discover those issues before an application is deployed.

    It’s not clear how long it might be before DevSecOps has a meaningful impact on cloud application security. The number of applications already deployed on cloud platforms is already innumerable. In theory, at least, as each of those applications is reviewed and updated, they should become more secure as DevSecOps best practices are more widely employed. However, it may be years before the overall security of cloud applications materially improves.

    Eventually, the next generation of cloud applications should be substantially more secure than their predecessors. The hope is, in the meantime, any vulnerable cloud applications that have security flaws won’t be exploited before IT teams can bring to bear the resources required to fix them. In effect, it is a race against time.