Category: DevSecOps

  • Live Fireside Chat with Christopher Krebs: How to Combat Disinformation

    Live Fireside Chat with Christopher Krebs: How to Combat Disinformation

    We live in a digital world where most information is now found online. This makes it increasingly difficult to verify the veracity of information. Threat actors have been taking advantage of the digital landscape to spread disinformation, propaganda and conspiracy theories to manipulate the public and sow doubt, discord and chaos. How can we distinguish between fact and opinion, truth and supposition? How can we spot fake news and tackle disinformation?

    Former Director of the Department of Homeland’s Cybersecurity and Infrastructure Security Agency (CISA) and Co-Founder of Krebs Stamos Group, Christopher Krebs, will be speaking about disinformation at this year’s DevOps Connect: DevSecOps on May 19 at 12:00 p.m. EDT. During his keynote session, Krebs will explain what disinformation is, how to recognize fake news and the challenges disinformation poses to cybersecurity teams. He will reveal effective ways to combat disinformation, and how public and private partnerships can help. Krebs will also be answering questions from the audience during the live Q&A session.

    Krebs is a founding partner of the Krebs Stamos Group, and previously served as the first director of the federal CISA for two years. Before that, he served in various roles at the Department of Homeland Security (DHS), responsible for a range of cybersecurity, critical infrastructure and national resilience issues. He has also directed U.S. cybersecurity policy for Microsoft and advised industry and government clients on complex cybersecurity and business risk matters while serving in positions with Obsidian Analysis and Dutko Consulting.

    DevOps Connect: DevSecOps has been part of the RSA Conference for six years in a row. This year, the main focus of the event is on “Securing the Cloud Native World.” Krebs has joined a stellar lineup of DevOps, cybersecurity and IT thought leaders as the DevOps Connect 2021 featured keynote speaker. Attend his live session, “Disinformation: As Dangerous as Cyber and Physical Threats,” and check out all the other breakout sessions to learn more about cloud security, DevSecOps, cybersecurity threats—such as disinformation—and more.

    For more information and to register for free, visit the DevOps Connect 2021 website. Save your spot today and learn how to better secure, monitor and maintain the security of your systems.

  • The Pandemic’s Impact on Mobile App Security

    The Pandemic’s Impact on Mobile App Security

    Mobile device use has continued to grow throughout the global pandemic, surpassing 5.19 billion mobile phone users worldwide over the past year. As a result, companies have been launching mobile apps at an incredible pace to capitalize on the abundance of potential users.

    The rapid pace of mobile app development, however, has led to a sudden uptick in privacy and security issues as well. As a result, many mobile developers are starting to recognize the need for a more proactive and streamlined approach to app security by adopting a DevSecOps mindset.

    Mobile Security In The Spotlight

    Mobile apps have become an enticing target for criminal exploitation because many developers don’t have the time to prioritize security measures like obfuscating their code, encrypting sensitive information or monitoring for live attacks after publishing an app. In fact, the FBI has reported a 50% surge in mobile banking usage, which has led to an increase in banking trojans and other attempts at financial fraud. Moreover, studies have shown that nearly every sector and companies across industries are facing cyberthreats, with 55% saying that being compromised had a lasting impact.

    With regard to government responses to COVID-19, the release of contact tracing apps intended to help contain the coronavirus were recently in the spotlight for their lack of adequate security measures. These crowdsourced solutions gave governments more widespread reach for warning individuals that may have been exposed to the virus, but many mobile app developers had to launch them quickly, and security was not made a priority. Some contact tracing apps, like many other mobile apps on the market, failed to protect user privacy because they relied on the phone’s GPS, harvested personal information or sent data to a centralized database.

    In an effort to make these contact tracing apps more secure, build trust and gain more user adoption, Apple and Google jointly released an Exposure Notification API. One year into the pandemic, mobile developers can use this API to build more secure contact tracing apps without compromising personal information. While the majority of contact tracing apps have adopted the API, this issue has revealed broader concerns about mobile application security and the need for DevSecOps in the industry.

    DevSecOps For Mobile Developers

    DevSecOps is an approach to application security that integrates security processes throughout the entire development pipeline. For mobile apps, this means scanning for issues during development, testing, deployment and following up on threats after release. By creating a secure software development life cycle (SSDLC), organizations can leverage automation to improve application security without burdening developers.

    A key aspect of DevSecOps is catching issues earlier in the SSDLC, which is often called “shift left.” This is a proactive approach to application security where app developers use code hardening tools to protect their apps and code scanning tools to detect and remediate issues during development. By preventing vulnerabilities from reaching later stages of the SSDLC, the cost and effort involved with remediating security issues is much lower. While mobile app developers have prioritized being first to market in the past, many companies are now recognizing that a shift left of security efforts aligns with this goal.

    Besides the development phase of the pipeline, it’s crucial for mobile app developers to implement security processes in the testing phase, as well. Both static and dynamic automated testing tools can detect vulnerabilities in the source code and execution of mobile apps to prevent issues from reaching production. With a DevSecOps approach, mobile developers can integrate these tools directly into the continuous integration and continuous delivery (CI/CD) pipeline to minimize the manual effort involved with improving their security posture.

    While many mobile app developers have had to learn the hard way by experiencing a security breach, the pandemic has motivated others to take security more seriously. As people spend more time at home and shift to digital means for everyday tasks like shopping and banking, they’re using mobile apps far more frequently. Prioritizing security as well as speed by adopting DevSecOps methodologies allows mobile app developers to better protect their users and intellectual property as well as build greater trust in their apps without sacrificing time-to-market.

    Enterprises may have more mature security programs in place, but mobile app developers are quickly catching up. The pandemic has put mobile security issues in the spotlight and motivated app developers to adopt DevSecOps. As mobile apps continue to become more critical for businesses, the maturity of security programs within the mobile app industry will likely improve even further.

  • Is Low-Code Development a Security Risk?

    Is Low-Code Development a Security Risk?

    According to Gartner, the worldwide low-code development market is projected to be $13.8 billion in 2021, a whopping increase of 22.6% from 2020. Gartner also predicts that the surge in remote development during COVID-19  will continue to boost low-code adoption, despite budget cuts and efforts to optimize cost.

    Low-Code’s Popularity Among Professional and Citizen Developers

    Low-code is no longer the new kid on the block. From simple dashboards to complex applications, low-code applications are becoming more and more diverse, with mainstream adoption in the enterprise world. In essence, low-code is a visual paradigm of application development that involves drag-and-drop of pre-built components and integrations resulting in fast, easy and less-error-prone development.

    The advantage of low-code is that it enables users from a non-traditional development background to participate in the app development process, thus democratizing development and accelerating project timelines. It also narrows the demand-supply gap that arose as organizations catered to ever-rising digitization needs with limited resources and developer scarcity. Many low-code platforms make it easy for citizen developers (business analysts, line-of-business users, junior developers, for instance) to build applications while drastically reducing delivery time compared to traditional coding methods.

    But citizen developer productivity and speed are not the only benefits of low-code development. Today, low-code platforms also come with capabilities purpose-built for professional developers from enterprise IT teams to ISVs. These platforms are hardened for enterprise use, are able to leverage the scalability and security needs of a complex application and have integration capabilities mature enough to seamlessly fit in with existing tools and technologies. During the COVID-19 pandemic, many businesses reinvented themselves through adoption of low-code platforms and applications that helped them adapt to the sudden shift to a remote work scenario and enable the necessary modern application needs that came with it.

    Security Challenges with Low-Code and Remote Work

    Compared to traditional development, low-code involves a variety of personas working together to build applications while dealing with automatically generated code, ready-made components and built-in default configurations. This shift in environment revealed some unique challenges that need to be addressed. There are a few common security challenges with remote teams building on low-code.

    Application Development and Remote Team Collaboration

    • Lack of security awareness: Low-code users come from both business and tech backgrounds. Some practitioners aren’t familiar with application security best practices and lack awareness and understanding of potential vulnerabilities and security holes.
    • Platform access and admin controls: Low-code is deployed centrally and available for users across an enterprise via browser access. This introduces a risk of network intrusion; providing access to unauthorized developers and opening up greater permissions to users that do not need it when accessing the platform remotely.
    • Code repository and team collaboration: Low-code platforms must ensure that the automatically generated code can committed to enterprise-sanctioned repositories. This code access shouldn’t be misused, and ought to have sufficient protocols in place for code control and upgrades.

    Code Generation and DevSecOps Best Practices

    • Securing custom code: Low-code tools allow for writing custom code to extend and enforce platform coding guidelines and design patterns to protect sensitive data from unauthorized access.
    • Adhering to secure release practices: Integration with the existing enterprise CI/CD pipeline is important so that dev teams can extend the same release governance protocol to the auto-generated code before going to production.

    End User Application Access and Data Protection

    • Preventing malicious attacks: Today, both web and mobile apps are becoming constant targets for security breaches. Automatically generated code, and citizen developers working remotely, can make low-code applications more prone to vulnerabilities. Platforms should generate apps that are fully protected against phishing attacks, SQL injections, brute force attacks and DOS attacks.
    • Secure data and application access: Low-code platforms should provide a comprehensive access control mechanism preventing unauthorized access to data and app functionality. With remote teams accessing apps from anywhere, at any time and from any device, data breaches can be prevented with the right controls in place.

    Low-Code and Security – The Future of Development

    As enterprises and ISVs turn to low-code for more serious use cases, the larger question still remains. Can low-code platforms enable modern development teams to deliver applications faster, while still enabling a secure and tightly governed environment?
    The answer is, yes, they can! However, development teams must consider the following security checklist when considering low-code platforms:

    1. The chosen low-code platform must be set up within an enterprise secure DMZ or secure private cloud, and must effortlessly pass cybersecurity clearances.
    2. The platform must enforce best practices in programming (coding conventions, design patterns and data encryption) for automatically generated code as well as custom code written by the developer, facilitating easier integration with existing CI/CD processes and tools.
    3. The platform must offer full protection against the top 10 OWASP vulnerabilities for web and mobile apps, and have third-party certifications to guarantee code quality and security. Also, organizations should ensure that there are no vulnerabilities in their chosen platform’s binaries, as well as all third-party dependencies (including open source libraries) as listed in the CVE library.
    4. The solution must support multiple authentication providers (database, LDAP, AD, SSO, SAML, Open-ID, multifactor, biometric) to build applications with strong user security. For user authorization, ensure support for both coarse-grained as well as fine-grained access control policies to protect various aspects of the application based on RBAC.

    Development teams can embrace low-code technology while ensuring security best practices are in place. Low-code is here to stay, and with the right platform, enterprises and ISVs can make sure security is shifted left and addressed by developers much earlier in the development process. The result is a highly productive, remote workforce churning out applications that are modern, scalable and secure.

  • WhiteSource Acquires Diffend to Secure Open Source Supply Chains

    WhiteSource Acquires Diffend to Secure Open Source Supply Chains

    WhiteSource this week announced it has acquired Diffend as part of an expended effort to discover malware that has been deliberately injected into open source software by a contributor acting in bad faith.

    Company CEO Rami Sass said cybercriminals are increasingly trying to compromise software supply chains that today depend heavily on open source projects. The Diffend platform surfaces anomalous contributor behavior that would be indicative of someone trying to compromise the integrity of a project, said Sass.

    Previously, WhiteSource provided a tool that would discover malware that had been inadvertently included in open source software. WhiteSource now plans to add the Diffend tools, now known as WhiteSource Diffend, for free to a portfolio of security tools that many organizations have already incorporated into DevSecOps workflows. Earlier this month, the company raised an additional $75 million in financing that, in part, was used to fund this acquisition.

    As cybercriminals begin to target software supply chains, many of them are taking aim at open source software that is likely to be adopted by a broad spectrum of organizations, noted Sass. The challenge is that bad actors have become adept at embedding malware in software components in ways that are difficult to detect, he said. However, spikes in activity from, for example, a new contributor to the project might warrant additional investigation, Saas added.

    These type of attacks, unfortunately, will require the maintainers of open source software to vet more closely who is allowed to contribute to the project, added SaaS. New contributors that might have once been greeted with open arms need to now be initially met with a modicum of paranoia, Saas said.

    That level of suspicion will be considerably higher if that contributor is located in a country that has a reputation for trying to compromise the security of both adversaries and companies that have intellectual property they might want to surreptitiously acquire.

    In the wake of some recent high-profile breaches involving software supply chain compromises, organizations are revisiting their application development processes. Cybersecurity teams are now asking developers to vet any external code that is incorporated within an application. Most applications regularly incorporate both open source and commercial components that developers assume have been vetted for malware when, in most cases, they have not. The Diffend platform, for example, aided in the detecting of 60 suspicious packages found in Rubygems, an open source platform that makes it easier to package software built using Ruby programming tools.

    It’s unclear how increased inspection of software components may impact application developer productivity. However, given how dependent organizations are on software today, the discovery of malware downstream that compromises the security of the application is potentially catastrophic.

    Sass said it’s doubtful these security concerns will lead to decreased reliance on open source software in general. There is no real alternative for efficiently driving software innovation, he said. The challenge now is finding a way to make sure all that innovation continues to occur as securely as possible.

  • DevSecOps Practices Gap Assessment

    DevSecOps Practices Gap Assessment

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

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

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

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

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

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

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

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

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

    Step 1: Pick a Topic to Analyze

    For our purposes here, the topic is DevSecOps.

    Step 2: Determine Recommended Practices for DevSecOps

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

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

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

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

    Step 4: Determine Who to Include in the Gap Survey

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

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

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

    Step 5: Collect Data Using the Gap Survey

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

    Step 6: Perform a Gap Assessment

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

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

    Step 7: Perform a Gap Analysis

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

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

    What This Means

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

  • Web Isolation and Secure Web Gateways with Menlo Security

    Web Isolation and Secure Web Gateways with Menlo Security

    Since the COVID-19 outbreak, many enterprises have implemented remote work policies to monitor network traffic and protect sensitive data. Organizations have been adjusting and adopting new practices and technologies to improve data security across cloud-based environments.

    In this episode of TechStrong TV, Nick Edwards, vice president of product management at Menlo Security, joins Mitch Ashley to discuss the move from network and application firewalls to creating web isolation, using secure web gateways for updated, contemporary cloud security.

    The video is immediately below, followed by the transcript of the conversation. Enjoy!

    Transcript

    Mitch Ashley: I have the distinct pleasure of being joined by Nick Edwards. Nick is VP of product management at Menlo Security. Welcome, Nick—good to be talking to you.

    Nick Edwards: Hey, Mitch, thank you. Glad to be here.

    Ashley: Excellent. Well, tell us a little bit about yourself, and tell us a little bit about Menlo Security for folks who may not know much about Menlo.

    Edwards: Sure, yeah. So, I am VP of product management at Menlo Security. So, my team is responsible for kind of product direction and definition of our company and where we’re taking our product line. 

    I came from somewhat of a circuitous background. I spent time in the Navy, I was a Submarine Officer, so I kinda feel like I’ve been, you know, in the good guys versus bad guys world for a while. And, you know, cyber security has always been something that’s kind of near and dear to my hart, just because, as a society, I think technology can bring on so many positive changes, but it’s unfortunate that we have to deal with this overall drag of embracing it because people are capitalizing on it.

    Ashley: Mm-hmm.

    Edwards: And Menlo was started with the fundamental notion that how we’ve been going around fighting security is just not keeping pace with kind of where the bad guys are and where the threats are. You know, in the traditional world, it’s around letting traffic in and then inspecting it. You know, you basically put the traffic stream underneath the magnifying glass, you have the Petri dish, “Is this a virus, is this malware, is this phishing?” or whatever it may be. And the industry has gotten a lot better at detection, but the bad guys only have to be right once.

    And so, our fundamental approach is different, which is—you know what? We’re gonna not let anything in, and instead, we’re gonna give you a clean stream that is reconstructed via our technology called isolation. And so, you’ve probably heard this term of web isolation—that’s what the company was founded on, and that’s what we do. And it’s been primarily made more simple to adopt and execute on by the advent of cloud computing and the capabilities that are continuing to expand kind of on that front. So, we’re excited to be here, excited to talk to you more about it, and let me know what you think about, what you wanna talk about.

    Ashley: Cool. Well, you know, as more and more of the network stack has been virtualized and turned into software, it makes sense that you’d see innovations like what Menlo Security is doing, right? Because you can do things very quickly and innovate very quickly in that space. And it’s kind of interesting to me that—you know, we hear about network isolation in WiFi and other technologies, because the pipes are just getting bigger, of course.

    Edwards: Mm-hmm.

    Ashley: And just, that much more of trying to inspect as it’s coming in in real time, it makes sense that—I can see how reconstructing that web stream, as you’re talking about.

    I’d love to get your perspective of what’s the thing that somebody goes, “You know what, we need a secure web gateway instead of what we have”—what is the impetus, or impetuses, if that’s a word, to say, “I need to get to the next thing, because this ain’t workin’ for me”?

    Edwards: So, I think a couple of factors. I think one, and we saw COVID and the work-from-home dynamic of the past year expedite this, is just that when you and I were growing up in the office of 20 or 30 years ago, everyone got in their car, they drove to the parking lot, they walked in, their computer was waiting for them, and everything was in one location. And that made it easy to apply security and controls. 

    I remember my first spam message that I got, you know, in 2001 and I thought that was really weird. And I remember not being able to go to certain websites, and it was very easy to do that because everyone was in one location or, okay, maybe a big multi-national had three different locations, but it was all connected to the same network and it was easy to provide policy, and kind of what proxies merged from that environment.

    Now, you fast forward even to 2019, you know, roughly 20% of the workforce worked remotely. Then, during COVID, it quickly became 75% or greater. And so, with that, it meant that everyone is everywhere. You know, you might be at home, at a coffee shop, in the old days at a WeWork or something. And in that environment, it was very difficult to apply security based off of different devices they were accessing the Internet with, what they were doing, where they were coming from, and COVID just made that worse.

    So, I think what we’re seeing in our customer base, the people we’re talking to is, they realize that they’ve been kind of using Band-Aids to hold the old notion together, but they realize that the cloud offers a new way to think about things. And it isn’t just taking the old widgets and just dumping it in a VM, it’s about—hey, is there a way to fundamentally rethink how we can leverage this technology to advance our business needs?

    And I think all that combination of factors, you know, different users coming from different places, different devices, what they’re trying to do, applying policy based off the context of the user—all those factors have combined to really, I think, kind of introduce this tipping point of new ways of thinking about leveraging technology. I think web gateways delivered via cloud form factor is one of the primary kind of locomotives for people to rethink about their architecture.

    Ashley: It’s interesting you say that. I’ve had several discussions in the last month or so about, as people are thinking about a hybrid office or something about returning to the office, it’s really easy to kinda fall back into, “Well, let’s do what we’ve been doing, right, and make some adjustments.” And I had to go through this transition, actually, a few years before this of thinking about it as just a work anywhere strategy, whether they’re sitting in Starbuck’s or sitting in the United Club, they’re in London or Denver or South Florida—wherever they are, or in an office, or at home, or on the beach or whatever, you just have to think about it.

    And I think that was one of the choke points we ran into with COVID was, the natural tendency was, “Well, okay, swing all the traffic onto the corporate VPN, push it all through our existing pipes” and sometimes, that can fall apart on you, right?

    Edwards: Yeah.

    Ashley: It’s just so much of a big swing. How do people need to rethink this, you know, thinking in a secure gateway, web gateway mode?

    Edwards: Yeah, so, I think that whole trend that we described of, “Put everyone on the VPN” and then—uh oh, VPNs can’t keep up, call up our VPN vendor, give us 50 more boxes. 

    I think what we’re seeing customers re-evaluate is, instead of giving everyone access to everything, let’s flip it on the head and say, “Let’s give them access to only what they need.” And this notion of zero trust is what is kind of capturing this movement, you know? “Okay, we know this is who you are, this is your role. You may be a salesperson—you don’t need to have access to Jira or Jenkins or these development tools, but maybe you need to have access to our CRM system, our customer application for managing pricing and quotes and all this kinda stuff.”

    So, zero trust [Video freezes].

    Ashley: Oh, we lost Nick, there. Let’s see if he comes back—oh, there, you’re back.

    Edwards: Okay.

    Ashley: Okay, so, just, why don’t you re-start with, you were talking about Salesforce and getting access to the applications, you don’t need Jenkins and Jira and stuff. So, you can just pick up on—so, zero trust in a secure gateway, web gateway means this.

    Edwards: Yeah. So, zero trust in a secure gateway mans that, instead of giving users the ability to go wherever they want just because they’ve authenticated, you give them the ability to access the content that they need associated with who they are and their job. You know, a sales rep might need access to certain applications that an engineer might not need access to.

    The VPN model allows anyone who gets connected to have access to whatever, and cyber criminals realize that and they can move around laterally and they can exploit that. And a similar type of construct applies when you’re facing the Internet side of the network. Get people access to what they need and secured gateways via the cloud have much more granular capabilities to do that with tools like CASB, DLP inspection. 

    I think cloud gives the ability to do things at scale that on premise proxies can’t. So, for example, something as seemingly mature and pedestrian as SSL inspection, you know, that’s been around a while, but I remember in the old days, having to scale X number of proxies to be able to address the traffic. Now, almost any website that is being used in a professional manner has SSL and cloud allows you to inspect that very easily and very seamlessly. 

    And on a Menlo perspective, zero trust says, “Hey, look, for Internet related applications, deploy the same type of mentality,” except you flip it on its head and say—don’t trust any of this content from these websites. Okay, maybe you wanna trust O365 for Microsoft, dedicated IP space, domains, you may wanna do that. Or Zoom, for example. But other than that, you might wanna say, “Let’s just allow a clean stream to come in.” And that’s what Menlo does with our isolation by kinda stripping away all the active content, rewriting the web traffic, and giving this native experience to users in a way that doesn’t disrupt their flow or doesn’t require another agent to be deployed on their endpoint.

    Ashley: Plus you have the scalability of the cloud, right? So, you’re not looking to add another box, right, to do this.

    Edwards: Yeah.

    Ashley: It’s, “Okay, great, traffic doubles, we’ve got the resources right there to handle it.”

    Edwards: Yeah. Yeah, that’s right. And, you know, there are some vendors out there, I think, in the cloud web gateway world who have done a lot to mature the industry’s understanding of it. But there’s, again, I mentioned this earlier that properly capitalizing on the benefits of the cloud doesn’t mean taking what you were doing on premise and then just dumping it in a cloud data center. 

    It gives the opportunity to think about things anew and potentially consider new architectures, and leverage the autoscaling of public cloud infrastructure where it makes sense, leverage the near infinite compute and all these things where it makes sense, but still be able to deliver the same type of capabilities. And that was kind of the approach that Menlo took, being kind of more of a cloud native security company delivering these capabilities to our customers.

    Ashley: Mm-hmm. I wonder, too, if—you know, we have different software architectures that can tend to be more porous, you know, with microservices, service mesh, et cetera. We have hybrid, multi-cloud—so, we’ve got a much more, in some ways, complex environment than we had in our on premise data center if that, I don’t know if you wouldn’t say it was complex, it was. But it’s a different world, and the pace at which it can change is so much faster. I mean, you can have an application pop up in a week or a day or an hour that wasn’t there, and now you have to be able to respond to, “Oh, sorry, we didn’t enter a ticket for security to configure us,” right?

    Edwards: Yeah.

    Ashley: You need to be able to react quickly. What do you think are some kinda new applications that are pushing the boundaries of security that make it easier to do it in the cloud?

    Edwards: So, I mean, I think in general, there’s a proliferation of engineering teams inside organizations that are adopting the same type of model of just rapid iteration and agile development for their own products that they’re releasing to their customers. And so, the companies that we’ve seen are some that, they may actually use a combination of AWS or Azure or Google, but they’ll also probably use some of their own data center infrastructure that they’ve already leveraged in a model that is very similar to AWS.

    So, I think this notion of customers going through this migration path, of going from all on prem, maybe with a target of landing with nearly all SaaS, there will be this period of kind of hybrid modes where multi-clouds exist, their own or a public cloud. And I think what we see is customers kind of chipping away at this over time, and an application that was on prem, they say, “Okay, let’s run it in our own kind of cloud data center type of thing” and then slowly migrate that over to AWS or whatever.

    So, we see a lot of this kind of sequenced staging of applications and assets, and with that, it means that the data ends up living in these different places as the application evolves. So, from our perspective, this requires of our customers a rethinking not only of the technology assets, but also the team structure and the profile of the teams. All these teams have to have some level of application understanding, scripting, automation capabilities, whether you’re the application developers or the networking teams, or the SOC teams. 

    And I think the vendors who will end up winning in this world from a security perspective will build security tools that play well in that environment. So, we’re talking about having APIs that will work with their SOC teams, have APIs that will work with, come to their networking teams, so if they need to make network changes quickly, then the cloud applications will be able to respond accordingly.

    And so, in that world, it helps kind of being API friendly and kind of cloud native, because hopefully, that will easily extend to the environments that we’re deploying in from a customer point of view.

    Ashley: There we go. I keep hitting my mute button. You’d think I’d be used to this by now. [Laughter] You mentioned several things I thought were really interesting, and one of them is that, we’re using many, many more SaaS applications, as you referred to, Office 365 as well as SaaS applications, but think how much more Slack and Team and other online non-premise applications that are being used in the cloud. And a lot of times, those things don’t go through IT, and maybe the Finance Department does their own conversion from what they’re using to some cloud financial system or adding other apps to what they’re doing.

    It seems like that ability to be able to isolate some of those environments, make sure that SSL is being used across all of that, and making sure that it’s not a bigger pipe into a bigger world that’s opening up the rest of the network through somebody else’s service is a huge value, and having that visibility is super important.

    Edwards: Yeah, I completely agree. And I think one of the things, when we talk about isolation as a technology construct, not only do we essentially kind of rewrite the web stream that lands on your browser, we also have a similar capability of doing that for documents.

    So, for example, a good application is exactly what you mentioned with SaaS services, and let’s say you’re posting something on Dropbox or maybe you’re accessing something from webmail. Well, what we see customers wanting to do with our CASB solution is say, “Hey, look, we know there’s all these SaaS apps. There’s a world that we know are sanctioned by our company based off policy. So, we’re gonna let people do what they need to do there, maybe insert security for file scanning and all that kinda stuff. But if it’s an unsanctioned application, maybe we want our employees to still be able to go to webmail, but we don’t want them to necessarily download documents and potentially infect our environment.”

    So, what they can use Menlo’s approach for is to basically use isolation of the document. In this case, the document gets kind of rendered as a safe .pdf, so someone can actually still access it. You know, because IT Departments don’t want to be Dr. No and just say you can’t do anything, because in today’s environment, you know, younger employees, Millennials, that doesn’t work for them. But I think people realize that there is a balance between security and still being able to do your job and maintain your own kind of life.

    So, with unsanctioned applications, we’ll give people the ability to actually still go to these applications, but then use isolation to render documents in a secure fashion, or render the content in a secure fashion to give kinda the IT teams maximum flexibility based off policy and the use cases of the users. And I think that’s something that kinda gives the users the ability to strike the right balance based off their employee base and their business needs.

    Ashley: Mm-hmm. I think that’s a really good point. Where do people typically make this transition to a secure web gateway? Is it, “I’m in the process of moving to cloud, I’m setting up my infrastructure, getting ready to move my apps and interconnect with third party apps that I’m using, let me set it up then” or is it oftentimes, “No, I’m in the cloud, I’ve gotta figure out a better way to do security. Let me add a secure web gateway to it”?

    Edwards: Yeah, so, I would say there are kinda two types of customers, as you alluded to. There’s next gen companies who were born in the cloud and they’ve only ever known the cloud, you know? Like, consider any of your contemporary startups that are now successful public companies. They were predominantly born in the cloud, they might have added some on prem stuff for a variety of use cases, but predominantly, they’re cloud first, and they’re a different type of sell and they get it, and they understand it. And, as they have their workforce more broadly deployed, it just makes sense for them to have a way to instrument policy and security across their workforce.

    The customers who are coming from an on-prem environment, maybe traditional large financial institutions, health care, maybe military and defense environments—for them, I think, we’ve seen an acceleration of their adoption over the past several years, and really culminating with COVID as they realized, “Hey, look, this is just very problematic and costly and the TCO associated with maintaining this is problematic.” Main drivers that are the tipping point—remote us, SSL inspection and just having to deploy another box to do CPU intensive scanning. And I think just this overall notion that they realize that the SaaS adoption of all these applications, it’s here to stay, you’re not getting that genie back in the bottle. Oh, and by the way, it is making the company more effective, efficient, and in a more cost friendly manner—so, how can we find a way to embrace that trend and make our business more successful during this march toward digital transformation, but do it in a way that aligns with our own cadence of adoption?

    And I think those trends kinda culminate, and we’ll see a lot of customers start with the kind of CASB use case of securing these applications and doing it in a way that makes sense for their policy, DLP, and security related reasons, and that’s one of the main drivers we’ll see for a lot of our customer engagements when they’re coming from on prem.

    Ashley: Interesting, too. I can totally see that evolution that people have to go through.

    Edwards: Yeah.

    Ashley: Are there any operational considerations that folks need to make in thinking about security differently? Is it different from an operational world making it easier, less false alarms, those kinda things? Because we’re adding more stuff, right? I had a CISO tell me once, “Every product, I evaluate whether it adds any work. If it adds any extra work, I don’t look at it, because I just, we don’t have resources to do it. I can’t add more stuff to my team.”

    Edwards: Yeah, yeah. I think that’s a very valid concern from buyers, and we hear that a lot. They don’t want more loads for the SOC team, they pretty much don’t want another pane of glass to manage, configure and look at reporting.

    So, I think that all of these products need to think about it through the lens of, you know, not only who’s gonna be typing away setting policy, but also, the CIO, CISO, the people who are gonna be consuming the reporting and where they can get access to the information they need to evaluate their purchase decisions and that sort of thing.

    So, I think, on that level, having an API friendly platform that can integrate seamlessly with security orchestration tools, that might be a place in the Security Operations Center that can integrate with other networking devices. All that stuff helps alleviate that friction and that pain. And I think, you know, one of the things that we’ve seen for customers who deploy Menlo is that, with isolation, we actually reduce the number of spurious alerts. Because, you know, you’re not getting all this gray area vendors who rely on detection saying, “Hey, we don’t know enough to say this is bad, but we don’t know enough to say it’s good, so we’re gonna just flag this as an orange” or, you know, whatever. [Cross talk] But hey, you’ll have a human being who can look at it and they’ll decide.

    All that stuff goes away with Menlo, you know? So, what we’re able to do is just deliver this clean stream and we’ve seen multiple customers who, you know, their alerts dropped 80, 90% because of the fact that the data that they’re seeing of their users is no longer being triggered by their endpoint detection tools, these other tools that were kinda living in this gray area. And that means a lot to our customers and kinda their SOC teams.

    Ashley: Cool. What does it take to set up something like this? What’s the implementation process?

    Edwards: Yeah, so, there are a couple different ways. It depends on where the customers are coming from. I mean, I think the most fundamental, simple approach since it is SaaS is that they don’t need to deploy any hardware. There’s the PAC file that lives on all their endpoints, which basically will point traffic from their computers, laptops, et cetera to our cloud form factor, and that’s easily disseminated. Or in some cases, they might want to route traffic from their firewalls or other upstream network devices to us.

    All those things typically take less than one business day, you know, to get up and running. And we’ve had customers, one of our biggest accounts is the Defense Information Security Agency, and they’ve entered into a long-term business relationship with Menlo, and they have all these different teams who are deploying our technology. You know, different military groups, different defense agencies. And it’s basically, “Hey, Menlo, we need to get up and running on this particular agency” and it usually can happen within a matter of several days at a maximum. We’ve had customers scale to tens of thousands of users in a matter of hours. 

    And that’s, again, leveraging the benefits of cloud computing. You know, in the old days, it would be, “Okay, let’s have a pilot for a couple users, and let’s get one or two boxes—okay, great. Let’s do the math. Okay, we have 10,000 users, we need 5 more boxes.” And then if they need to scale quickly, then they’ve gotta make a phone call, I’ll have the box get shipped and all that kinda stuff—cloud takes all that headache, all that thrash away, and you can just leverage the autoscaling that’s inherent in cloud computing. And I think that’s something that really will help expedite the adoption of this as customers become more and more comfortable with security and the compliance associated with it.

    Ashley: I’m glad to hear that. You gave me a few flashbacks to the, “Where is it? It’s in shipping? Okay. Who’s gonna rack and stack it? Okay. Who’s configuring it? Okay. Who’s putting testing and putting in for”—you know? Whoa.

    Edwards: Yeah, yeah, the weekend change requests, you know, [Cross talk] by the IT guy coming in on Saturday night, you know? All that stuff, a lot of that pain has gone away by the new form factors.

    Ashley: Mm-hmm. Cool. How do folks get ahold of this, get access, try it out? Where do they go?

    Edwards: Yeah so, come to MenloSecurity.com, we have a Contact Us, you can try now. We have ways where you can kind of go down the self-service path to play around with it and see that, you know, try menlo.com. Or just feel free to shoot me an e-mail directly, you know, Nick.Edwards@menlosecurity, happy to help point you in the right direction and to cut through all the red tape. You know, we have customers who call up on a Monday with a security issue, we can be out and deployed within that week to get them the security they need, and we’re happy to help customers meet them where they are.

    Ashley: Excellent. Cool. Well, it was really fun talking to you, Nick. Thanks for joining me today and haring more about secure web gateway technology and services that you guys offer from Menlo Security.

    Edwards: Alright. Thanks a lot, Mitch. I appreciate you having me. I appreciate it. See ya.

    Ashley:  You bet. Look forward to talking with you again. Join me in thanking Nick Edwards for joining us today, VP of product management with Menlo Security.

    Edwards: Thanks.

  • Seeing the Bigger Picture With BizDevSecOps

    Seeing the Bigger Picture With BizDevSecOps

    Not long ago, if you can believe it, software was shipped on physical floppy disks and CDs. These physical relics contained dense paper instruction books that humans read diligently for hours on end (I guess they had more time to spare back then?). Complexity was a given for computer-based tasks.

    Fast forward past the consumerization of IT to 2021, and you’ll find extremely high standards for technology. End users now expect intuitive apps with instant end value and 100% uptime. If they don’t receive gratification within minutes, they’re likely to trash it.

    In the race to meet digital innovation demands, software companies are increasingly tapping new strategies to deliver iteratively. Thus, disciplines like DevOps, DevSecOps, low-code and SRE have flourished. But are we adequately considering the end value of that work? Some feel business leadership needs a larger seat at the table and more input: enter the newest iteration of these disciplines, BizDevSecOps.

    I recently met with Gregg Ostrowski, CTO at AppDynamics, to discuss how to introduce BizDevSecOps in an organization. For Ostrowski, it boils down to having full-stack observability to connect application performance, security threats and revenue generation. Only by democratizing access to important metrics and identifying runtime weaknesses can business outcomes truly drive production.

    Full-Stack Observability

    Within our new pandemic-first reality, all organizations are amplifying their use of digital services to interact with customers. However, software teams are struggling to keep pace in this new environment — 89% of technologists report feeling under tremendous pressure at work, the Agents of Transformation 2021 report found. This strain has only increased as IT complexity soars amid the pandemic — 83% felt their job became more complex over the past year.

    IT staff is under mounting pressure to perform, and they may not have the correct elements in place to support elegant and profitable applications, said Ostrowski. When it comes to monitoring, in particular, alert fatigue could especially hamper innovation attempts and make it difficult to know what to prioritize.

    Instead, Ostrowski advocates for letting tangible business outcomes, such as conversion rates and performance, drive development. To correlate the impact on revenue more directly, he encourages “giving business leaders a seat at table during the entire CI/CD pipeline.” One aspect to roping in business, security, development and operations is unified observability across the entire stack.

    The Pendulum Swings

    But wouldn’t it be challenging to give business leaders a seat within a technical software delivery process? Well, this wouldn’t be the first time business has directed technological change.

    Ostrowski recalls the mid–2000s and the dawn of the mobile market. During this period, IT became consumerized for laypeople, with glossy apps and impressively intuitive experiences. He recalls a general loss of faith in IT staff, as workers often had “better tech at home than they did in the office.” This drove business leaders to invest heavily in modernizing their companies.

    In the following years, cloud solutions quickly re-empowered IT with new computing models, emboldening them to compete using the same tools as tech companies. However, simple deployments using a single server quickly morphed into arranging multiple workloads on various cloud service providers (CSPs). Virtualization, serverless and microservices architectures also brought novel complexities into the stack.

    “The IT staff is being asked to do jobs they’ve never done before,” Ostrowski said. He explained that SREs, for example, must understand networking, infrastructure and security — a vast portfolio for a single person and role. Supporting many disparate paradigms is simply beyond the scope and scale of what a single person can do, meaning new automation must be constructed — because “if you’re too busy debugging, you can’t innovate,” says Ostrowski.

    Amid mounting complexity and the burden of rising cloud costs, it appears business leaders again have a role in directing and prioritizing technological efforts.

    Getting Busy With BizDevSecOps

    According to Ostrowski, connecting IT and business with BizDevSecOps all hinges on collaboration. “If you don’t get to a point where you can collaborate with all these pillars, you’ll degrade your business,” said Ostrowski.

    BizDevSecOps also could help connect the dots to comprehend anomalies. For example, suppose a commerce application is experiencing a 15% conversion rate, but it drops to 7% after an upgrade. In this scenario, collaboration is crucial to identify usability bottlenecks in production and adjust accordingly.

    Tracking business outcomes can align development around improving the user experience. If broken features are hurting conversion rates, all stakeholders need to know to adjust accordingly. “User experience is the golden gem,” said Ostrowski.

    Other benefits of a BizDevSecOps approach may include:

    • Correlating activity and revenue: Ensuring spikes of activity are associated with revenue generation and not attacks or faulty instances.
    • Workload optimization: Monitoring business outcomes can help adjust the scope and size of machines as needed.
    • Before and after: Comparing financial results before and after migrations, new versions or new feature additions.
    • Postmortems: Pinpoint and correlate data when conducting postmortems.
    • Progressive delivery: A more rapid release frequency helps a business retain agility and pivot when needed.

    Visibility Enables BizDevSecOps

    DevSecOps is now a common philosophy — it promotes development with security baked into the application. Now, BizDevSecOps could be the next iteration; a collaborative approach that considers additional perspectives. BizDevSecOps is a vital method to “continue to build trust and collaboration so everyone has a seat at the table,” said Ostrowski.

    Ninety-six percent of technologists agreed that monitoring the entire IT stack to connect technical performance to business outcomes will be important in 2021, the Agents of Transformation Report found. To enable this, business, security and development must inevitably de-silo. According to Ostrowski, adopting BizDevSecOps depends on a window into performance management and business intelligence, because “when changes happen and no one knows about it, it’s a serious problem,” he added.

  • 1Password Extends Encryption to Automate Secrets Management

    1Password Extends Encryption to Automate Secrets Management

    1Password this week added a Secrets Automation platform to its offerings that enables IT organizations to more easily encrypt, manage and orchestrate credentials, application programming interface (API) tokens, keys and certificates.

    In addition, the company revealed it has acquired SecretHub, a provider of a separate secrets management tool. Terms of the acquisition were not disclosed.

    Carson Brown, senior product manager for 1Password, said the SecretHub team will now focus on the development of the 1Password Secrets Automation platform based on encryption technology previously created by 1Password.

    Finally, 1Password this week also announced an alliance with GitHub under which it will, at some future date, enable DevOps teams to employ SecretsHub to encrypt secrets used to access the source code repository. 1Password already provides integrations with HashiCorp Vault, Terraform, Kubernetes and Ansible, in addition to client libraries written in Go, Node and Python.

    The 1Password platform for managing and securing passwords is already in use by more than 80,000 businesses worldwide. The Secrets Automation platform now extends the reach of the company’s core encryption technology into the realm of DevSecOps best practices, said Brown.

    It’s still early in the cycle of DevSecOps best practices adoption, but it’s clear an initial focus will be secrets management. In the wake of recent high-profile breaches involving software supply chains, there’s now increased scrutiny of secrets management. Cybercriminals have become more adept at scanning for secrets left exposed as plain text. The challenge organizations face is that developers, while building applications, tend to copy secrets for the sake of convenience, which they often forget to delete after an application is deployed in a production environment.

    In response, many IT teams vacillate between overly restrictive and overly permissive access controls that are rarely implemented consistently.

    Of course, it’s now also only a matter of time before auditors start citing all those unencrypted secrets as compliance violations, Brown noted. A set of DevSecOps best practices based on automatic encryption of secrets eliminates those compliance concerns in a way that is transparent to application developers, noted Brown.

    It’s not immediately clear whether it will be DevOps teams that lead the charge to automate the encryption of secrets, or whether cybersecurity teams will take the lead. Regardless of which team assumes responsibility, the number of secrets that need to be tracked keeps expanding as the number of platforms employed increases. Manually keeping track of all those secrets is no longer feasible. Centralizing secrets management is the first step toward regaining control over an IT environment, said Brown.

    Secrets management may not always be the first thing that comes to mind when organizations begin their DevSecOps journey. As it turns out, however, securing secrets may very well turn out to be the first order of business as senior business and IT leaders review their entire software supply chain. After all, once it becomes apparent just how dependent organizations are on software, they quickly realize how much of their intellectual property is one compromised credential away from being stolen.

  • Is Open Source More Secure Than Closed Source?

    Is Open Source More Secure Than Closed Source?

    There’s no getting around the fact that security is one of the most essential factors in day-to-day operations for most software developers. From proprietary code to sensitive customer data and everything in between, there are hundreds – if not thousands – of crisis scenarios that can result from gaps in security.

    Data security is an issue that every company faces, no matter how large or small. Developers look for security solutions that follow today’s data and application security best practices in order to reduce risk and provide the most secure experience possible to the end user.

    A common debate among both users and developers is whether open source software is more or less secure than closed source alternatives. While there are a variety of different schools of thought as to what makes for a truly secure environment, there is good reason to believe that open source software is the superior option for those looking to prioritize security.

    While open source code may not be inherently more secure than its closed source brethren, here are a few reasons why it almost certainly can be — so long as you take the right approach.

    Open Source Offers True Transparency

    Both well-established tech giants and up-and-coming startups work with some of the brightest minds in the development community to bring valuable proprietary software products and services to market. At the end of the day, however, users have no choice but to trust what a vendor says about how a particular piece of software actually “works.” Since you can’t see the code itself, there’s no way to really verify whether or not what you’re being told – about features, functionality and security – is accurate.

    This can be problematic for a host of reasons—not least of which being the threat of potential security flaws. A company might boast about its commitment to user security and privacy through savvy public relations and product marketing efforts. But, by no means does this provide the user with anything more than lip service if the code doesn’t measure up; even if it’s rock-solid, the question of “How truly secure is this?” can never be answered with confidence.

    Open source software offers greater transparency to the teams that use it; visibility into both the code itself and how it is maintained. Giving organizations access to the source code allows them the opportunity to evaluate the security of the code for themselves. Additionally, users have more visibility into how and what changes are made to the code base, including the pre-release review process, how often dependencies are updated and how developers and organizations respond to security vulnerabilities.  As a result, open source software users have a more complete picture of the overall security of the software they’re using.

    Open Source Encourages Community Input

    Another major benefit is found in the communities which drive the growth and development of open source software. The vast majority of open source software is backed by communities of forward-thinking developers, many of whom use the same software they build and maintain as a primary means of communicating with team members. Open source developers and the communities around the software value users’ input to a significant degree, and many user suggestions end up getting incorporated into new versions. The community involvement and investment ultimately leads to many more responsible vulnerability disclosures than would likely occur if the software was closed source.

    When vulnerability reports do occur, they tend to be more detailed because the code is open source; often, they even come with code suggestions for how to remedy a given issue. This is incredibly helpful and can dramatically speed up patching the vulnerability, as it allows developers to move faster without spinning wheels and getting stuck in the diagnostic process.

    Faster Security Updates

    Within the framework of closed source software, users are at the mercy of the companies behind those products or services when it comes to receiving software updates―open source tends to be a different story. Fully open source projects even allow users and developers to take things into their own hands and contribute feedback and fixes, should they choose to do so.

    More often than not, updates and fixes for high-profile closed source applications involve a great deal of complex planning. If it’s not in the budget, for example, users may not see a new update for weeks, months, or even longer—security flaws or not.

    In most circumstances, open source tends to move faster than closed source when it comes to iterating and releasing new versions. This is true for a handful of reasons, including the fact that open source software tends to have more eyes on the source code at any given time, as well as a community-driven interest in bettering the product whenever possible. If a significant security flaw is uncovered, users may even choose to fix the code themselves, resulting in a level of control that can never be achieved in a closed source environment.

    Open Source Offers Flexibility, Collaboration and Enhanced Security

    An open source methodology, in and of itself, is no guarantee of security, but it does offer teams greater insight and control over the software they rely on. And as open core and source-available software are more broadly adopted, they offer a wealth of opportunities to build incredibly secure environments without sacrificing usability for end users or support from official maintainers.

  • 4 Ways SASE Fuels DevOps Productivity

    4 Ways SASE Fuels DevOps Productivity

    Many enterprises are adopting secure access service edge (SASE) solutions as part of their digital transformation efforts. SASE, in a nutshell, merges together SD-WAN and security stacks to deliver secure networking and improved WAN performance, making it a logical choice for cloud-enabled businesses going through the throes of digital transformation. However, SASE offers other benefits, which may be of particular interest to DevOps teams.

    Let’s take a look at four ways SASE can enhance the productivity of DevOps teams.

    Reducing Collaboration Challenges

    SASE reduces the challenges associated with team collaboration. SASE, by design, integrates WAN optimization with cybersecurity. Today’s DevOps teams need to work together, despite being physically separated, and must have reliable, secure connectivity amongst the team. “DevOps are all about time-to-market, and DevOps teams are looking for ways to shorten their  CI/CD cycles. A critical part of that process is reducing their dependency on the networking and the security teams,” said Boaz Avigad, director of product marketing, CATO Networks. “Since SASE solutions already provide optimized performance and robust security, DevOps [teams] are free from waiting for infrastructure teams to provision the necessary resources. SASE provides DevOps the control and operational cadence they need without compromising performance or security.”

    SASE Improves Networking

    SASE improves overall network performance with integrated load balancing and failover capabilities. DevOps teams cannot afford to lose connectivity, especially when rolling out new iterations of software or resolving bugs. “For DevOps teams, fast and reliable application performance is critical,” said Avigad. “SASE architectures free DevOps [teams] from worrying about the infrastructure by connecting all the company’s edges, data centers, mobile users and cloud resources, with the same self-healing, secure and fully optimized global network. Should a line fail or a route become congested, SASE automatically switches to an alternate path.”

    Better Security Built In

    SASE helps to secure DevOps projects with native cybersecurity capabilities. When properly implemented, SASE integrates numerous security technologies directly into the network stack. “DevOps teams worry about information interception and protecting their applications from threats. All security services share a single, unified context, improving insight and closing the gaps in legacy security architectures; gaps attackers often exploit,” said Avigad. “SASE not only includes NGFW, IPS, SWG, AV and MDR services, it also converges them together into a single-pass architecture.”

    SASE Removes DevSecOps Burdens

    SASE secures internal applications, along with the interactions with those applications, which in turn helps to reduce the burdens on DevSecOps team members. Applications that run over SASE/SD-WANs are further secured by zero-trust network access (ZTNA) and software-defined perimeter (SDP), technologies that help to keep all interactions between an endpoint and an application secure. “Many proprietary applications are too sensitive to run over the public internet. SASE protects those applications by obfuscating traffic, protecting all entry points with a NGFW and restricting access with its zero-trust architecture,” said Avigad. “All internal application traffic is also continuously inspected for threats.”

    Adopting SASE for DevOps teams is beginning to make a lot of sense. The technology addresses many of the pain points that DevOps teams experience as businesses drive toward digital transformation. What’s more, the security benefits offered bring forth additional productivity, while also unifying the security stack.