The DroidDevCast is a weekly podcast brought to you by the team at Esper, where we explore all things Android, DevOps, and OSS development. In this episode, Esper Platform Evangelist Rin Oliver spoke with Tyler Shields, CMO of JupiterOne, and Esper Director of Cybersecurity Jasmine Henry to learn more about continuous observability, continuous enforcement, and what DevSecOps looks like in today's enterprise.
Rin Oliver (00:09):
Welcome to the DroidDev Cast, a podcast brought to you by the team at Esper, bringing you the latest news, thoughtful discussion, and insights into all things Android, Android security, and open-source software development. I'm your host, Rin Oliver, platform evangelist at Esper. And today I'm joined by Tyler Shields, chief marketing officer at JupiterOne, and Jasmine Henry, director of cyber security at Esper. We're here this week to discuss all things related to continuous observability. More specifically, what does continuous observability mean?
Rin Oliver (00:33):
And why should it matter to all types of organizations that are deploying new products on edge devices. Today we're going to look at what continuous observability means to JupiterOne and Esper, and what it means to digital product creators at any organization. So, with that said, we're going to get started. Tyler and Jasmine, thank you so much for joining me today.
Jasmine Henry (00:50):
Glad to be here.
Tyler Shields (00:51):
Nice to hear from you.
Rin Oliver (00:53):
So, for both of you, Tyler, Jasmine, could you share a brief description of who you are, what you do and the kind of things that you're working on?
Tyler Shields (01:01):
Sure, absolutely. I'll take the first crack at that. Hey everybody, I'm Tyler Shields. I've been in the cybersecurity space for going on about 20 years. I'm currently the CMO at JupiterOne. JupiterOne is a cloud asset management security and governance platform. So, think beyond just your general assets, but more like any software-defined asset, and applying security to that in a continuous observability kind of way.
Jasmine Henry (01:26):
And I am Jasmine Henry. I'm a cyber security director at Esper. We're a Seattle-based startup that does infrastructure for Android single-purpose devices, which includes everything from mobile point-of-sale in kiosks, to smart exercise equipment and healthcare devices. We position ourselves as an Android DevOps tool. My background's in data, actually. I started off as kind of like a DBA.
Jasmine Henry (01:51):
After undergrad, I was promoted into project management roles where I got to work with the Tennessee Valley Authority on their home energy efficiency eScore program roll out using Android dedicated devices almost a decade ago. And then after finishing grad school, I was an independent industry analyst for about five years before I joined Esper. And I've been a customer of JupiterOne in my cybersecurity role for about two months. I'm a huge fan of their product and I'm using it for compliance at our organization.
Rin Oliver (02:17):
That sounds fantastic. Wonderful. I actually didn't know some of that about either of you, so it's great to always have the inside scoop. So, moving onto my next question, which is the meat and bones of why we're here, what is continuous observability and why does it matter?
Tyler Shields (02:33):
It's actually a very overloaded question. Continuous observability is really something we have to kind of point out and apply to a specific field, or section of a field in JupiterOne's eye of continuous observability. In many ways, it's like shining a light in the dark sections of your attic continuously. Moving that spotlight around to every dark corner and continuously checking to make sure there's nothing going wrong in any dark corner of the attic. But the trick there is making sure that that light is continuously running, continuously deployed.
Tyler Shields (03:04):
In a better analogy, it might even be a big overhead light that illuminates the whole room. Security has traditionally been seen as kind of a point in time assessment. And so your application security scans are a point in time. Your assessment of compliance tends to be a point in time. And really if you're doing security right, continuous security or continuous observability is the first step towards a true continuous approach to security. Because if you can't continuously observe your environment, you can't continuously secure your environment. So it's kind of a nebulous answer for a bit of a broad question, but I think as we go through most of this podcast, we can drill down on some more details around that.
Jasmine Henry (03:42):
I think that's absolutely accurate. I think that Tyler completely nailed it. Esper, like a lot of other cloud-native organizations, we have this vast multi-cloud environment that can change very, very quickly. And so how I use JupiterOne in my role is to see those real-time changes. Adding to that, speaking from the perspective of the smart connected edge devices that Esper works with. Continuous observability is about seeing the entire picture, which for a smart connected device at the edge can be configurations, apps, hardware, firmware, and user, and being able to continuously enforce a healthy state for all of those factors.
Jasmine Henry (04:14):
I had an early mentor, Michael Howard of HP, who often said that humans are the biggest piece of malware on your network. And that's definitely true with the single purpose device space. If you have an employee with a tablet who decides to download an insecure personal app in the play store or a random website. It may seem okay in their eyes, but it can also seriously threaten the integrity of enterprise devices and data. So, in my experience, the security state of an edge device is something that needs to be observed continuously after deployment. Can you track it? Can you remediate it?
Jasmine Henry (04:41):
Can you attribute whether performance issues are caused by the battery being drained because the device is unplugged, or whether it's a serious sign of misuse, theft, or tampering. Some of the most compelling use cases in Esper space include Android respiratory monitoring devices, so that patients with chronic respiratory conditions, like COPD, can breathe. And the big question in that case is whether the product is effectively monitoring their health and safety outcomes. And if there's a device event, can the dev team use APIs to programmatically retrieve crash logs and troubleshoot?
Rin Oliver (05:11):
Fantastic. That makes a lot of sense. So, where does that continuous observability fit in with CI/CD and things like DevSecOps?
Tyler Shields (05:20):
Yeah. Another wonderful question. DevSecOps really is the merging of what used to be three silos, development, security, and operations, into a single unified human being process or approach to development, security, and operations. And I think a broad well-formed security program will be able to tackle any of those three pillars, development, security, and operations, in a way that requires continuous observability. The ability to understand current state, historical state over time, and future state changes over time to apply security impacts to those.
Tyler Shields (05:55):
What JupiterOne does when it comes to DevSecOps and CI/CD is really take every entity, or asset as we call them, whether it be, for example, your infrastructure, your cloud infrastructure, whether it's Amazon or Google or Azure. The configuration of that, the configuration of your workloads. Instances being run or not run. Mapping all of that back to alongside of analysis and connection to your development assets, like your repositories, and your commits, and your code itself, and connecting that directly to your security operations assets. Of, say, interconnectedness between nodes, and design type architecture as code, and really pulling all of those assets in a very generic software-defined way into a single view.
Tyler Shields (06:38):
And so when JupiterOne talks about continuous observability of that full stack, we're talking about taking all those entities or assets, normalizing them, and really understanding not only the assets, which could result in thousands, tens of thousands, or millions of assets, but the relationships between those assets. And that's where we find the bulk of the value around security for our customers. And it comes from the fact that dev, security, and ops aren't isolated anymore.
Tyler Shields (07:07):
The relationships between development, security, and operations... The relationships between those are the relationships that we have to track and understand state of. So, JupiterOne really targets all of your cyber infrastructure and security assets and pieces of configuration and content. And actually looks at that continuously for deviation off of an accepted secure state. And that's why we're able to provide so many different use cases to our customers, such as Esper.
Jasmine Henry (07:33):
That is really eloquent. That's remarkably well-spoken. CI/CD can't end when the code ships. I think that organizations need to be using production data to make improvements in mid-flight due to that sense of interconnectedness that Tyler referenced. We have a customer whose Android device protects patient fall risk. And one thing they do is they use our APIs to automatically retrieve kernel logs for debugging, if there's a crash or another device event. I think that example is pretty relevant because healthcare device failures have been a very prominent component of the media cycle.
Jasmine Henry (08:03):
There's an unfortunately enormous number of tragic examples where device failures have caused serious patient injury. The healthcare device safety is obviously a very complex topic, but it's a clear example of why being able to make changes in mid-flight really matters, especially if it means avoiding a patient injury or an FDA product recall. So, organizations need to be able to learn from real world data in an environment that's backward compatible to their developer tools.
Jasmine Henry (08:29):
And again, it's that sense that Tyler referenced of the fact that security, development, and ops are no longer separate. So it's a need for transparency and compatible tooling. If a device fails a patient or a user, manufacturers and dev teams need to be able to analyze that real-world data and disseminate a response in real time. So, continuous observability means seeing the bigger picture and being able to respond and learn from it quickly.
Rin Oliver (08:53):
I agree completely. Having that layer of observability and being able to act on things is crucial, especially when something goes wrong. So, switching gears a bit, I'm going to direct a question towards Tyler and dig into how JupiterOne operates. What's the relationship between continuous observability, DevSecOps, and compliance?
Tyler Shields (09:10):
Yeah, I got into that a little bit on the last question. I tend to jump the gun there. But I mentioned before about the breakdown of DevSecOps and the unification of that, and the relationships between your assets and entities. What's really interesting is if you take the concept of all of your cyber assets, all of your cyber infrastructure and security assets. From all the ones that I talked about already, let's also add in there identities, human identities, LDAP entries, vulnerability management results, scan results. The breadth of entities is important to success, because what we do at JupiterOne is actually unify all of these entities and map the relationships between those entities, but also normalize them.
Tyler Shields (09:52):
So, for example, what used to be difficult to do for an engineering team when faced with compliance, for example, there is a question in most compliance, do you have any data stores outstanding that are un-encrypted and facing the internet publicly? Well, if you're just running Amazon, maybe that's easy, except that you start to think about, wait a minute, there's like four different, five different data store classes in Amazon alone. Let's add to that the fact that most companies are multi-cloud. So they might have two or three different Amazon data stores, or a data store in GCP, and then one sitting in Azure to support multiple different development languages.
Tyler Shields (10:29):
And when you see it and start to really understand and grasp the complexity of what we're talking about. What JupiterOne does is normalizes all of that into a way that's consumable and query-able. And you're able to ask those very difficult questions. And so when we talk about the analogy I made about shining the flashlight around your attic, it's to continuously understand what those relationships and assets are, which then directly can drive compliance. Because if we look at all of our assets and we thoroughly understand what the assets are, where they exist and the relationships between them, we can ask those generic questions and get great answers that are highly accurate and continuously updated.
Tyler Shields (11:06):
That can then feed a workflow or an alerting system. So when deviation off of accepted compliance norms happens, you're able to secure it quickly. And so the best thing about this, there's an old saying that compliance is not security. And, in general, it hasn't been. Because compliance is a snapshot in time where you set a low bar and say, "If you can jump over this hurdle, you're compliant." Well, guess what? You're still not secure. And we can prove that because of the vast majority of breaches that have occurred in the last decade, most of those companies had compliance. And so what JupiterOne is aiming to have is compliance that is secure.
Tyler Shields (11:44):
And you do that by having continuous and complete observability, continuous and complete mapping of the assets, and understanding of the relationships, and then continuous and complete alerting workflows and the ability to remediate problems in that model. And so that's what JupiterOne is really focused on when it comes to DevSecOps and compliance is, yes, we do compliance. Yes, we do cloud security posture management. Yes, we do vulnerability management. Yes, we do breach handling. But we do that all under the concept of this broad asset security model. And that's really what we bring to the table to help break down the silos of dev, sec, and ops.
Rin Oliver (12:21):
That makes a lot of sense. Having silos can really impact a business's performance, especially when you can't get visibility into what's happening with your entire system.
Tyler Shields (12:29):
That's right, indeed. That's the key thing. It's the entire system. If we wanted to put a point solution in play, we could do a point solution, but the reality is the breadth that makes it valuable.
Rin Oliver (12:38):
Exactly. And in that vein, I'd like to hear from Jasmine too. Jasmine, what's the relationship between continuous observability and COSU?
Jasmine Henry (12:48):
So, COSU an acronym that means devices that are not your boss's Blackberry. COSU means corporate-owned single use. It's a term from Google. That includes Android kiosk point of sale devices, kitchen display systems, your smart exercise bike, healthcare devices, and a lot more. We typically say single-purpose devices. We have data from IDG that indicates that these smart connected devices are going to outnumber humans by a factor of more than five to one by the year 2025. There's no question the IOT is growing and many of us are betting that Android's the platform of choice for IOT growth on the road ahead.
Jasmine Henry (13:20):
For a lot of reasons. Android is user-friendly, it's an open-source framework with broad global adoption. And there's really great possibilities for telemetry development with Android. One really compelling example of continuous observability and COSU is the idea of smartwatches to predict patients seizure risk in people with severe epilepsy. Researchers are actively working to figure out the biometric signals that indicate an oncoming seizure, that's detectable by this wearable device before it's apparent to the patient or their caregivers. So, in this type of case, continuous observability would be crucial to development, testing, and deployment.
Jasmine Henry (13:55):
To understand these seizure signals, and also help these patients and their caregivers respond in a timely way. So, continuous observability in the case of COSU is about getting the insights to the right person at the right time. Whether that person's at the edge, a patient at home, or in a hospital, or anywhere else. The relationship between continuous observability and COSU is about decentralized control and scaling.
Jasmine Henry (14:18):
Organizations need to be efficiently able to manage these fleets of devices as the fleets grow, and incorporate custom built devices because traditional methods and solutions just don't work when you're dealing with a fleet of a 100,000 or 200,000 devices. In that sense, continuous observability is a design factor. When you're custom building solutions, it needs to be part of your infrastructure to create that real-time awareness and response between edge device and cloud.
Tyler Shields (14:44):
I love that line of talking, Jasmine, because what you're talking about is going even beyond breaking down the walls of dev, sec, and ops. And actually breaking down the walls between healthcare patient and practitioner, which is just yet another way of continuous observing and broadening our approach to how we manage that data from a security and operations perspective. So I think it's really cool.
Jasmine Henry (15:05):
Well, I think that JupiterOne also builds on the idea of continuous observability, which you mentioned at the beginning. It's a huge idea. It's a huge concept. And gives users like me awareness, the ability to respond in real-time. And that's really where I think continuous observability as a subset of DevSecOps is going, is into real-time awareness in an internet connected environment and the capacity for real-time response.
Tyler Shields (15:31):
Rin Oliver (15:33):
I also agree. I think that's exactly right. So, I have one more question for Tyler. What are some of the risks associated with treating security and compliance as an afterthought? And why does a concept like security by design and security by default matter?
Tyler Shields (15:47):
Yeah, that's a great question. There's a couple of different ways you can view this one. In the traditional product sense of the word, as a company building a product, which is typically where security by design and default has come into play. There's the old notion that it costs a lot more in the long run to bolt on security fixes than it does to design them in properly from the get-go. And not have to run into the problems that happen in the long run from having to bolt it on anyways. And that's the big piece of it. Not having security in will inevitably result in failures, risk, and other breaches or vulnerabilities.
Tyler Shields (16:22):
And then as you bolt it on later, the cost of the actual implementation there doubles, triples, quadruples, or whatever that mathematical formula ends up being, but it's significantly more expensive. If we broaden the scope of the question a bit beyond the traditional AppSec view of how we would do security by design and default, I think that it actually goes into how we secure by design and by default our entire security program. I don't think the analogy is any different or the fit is any different if we talk about the broad security program.
Tyler Shields (16:52):
If we design our day-to-day operations of our business in a secure way that matches the level of risk exposure that's acceptable to the business, to the amount we have to spend to serve the problem and fix the problem, finding that balance and designing that in right from the get-go will result in a higher efficacy rate of the dollar spend. So for every dollar spent, you'll get a return of 80 cents or 90 cents, versus 20 or 30 cents on the dollar spend. So that's, if we're looking at it in a purely financial mathematical way, one way to look at it.
Tyler Shields (17:24):
If we look at it in a broader view around the risks associated with treating security and compliance as an afterthought, what you find is that you end up with just so much more resources to go back and retrofit everything than if you had just clicked the box as you were going through the setup. The problem is, people don't always know to do it. And so with tools out there, JupiterOne being one of them, you can actually point it at your current environment, get that environment compliant, whether it's to a public standard or even an internal standard.
Tyler Shields (17:56):
Security is compliance in our model. And essentially secure your environment as you go in a continuous way. So as you build it, grow, add new workloads, add new segments, add new whatever, those things are automatically collected, managed, observed, continuous observability, compared against acceptable policy, whether it's internal or external, and resulting in a secure environment. You don't have that gap of insecurity that comes with that. So, essentially what we're talking about here, using continuous observability to lessen risk in real-time is actually creating a mature security program for your business. They really do equate to one and the same.
Rin Oliver (18:35):
That makes a lot of sense, actually.
Jasmine Henry (18:37):
And I can attest that as a startup we move quickly, our cloud environment moves quickly. And the automation that we've been able to achieve with JupiterOne is incredible. We have cloud alerts being sent in real-time to Slack and stuff like that, which is absolutely fantastic. That we've set a mature... I feel like it's almost a mature framework for growth without limitation through JupiterOne.
Tyler Shields (19:00):
We firmly believe that every company, no matter the size, no matter the resources available, no matter the scope, should have a right to security and risk reduction and safety within the organization. And so our product ranges from free product that you can connect to and join and use today, up through a product that can support the broad underpinning of major, major, large fortune 100 customers that we already have on the books. So, we're happy and glad and excited that Esper is one of those that is building on top of the JupiterOne platform.
Rin Oliver (19:30):
I agree completely. That makes perfect sense. And I'm excited that Esper and JupiterOne are working together as well. To that point, Jasmine, I was wondering why do edge devices up the ante for continuous observability in DevOps?
Jasmine Henry (19:45):
So, your boss's Blackberry is an example I used earlier. This is a mobile device, but it's not really a mission critical mobile device. If a CEO's Blackberry or iPhone or Android crashes, it's not a great situation, but the consequences might not be enormous depending on a lot of security and data exposure factors. In the best case scenario, you're looking at a really ticked off executive who can't respond to their emails and it's inconvenient. But edge devices are another story. We faced a really scary bout of patient injuries and deaths over the past few years, as there's been update issues and pacemakers have started getting hacked.
Jasmine Henry (20:17):
Currently there's zero examples on record of actual cybersecurity attacks impacting patient life, including the 2017 WannaCry attack that took down the British healthcare system. But I think all of us in cybersecurity really fear that we're right on the verge of a much different story, especially after a surge of attacks on cities late last year and in recent months. I think, for a lot of us, it's a scary question of how long until an attack on monitoring devices or patient implants does result in death. So, that said, many single use edge devices are mission critical.
Jasmine Henry (20:47):
They could be revenue generating devices like a mobile point-of-sale at a restaurant, or a self-service loyalty program machine at a gas station. But in many more cases, there's a lot more riding on these single purpose edge devices, such as patient safety, like I mentioned earlier. Organizations are using these smart edge devices to keep lone workers safe on industrial sites, or monitor environmental conditions in warehouses, or monitor respiratory breathing so that patients with chronic conditions can be kept safe at home with their families instead of paying for hospital stay to access constant monitoring.
Jasmine Henry (21:17):
So, single purpose devices at the edge definitely raise the bar for continuous observability, even if you're not in healthcare. If you're in a consumer facing industry, like retail, restaurants, or hospitality, performance issues at the edge can result in a loss of customer happiness or brand reputation. I read that a study from Shekel Brainweigh recently stating that 87% of customers expect self-service digital options like kiosks because the COVID-19 pandemic has dramatically changed consumer behavior across many different demographic groups.
Jasmine Henry (21:44):
Edge devices need to be available online, accessible to everybody who wants to use them. And just as helpful and convenient as face-to-face customer service, especially considering that customer service rep interactions are becoming less common in today's world. Not every brand's edge devices are life sustaining, but they're generally mission critical. So I think that organizations need to understand what's at risk for them if they can't continuously observe these edge devices for performance and security. Especially with the understanding that COVID-19 has changed absolutely everything, and historic data on customer behavior may not be the best indicator of today or tomorrow.
Jasmine Henry (22:17):
I think that companies need to carefully consider the risks of treating security like an afterthought, to Tyler's point, especially with Horizon's data that shows that putting security off can double the chances of a multi-million-dollar cybersecurity attack. And organizations need to strive for observability by design and default. As they release new products they should consider as early as possible, how we'll observe and respond in a production environment, because this is a huge part of their governance frameworks. I come from a development background. I've worked really closely with the devs for most of my career. And I can tell you a few things about how developers operate.
Jasmine Henry (22:48):
Most developers, including myself, are really bad at time management. And all of us hate ripping out work that we've done previously. And aside from developers, who likes redoing work? So if I can lump Android devs and cloud devs and innovators into a single bucket of creators, that's something that we all have in common, is wanting to get it right the first time and not redo our work. To Tyler's point, Ponemon data shows that it's costlier and riskier to redo work when you're not secure from the start. And that's really just confirmed by, I think, common sense and experience. So, continuous observability, in that vein it's a design factor, it's an infrastructure factor, and it's a major factor that feeds into the long-term health and success of edge devices.
Rin Oliver (23:29):
That makes perfect sense. I think that's absolutely true. And for my last question, I would love to know what gives you hope about the future of cybersecurity, considering you've both been in this industry for a while. What makes you wake up and go, "Okay, the cybersecurity industry isn't all that bad after all."
Tyler Shields (23:45):
Yeah. Honestly, the people. It's the people in it that are just amazing to work with. Everybody, from both of you fine folks, to a lot of the people that I've worked with over my 20-year career in cybersecurity. I do wake up every day, and I believe that the bulk of the cybersecurity world has the best interests of the enterprise and the security professional in their hearts. We may not always do the best thing when it comes to helping them, but we have the best interests in our hearts.
Tyler Shields (24:13):
And I think that's what gives me hope for the future, is that I think someday we will figure out how to design security in, make security ubiquitous, make security just something that comes with everything that we do. And it may take another 10, 20, or even 50 additional years from now to achieve that goal. But I think it's a rational, reasonable, and a completely achievable goal someday in the future, just because of the people that are involved in cybersecurity today.
Jasmine Henry (24:42):
Yeah. I think if you'd asked me that question about two or three years ago, Rin, I probably would have answered that I was given a lot of hope by the fact that CSOs were becoming a part of the C-suite. They were starting to have business conversations. CEOs were starting to take security seriously. And another thing that I feel like was huge a couple of years ago was the fact that I was starting to see women at cybersecurity conferences, which I feel like was not as much of a factor before, gosh, I don't know, 2016, 2017.
Jasmine Henry (25:10):
So, those are two things I've seen change in a big way in my career that make me feel very hopeful. But I think right now it's the idea that we're talking about DevSecOps. The fact that we're seeing development, security, and operations as continuous, as interconnected. And we're starting to talk about security by design and default in a real operational way that's changing the way that we practice and the principles that we use in the workplace. That's something that gives me a lot of hope for how the industry is going to scale security to tomorrow's solutions.
Tyler Shields (25:43):
Yeah. It's funny you say that you. You sparked a technical nugget in my head, too, that I want to throw out there. Another thing that really does give me hope is the last three to five years... Not even five years, let's just call the last two or three years. We've seen a real big push to every technology, security tool, product, et cetera that we use in the enterprise becoming an API-driven technology. And that gives me significant hope. That gives the technical side of me significant hope because the interconnectedness and the relationships can now be properly discovered, weighed, and valued. And so that, I think, is a fundamental... Let's call it a major industry shift that has occurred in the last few years. That gives me hope that we might be able to actually bake security into this thing over time.
Jasmine Henry (26:26):
I think that you absolutely nailed it and we can pack up and go home now. But you're right, that's confirmed by... Google has that amazing annual State of DevOps report that they do with, I believe it's DORA, and they talk about that most mature DevOps organizations have this just infinitely scalable cloud infrastructure, various measures of infrastructure maturity and cloud maturity. And the idea of infrastructure as code, APIs, like you mentioned, is really what the most mature and effective organizations are doing.
Rin Oliver (26:55):
I agree completely. Well, thank you both so much for joining me. I really appreciate it. And to our listeners, thank you so much for joining us on this episode of the DroidDev Cast. We'll be back next week with another exciting show for you. Please remember to like, subscribe, and share this episode on social media. You can visit us at JupiterOne.com\DroidDev, D-R-O-I-D-D-E-V, and download the IT Asset Revolution today to learn more about asset management. We'll be entering the first 100 demo requests into a raffle to win a Khadas single board Android computer shipped straight to your home or workplace device lab, which is really exciting. You can listen to the DroidDev Cast on Apple podcasts, Spotify's Simplecast, or wherever you get your podcasts from. Thank you again for listening.