Tag: zero-trust

  • Establishing Trust in Multi-Cloud Environments

    Establishing Trust in Multi-Cloud Environments

    Modern applications are transforming enterprises into digital innovation factories. However, the distributed nature and complexity of modern apps have made it extremely difficult for organizations to maintain trust and compliance across multi-platform, multi-cloud environments. 

    Although Kubernetes is the standard for application platforms today, each cloud service provider (CSP) has a different offering for infrastructure-as-a-service (IaaS) or their own platform-as-a-service (PaaS) with varying capabilities and APIs. Not only are these APIs incompatible (with the exception of Kubernetes if no vendor extensions are used), each infrastructure and platform are treated and managed in silos. These silos act as an isolated and non-overlapping administrative boundary,  preventing cross-boundary visibility and trust between microservices.  This makes it much harder for enterprises to know and consistently remediate their security posture across clouds and platforms, opening them up to attacks.

    To solve this problem, organizations are extending enterprise security controls to cloud environments. The problem is that application teams and security teams have traditionally had competing goals—agility versus risk and control—and security operations have not evolved at the same pace as application operations. This creates friction between the teams and forces application operation teams to make a choice: 

    1) Slow down application delivery and operations to reduce risk and miss out on the transformative benefits of multi-cloud or 

    2) Continue to develop and ship applications as quickly as possible without considering security and compliance. 

    Neither is a good option. To unlock the power of modern applications running in multi-platform and multi-cloud environments, organizations need to find a way to integrate security seamlessly throughout the software delivery life cycle at the speed users expect.

    Integrating Zero-Trust into the Application Delivery Cycle

    The key to securing applications in a multi-cloud world is zero-trust. Building zero-trust principles directly into modern applications allows organizations to identify threats early, reduce attack surfaces and ship security functions alongside the rest of the application stack—regardless of the underlying application platforms and cloud stacks underneath.

    In this use case, one of the key components of zero-trust is application segmentation; in other words, how to make access decisions between different applications or components of applications. Zero-trust must provide identity-aware, adaptative and on-demand access to any app from any user or app in a way that improves the flexibility and the agility of application access through a scalable model.

    Application segmentation must be provided to application operation teams so that they can embed it into their application quality processes as another gate. Application operation teams can do this by implementing application segmentation policies that identify workloads as they are created through rich, dynamic attributes. The more intrinsic/static attributes (IPs, digital certificates, namespaces, labels, etc.) and extrinsic/dynamic attributes (user behavior, workload behavior, network behavior, etc.) that are identified, the more fine-grained your access decisions can be. 

    Incredibly, application segmentation today continues to be done manually. But with millions of transactions happening across multiple cloud environments, there’s no way a person—or even a team of people—can manually assign policies to each workload. Organizations need a way to deliver zero-trust application segmentation in a scalable, transparent and automatic fashion. 

    A Connectivity and Security Platform 

    The way to do this is through the use of a modern application connectivity and security platform. Through a service mesh, an attribute-based access control (ABAC) model consolidates multiple third-party tools that provide visibility and security across application platforms and multi-cloud environments. This single view operational model gives application teams the ability to seamlessly and simply orchestrate security services across multi-cloud environments, automatically and at scale. 

    Unfortunately, granular policy management through microsegmentation increases complexity, which is the enemy of security. Suddenly, an organization may find itself with thousands of policies that dictate how different workloads access and interact with entities inside the network. These policies need to be continually updated and maintained, creating massive headaches for both application and security teams.

    When a workload is deployed, the associated policies are created along with it and move through the environment with the workload until the workload reaches the end of its life and is decommissioned. As applications run over time, they are being characterized by their unique behavior. This runtime security characterization allows policies to be automatically selected and applied directly to the workload.

     However, for a service mesh to work and enable secure applications in a multi-cloud environment, it needs to follow zero-trust principles without adding complexity and without slowing down the agile delivery cycle. Here’s how you do that:

    1. Baselining trust: A modern app connectivity and security platform should have native observability and self-discovery capabilities, such as being able to automatically discover APIs, catalog APIs and generate API documentation based on the OpenAPI standard. The modern app connectivity and security platform should be able to continuously baseline application behavior and detect anomalous application behaviors. This needs to alert on unknown and zero-day attacks, especially exfiltration of sensitive data.
    2. Establishing trust: It is critical to define the interconnectivity needs of different pieces of the application right off the bat. This explicit declaration of intent is typically done manually by application teams during the deployment of the application as part of a CI/CD pipeline. Another option is to automatically discover the connectivity intent during the testing phase of the application and allowing the service mesh to identify and record the resulting communication flows between microservices’ APIs. These are the basis of the application’s segmentation policies.
    3. Enforcing trust: There also must be a mechanism to automatically apply the appropriate application segmentation policies to enable the necessary communication for the application to run as intended. In the microservices model, different pieces of the application are spun up and down dynamically to enable the application to run as intended. It’s critical that the application segmentation policies that govern accessibility also adapt to these changes. This is done through the service mesh control plane that interacts with the application platform to gather the inventory of workloads.
    4. Dynamically adjust trust: As the applications run over time and clients interact with them, they are being characterized by a behavior. In this case, a security behavior. Observing this behavior can be accomplished through various runtime analysis tools that organizations already have in place that detect process, container, network and user behavior to provide security context. However, to maintain trust, there needs to be a way to integrate these tools through the service mesh to create a single source of truth. 
    5. Extending the trust model to the edge: Applications also interact with software-as-a-service (SaaS) platforms such as Salesforce or SAP, and other apps outside the data center. Ideally, the service mesh/zero-trust application segmentation model can integrate with other security solutions in the cloud such as secure access service edge (SASE), secure web gateway (SWG), cloud access security broker (CASB) and other zero-trust security components. This standardizes the processes for establishing trust across the data center, multiple cloud service providers, SaaS platforms and web apps—ensuring consistent security and compliance posture across the entire organization.

    Modern applications are transforming how business works by enabling agility and real-time decision making, but they will never reach their full potential unless application teams work with security teams to protect users, data and applications in multi-cloud environments. It’s clear that organizations need an evolved security model that application teams can use to seamlessly establish trust and orchestrate application segmentation across multi-cloud, multi-platform environments. Service meshes can provide the visibility and control needed to establish and continually evaluate trust.

  • 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.

  • How Service Mesh Enables a Zero-Trust Network

    How Service Mesh Enables a Zero-Trust Network

    How can we achieve high-grade security within a microservices ecosystem? Service mesh may be the answer

    Enterprise applications often assign an identity to humans to determine security clearances. Using standards such as OpenID Connect and SAML, we can delegate authorization scopes across a suite of applications to determine precisely what a user is permitted to do. But what about the applications themselves? Some believe that microservices should follow this identity-first approach, too.

    For large-scale application ecosystems, microservices is arguably more secure than a monolith. As Marco Palladino, CTO of Kong, described, “A monolithic application is a security incident waiting to happen.” Yet, microservices shouldn’t necessarily trust one another. So, how can we achieve high-grade security within a microservices ecosystem?

    The answer may lie in service mesh. I recently met with Palladino to discover how a service mesh can achieve bank-grade security for established and emerging microservices patterns. Similar to how enterprises assign an identity to end users, a zero-trust security network gives an identity to microservices themselves.

    A Zero Trust Network Trusts Nothing

    With more personal data used in cloud operations, more and more personally identifiable information (PII) is vulnerable to attack, and the costs are high. In Q1 2019, the cost of breaches in the financial sector was $6.2 billion. In 2018, 97% of breaches exposed PII, a top target for cybercriminals.

    Organizations are thus feeling pressure to secure their assets. The most precious data is held within financial services and health care, where GDPR and HIPPA enforce strict accordance with data privacy. This pressure is leading U.S. banks to clamp down third-party application access. Simultaneously, European banks face similar security dilemmas while appeasing PSD2 regulation for open banking.

    To safeguard user data, organizations are adopting a zero-trust security model. “Zero trust security means that we’re not trusting anybody,” said Palladino. “We don’t trust our own services. We don’t trust our own team members.”

    Placing too much trust in users, services and teams could cause a catastrophic failure. And, “there is no bigger risk than thinking you are secure, while in reality, you are not,” he said.

    Monolith ⮕ Microservices

    In practice, architecting a zero-trust application network runs parallel with the trend toward microservices designs. Though it may seem counterintuitive, a microservices system is arguably more secure than a monolithic architecture.

    In a monolithic application, every resource—whether invoices, billing orders or transaction history—is always just one line of code away. Since everything is connected, you could expose a resource with a single access.

    A microservices architecture decouples applications into separate services, each responsible for specific resources that make up the smaller applications, which can be secured and provisioned over a network.

    Segmenting the service landscape avoids one cascading defect affecting all applications. It also enables more control. “By decoupling from monolith to microservices, we can apply fine-grained security permissions and rules to determine what’s possible in the context of the application,” Palladino said.

    Microservices ⮕ Service Mesh

    Implementing these permissions is where a service mesh comes in. The application teams often build security, yet it’s generally bad practice to build your own cybersecurity. Security for microservices requires high expertise, and standardizing connectivity between various microservices can easily result in fragmented security implementations.

    Instead of building your own security infrastructure, Palladino recommended utilizing service mesh. By using service mesh as a control plane for microservices, platform architects can specify specific rules and attributes to generate an identity on a per-service basis.

    Service mesh also removes the burden of networking from developers, enabling them to focus more on their core logic. “Application teams become consumers of connectivity, as opposed to the makers to this connectivity,” Palladino noted.

    Identity for Services

    In the same way enterprises create identity profiles for humans, Palladino said we must extend the same model to services, pairing each service with authorization scopes. “Services must provide their own identity,” he noted. “Based on that, they can do certain operations in their infrastructure.”

    When we think of identity for services, attributes such as geographic location and certificates come to mind. These and other traits could make up a microservice’s authorization scopes. Utilizing a service mesh, architects could assign such attributes to each workload and service to determine what operations are allowed or what requests can be made to what other services.

    For example, services from one region could be designed not to consume services from another region. Such attribute-based control for microservices is a novel, well-needed strategy, Palladino said. “It was crazy this was not in place before; not having zero trust is like having all your money in an open vault.”

    Best Practices for Service Identity

    Knowing that we want to implement identity-based security for microservices, where are some best practices? Palladino recommended:

    • Automate some attributes: A service mesh could automatically assign identity attributes upon creation, such as cloud zone or geographic boundaries.
    • Provide a way to manage attributes: A dashboard would be necessary for DevOps engineers to create, edit or delete service-level attributes.
    • Governance: Architects must manage the control plane and create identities for the right parties to access this capability.
    • Secure encryption and Mutual TLS: Teams will require a system for rotating and expiring certificates for hundreds of thousands of workloads running across an organization, noted Palladino.
    • Standardize: Secure Production Identity Framework For Everyone (SPIFFE), a CNCF incubating project, is a good framework for service identity, making it operable with other cloud-native projects.
    • Play nice with CI/CD: Attribute creation could be hooked into an underlying CI/CD process to occur when deploying products automatically.

    Once microservices have identities, the services they interact with can determine what actions they are authorized to perform. This limits machine-to-machine communication to allowed operations.

    Zero-Trust Security With One Click

    Many teams have transitioned to a microservices architecture to deploy more often, be more distributed, decoupled or improve overall reliability. While these innovations are largely positive, Palladino cautioned against innovation without the proper security forethought: “It’s silly to transition to a microservices strategy without thinking about how these services are secured,” he said.

    Teams will also be running microservices on various environments—VMs, cloud or physical data centers. Thus, considering microservice-to-microservice communication, how do we route traffic between such environments? How do we observe metrics and logs? Palladino believes an agnostic service mesh that supports multi-region, multi-zone, multi-cloud and hybrid modes is the answer to these dilemmas.

    If used correctly, service mesh can plug security gaps for internal service-to-service communication, thus obfuscating high-value resources, such as financial services data, from nefarious players. The key to solving the service identity challenge is a usable dashboard. As Palladino described, “Zero trust security with one click.”

  • Your Applications Are the Weakest Security Link

    Your Applications Are the Weakest Security Link

    Amazon, Microsoft and Google have much bigger security budgets than you do. They have hundreds of people all over the world ensuring that their infrastructure is secure. Their teams are constantly reviewing their code, looking for flaws, vulnerabilities and potential exploits. They monitor hacking forums and run attractive bug-bounty programs in order to remain proactive.

    Only a few years ago, kernel errors were prevalent. Now, Microsoft’s and Linux’ teams have nearly eliminated kernel vulnerabilities. For example, according to the CVE database, in 2017 Linux kernel had 169 code execution vulnerabilities, in 2018 only three and in 2019 just five.

    When it comes to the cloud platforms, the cloud providers indeed take responsibility for security of the cloud, while the customers remain responsible for security in the cloud–which is where the danger lasts.

    Solution architectures are distributed across public cloud and legacy on-prem environments. They contain the customer’s own software as well as open source and third-party products, over which the customer has no control. Proliferation of microservices significantly increases the amount of network interfaces. Growing release velocity leaves no time to identify and address potential security problems and configuration oversights.

    While the operating systems and critical infrastructure software are improving, the number of vulnerabilities in application software are growing quite significantly. The ability to alter existing applications or inject additional code allows attackers to turn legitimate software into malicious ones. This kind of vulnerabilities is listed in the “code execution” category, which happens to be the biggest group in the CVE database.

    Patching known vulnerabilities takes more than 50 days on average, while attackers need just a few minutes to utilize them. On top of this, there is a huge amount of unknown/unpublished zero-day vulnerabilities, frequently used by commercial attackers who pay for them and keep them to themselves.

    In the well-known Equifax data breach, malicious software infiltrated a legitimate web server using an Apache Struts vulnerability that allowed arbitrary code insertion. Since this attack occurred in 2017, the CVE database shows that Apache Struts has had at least five similar types of vulnerabilities.

    Basically, customer applications are and will always be the weakest and the most exploitable software. How do we protect them?

    Code execution vulnerabilities are exploited while the software is running. Some of the exploits do not leave any file system footprint at all—fileless malware. The exploit may happen days, or even months, into the execution session. The only reliable way to identify a break-in is to verify the software integrity in the same memory where the code is running throughout the entire execution session. Any change to the code or an addition of the unsigned code will compromise its integrity and therefore will be identified.

    Traditional, file-based, signature mechanisms will not help here, because the executable files are changed when they are loaded into the memory; therefore, it must be a special algorithm sufficiently robust to protect itself and the application software.

    Cryptographic signature uniquely identifies software just like human DNA identifies a person. This mechanism can be further used to provide applications with proper authorizations such as communication and information access. This will ensure that only applications with the right “DNA” can communicate with each other and access encrypted information, which is the ultimate Zero-Trust paradigm.

  • How 5G Mobile Networks Will Change IoT Security

    How 5G Mobile Networks Will Change IoT Security

    Depending on your location, you might have noticed a new 5G icon on your cell phone recently. The roll-out of the new 5G mobile network is largely a positive change for consumers and businesses. The fifth generation of cellular networks (hence 5G) purports to be one of the fastest wireless networks ever created.

    This technology claims to provide more efficient interconnectivity, and faster data transfers between people, objects and devices. All good things, right? But what security risks does 5G represent for the modern age?

    Some cybersecurity experts suggest that new vulnerabilities are versions of problems not entirely flushed out from 4G and even 3G networks. This article will attempt to explore some problems and opportunities that IoT security experts need to be aware of, and how savvy enterprises can be proactive about security in the age of 5G.

    Riding the 5G Wave

    A business’s potential is only as great as the technology they elect, as an organization, to adopt and use. One of the first benefits that 5G provides comes from the additional speed that the network provides. 4G posted average download speeds around 20Mbps. With a fully deployed and optimized 5G network, users should expect those download speeds to reach anywhere from 500 to 1,500Mbps. 

    Raw speed is one thing, being able to harness this type of efficiency is another. A Barclays’ poll recently reported that only around 28% of businesses understand 5G or the practical business applications the network offers. 

    Along with the challenges of leveraging the increased speed of the 5G network for business purposes, another important aspect of 5G education involves the security risks associated with faster technology. We suspect that if only 28% of businesses understand the practical applications of a 5G network, the awareness of potential security risks may be a similarly low figure.

    Getting Up to Speed on G Security

    While 5G touts a tighter grip on security, experts in the space will remind us that some of the concerning holes in the security of 4G, and even 3G, networks have been carried over into the rollout of 5G. Give credit where it’s due, the 5G security wins are associated with the encryption process which improves anti-tracking and spoofing features. This means that would-be criminals have a much harder time tracking and manipulating device connections.

    5G is also more software and cloud-focused than previous versions, which allows for better monitoring so threats can be spotted and mitigated more quickly. 

    While this is good for consumers, it’s not a perfect system by any means. “Stingray” devices can still be used to deploy fake base station attacks, which allow attackers to intercept mobile traffic and potentially manipulate data.

    Downgrade Attacks

    Purdue University and the University of Iowa outlined findings from design issues in the 5G protocol that exposed 11 vulnerabilities that may be exploited by bad actors. Five of these discovered vulnerabilities were carried over from 3G and 4G networks. Notably, a “downgrade attack” which essentially reverts the devices to use old mobile data networks. On top of potentially leading to higher wireless bills, this may allow attackers to track calls, texts or browsing habits on devices.

    If a device is forced to operate in a limited-service mode, an article in WIRED explains how IMSI numbers may also become exposed because of a downgrade attack.

    “One purported benefit of 5G is that it protects phone identifiers, like your device’s ‘international mobile subscriber identity,’ to help prevent tracking or targeted attacks,” stated WIRED. “But downgrade attacks like the ones the researchers found can bump your device down to 4G or put it into limited service mode, then force it to send its IMSI number unencrypted. Increasingly, networks use an alternative ID called a Temporary Mobile Subscriber Identity that refreshes periodically to stymie tracking.”

    Tips to Avoid Security Pitfalls in the Age of 5G

    In the age of the fastest speeds ever seen and nearly ubiquitous connectivity because of the rapid adoption of IoT devices, it’s becoming apparent that a zero trust model could help address security concerns with 5G and beyond. 

    This may require additional education to be available for employees, but an increase in security best practices for endpoint users is something that will benefit an organization tremendously. Zero-trust security models continually check the user’s presence and behavior within a network regardless of whether the user is human or machine. 

    It might seem like a great idea, but adopting the model isn’t a change to be taken lightly. A survey conducted by AT&T about 5G security indicated that just 33% of respondents reported they are currently using multi-factor authentication—the road to zero trust will take buy-in from executives and managers. 

    Sharing the Burden of Security

    The 5G rollout does provide built-in security features, but it should not be viewed as the Holy Grail. An organization will benefit from having a comprehensive security model, but that doesn’t mean they need to single-handedly oversee every aspect of that model. 

    5G is a combined effort that involves network operators and enterprises, and shared responsibility is essential for long-term success. Managed service providers should be considered by companies that may be short-staffed, or don’t have the in-house resources to cover other important areas of security, such as ransomware protection.

    Security within a business can’t exist in a silo, it’s a team sport—make sure you’re on the winning side.

    — Marty Puranik

  • Multi-Cloud Adoption: Time to Rethink Your Identity and Access Management

    Multi-Cloud Adoption: Time to Rethink Your Identity and Access Management

    This may well be the decade that the data center’s reign falls, and multi-clouds prevail. A multi-cloud strategy, which incorporates cloud services from multiple vendors, promises plenty of benefits, including improved resilience and flexibility that makes it easier for enterprises to meet various application and data needs. But, there will also be operational challenges. Expect security, specifically identity and access management (IAM), to be one of them. 

    Gartner states that “by 2025, 80% of enterprises will have shut down their traditional data center, versus 10% today.” Except for a few mission-critical processes that will remain on-premises because they require intense oversight and control, much of an enterprise’s workloads and data will be spread across a multi-cloud environment, with users accessing applications from a range of devices from multiple locations–making it more difficult to secure, control, track and manage access to applications and services. Without a comprehensive IAM plan, an organization could be more vulnerable to attacks and data breaches.

    Instituting the right IAM strategy now, in concert with an evolving multi-cloud architecture, will help protect threats and ensure that the right users have access to the right information when they need it. To get started, we recommend following these key recommendations. 

    Get Your ID Store in Order

    IAM solutions are designed to make sure only people appropriately identified and cleared can access an enterprise’s systems and services. In today’s increasingly complex IT environment, an IAM solution must include an ID store that supports both on-premise systems and cloud services. Unfortunately, too many companies still rely on Microsoft Active Directory as the single source of truth for the IT services they provide. This needs to change.

    As companies begin to adopt multi-cloud architectures, they’ll soon discover that Active Directories are not flexible enough to support IAM, nor can they keep up with the growing number of potential threats. Integrating an identity software product that can manage users’ digital identities, credentials and groupings with Active Directory may work as temporary solution, but as user passwords and access rights are dispersed across on-premise and cloud-based systems, things can get complicated quickly, taxing even the well-resourced IT team.

    If you haven’t already done so, it may be time to extend Active Directory (AD) to Azure Active Directory (Azure AD), Microsoft’s multi-tenant cloud-based directory and identity management service that enables Single Sign-On (SSO) access to on-premise and cloud applications, putting users through an authentication process to prove they are who they say they are. It uses multi-factor authentication, a two-step identity verification system that requires two or more of the following methods: something you know (password), something you have (trusted device) or something you are (biometric screening).

    Embrace Zero Trust

    The premise of zero trust has been around for several years. According to CSO, the first model was defined by John Kindervag (then principal analyst at Forrester Research Inc.) in 2010. The idea is that when it comes to securing enterprise systems and data, no user–internal or external–can be trusted. Security threats are much more sophisticated today and are impacting organizations at greater rates than ever before.

    Malware such as phishing, email phishing and drive-by downloads–which can occur when visiting a website, viewing an e-mail message or by clicking on a deceptive pop-up window–put an organization’s identity and authentication at increased risk. Once an attacker gets a working identity and authentication method, he or she can do almost anything, including system damage, data leaks and destruction, and more. A zero trust network that rethinks approaches to resource access is quickly becoming a necessity.

    Part of the move to zero trust should include a decision to move away from passwords, which are still widely used. Passwords are typically too weak or often re-used, making them vulnerable and difficult to manage. As such, they don’t deliver robust enough security for sensitive systems and confidential information. A passwordless approach eliminates this problem by removing the need for users to remember passwords and for organizations to store them. There are several ways to go passwordless, including adopting biometric authentication such as touch ID and face recognition, and token-based methods such as mobile app authenticators or secured USB keys.

    Control Your Multi-Cloud Strategy

    Of course, distributing an enterprise’s workloads and data across larger numbers of clouds operated by different providers and located in various geographic regions can increase the complexity of IAM. IT staff will have to learn how to manage, provision, control, track and synchronize the systems in each environment, and such a highly distributed operation can easily become an operational challenge. Things can get even more messy, and risky, if an enterprise’s multi-cloud adoption develops in an ad-hoc manner.

    Multi-cloud best practices include working with existing cloud partners, adopting orchestration tools, controlling the risks of shadow IT and keeping the number of cloud environments to a minimum by adding only those clouds that support and elevate an enterprise’s business goals.

    With multi-cloud adoption on the rise, IAM is becoming increasingly important in order to protect against insider and outsider cyber threats and to ensure that the only the appropriate users can access the resources they need, when they need them. 2020 is the year to get identity and authentication right. It’s time to develop a comprehensive IAM strategy that includes an advanced ID store, zero trust and controlled multi-cloud adoption.

    — Richard Diver

  • Predictions 2020: 7 DevOps Predictions Shaping 2020

    Predictions 2020: 7 DevOps Predictions Shaping 2020

    2019 was an exciting year for DevOps practitioners, with DevOps adoption continuing to grow at a fast pace. Most organizations were either executing or evaluating their DevOps strategies. So, what is 2020 going to bring in DevOps, infrastructure and application automation? Here are seven DevOps predictions for emerging trends in the new year.

    Customer Experience

    CX will become the guiding light of the DevOps journey, and not necessarily just technology. This is a big mindset shift from the early days of pure-technologist enthusiasm. As DevOps matures, we have to remind ourselves that it’s all about making business faster, not just the cool tech.

    Take advantage now:

    • Tie DevOps achievements to business needs and results to get executive buy-in and budgets.
    • Successful QA teams will start looking at their role as guardians of customer experience and not just testers.

    Trust

    Everyone will be talking about trust—not only in the context of zero trust networks but also in the context of making it possible for Dev and Ops to trust one another as the foundation for DevOps.

    Take advantage now:

    • Proactively invest in creating a culture of trust. Identify causes for lack of trust in your value stream and make trust a 2020 goal.
    • Encourage product-level conversation and define methodology and ownership when it comes to value stream management, application and infrastructure automation. It is the foundation that everyone is working on.
    • Invest in staging environments—Staging environments are needed to ensure things work before you put them in production. For many of us, jumping directly to automatically deploying to production is a big step. The risk can be mitigated by investing in staging environment automation, which will be the first step toward deployment to production.

    Value Stream

    The DevOps toolchain is going away. In 2020 we will think value stream. The industry is maturing beyond the notion of chaining together dozens of open source tools and trying to make it work together. In previous years many felt comfortable saying that if they have a CI system in place it means they “do DevOps.” This is no longer the case. DevOps is not just CI, and DevOps cannot be established in silos. Mature DevOps needs to take into consideration the entire value stream—from planning a new capability and the business requirement, all the way to the customer getting more value and a wonderful experience.

    In 2019, Gartner announced it’s the last year of the ARO MQ, as it’s not the right perspective. In 2020 we finally gain a system-level view on the value stream. More players are announcing end-to-end value stream management including Atlassian’s new Forge platform, GitLab and CloudBees. Companies are maturing and adopting system-level solutions. 

    Take advantage now: 

    • Plan for platform operations. System-level value stream perspective requires roles that take ownership of orchestration and automation throughout the value stream and not just in silos.

    The SRE Role Will Continue to Mature

    The SRE role that started with Google bringing software development practices into Operations will continue to evolve. Increasing volume, velocity and variety of data will make AIOps solutions thrive. Also, increasing levels of automation will require smart ways to handle dynamic infrastructure and applications without losing control, and being able to track changes all the way back to the coder. 

    Take advantage now:

    • If you haven’t implemented the SRE role yet, consider how SREs can be part of your teams in 2020. Define SRE areas of responsibility and KPIs, and how the SREs communicate with the teams. Is it a centralized position or are the SREs part of the team?
    • Make sure you provide SREs with the tools they need to succeed including:
      • What are the observability solutions you use? Who uses them today? How do you analyze it and how is it communicated?
      • What are the production environment orchestration, deployment and configuration tools that you use today?  How do you connect them to application and infrastructure automation that happens before production?

    Seamless Infrastructure

    We will have to make infrastructure seamless for our teams. Internal customers are also customers, and their experiences will be just as important. Self-service and empowering teams will be the main themes in the bridges that need to be built between Dev and ITOps. Public cloud, Kubernetes and serverless technologies will grow. And while it makes automation more feasible than ever, the emphasis will shift to self-service and to the end users. With more companies adopting similar approaches, the need to develop internal expertise will decrease, and we will see more off-the-shelf solutions.

    Take advantage now:

    • Map how infrastructure is used throughout your value stream, and work on unifying the approach in product-level.
    • Make sure you build self-service solutions with strong focus on the end-user in order to enable and balance both speed and control. Make sure developers and ITOps are equally represented when determining an approach to infrastructure automation.

    Infrastructure Automation

    Infrastructure automation is going to get smarter, with a lot of AI and ML. Making sure automation is properly governed will also increasingly be important. Take into consideration security and compliance, as well as cost.

    Take advantage now:

    • Assess infrastructure automation practices throughout your value stream. Who builds the automation? What teams and systems consume it? How do you enforce security best practices (e.g. no passwords in public repositories, using proper data sets for testing, compliance of automation blueprints)? How do you enforce cost control (e.g. tagging, reviewing cloud spend reports)?
    • Invest in control mechanisms before you lose control, especially in public cloud automation. If you don’t have governance in place, look at baking governance into automation, rather than adopting traditional cloud management approaches. Invest in automatic de-commissioning of infrastructure, automatic tagging, analysis of infrastructure consumption data and connecting it back to the business requirement, secrets and key management and access control.

    SaaS

    Open source is nice. SaaS is great. While big open source projects set the pace (K8S, Github) and are strongly backed up and funded by the industry’s giants, smaller projects are increasingly difficult to scale and glue together, especially when trying to assure enterprise readiness. The need to “do it yourself” is gradually fading, as more vendors offer products and services for supporting DevOps with clear business and support models and, as important, with OOB integrations with the ecosystem. Just Rest API is no longer enough.

    Take advantage now:

    • If your enterprise-readiness requirements make it difficult for you to scale DevOps initiatives, consider evaluating new SaaS offerings that eliminate much of the heavy-lifting and gluing that were typical to the skills-heavy early-days implementations. If you were concerned with security, cost and skill requirement, today you can find tools that are purpose-built to support DevOps for enterprise at scale. The good news is that most of the vendors are well-aware of the criticality of integrating to your ecosystem, making it easier to achieve your end-to-end value stream vision.

    Want to learn more about what to expect in 2020? Join us Jan. 23 for our Predict 2020 Virtual Summit featuring discussions from some of the industry’s best and brightest offering up their visions for the future. Sign up today for this free daylong virtual event.

    — Maya Ber Lerner

  • Portable Security Policies: A DevSecOps Primer

    Portable Security Policies: A DevSecOps Primer

    Protecting critical data and applications is a challenge under any circumstances, but it’s especially daunting when resources reside in the cloud. Most organizations today operate a significant portion of their workloads in the cloud, which adds to the complexity of the security problem—a security team can’t fully control cloud environments but is responsible for securing workloads and applications running there.

    Cybercriminals are exploiting the situation. They’re becoming more aggressive and ingenious in their efforts, taking advantage of the fact that there is confusion about who is responsible for which aspects of security under the Shared Responsibility Model. Adding to the chaos is the differentiation between cloud providers’ security offerings and capabilities. Quite simply, in most cases, cloud providers are responsible for the security of the cloud and consumers are responsible for security in the cloud, meaning that security and networking teams still need to ensure their organizations’ workloads and applications are free from malware or other tampering.

    To accomplish this, security and networking teams can’t rely solely on firewalls, threat detection and vulnerability patching to secure vital digital assets. Security tools developed for traditional data centers are not effective at securing workloads in the cloud due to the cloud’s dynamic nature. Security and networking teams must rethink their approach.

    Unfortunately, many organizations are still relying on old and ineffective strategies—further hardening the perimeter, investing in additional threat detection and adding new tools and controls that focus on identification rather than prevention. This security approach has its place, but it does nothing to prevent malicious actors from moving laterally across the network once they achieve a foothold, which leaves cloud-hosted apps and workloads extremely vulnerable.

    Instead, security teams need to enable zero trust in cloud environments, which treats all internal communications as untrusted by default. With zero trust, only authorized applications and services are allowed to send and receive communications, and only in specific ways governed by the principle of least privilege.

    The Second Layer

    Traditional tools aren’t effective in enabling zero trust in the cloud because security and ops teams have a very limited ability to manage all layers of the cloud’s open systems interconnection (OSI) model. Specifically, the lack of Layer 2 controls in infrastructure-as-a-service (IaaS) environments makes tools developed for discrete networks all but useless for locking down ports and controlling or scrutinizing IP addresses.

    Even if an organization manages to implement these tools in the cloud, it cannot provide the level of granularity required to stop malicious lateral movement. For example, when on-premises tools are repurposed for cloud environments, they usually rely on subnets to define the boundaries of communication. Because cloud subnets are designed to handle elastic workloads, they need to be far larger than those in on-premises environments. As a result, cloud workloads are more exposed than is necessary.

    Securely migrating workloads and applications to a cloud environment is a huge and cumbersome job when relying on traditional tooling. The best way to make workloads portable and secure is to decouple workload protection from the underlying infrastructure. In this way, organizations can be certain that any policies applied on-premises can migrate to the untrusted environment of the cloud, without the complexity of mapping changing network addresses, writing policy exceptions or losing fine-grained control during the process.

    Decoupling workload protection from the network requires abandoning a network address-based approach in favor of one based on identity. By using the immutable properties of workloads, security teams can create cryptographic identities for applications and services, which then can be used to determine what is allowed to send and receive communications. Not only does this model provide stronger security, but it also works regardless of where applications are located, because these identities are unaffected when network elements change. What’s more, they can be constructed to tolerate upgrades. By building identity-based policies, security teams can create microperimeters around applications that follow workloads wherever they go, and the policies verify communication across boundaries every time an application attempts to communicate.

    Implementing network-agnostic policies doesn’t just harden security. Software developers benefit as well. Without the roadblock of translating application-speak to network-speak, developers can build software and applications in any environment favorable to their workflow while defining policies to protect their work. Once the software is built, they can securely deploy the finished product to the production environment—even if it is hosted by a third party.

    No organization should have to compromise security to benefit from the efficiencies offered by the cloud and ephemeral auto-scaling containers. Building identity-based policies that enable zero trust and are independent of the underlying network ensures that companies never have to consider making that trade-off.

    — Tom Hickman

  • Simplify DevSecOps with a Zero Trust Approach

    Simplify DevSecOps with a Zero Trust Approach

    There are major cyberattacks and data breaches weekly, if not daily. Each incident is unique in some way, but one element common to almost all successful attacks is trust. Whether it’s a disgruntled employee conducting an insider attack, an attacker infiltrating the network using stolen credentials or an exploit that leverages a third-party vendor or supplier, what makes the attack possible and allows attackers to fly under the radar is the fact that the credentials and activity appear to be legitimate. A zero trust security approach could solve that.

    In DevOps environments, where new application architectures such as microservices and containers make things much more dynamic and rapidly changing, security can be especially difficult. Automation, virtualization and new tools combine to increase the potential attack surface exponentially. And, granting and removing access for containers or virtual machines that appear and disappear by the hundreds can be a Herculean task—traditional permissions management and access control solutions just can’t keep up.

    “DevOps creates a challenge for many organizations because they need to maintain agility while also recognizing that security is an increasing concern in broadly distributed networks,” said Bill Mann, chief product officer at Centrify. “Prioritizing functional requirements over security while building applications leaves organizations exposed to significant risk.”

    Centrify, however, is up for the challenge of bringing zero trust security to DevOps environments. The company claims to simplify integration of security into DevOps applications development pipelines without restricting development velocity.

    Centrify starts with the premise that users, applications and endpoints are not trustworthy by default. Everything must be verified at every point of access to ensure that security of the development pipeline is not compromised in any way.

    Its DevOps-focused portfolio includes products that help developer, security and operations teams manage access to complex development environments, enhance application security and provide auditable logs of privileged activity. Centrify provides centralized management of user access rights and privileges to Linux and Docker hosts, including hosts running CoreOS Container Linux. I am especially intrigued by its ability to implement multi-factor authentication (MFA) and temporary privilege elevation to gain access to individual containers independent of the container hosts.

    Centrify also announced that it can now be used to authenticate to HashiCorp Vault, one of the most popular tools for securely strong and accessing secrets. Centrify provides centralized access management for the Vault, as well as protects against malware attacks by eliminating the need for locally stored access credentials.

    On the application security side, Centrify focuses on securing privileged service and system accounts and enabling secure communication between applications, containers and microservices. Centrify leverages Kerberos, SAML or OAuth to enable services authenticate to each other.

    The basic premise of Centrify is that “trust but verify” sounds good in theory, but in reality “never trust, always verify” is a much better strategy for security. Rather than hoping you can find the needle in the haystack and identify the one bad actor, it makes more sense to assume the bad guys already exist both inside and outside your network and simply remove trust from the equation.

    The approach certainly seems to have some merit. It’s sort of like applying a whitelist instead of a blacklist to filter email or applications. Rather than assuming everything is good and trying to find the bad ones, just assume everything is bad and only let through the ones you choose. In this case, however, you don’t even have the whitelist. You’re literally verifying the user and device and applying policy to determine the level of access and privilege each time.

    — Tony Bradley

  • Moving Security Beyond SSH and PKI

    Moving Security Beyond SSH and PKI

    SSH (secure shell) is still the most common method of remotely accessing a Linux server, which makes it a common target for attackers attempting to infiltrate corporate networks. While the protocol itself carries a number of advanced security properties, it does allow for human error, opening the door for unwarranted privileged access to sensitive company resources.

    Keeping track of all valid credentials across a company is something that IT departments continually struggle with. The stakes are high if they fall into the wrong hands, essentially handing over the proverbial “keys to the kingdom.” A recent study by Dimensional Research found that 90 percent of respondents do not have a complete and accurate inventory of all SSH keys, and 63 percent don’t actively rotate keys, even when an administrator leaves the company.

    Managing privileged access to servers has always been a rigorous exercise in key management. There are a number of best practices to follow to avoid the many common pitfalls, such as storing private keys in a vault service or maintaining a strict rotation policy, but they don’t get to the crux of the matter: The credentials are static. Here’s a (not so) crazy thought: What if we got rid of them entirely? Static credentials are a thing of the past, representing the failed perimeter model of corporate security.

    Problems with Traditional PKI

    The traditional PKI (public key infrastructure) that backs SSH was built for a different time, when a key exchange meant enough to grant trust. Without a proper authentication process, there is no clear way to attribute to a person, nor a feasible way to provide any historical context. As these keys get issued and distributed across fleets of infrastructure and cloud services, the challenge only compounds. Each public key accrues more privileges over time; the longer it’s been alive, the more likely it’s been shared with a resource, making it extremely difficult to track and subsequently revoke. With this model, time is a bug that can’t be fixed.

    Authorizing a specific request should also go beyond the mere presence of the public key within the authorized_keys file of the server. Independent of authentication, authorization is about who should and should not be able to access a specific server from a known device, and what permissions they have on the machine. You may have a policy that states only members of the engineering team can only access a production server through a bastion host. Adhering to that policy in practice, however, is impossible without a proper authorization process.

    Enter Zero Trust Security

    We’ve come to a consensus across the industry that the network perimeter is breaking down in the modern cloud era. It’s time to take that one step further and agree on a new model of trust attestation to match, where decisions are removed from the network layer and handled correctly at the application layer. Flipping the model around like this means starting with zero privileges by default, and only granting access to a resource once a request has been fully authenticated and authorized. Verify, then trust—the mantra of Zero Trust.

    Google’s BeyondCorp is the marquee example of Zero Trust done right, an internal initiative meant to better secure how employees access corporate resources. The end result is a carefully crafted distributed system that makes real-time trust decisions based on what is known about a user and their device, allowing the thousands of Googlers across the globe to work securely from any location without the use of a VPN. BeyondCorp is just one example, and we’ve seen more and more companies start to adopt a similar approach.

    Ephemeral Client Certificates

    The thinking behind ephemeral credentials is that a request triggers independent authentication and authorization processes, where a trust attestation is made against the policies of the resource. If valid, a single use credential is issued, which is used to initiate a secure session with the resource. This credential is tightly scoped to the specific request, rendered useless in any other scenario.

    The fundamentals of this workflow can be accomplished through a client certificate-backed PKI architecture. Client certificates became a supported feature of OpenSSH in 2011 with the introduction of version 5.4. Unlike standard SSH keys, which carry no metadata, certificates are cryptographically verifiable metadata objects that can inject information such as usernames, roles and more. Time now becomes a feature because the scope of the credential truly represents a dynamic attestation of trust.

    The fine-grained access controls inherent in a client certificate-backed PKI architecture solves for the problems with SSH keys because the credential can be tied to an actual user. The threat vector of lost, stolen or misused credentials is also eliminated, saving managers from the numerous headaches associated with SSH key management.

    To put these ephemeral credentials into action, you need to surround the client-certificate PKI with the supporting access controls. Companies with the means can build their own system similar to Google’s BeyondCorp, but this is no simple task, as you need to operate your own Certificate Authority along with a distributed system capable of performing dynamic authentication and authorization against policies in real time.

    About the Author / Ivan Dwyer

    Ivan Dwyer is the VP of Product Marketing at ScaleFT, working with the community to raise awareness around BeyondCorp and Zero Trust for organizations of all kinds looking to modernize their security architecture. Connect with him on LinkedIn and follow him on Twitter.