devopsy.kinsta.cloud

Tag: data security

  • TechStrong TV: strongDM With Betterment

    TechStrong TV: strongDM With Betterment

    Betterment is a goal-based financial advisory company that provides robo-advising services to help customers make the most of their money, taking away all the complexities of investing and saving.

    In this interview for TechStrong TV, strongDM co-founder and CEO Elizabeth Zalman and Chris Becker, SRE manager at Betterment, joined us to discuss how strongDM helps make things faster, automated and easy at Betterment by tracking and auditing all changes on their system.

    Chris was the project lead for implementing strongDM at Betterment. During this segment, Chris shared his journey of becoming manager of the SRE team at Betterment and the reasons why they chose strongDM to secure access to their data.

    Check out the interview below and follow along with the transcript to find out more.

    Transcript

    Alan Shimel: Hey, everyone. We’re back here at TechStrong TV, and for our next segment. For this segment, we have one of our semi-regulars back here, Liz Zalman of strongDM. Hi, Liz—how are you?

    Elizabeth Zalman: Hi, Alan. I’m well, thank you.

    Shimel: Good, thanks for joining us. And joining Liz and I today is Christopher Becker, SRE with Betterment. Is that correct, Chris?

    Chris Becker: Yep, SRE manager at Betterment.

    Shimel: Very cool. So, Chris, you know, I got a little background on Betterment before we started recording today, but why don’t you share with our audience—what’s Betterment? What do you guys do?

    Becker: So, yeah, the elevator pitch for us is that we’re a robo-advising platform that helps you make the most of your money. So, the idea with us is, we take away all the complexities of investing and saving and we’ve turned it into a goal based platform that lets you invest your money, save for what you’re going for, and try and make the most on top of the market and everything like that.

    So, we—yeah, we try and take all the trouble of saving and all that, we dynamically balance portfolios and things like that for you and, as Liz said, it kinda removes all the distracting stuff with money.

    Shimel: Very cool. And, you know, what’d kinda unique about it is, it’s very goal based, right? So, you gotta tell Betterment what are your goals, what are you saving for, here? I wanna buy a house, I wanna buy a car, I wanna put money away for retirement.

    Becker: Mm-hmm.

    Shimel: I wanna go on—I wanna take 180 days off and cruise around the world. That would be mine, but anyway. [Laughter]

    Zalman: [Laughter]

    Shimel: You know, so, it’s a pretty unique kind of thing like that, and it’s—I guess it’s kinda uniquely situated for, I’m gonna assume, a lot of your customer base is sorta Millennial, Gen Z kinda folks, or do you get, you know, old people like me?

    Becker: [Laughter] We have everyone, all over the gamut. I think—yeah, like, you mentioned the goal based investing, and that’s what’s super important to us. And it helps us sort of like—it helps us make the calculations about how we balance everything.

    Me, for instance, I have a goal that’s like saving for a house, and that’s a much different trajectory than something like retirement for me, based on my age and my income and everything like that. And what Betterment helps you do is just save in the best way to hit those goals. So, if you’re trying to get X amount of dollars by Y date, there’s sort of a formula that does that, and if you’re saving for retirement, there’s a different formula that works with that. It’s all kind of within our platform.

    Shimel: Cool. So—and, of course, the website, let’s get that out of the way, B-E-T-T-E-R-M-E-N-T dot com?

    Becker: You got it.

    Shimel: Okay.

    Zalman: And there’s a mobile app.

    Becker: And there’s a mobile app. [Laughter]

    Shimel: [Laughter] There’s an app. And we should also—hey, full disclosure, Liz has told me not only is Betterment a customer of strongDM but Liz is a customer of Betterment, so.

    Becker: [Laughter] Exactly.

    Zalman: It’s a great product. [Laughter]

    Shimel: Take it with a grain of salt—take it with a grain of salt. [Laughter] Anyway, Chris, let’s talk a little bit about your background, though, now. So, you are manager SRE there, and our audience is very, very familiar with SRE and SREs in general. But how does one become a manager of the SRE team?

    Becker: Absolutely. My background is particularly interesting. I guess, rewinding the clock a little bit, I was—I got into sort of computers and computer management and server stuff, like, way back in high school. I come from a pretty, I guess you could say, classical IT background. I actually have, like, a Microsoft MCP, if you can believe that, like, from back in the day.

    Shimel: I do.

    Becker: [Laughter] Yeah, Server 2003 Active Directory, so.

    Shimel: Mm-hmm.

    Becker: That’s—yeah, I went to a high school with a really great computer program that let a lot of the students get hands on access to stuff, and by my sophomore year, me and my other classmates were sort of managing our computer labs and learning about how to do all that kinda stuff.

    So, that’s like—yeah, I guess I was fortunate in that I got into this really early and it was something that I was really excited about and I was kind of like, you know, that guy in high school with my buddies, we built computers and things like that as well.

    But yeah, and then right out of high school, I went to college and studied Information Technology as well. And one of the things that, like, for me, I’ve always sort of been, I guess, the jack of all trades when it comes to technology—everything server management, a little programming, and things like that. And then out of college, I actually got a job at Warby Parker doing office support, so like, IT support.

    And that’s kind of, for me, where, I guess you could say the automation bug, I got bit by that. Because we were doing a lot of software installations and things like that on people’s machines and we wanted a way to, like, with our two person IT team scale out to support, like, you know, 300 people at Warby at the time.

    So, it was like investigating, you know, more things that we use in the SRE world today, like, things like Ansible and things like automation scripts and stuff like that. I was kind of, like, getting introduced to that as a way to just make it so that our small team could manage and automate installations on a bunch of work stations.

    And then from there, actually, within Warby Parker, I had the opportunity to change to what they called an infrastructure engineer role which, looking back on it now, it was essentially, like, DevOps, right? You know, because DevOps is, I guess, the big umbrella that covers a lot of different disciplines and stuff like that.

    So, from there, I really—I leveled up a lot of my programming skills as well, writing automation scripts and stuff to set up developer work stations. But what was important, I think, in that role for me is that I had a really good relationship with sort of internal customers, as I like to call them, for my IT role where my sort of stakeholders of the things that I built weren’t people that were the traditional customers of the business but rather those that, people that worked or the business.

    So, I think a lot of—like, one of the reasons why I like DevOps and SRE and things like that is because it allows you to have a really close relationship with your customers, because they’re in the same company as you are a lot of the time, so.

    And yeah—and then after Warby Parker, I got a job as an SRE at Betterment and our team was similarly very small. There was, I think when I started, there was four of us and we were supporting an engineering organization of around 80 folks and then, from there, our engineering team grew as well as our SRE team. And now, I’m the manager of that team and so, having been on that team for two years and change before becoming the manager, I had a really good sense of what we liked to do, things we wanted to build or our engineers and platform things as well. So, now, I’m kind of like at the helm and get to control that, which is really, really cool.

    Shimel: Excellent, man. Great story. You know what, Chris, I don’t think your journey is that unusual, to tell you the truth. I mean, I spend my life talking to people like you and Liz and—I mean, what’s different is, you know what, my high school didn’t have a computer lab, my college had punch cards. But, you know, my children, for instance, our local high school here in West Boca Community High, they actually do have, they have actually a Microsoft Certified program. So, a lot of—you know, you become Office certified, big deal, as a freshman. But by the time you graduate, you are Microsoft Certified.

    They might have, I don’t know if they’ve moved over to Google stuff now and more cloud-based kinda things, but there’s a cyber security area of concentration they call it, which is pretty cool, too. And, you know, it’s good. I mean, because so many people of my generation who—look, we took the Internet commercial, right, and built what you see here. But so many of them are self-taught, especially in things like DevOps or cyber or, you know, those kinds of things. And so, it’s good to hear people with real academic backgrounds in this stuff. I think it bodes well for the future.

    But, you know, part of what you guys are doing, obviously, is, you called it infrastructure engineering or at Warby Parker, DevOps. But the real thing here is that we’ve moved, in your lifetime, right, in your career—I don’t know if they ever had the concept of the server closet and the data center on prem. Everything is SaaSOps, right, or cloud or some sort of hybrid of that, right? There might be some third party data center you use where you’re running, let’s say, a private cloud kinda thing. You mentioned Ansible—well, that was back at Warby, so I don’t know if you’re using OpenShift or anything like that.

    But clearly, right, it’s not—this is today’s infrastructure, today’s kinda new stack as I like to call it. What about Kubernetes, cloud native, any of that stuff?

    Becker: Yeah. So, that’s like, at Betterment, we’re using Kubernetes. We’re on top of AWS as well. And I think it’s—I like that you mentioned sort of like old server clouds and stuff. I think the last time I interacted with a physical rack server was probably in college. But, I mean, I grew up punching Ethernet cables and racking and stacking and configuring, you know, Ratarays and things like that. And I think what—

    Shimel: Fun times. [Laughter]

    Becker: Yeah, right? [Laughter] Well, not with Ratarays, but I think—yeah, what I really like about sort of my, I think where my background has been really helpful for me is like, you know, when you enter this new world of AWS and cloud configurations and Kubernetes and stuff like that, like, it’s all still based on the fundamentals. And I feel like I got a really good sense of, and a really good education in networking fundamentals and things like that. Which, if you look under the hood, Kubernetes abstracts a lot away from you, but you still might have to do some kind of site or notation calculations, right? Or figure out, like, some [Cross talk]—

    Shimel: It’s been a long time since did CIDR.

    Becker: [Laughter] And it’s—and things like, yeah, and figuring out, like, we were debugging an issue with network connections and being able to Wireshark and look at the TCP handshake and figure out why we were dropping packets or getting RSTs or something like that. Like, being able to sort of zoom into those things that we don’t necessarily think about a lot these days when we sort of turn on a server in AWS and we don’t really think about—like, being able to sort of lean on that knowledge is incredibly helpful in those head scratching debugging moments and stuff like that.

    Shimel: Yeah. No, no, it’s always good to understand what the underlying technology is about. But part of what—and this is really something strongDM does, right? Part of what we’re doing here is, we want to make it chimp simple. We want it to be fast, automated, easy. That’s a big part of the SRE kinda mantra as well, right?

    Becker: Yeah.

    Shimel: And so, let’s talk a little bit about strongDM over at Betterment, right? How did—was it there when you got there? It sounds like you’ve kinda built the thing, though, you brought it in. Talk to us about the use case, here. What made you go with strongDM, why, what problem were you trying to itch, here—or, yeah, what scratch were you trying to itch?

    Becker: Absolutely. Yeah, no, for us—so, I was actually the Project Lead for implementing strongDM at Betterment. So, I absolutely love it, first of all. It’s one of my favorite apps because I don’t have to think about it ever, and that’s like—if I forget, like, it’s something so seamless and it is so well run that I forget about it, those are my favorite kind of pieces of software. [Laughter]

    Shimel: Well, no, that goes to what we just said. We wanna make it that simple, man.

    Becker: Easy, simple, automated.

    Shimel: I don’t wanna do CIDR calculations.

    Becker: [Laughter]

    Shimel: [Cross talk] [Laughter]

    Becker: Yeah, no—so, for us, we had a need at Betterment, obviously, we’re a financial institution, we have regulations that we abide by and these things, one of these things is auditability and we need to make sure that any changes to any systems that we have and that we run and we operate are auditable, it’s tracked, it’s logged.

    So, for us, strongDM was sort of like the perfect picture, because it allowed us to use that platform to get auditability, we could track and log everything as well as push everything with SSH at the time through one system, which was really nice. And it also had the added goal of not being dependent on our VPN, which we’re trying to get rid of as well, for a lot of reasons. [Laughter] strongDM, yeah, allowed us…

    And also, the thing that I’ve said amongst my team and one of the reasons why I really like strongDM is, it sort of abides by what I like to call the Unix philosophy, right? Like, it does one thing and it does it well. And it’s very predictable in its command line, it’s very predictable in the way that—its interface and it interacts with other servers and things like that. And it was really easy for us to build out this entire system with, you know, literally running two EC2 instances and they’re able to get into hundreds and hundreds of servers every day and have never had an issue, so.

    Shimel: So, Liz, five interviews—this is the longest I’ve ever heard you go without speaking. What’s up? What can you tell us about this?

    Zalman: What I can tell you is that Betterment, I think, is, I’m gonna say top three in terms of forward thinking customers that we have. They’ve pushed the envelope in a variety of ways. They were using SSH, I think, where they had requirements for how they wanted engineers to interact with SSH that we didn’t yet support in the platform. I think the same thing went for kubectl as well or usage of Kubernetes. They were the first to really stress our system—not stress our system in terms of, like, we went down, but stress in terms of, “I wanna automate stuff like this, and you’re doing this, and I need you to get to this.”

    I can’t count the number of times that Chris asked for a REST API. Have you used it yet, by the way?

    Becker: [Laughter]

    Shimel: Tell the truth, have you?

    Zalman: Have you used it yet?

    Becker: Oh, yeah—no, we have. Yeah, we used it.

    Zalman: Okay—good, good, good. [Laughter]

    Becker: Yeah.

    Zalman: They had requirements in terms of directory syncing—yeah, so, it was a pleasure to work with them. And I actually don’t recall—did we meet when you were at Warby, or were you just sort of aware of that relationship?

    Becker: You actually, I think you came in to meet the infrastructure team, like, the Ops team at Warby at one point.

    Zalman: Yeah.

    Becker: Because I remember we were piloting strongDM at one point. I don’t think I was there when the implementation happened or anything like that.

    Zalman: Oh, yeah.

    Becker: But I was familiar with the product from Warby, actually.

    Zalman: Yeah. And Alan, it’s actually interesting—Chris is part of a, Chris used to be based in New York City and in New York, there is this group of infrastructure folks that stays within sort of the B2C world in my opinion and goes to the unicorns. And it was almost borne out of Warby, some went to, like, Harry’s for shaving, some went to Peloton, some went to Betterment—I’m sure I’m missing a couple companies. And they’re almost more forward thinking than our traditional B2B clients are. It’s a very interesting trend.

    Shimel: Yeah. You know, one of my good friends is a guy named Brad Feld out of Boulder, and Brad, he founded TechStars and Foundry Group. He used to be—he’s a big VC. But he’s also an author and he’s written this whole series around what they call startup communities, and it really talks about, Liz, what you were just saying, right? Generally, you get a pool of talent, right, in a geographic region—within a community; it doesn’t have to be geographic, actually, but within a community. And that talent, it’s almost like the six degrees of separation, right? You can see a company has a liquidity event, people make money and they start other companies. Or they develop some really great expertise—in this case, kinda B2C, using real edgy kind of…I gotta stop using the word edgy, because it’s now meaning The Edge. But, you know, kind of cutting edge is what I mean—technology players.

    And they do, that—you can almost trace the DNA, if you will, right, from company to company to company because it’s that same, the same roots of people. And that’s what makes a startup community, because along the way, right, more people get added into the tribe, if you will, right? And that tribe continues to grow. And that’s how—I mean, that’s how tech centers are born, right? You can trace—like Boulder, for instance; Boulder, Colorado—you can trace a lot of what came out of, what’s coming out of Boulder by from when the storage folks were there and IBM had a big facility there and the University of Colorado and Brad coming in and investing a lot of money. There were a handful of companies that had really great outcomes or liquidity events, and it gave rise to this whole—Austin the same way, I mean, by the way.

    Anyway—strongDM. So, Chris, what are you guys using it for? Liz mentioned some REST APIs and stuff like that, but how—what are you using it for, how is it working out, what do you see?

    Becker: Yeah, so, we’re using it for, our sort of highest level use case is any time a developer needs to access a server or a database or a cluster, a Kubernetes cluster that we run and operate, they go through strongDM. And for us, like I said before, that was super important, because we want to make sure that all of the changes to our systems are tracked and audited.

    So, we have—we actually started out just implementing sort of the SSH back end, and like Liz alluded to, we had some very interesting requirements around directory services. So, we use Okta as our identity provider and directory service.

    Shimel: Sure.

    Becker: And strongDM helped us wire that together so that a person on the team, their e-mail address and their Okta identity is used by strongDM so that we can sort of tie all those things together.

    We also had, like, another thing that Liz alluded to was sort of like, we had a ton of servers and one of our unique use cases was, at the time, we were heavily using autoscaling groups within AWS. So, one of the big things with us and strongDM was that the server inventory was extremely dynamic, depending on load of our servers, depending on deployments and things like that. We might have 100 servers in inventory, we might have 200 servers. And they were coming up and down sort of all day.

    So, for us, one of the other interesting requirements is, we needed some kind of automation so that when an AWS would turn on a new server to handle extra server load that that server was automatically enrolled and registered in the strongDM platform.

    So, yeah, again, we worked with strong a lot on sort of nailing down that interface and we’ve written some automation scripts and things like that to get it to register and everything like that, and their admin, their admin token API and everything like that made that a breeze. And then our most recent implementation is actually, we use strongDM for Kubernetes. So, we basically have a, when you need to get access to our Kubernetes cluster or debug an application in our cluster, we actually live provision a container and then your proxy through strong, like, right into that container and all of that is audited as well.

    And all of our developers, actually, they don’t even—the best part is, they don’t even understand, like, they can connect to an old system or a new system and for them, it’s completely transparent. But yeah, it all runs through strong and it all is—and for our compliance reasons, that’s all audited and tracked and logged, which is great.

    Shimel: That’s nice. Two things I wanna highlight here and then Liz, I’m gonna ask you to expand on it. Number one is that, by using strong, what Chris’ team is able to do, as he mentioned, they use Okta—they don’t have to worry about hooking up this person’s identity maybe via e-mail with their Okta identity for purposes of IAM, right, across their disparate network infrastructure, right?

    strongDM here, as part of the proxy process, is lining up that person’s real identity, right, their e-mail or whatever you wanna use as their real identity with their IAM identity—I call it an IAM because it could be Okta it could be others, right? And then—but the person doesn’t have to think about that, and quite frankly, Chris, neither do you or your team, right? strongDM just makes that—again, chimp simple, easy, done.

    Becker: Yep.

    Shimel: That’s number one. Number two—and Liz, this is where I really, I’d like you to comment in—the idea of using it in this Kubernetes system and containers, as Chris is referring to, is that the norm now, or do you think this is kind of an advanced use case?

    Zalman: It’s an interesting question. And yeah, I think to your first point, it’s, we’re acting as an infrastructure API, right? We don’t care what Chris is using as his identity store. We don’t care where his infrastructure is, we’re just connecting the dots.

    Shimel: Yep.

    Zalman: Kubernetes was—I mean, we’ve seen different instantiations of Kubernetes over the years, right? Docker tried with Swarm and it didn’t stick and Kubernetes did. And maybe people were using it, they were trying it on. And I remember, like, the month that it hit production workloads, because I think we got seven or eight requests in one week. It’s like—why don’t you have support for this protocol? And we said, “Okay, time to build kubecl support.”

    Shimel: Time to do that, yeah.

    Zalman: Yeah.

    Becker: Yeah, guilty. [Laughter]

    Zalman: Yeah, you were one of them. [Laughter] It was like plain, plain, plain, plain, plain—mainstream. And so, I think everybody is trying to find some way to systematize and puppeteer everything that’s going on and abstract away a lot of complexity.

    So, no, to me, Kubernetes is certainly here to stay. I see everybody using it.

    Shimel: But is their—because it sounds like their Kubernetes installation, if you will, the way they’re using strongDM is maybe a little different than—is that the standard way that people are using strongDM and Kubernetes or is theirs a little different?

    Zalman: I think Betterment has a particular approach to locking down access which is, you literally get this much access or this much access or this much access or over here, maybe this much access. It’s highly tailored and fine-tuned, and I think that is the—that’s sort of the forward thinking way. Like, people talk about lease privilege and Betterment has actually implemented it across the board for every single thing that somebody needs access to.

    Shimel: That’s great, man. That’s—and Chris, kudos to you and your team for that, right? Because that is—look, you’re in the financial industry, you’ve gotta do what you’ve gotta do there, but that’s an excellent thing.

    Guys, we’re over time, to tell you the truth, but I kind of enjoyed the conversation today, so I let it go. But we need to break out of here. Chris, enjoy—I know you’re about to take, you said, like a week off over that at the shore and enjoy it. I see maybe you’ll get that oar off the wall and actually do something.

    Becker: [Laughter] Some paddle boarding.

    Shimel: Yeah, that sounds cool. Anyway, I’m just thinking, I’m supposed to be going out on the boat tomorrow, but it’s also supposed to rain, so I’m not sure. But anyway, enjoy your week off. Thanks for joining us, thanks to Betterment for allowing you to tell your story here today.

    Liz, always a pleasure to have you on and hear more about strongDM and this whole kind of—you know, these new companies, not necessarily new like today new, but a new way of doing things and a new way of making it easy to bring people on and access assets wherever the infrastructure is, so—fantastic.

    We’re gonna wrap. This is Alan Shimel for TechStrong TV. We’re going to be right back with our next guest.

  • Safeguarding Secrets Within the Pipeline

    Safeguarding Secrets Within the Pipeline

    How can an organization write source code to use secrets without directly referencing them and risking them being leaked to the public?

    2020 closes out a decade full of countless code leaks, a topic we talk about quite often. In fact, just recently, Intel became the latest victim after 20GB worth of internal documents were leaked and uploaded to a public sharing site.

    Intel finds itself in good company as it joins a long list of 2020 victims whose confidential source code has involuntarily gone public.

    Many, if not most, of these victims share one common fatal flaw: They hard-coded secrets (logins, tokens, etc.), then published their source code to a trusted cloud computing service platform such as an online Git repository.

    It would be naive to lay blame solely on the platform, however. It has long been a reliable rule of thumb that anything you put online—gated or not—is always at some level of risk. With this in mind, one should never, under any circumstances, include secrets in their source code. Stealing source code is damaging enough; the keys to your kingdom should not be included.

    That’s easier said than done, of course. How do you write source code to use secrets without directly referencing them? In this blog, we’ll show you an overview of how you can utilize your continuous integration and delivery tools to inject secrets into your code at build/runtime without actually including them in the code itself, thus placing a veil between your code and your secrets.

    Injecting Secrets

    One method for publishing source code reliant on secrets without actually including the secrets in the code is to use placeholders within the source code which, at build time, are replaced with the actual values needed.

    Microsoft Partner Technology Strategist Primoz Kocevar details such a method in his Medium post. The general idea is that secret variables are provided to a Docker image so that no secrets are found within the source code itself.

    An environment variable, set up beforehand, stores the secret. This variable is defined in a Docker file, which is used to create an image. During the build phase, secrets are then passed via the Docker image through the variables specified in the source code. Once complete, the application and image can be deployed.

    If you happen to run your images on Kubernetes, you can also leverage its own feature for securely storing secrets. This method allows you some additional options, such as using a Kubernetes environment variable or ConfigMap within a Kubernetes pod to store secrets for injection at build time.

    By the way, this approach to secret injection is by no means exclusive to Docker or Kubernetes. Though we highlight them here as specific examples, the same method can be employed via virtually any similar solution you rely on for deploying pods or containers.

    Injecting secrets via clever use of environment variables and configuration files in your microservices platform of choice is certainly a viable option, but we don’t think it’s the best option. Consider that this approach requires one image per each secret.  This can get cumbersome fast if you have a development environment with one secret and a production environment with another secret, each requiring different images.

    Leveraging Your CI/CD Tools

    First, a quick primer for the uninitiated: Continuous integration (CI) and continuous delivery (CD) tools and practices are an essential part of the larger software supply chain. Continuous processes are those that enable developers to publish code changes easily and frequently without degrading the product’s reliability.

    Continuous integration tools and practices establish uniform processes for creating, testing and building source code, integrating with any required external systems along the way. Continuous delivery covers the activities that follow, streamlining and automating the delivery of source code to infrastructure, especially when multiple multiple environments are involved.

    Many CI/CD tools provide their own built-in solutions for securing sensitive data. You can leverage these features when storing secrets until it’s time to inject them during the build.

    For example, Jenkins provides its own credentials store and its own automatically encrypted Secret field type. (A word of caution: This alone doesn’t prevent a user from accidentally printing a secret in the console log.)

    Another CI tool, CircleCI, offers a number of options for protecting secrets, such as secret masking to prevent secrets from appearing in terminal output and contexts, which limit access to certain variables to only specific user groups.

    There are, of course, as many additional options as there are tools available.

    We can leverage such features to enhance our previous example: secrets stored in your CI/CD tool can then be injected into our Docker run command (or your platform’s equivalent command) during deployment. In other words, your CI/CD tool of choice injects secrets into the image, which in turn injects the secrets into the corresponding source code’s variables. This method ensures our secrets never appear in the actual source code.

    A word of caution: Even utilizing this approach, your secrets are still only as safe as the tool you use to secure them. The Bleeping Computer article we linked earlier in this post points out how weakly configured tools themselves pose a threat: “The leaks have been collected by Tillie Kottmann, a developer and reverse engineer, from various sources and from their own hunting for misconfigured DevOps tools that offer access to source code” (emphasis ours).

    It’s important to stress the universal rule that there is no such thing as perfect security. Consider that encrypting your secrets within one of these tools offers little protection if access to those tools is not sufficiently restrictive. We recommend cautiously limiting who is granted what level of user access to each tool, applying the least privilege principle.

    Protection Post-Deployment

    Now that we have built and deployed our secret-free code, what’s next?

    If we were to stop here, we would have overlooked the fact that any developer who has access to our containers can see our secrets. The downside to utilizing a microservice infrastructure is that there are many opportunities for security gaps to appear between all the moving parts, from the moment the first line of code is written to when it all goes live, which can easily go unnoticed.

    Containers and pods need to communicate with each other and other endpoints, thus an attacker can leverage this by compromising one container or pod then moving laterally to others, rendering any secrets stored within ripe for the taking. The bigger your distributed infrastructure, the more difficult this is to prevent, because of the inevitable complexity of security policies required to do so.

    Thankfully, many tools offer options such as built-in network/firewall policies between containers/pods and endpoints, an option to encrypt data at rest or a mechanism for enforcing the least privilege principle, such as via restricted security groups.

    Some tools may also allow you to configure a Key Management Service (KMS) provider to encrypt your secrets. A KMS provider employs an envelope encryption scheme for data stored within etcd. The added benefit to this approach is that the decryption key is stored remotely on the KMS as opposed to on the same host.

    Conclusion

    Regardless of what tools you have in play along your development pipeline, secrets must always exist outside of the source code and should be (securely) injected into the code as it passes through the pipeline.

    Wherever secrets ultimately live, be it in a remote storage location, a container or pod or within a CI/CD tool, they must always be encrypted and never stored in plaintext.

    Finally, all the obfuscation and encryption in the world will not protect secrets from a lackadaisical user access policy. The least privilege principle should always be in play and user security groups should be strictly managed to control who has access to the systems responsible for securing your secrets.

    All that said, mistakes still happen, and none of the tools discussed here perfectly ensure that no developer will nonetheless accidentally hard-code secrets into your source code. It is with that in mind that we advise adding another layer of security by automatically monitoring your source code repositories for secrets.

  • TechStrong TV: strongDM Helps Kustomer Go Remote

    TechStrong TV: strongDM Helps Kustomer Go Remote

    For a procurement process to be effective, the relationship between the customer and the product team is almost as important as the functionality and features of the product itself.

    During this interview for TechStrong TV, strongDM CEO Elizabeth Zalman and Steve Flinchbaugh, senior SRE at Kustomer (a customer support CRM platform for managing high support volume effortlessly), talk to us about the strong bond between the Kustomer team and the support team at strongDM.

    Steve explains how Kustomer uses strongDM to empower its remote teams, how it fits into their development workflow and how strongDM has made his and his team’s lives easier.

    strongDM allows remote teams to easily manage access to databases, servers, Kubernetes clusters and web apps.

    Check out the interview below and follow along with the transcript to find out more.

    Transcript

    Alan Shimel: Hey, everyone, thanks for joining us for this next session here on TechStrong TV. This is gonna be a really good session; it’s something we haven’t done before. I have two guests, which we’ve done before, but we’re really gonna zero, we’re gonna take two different companies and see how they interact and how that helps, especially given everything that we have going on around us.

    Let me introduce my two guests to you first. First of all, we have Elizabeth Zalman. Elizabeth is the CEO of strongDM. We’ve done—I think we’ve done at least a podcast and so forth with strongDM before. Liz—hey, welcome, thanks to TechStrong TV.

    Elizabeth Zalman: Thanks, Alan. Nice to be here.

    Shimel: Thanks for joining us. Okay, and then joining Liz and I is Steve Flinchbaugh. Steve is with a company called Kustomer, and that’s spelled with a K, and he’s gonna tell us about it, as well as his position and background there.

    Steve, why don’t we start off with you, okay? Kustomer with a K—what do you guys do, and what do you specifically do at Kustomer?

    Steve Flinchbaugh: Sure, Alan. Thank you for having me. So, I’m a senior SRE at Kustomer, and what Kustomer is, is a CRM for customer support. And we really are built off of our platform. There’s a lot of intelligent automation that allows our customer service teams, our customers, to give the best possible customer experience they can and accomplish their customer service goals through, ideally, less staff and less effort using our platform.

    My goal as the senior SRE is to ensure the reliability of our platform, the kind of implicit trust that everyone expects, and to make the job for our developers as easy and seamless as possible.

    Shimel: Cool. So, a real, live SRE right here on our show—very cool. You know, there’s a lot—I don’t know if you guys have seen, there’s been a lot of articles written lately in the press around, you know, are we overblowing the whole SRE thing, right? And is it real, how real, and where does it fit in and all of these other things.

    But anyway, Liz, we gave Steve a good chance to tell us about Kustomer with a K. Let’s give you your chance—tell us about, remind our audience about strongDM.

    Zalman: Yes. Steve is one of my favorites, by the way—so is Kustomer with a K. They’re one of the most forward thinking customers with a C that we have. [Laughter]

    Shimel: Okay. Very good play on C/K, there. [Laughter]

    Zalman: strong is a—it’s a proxy, it’s a control plane, it’s insert whatever word you want there and it lets you manage and audit access to servers, to databases, to Kubernetes clusters, to whatever infrastructure you’re running that is firewalled. So, typically, that access is managed by hand, or keys are sitting in a box or a vault somewhere, and we let you collapse all of that down into a single control plane for both the management and auditing of that access

    Shimel: Yep. And I just—look, I feel like we have to mention that, you know, given the whole COVID situation and working from remote, you know, strongDM has been a real godsend to a lot of companies who had to kind of flip a switch and empower remote people to have access and stuff that, you know, from a different place on different machines, devices than they had before.

    So, though strongDM had a great case before COVID, right, a great use case, post-COVID, Liz, how many—you know, I’m not asking for the amount of customers, but I mean you’ve seen a lot, I imagine you’ve seen a lot of activity from customers who are, have switched to remote and need help with that.

    Zalman: Yeah, certainly, it was challenging before. I think most companies today have remote workers, anyways, or multiple office locations. With the lockdown with COVID, I think what ended up happening is, for companies who rely on the corporate network itself as the perimeter within the building, that perimeter is now gone, and so, what do you do? If you’re using something that’s IP-based, all of a sudden, your IP surface area went from, like, two to 5,000 if you’re an enterprise.

    So, we certainly saw a doubling down of existing customers and an increase in interest in the product. I might ask Steve, like, could you have imagined what—I mean, what was it, like, you guys have an office in New York…do you guys have remote workers? I don’t—yeah.

    Flinchbaugh: Yeah, so, we have an office in New York and we recently—that’s our headquarters—and we recently acquired some office space down in Durham, North Carolina. That’s kind of our first official outpost, and that was kind of our introduction to people outside of New York, and it was—this was after we had adopted strongDM, and I have to say, it was entirely seamless. And ever since the pandemic began, I know it’s good because I haven’t thought about it that much. strongDM is—

    Shimel: That is always the sign. You know what—sorry—I was in security for 20 years. They didn’t call it cyber then, it was InfoSec, but we always used to say, “If they didn’t think about it and it didn’t hit anyone’s radar screen that they—you know, that was a good thing.” When people hear about security stuff, it’s because something bad happened.

    But I wanna make a point here, though, and that is—Steve, it’s my understanding you guys didn’t, you’re not a Johnny come lately to strongDM. You guys were using this well before COVID and the present situation. Talk to us—let’s go back in time to then, it was about a year and a half ago, right?

    Flinchbaugh: Yeah. And actually, if you don’t mind, I’d like to go even further back in time, about four years ago—

    Shimel: Be my guest.

    Flinchbaugh: – when I joined Kustomer.

    Shimel: Okay.

    Zalman: You joined it four years ago?

    Flinchbaugh: Four years in September.

    Zalman: Wow! How big were you then?

    Flinchbaugh: I was, I think, employee number 16. We were still in stealth mode, we weren’t charging our customers yet, and Steve comes into Kustomer bright-eyed and bushy-tailed. But at this time, we were running agents on our servers to provide SSH access to our engineers, and I was charged by the CTO to stand up a VPN, which I had never done. And this came in the form of open VPN, and I had to manage the certificates and the log-in and the users and every employee that joined the company, I had to on board them and configure a profile.

    And then, fast forward to, I think it was about a year ago, where the CTO again came to us and said, “Hey, there’s a really cool company that I think we should take a look at. We have a mutual investor, and they have a lot of cool features that we haven’t had for the past three years.” So, we had a couple really cool meetings with Liz and her team. I could immediately tell that we were working with a team that knew what they were talking about, they were technical, they were fun to work with and they kind of just got what we needed out of the tool.

    And now, today, there are so many things that are taken off of my plate in addition to more features for security and making developers’ lives easier that strongDM now gives us.

    Shimel: Very cool, very cool. Alright, now, we can fast forward to Durham and how strongDM helped with the rollout there of a new—I don’t wanna call it a remote office, but I think you used the term outpost?

    Flinchbaugh: Yeah, so, it’s definitely, like, our—we call it HQ2, I believe, but we’ve got a fully functioning, we call it squad, so we kinda have self-sufficient and cross-functional teams out there, and everywhere across the country, but Durham was our first remote squad, if you will.

    And the neat thing about strongDM is, I don’t necessarily have to say when a new user joins, when someone joins the company, there’s not necessarily a task in my to-do list. It’s so self-service with our Okta configuration, a user can go in and say, “Hey, I wanna start using strongDM, I’ve heard all about it. How do I get access to our data storage and our private resources?” And at that point, I get an e-mail, I can add them to a roll, to a group, and they’re happily on their way. So, I don’t need to configure a profile, I don’t need to do anything special for these individuals. So, from my perspective, it’s incredibly easy to onboard new and remote folks.

    Shimel: That sounds like too good to be true. Is it true, Steve?

    Flinchbaugh: [Laughter] It does feel too good to be true sometimes.

    Shimel: Okay, and you’re saying you guys use Okta for a lot of your IAM and stuff like that?

    Flinchbaugh: Yeah, part of our maturation as a company, you know, back in the day, we had, of course, authentication and identity all over the place and now it’s much more unified. All of our tools that can integrate with Okta, it just makes it that much easier. And again, it’s just things that I don’t have to think about as often

    Shimel: So, Liz, let me throw something back at you. Again, the whole IAM space is something I’m somewhat familiar with—how important is it for strongDM to integrate with an Okta or ADs or other kinda directories and stuff like that

    Zalman: It’s critical. It’s one of the core principles of the business. I think, you know, I’m guessing, Steve, the customer made the decision to buy Okta well before strongDM.

    Flinchbaugh: I think it might have actually been around the same time—but yes, I think Okta was shortly before strongDM

    Zalman: Yeah, so, you have to start with the question of, “What is my identity store? What controls identity, and then how do I integrate that identity store with everything else?” So, strong has integrations with all of the SSOs—because I don’t want to reinvent the wheel. Steve’s already invested a bunch of money in Okta. He’s already reinvested a whole bunch of money in whatever he’s using for automation, Terraform or otherwise or an Amazon tool. Most companies have already invested a whole bunch of money in Splunk or Sumo Logic or QRadar, whatever they’re using for logging, I don’t need to reinvent the wheel with logging and alerting, I just need to make sure there’s a connector between the two.

    And so, honoring what people have already invested a whole bunch of money in and sort of bet the farm on already is critical.

    Shimel: Yeah, you know, Steve, you’re an SRE, so you live this every day. But it’s something—I’m an observer now. My days of those battles are over, right? But as an observer, it’s still, I shake my head sometimes, because so many companies like Kustomer, right, have kinda made their bets on the tools that they use, right? They’ve put together an identity in access management, but it’s not log management, cloud platforms—you know, your whole tool set. But yet, there are still plenty of companies who are trying to say, “No, no—you should use us for everything, right? We can sort of do what strongDM does.” You know, and you know the old saying with this, right? They try to give you 80% of the functionality for 40% of the price, and if that’s good enough for you, it’s good enough, right?

    And I was never a fan of that model—Liz, you’re laughing; what do you think? I mean, we see this still, and I don’t—you know, I assume some companies go for that, you know? But I can’t imagine it really works out. You just don’t get the function—we live in a great time where there’s so much available to us to try to make lives easier for people like Steve, for the SREs of the world and the Ops folks. You know, why would you try to just shove everything into one vendor and do, and put up with less than.

    Steve, what do you think?

    Flinchbaugh: So, it’s definitely, when you’re a smaller company, it’s, of course, much easier to adopt and drop and try new technologies and vendors. But, of course, as we’ve grown, that cost becomes higher and higher. So, when I first joined Kustomer, we could try new things whenever we wanted, but I can already see in the couple years that I’ve been with the company that implementing something like strongDM would be almost exponentionally more effort now, because I’d have to go through different departments and accounting and finance and communicate with the team, and developers just wanna know, “How do I do my job? Like, just tell me what to do.”

    Shimel: Mm-hmm.

    Flinchbaugh: And more than the functionality and the features of the product, I truly feel like we have a relationship with the strongDM team, and that’s almost just as important to us. We know that they are responsive, that they’re gonna listen to us, that they’re gonna help us out—and they have, you know, literally weekly.

    And that is so important to us as customers that, if someone came along and said, “Hey, we’ll charge you 50% of the price that strongDM does,” I don’t think I would be too tempted to consider that right away.

    Shimel: Yeah. But I think that goes to the model today, right? It’s part of this whole cloud native, open source, freemium core, open core, whatever you wanna call it, which is—the key is not to go hire some enterprise sales guy who comes by and wines and dines people. It’s about—hey, here’s the product. Let me get the product in your hands, right? Let me deliver delight, as they say, right, with that product, and the bonds that are formed from that type of relationship, right, it’s—if you wanna call it DevRel, you know, a lot of people call it developer relations and community relations—those sort of bonds are much stronger than the old sort of sales game that I grew up in, for instance.

    Elizabeth, with what Steve is saying, is that sorta news to you that it’s much easier to get in and kinda grow with these customers than it is to kinda come in when they’ve reached a certain scale and it’s a lot harder to get adoptions done

    Zalman: Certainly, it’s easier when a company is young—50, 100, 150, even 200—to get implemented. I think to Steve’s point, eventually,  you have a procurement department, and then you have to go through the traditional, like, “Oh, that’s the price? Okay, we’re gonna knock it down by 50% now,” right, and that’s just how the operate.

    Shimel: Right, yeah. Mm-hmm

    Zalman: And certainly, there are much longer sales cycles in the enterprise side, with a company of Kustomer’s size. Even the size today, you know, two week POC and you can play with it enough, to your point, Alan, where you decide if it’s right for you, if it fits enough of your requirements.

    With larger enterprises, it’s—and again, to Steve’s point, it’s not…you do have to go team by team, right, at a larger enterprise and say, “Okay, we’re gonna do the finance team now, and then we’re gonna do the engineering team, and then we’re gonna do the DevOps team.” And it’s sort of rinse and repeat and you get the hang of it after a while, but it’s bite sized chunks, always, whether the bite sized chunk is the entire company at once, or work group by work group.

    Shimel: Yeah. And I think that very much mimics the whole DevOps adoption pattern as well, right? You don’t go in and just turn on a large enterprise to DevOps, you do it bubble by bubble, team by team, right? And quite frankly, the other thing is, though, is I will tell you that sometimes that procurement process and all the b.s. that goes with it is why developers or DevOps people will whip out a credit card and just do it, right? And you get the whole shadow IT thing or whatever you wanna call it, but it’s like, who wants to—you know, I gotta sit and explain to this person why strongDM makes my life easier? You know, I mean, it’s—especially someone who has no technical background, it’s like, you know, where do I begin?

    But, you know, nevertheless, you guys got a year and a half of history here. Steve, where do you see the first squad’s in Durham, I assume that means you guys are planning second and third squads and maybe outside the U.S. and what have you—is strongDM tied, I imagine, tied into that as the roll out moves along here

    Flinchbaugh: Yeah, of course. It’s become the way that we access our resources across all of engineering. And we actually acquired a Spanish company, Reply.AI, a month back.

    Shimel: Oh, very cool.

    Flinchbaugh: Yeah, so—

    Zalman: Congratulations

    Flinchbaugh: Thank you. So, I’ve been having some conversations with the Reply engineers, and I can already tell that they’re impressed with how we use strongDM and how it kind of fits into our development workflow. And so, that would be interesting, because they have infrastructure of their own, infrastructure that we haven’t used before, so it would be a cool opportunity to say, “How does this plug into strongDM?” And I really have no concerns that that would be the case, but it’s gonna be a fun task to get all of that in the same kind of workflow that all of our Kustomer engineers use today.

    Shimel: Excellent. When you say Spanish, like in Spain—they’re based in Spain?

    Flinchbaugh: Yeah, they’re based in Madrid. I believe they’re a fully remote company, though, throughout Spain. So, they kinda have that remote culture, already, so it’s perfect for us right now, and of course, their AI expertise is nice to have, as well.

    Shimel: Absolutely.

    Zalman: Steve, where is their infrastructure? Like, is it in the U.S. in AWS or is it in something sitting in Europe?

    Flinchbaugh: I can’t say too definitively, but I do know that they have a mix of AWS and Heroku right now.

    Zalman: Interesting.

    Shimel: Really?

    Zalman: So, you’ve got a distributed team in Europe and now, effectively, multiple data centers if you’re talking AWS and Heroku that aren’t merged with Kustomer as well—

    Flinchbaugh: Yes, indeed.

    Zalman: Yeah, I see.

    Flinchbaugh: That’s right.

    Shimel: Sounds like an opportunity, Liz. [Laughter] Liz, let me ask you a question—how many, I mean, what I’ve always loved about the Internet is, it knows no borders, frankly, right? I remember the first time I put up websites and I started seeing hits come in from around the world. This is, like, 1996, and I was like, “Wow, we’re global!” Not at Media—you know, not this company, obviously.

    But what is the customer mix at strongDM? Is it international or is it mostly U.S., or—if you know?

    Zalman: Yeah, it’s heavily international. We’ve got, actually, a big contingent in Australia, we have Europe, we have Asia. Our large enterprise customers all have offices in India, whether they’re using contractors as a work force or an actual office there, you’ve got the U.S., you’ve got Canada, you’ve got South America.

    Oh, and you know what? Actually, I was just gonna say we’re not in Africa—we’re totally in Africa, so it’s everywhere. And then even, we’re not in the Middle East, I don’t think. But even more interesting, I think, than where the people are, it’s where the data centers are. You’ve got this crazy Cartesian product of people trying to connect to stuff, and most companies—we’re in China, I mean, we’ve got people on, we have workers on factory floors in China who need to SSH into infrastructure.

    Shimel: Very cool.

    Zalman: And so, it’s crazy to think about all of the networking going on, the latency, and how to make that connect, and it’s just personally fascinating to hear the new use cases that come up. I was like, when I heard factory, I was like, “Wow!” And then I started thinking of, like, Tesla. I was like, “I wanna be on the factory of Tesla,” but no.

    Shimel: Yeah. That could be in China, too. You know, it’s funny you bring it up, I actually interviewed a CEO of a company maybe last week who, they are instrumenting manufacturing factories, because a lot of that machinery was not connected that you can, you know, you had visibility, and they actually put things on to machinery that allow you to instrument them and monitor and stuff. There’s amazing things going on. And by the way, each one of those add-ons to the manufacturing machines has to have a certificate, an identity—you know, there’s a whole piece of this, too, and I just think it continues to go on.

    Steve, we don’t have a lot of time left. How has the COVID thing kinda affected you guys?

    Flinchbaugh: So, personally, I feel incredibly fortunate to say that my work has changed almost not at all. I think my position and a lot of our department is very remote friendly, and even though we weren’t set up, really at all, for remote before the pandemic, the transition has been relatively seamless—obviously, from a strongDM perspective, it is seamless.

    But overall as a company, I think—of course, there’s a ton of adjustments with different departments and some are having it easier than others. But I actually think engineering is, our efficiency and output and how we’ve put out features since the beginning of this has actually increased just a little bit.

    Shimel: That’s great to hear, man. Really good. Guys, we’re about out of time. I want to thank both of you—both of you coming at us from New York, today, I should mention, so thanks for joining us. Liz, any last thoughts, comments you want to add?

    Zalman: Nope, I don’t think so. I wanted to say thanks to Steve, and I appreciate the comment on relationship. It’s so important, as I say—you know, at strongDM, everybody touches the customer equally. It doesn’t matter if you’re in account management or support or engineering that I joke that if we were to ever have commissions at the company, which we don’t, I would give support the commissions, because they’re that important.

    Flinchbaugh: As a support company, somewhat as an employee there, I can very much appreciate your support team as well, Liz, and it’s not an exaggeration to say it’s the best support that I’ve received from any vendor, ever.

    Shimel: Very cool, very cool. That’s a good way to end it. Alright, Elizabeth Zalman, CEO, strongDM; Steve Flinchbaugh, SRE at Kustomer with a K—thanks for joining us on TechStrong TV. This is Alan Shimel. We’ll be right back with our next guest.

  • TechStrong TV: How strongDM Helps mParticle in Secure Remote Access

    TechStrong TV: How strongDM Helps mParticle in Secure Remote Access

    In this interview for TechStrong TV, I am joined by strongDM CEO Elizabeth Zalman and mParticle CISO Dave Anderson. Dave shares with us how mParticle uses strongDM proxy services to rapidly enable the expanding mParticle team to access infrastructure, assets and applications necessary for mParticle to fulfill its mission to its customers.

    With the rapid growth of mParticle, the company needed a solution that would allow it to onboard its new employees and locations seamlessly. strongDM gives mParticle this capability. Have a watch of the video and follow along with the transcript to find out more.

     

    Transcript

    Alan Shimel: Hey, everyone—back here for another segment on TechStrong TV. I am joined once again by my friend Liz Zalman at strongDM. Hey, Liz, how are you?

    Elizabeth Zalman: Hi, Alan. I’m well, thank you.

    Shimel: Good to have you back on. And joining Liz and I today, another guest, is Dave Anderson. Dave is the CISO at mParticle. Hey, Dave—welcome to TechStrong TV.

    Dave Anderson: How’s it going?

    Shimel: Going great. Not as great as you are. Dave’s coming at us from a sailboat today and we’re all stuck in our homes and offices, but hey, the life of a CISO—and you guys complain.

    Anderson: [Laughter]

    Shimel: Anyway. You know what, we—yeah, I don’t know, it’s hard to make that less glamorous, Dave, but we’ll give you the pass. Liz, for those who haven’t seen some of our previous interviews with you and the strongDM team and some of the customers, why don’t we start off, give our audience a quick background, who’s strongDM, what you guys do?

    Zalman: Sure. Strong is a proxy and it lets people manage and audit access to any firewalled infrastructure—servers, databases, Kubernetes clusters, RDP, firewalled web apps, HTTP endpoints. So, essentially, instead of managing keys and creds, you give people access to strong, and then it talks to the target systems on your behalf, so you get access control and then auditing through the proxy itself.

    Shimel: Everything you expect from your proxy—great.

    Zalman: [Laughter]

    Shimel: And it’s sort of proxy as a service, if you will, yeah?

    Zalman: Yeah, there’s a portion of it that is hosted, the control plan itself, and then the rest goes through your own hardware.

    Shimel: Got it. And Dave—

    Zalman: Or whatever your virtual hardware is these days.

    Shimel: Well, yeah—no one uses hardware. Through your own infrastructure, how’s that?

    Dave, talk to us about mParticle.

    Anderson: Yeah, so, mParticle is a customer data platform. So, what that means is, our customers are able to use our platform to ingest pretty much anything, any data about their customers, about the activity that’s going on on their websites and mobile apps into the mParticle platform, and then we’re able to give our customers the full control of being able to fan that out to any of our different integration partners. So, there’s that, as well as being able to do things like data quality, match identity resolution, figure out where a particular user is, what sort of ways you want—like, how they’re interacting with their particular application or whatnot.

    To be honest, we have customers, like, in a bunch of different verticals, and they all use the product a little differently, and it’s—we’re continuing to grow and innovate and figure out different ways of kind of helping our customers along with their data journey.

    Shimel: Excellent. And, you know, that kinda mission is just so attuned with what I think companies are looking for today, right, which is—you know, there’s so much data out there. There’s so much—you know, do you want it all, what are you gonna do with it all, what makes sense, what doesn’t make sense? But the idea of being able to access that, analyze it—hopefully, with as much automation as possible—is what it’s all about.

    Of course, it also creates—as a CISO, you know this—it creates tremendous responsibilities and potential pitfalls from a security, data, access, compliance point of view. But it also, you know, to the strongDM mission of proxying through firewall to assets, whether those assets are remote workers who have to access, you know, data in the cloud or on-prem or wherever or just whether they’re remote or not, access incorporate assets, which, in your case are, in some cases, I’m gonna assume, a lot of PII kind of data.

    data
    Dave Anderson, mParticle

    Anderson: Exactly.

    Shimel: This is a potential security nightmare. This is what keeps CISOs up at night on their boats. So, talk to us, Dave, what is—you know, how does strongDM help you sleep better?

    Anderson: So, naturally, we’re a data collection—data collection and distribution company. So, we have a lot of data, a lot of data split up into a lot of different databases, and we have to have very tight access controls for those databases. So, one of the things that strongDM gives us the capability of doing for—when any sort of support people or operations people need access to a particular database or data set within the kinda mParticle back-end, we’re able to utilize strongDM to give us the ability to have secure access to that, that is able to be tied back to the individual who’s doing the work, everything is audited, everything’s logged, we’re able to generate reports for compliance.

    So, it gives us the capabilities of not having to give our, like a support person, for example, give them a direct access to the database. They have, like, a nice tool they can use, everything is integrated nicely on the desktop, and everything is integrated well with all of our identity management platforms as well.

    Shimel: Excellent, excellent. So, Dave, I think we—you know, we get what you’re doing there, we get what the potential risk is. And we’ve done a few interviews—in full disclosure, we’ve done a few interviews with some of the strongDM clients in fintech and other verticals. What we haven’t done is kinda peeled back what was—I mean, using a proxy, I think a lot of our audience has probably used a proxy one way or another.

    But I want to peel back now, in the case of mParticle, walk us through how you guys sort of say, “Okay, we’re gonna use strongDM.” How did you set it up? How did you deploy? How do you manage it, right? How does it give you the warm fuzzy feeling you need to know that you can sleep well at night?

    Anderson: Well, to be perfectly transparent, I was—I’m pretty new at mParticle, so, I wasn’t here when—

    Shimel: So, you inherited it?

    Anderson: Yeah, so, I inherited it. But I actually am a pretty early strongDM customer from my last job at Greenhouse Software, and so, I’m very familiar with that aspect of it. We used it for similar purposes back then. Back at Greenhouse, we had a lot of support personnel that were—and kinda data quality engineers that were using the strongDM platform to access our databases within AWS. And similar here, we want to have—we try to keep as much, the access as restricted as possible. We believe in the principle to release privilege, and separation of duties.

    Shimel: Sure.

    Anderson: So, with that, we need to have our networks deeply, deeply isolated. The databases live kinda deep into the network, not even having access to the outside world. And with that, the only way to give somebody in support access to that database traditionally would have been giving them VPN into that environment and then them having to actually install the different tools and having to manage authentication and access control. And even then, what would happen is, we would also lose visibility into what they did on that database. Like, what queries did they run, what data did they see? Because it’s not even necessarily a kinda everyday type of thing for someone to have access to the data itself. We tightly, tightly control who has access to what data, and using a tool like strongDM is pretty much a requirement for that.

    Shimel: Yeah. I mean, look—and I’ll try to put it in layman’s terms for our audience who maybe aren’t as familiar with this stuff. When you’re using a VPN, they call it a tunnel, right, a tunneling tool. Because really, what you’re doing is, you’re punching a tunnel through, whether it’s your firewall in your infrastructure, and it’s an encrypted tunnel at that, right? So, everything that takes place within that tunnel is encrypted.

    And so, when I connected to a database via a VPN, you may see that I did connect—oh, yeah, that’s Alan’s client and he connected to the database. But in terms of what data was in that tunnel and what—you know, you really don’t, you don’t have visibility there, by its very definition, right? On purpose. It’s not a byproduct, that’s how it’s supposed to be. And you don’t—you know, you can…it’s just, that’s how it was designed.

    And so, that doesn’t really play well, you know, in the areas of DLP and you wanna make sure data’s not ________, you know, taken out. It’s a problem. So, now, strongDM helps you solve that, is what you’re telling me, because now we can see, you know, it’s a proxy, but on the backside of the proxy, that goes into the firewall and into the trusted network as we used to call it 100 years ago when I was in security, right? When you go through that into the trusted network, you can still see where Liz went or Alan went or Dave went, because it’s not that tunneled, right? It’s not that encrypted tunnel through there, it’s more of the proxy. I remember when we were NAT-ing firewalls, right, a long time ago, and it was that same thing—at least I could match up this IP to that IP, the behind the firewall versus the public IP, you know, private IP, public IP. And so, you had some of that then.

    Then, on top of it—look, giving people a VPN, with everything going on in COVID and remote workers, you know, and all we’re hitting, and of course they’re not just hitting your database, there’s also SaaS apps that they need to hit and everything. A VPN is—I’m not a big fan of VPNs in today’s world, if you can’t tell, okay? I just—it don’t make sense. I mean, and then, and the whole idea of VPN-ing back into a central kinda office to go back into the cloud also kinda, I mean… You know, a friend of mine, I know a guy named Jay Chaudhry who is, of course, the CEO and Founder of Zscaler—he used to rail from the very time the cloud-first started coming on the scene big, 2006-’07, he was saying back then that VPNs were, you know, the time has come, but here we are, 2020—same thing.

    But, Dave, how easy was it to set up the strongDM proxy, and what kind of visibility is it giving you?

    Anderson: I mean, setting up strongDM is really easy. There’s a couple of pieces of infrastructure that you put into your environment, and that would all depend on how you deploy your infrastructure. So, there’s—I’m trying to remember the exact terminology. Like, a gateway and a—what was that?

    Shimel: Liz, can you help him here?

    Anderson: Yeah.

    Zalman: What?

    Shimel: Can you help him out, here?

    Zalman: I ________. I would never leave my friend hanging—never. [Cross talk]

    Anderson: [Laughter] Yeah, so, you deploy that infrastructure that, basically, that sits in your network and you have, and then it talks back to the strongDM portal and so, the strongDM clients actually know who to talk to, like, what IP addresses and what databases it has access to. You go through the strongDM UI or you can use their API, depending on your preference to set up different databases and set up the credentials in there and all the users and what users have access to what databases and what roles within those databases they have access to. And then there’s a client that runs on the person’s laptop, and that client, they’re like, you’re talking locally to that client and it’s magically on the strongDM back end, like, routing everything around to the right place and makes it extremely streamlined for the end user, because they just have this little control panel down there, like, in the bottom of their screen that lets them connect to the particular database, and it’s really, really ridiculously easy to use.

    Shimel: Very cool. Now, as part of the role in CISO, you’ve always gotta be thinking not if, but when we have an incident, right? I’ve gotta be able to do forensics, I’ve gotta have an audit trail, right, I’ve gotta be able to figure out, what the heck—I have to show people what happened here, did we take reasonable steps, right, and stuff like that.

    What is it, in terms of audit trail and forensics, how does strongDM help you there?

    Anderson: So, it shows us who connected to what resource when, how long they were connected, what they did, what sort of careers they were in, what sort of other kinda SQL comments or whatever the database may be, and be able to produce that in near real-time, as well as have logs to go back to if there was an incident that we would know what data was accessed by a particular individual.

    Shimel: So, that’s kinda the control plane that sits in the cloud, Liz, or that’s local to the client?

    Zalman: The auditing happens through the gateway. So, when the request hits the gateway, it actually deconstructs it in order to provide the audit trail—so, that stays resident in Dave’s network, yeah.

    Shimel: Excellent. So, we don’t have to worry about access to strangers to that.

    Zalman: Yeah, no, it’s his data. We don’t wanna touch it. [Laughter]

    Anderson: Yeah, that’s one of the most attractive things, actually, was the fact that the data stays in our network. strongDM operates the, how things actually get connected, but as far as, like, once you’re in that network, it’s, everything stays within there.

    Zalman: Cool. Alright, sounds great. Dave, one other question. With COVID and everybody working remote, I know—look, I mean, strongDM, from what I’ve seen, has built a…not built, but while there are plenty of people, obviously, suffering as a result of COVID and my heart goes out, I’m sure as you guys, too, to people who have lost loved ones and are sick and have lost jobs and money and all of the bad things that are happening with this. The fact is, you know, with remote workers being more and more common, solutions like a strongDM are thriving, right? Are being rapidly adopted. Not because they’re nice to have, because you gotta have something like that, right? So, I’m wondering, what are you guys seeing at mParticle and a similar kind of thing as you’re going remote?

    Anderson: Yeah. I mean, thankfully, we were really well-equipped for going remote. A lot of the engineering team is distributed to begin with. We had people in Seattle, Florida, Texas, and New York, of course. But we were able to transition to it pretty seamlessly. We just spend a lot more time on Zoom.

    Shimel: Don’t we all?

    Anderson: Yeah. [Laughter] Yes, but having the technology in place for being able to securely connect to remote networks, remote resources is definitely, it’s a requirement nowadays. I mean, especially with—you can’t, you don’t have a perimeter anymore. There isn’t that network, the whole concept of having that network firewall that was sitting there and protecting everything is kinda dead now, especially with, since everybody’s working from home. I mean, and VPNs, as we were talking about before, only give you so much. There’s only so much flexibility you have with how you can protect your network and segment your network to make a VPN be as flexible as a platform like strongDM.

    Shimel: Look, I thought network firewalls were dead in 2007, right? I remember the first time I saw a Jericho—I don’t know if you remember this, Dave, but do you remember the Jericho project? Did you ever hear of that? That, you know, they were the first ones to talk about the de-perimeterization of security and micro-perimeters and personal perimeter and all that stuff. That whole moat and castle setup that the network firewall played in and the VPN was sort of a bastardized child of, you know, that disappeared when we got mobile devices and people started going mobile. Sounds like a Who song—“Going mobile, mobile”—anyway. But yeah, I don’t disagree with you.

    Liz, let me ask you. I mean, mParticle, is this sort of the—it seems like it’s right in the sweet spot for what you guys are doing, then, right? This is the mission.

    Zalman: This is the mission, yeah, and it’s, and actually, Dave, shifting from—I mean, what do you call Greenhouse, ATS?

    Anderson: Yeah.

    Zalman: It’s a form of data management, actually, shifting into customer data. It’s a vertical that I hold dear, because I actually started my career in ad tech, and what he’s describing is what I wanted a decade ago. So, like, I personally love the fact that mParticle is a customer. [Laughter] There is simply no place to store that stuff and then to link it across various touchpoints—it never came to fruition.

    But yeah, a company that is distributed, that isn’t hyper-growth, it has large corporate clients who have, I’m guessing—Dave, tell me if I’m wrong—contractual requirements with respect to security and pen testing in various attestations.

    Anderson: Of course, yeah.

    Zalman: Yeah. [Laughter] Yeah, we do a good business in that area, and it hits all those things.

    Shimel: Very cool. Guys, we’re about out of time. Dave, I appreciate you taking time out of your busy day on the boat to join us here. [Laughter] All kidding aside, man, it actually is a very great socially distanced way to get work done.

    Anderson: Yeah.

    Shimel: Truth be told, I’m supposed to be on a boat tomorrow and I canceled, because I had some stuff come up, and [Cross talk].

    Zalman: Alan, it’s not that strongDM helps Dave sleep better at night, it’s those waves in the harbor, too. [Laughter]

    Anderson: [Laughter]

    Shimel: Yeah, well, that—right, they’ll help you sleep, either way. They’ll help you sleep well, as well.

    Anderson: Yeah.

    Shimel: I’m not gonna go there, though, Liz. You know, leave Dave alone.

    Anderson: It’s also my alarm clock in the morning. [Laughter]

    Zalman: [Laughter]

    Shimel: Yeah, that’s exactly it. You know what, alright, the guy’s on a boat, there’s worse things. It doesn’t make him a spoiled person. I don’t wanna get—you know what, but for all those people who say CISOs are underworked and overpaid, as Dave’s living here on the boat, that’s not true. CISOs are overworked and underpaid.

    But anyway—Liz, thanks for joining us.

    Zalman: Thanks, Alan.

    Shimel: We’ll hopefully have another interview with you soon, maybe.

    Zalman: I think we have one on Friday.

    Shimel: Very cool. Dave, thank you for joining us—great, continued success with mParticle. Sounds like a great business and a great use case here for strongDM, and enjoy—enjoy your time. Stay safe and stay well.

    Zalman: Thank you for having me.

    Shimel: Thank you. Hey, this is Alan Shimel. You just watched another TechStrong TV segment. We’re gonna be right back with another guest.

  • Fortanix Adds Platform to Manage Confidential Computing on Azure

    Fortanix Adds Platform to Manage Confidential Computing on Azure

    Fortanix today announced that a software-as-a-service (SaaS) platform for managing instances of confidential computing on the Microsoft Azure cloud is now generally available.

    Confidential computing is an emerging approach to encrypting data while it is running in memory. Today encryption is only applied to data at rest. Confidential computing makes it possible to set up secure enclaves for processing encrypted data in memory, which has become an increased source of concern for vulnerabilities in IT environments.

    Faiyaz Shahpurwala, chief product and strategy officer for Fortanix, said Confidential Computing Enclave Manager provides IT teams with a SaaS platform that enables them to provision a confidential computing environment, verify the integrity of those environments and manage the application life cycle for secure enclaves. Applications running on secure enclaves are built using Docker containers and images.

    Fortanix, along with Alibaba, Arm, Baidu, Google Cloud, Huawei, Intel, Microsoft, Red Hat, Swisscom and VMware, is a member of the Confidential Computing Consortium, an arm of The Linux Foundation. Confidential Computing Consortium projects include a Software Guard Extensions (SGX) software development kit (SDK) from Intel, an open source Open Enclave framework that allows developers to build Trusted Execution Environment (TEE) applications using a single enclaving abstraction, and Enarx, a project providing hardware independence for securing applications using TEEs.

    Microsoft earlier this month made available a DCsv2-series of virtual machines (VMs) that provide access to a TEE based on Intel SGX. Fortanix, for its part, already makes available a Fortanix Self-Defending Key Management Service on Azure.

    Shahpurwala said over time most applications will take advantage of trusted computing environments. Most of the initial use cases will focus on applications in which data privacy and securing personally identifiable information (PII) is critically important, he said.

    In the meantime, cloud service providers are racing to make available platforms for building and deploying TEE applications. Less clear is to what degree those environments will be integrated with DevOps platforms. The Confidential Computing Enclave Manager provides a management framework from which to begin that process. The Confidential Computing Enclave Manager also provides tools to convert applications to enable them to run on Intel SGX.

    There may come a day when confidential computing makes security a core element of any DevOps process. As such, the idea that there needs to be a distinct approach to DevSecOps may in time fade away as security becomes a series of infrastructure capabilities that are invoked programmatically. As that approach matures, application security would simultaneously evolve to become a natural extension of any quality assurance process.

    Of course, it may be a while before confidential computing is employed pervasively. Not every IT team has made the switch to containers to build applications. However, given all the focus these days on data privacy regulations it’s clear the requirements for protecting data within an IT environment are becoming more stringent with each passing day. The challenge now is finding a way to address those concerns during the entire application lifecycle management process in a way that doesn’t slow down the rate at which applications are being built and deployed.

  • 3 Ways DevOps Can Increase the Value of Organizational Data

    3 Ways DevOps Can Increase the Value of Organizational Data

    There’s a reason the term “data mining” came into existence. Enterprises sit on a vast resource of information—millions of digital gems that, if fully extracted, can not only answer many of their toughest questions, but also help them meet their most ambitious organizational goals.

    DevOps professionals have a unique opportunity to impact this mining process. Their vision can transform the way their organizations utilize data by building fresh capabilities and strategies into the applications and platforms they create. Yet, recent advancements in data science, particularly the use of parallel processing platforms that interrogate massive datasets in near-real time, are changing the game as well. 

    Time-to-Insight Is Shrinking

    Parallel processing improves analytics along two important paths.

    First is the time requirement. When organizations are able to process billions of rows of data in milliseconds, it changes the value of that data. In many industries—financial services, for example—there is a big difference between a query that is answered in seconds or minutes, versus one that is answered in a fraction of a second. Those small deltas in time can make a big difference in the bottom line. As they say, time is money.

    The other path is the curiosity factor. In conventional analytics, the paradigm is to ask a question and get an answer. But if the user can ask one question, get the answer and then ask three more questions based on that result, without concern for a time penalty, it creates an opportunity to be more curious. This is a pain point that is underappreciated and largely overlooked in most organizations. Without speed and agility, decisionmakers can end up in a rut, asking the same questions over and over again because the time/value equation never improves.

    When queries only take milliseconds to answer, it’s easy to ask new questions, dig deeper into data and look at problems in entirely new ways. DevOps has the ability to leverage the potential of parallel processing to empower their organizations and significantly raise the value of data.

    Here are three of the more prominent ways.

    Use Multiple Processors to Scale Processes

    A central data repository facilitates analytics throughout the organization, especially for enterprises that make heavy use of business intelligence (BI). While a centralized location is advantageous, it also places huge demands on DevOps to deliver adequate performance.

    Parallel processing can support this approach, even in mixed GPU/CPU environments. Parallelized code allows a processor to compute multiple data items simultaneously. This is necessary to achieve optimal performance on GPUs, which contain thousands of execution units. However, optimizing hybrid execution also translates well to CPUs, which increasingly have wide execution units capable of processing multiple data items at once. Parallelized computation can improve query performance in CPU-only systems as well.

    Accelerated analytics platforms allow single queries to span more than one physical host when data is too large to fit on a single machine. Such platforms can scale up to tens, even hundreds of billions of rows on a single node and can also run across multiple nodes. Load times improve linearly with the number of nodes because loading can be done concurrently.

    Connect Data Silos for Deeper Understanding

    New insights arise when questions are asked not simply within one silo or another, but at the place where those silos intersect and relate to each other. No longer do decision makers have to look under one rock and then move on to five other rocks; instead they can treat their organization’s data stores as one complete, interconnected resource.

    The advantages of connected silos don’t stop there. Using accelerated analytics, it’s possible to combine internal datasets with external sources. Analysts may want to review the impact of demographic shifts on retail performance, for instance, or of weather on public safety.

    Use Advanced Analytics to Tighten Datacenter Security

    No one has to tell developers that cybersecurity is essential. Yet, the difficulty often lies in staying on top of the challenge—log files, for instance, can grow to billions of rows of data every day.

    The ability to pull security data into an accelerated analytics environment provides instant insight into data center security. Dashboards that incorporate such capabilities allow staff to interrogate log files and other security datasets in near-real time. Furthermore, spatiotemporal analysis—the ability to combine and analyze time and location data—is becoming increasingly valuable for intrusion forensics. When professionals understand what region of the world an attack is coming from, it becomes that much easier to minimize or stop altogether.

    Giving Data a Second Look

    Despite the incredible rise in big data, organizations don’t always turn to their repositories to answer their hardest questions. They assume the platforms they have, or the data they possess, are too unwieldy, slow or difficult to leverage.

    Organizations need to go back to the era in which there was confidence in the ability of data to answer those really hard questions. Too many teams have succumbed to asking only those questions they know data can answer, rather than asking harder questions that more advanced analytics solutions can uncover.

    With the right technologies and processes in place, the questions that seemed to be impossible are no longer insurmountable. The data that resides in the organization is more capable than anyone thinks. All one has to do is have the daring to ask.

  • Six Steps Every Business Should Take to Protect Its Data

    Six Steps Every Business Should Take to Protect Its Data

    Data may or may not be the new oil but it is the growth engine of today’s digital age. Data about a company’s customers, products, services and sales is worth a lot to the company itself, of course, but also to its competitors, as well as to business-savvy hackers. This is why every business, regardless of size, needs to protect its data. 

    Once created, data never really dies, and it is used in multiple ways. In fact, the more data is used for making decisions, the more valuable this asset becomes to you and everybody else.  

    Protecting something of such value requires a different strategy–we need to start from the data itself. This may look complex but here is an easy way of thinking about that process.

    What Data Do You Have?

    Knowing what sensitive data your company is generating and storing sounds like a no-brainer, but many businesses don’t have a good handle on the different types of data they create, copy, use or store. You may not realize, but some of your data might include personally identifiable information (PII), healthcare data and financial data. As you are a custodian of such data, this requires special attention not only to protect your users, but also to satisfy compliance regulations. If you do not know your data, you cannot quantify your risk, and hence cannot prioritize your limited resources and time.

    Where Is Your Data?

    If you don’t know where your data is, you cannot protect it. And many times, even IT staff aren’t exactly sure where sensitive data resides. Your data could be in databases, file systems, applications or archives. For a hacker, these are all ripe targets, not to mention the four, eight or more copies of the same data distributed across less protected test, development, disaster recovery and backup systems. In addition, fragments of your sensitive data often get distributed across dozens of interlinked or even disconnected systems. If that sounds odd, think of your own personal information. Some of those bits may sit in email, Word and Excel, along with text messages, sticky notes and notebooks. Now, extrapolate this to a company of thousands of employees, and recognize that hackers need to get access to only one of those sources.

    Who Has Access?

    It is important to understand who your users are, and what access they have. Many companies give too much access to too many people, and worse, they do not know about how many keys have been distributed across the company, and to whom. Instead, companies should limit access to as little data as possible, and assign rights on a strict “need-to-know” basis. The fewer the people with limited access, the lesser the chance that they copy, share or contaminate that data. Even if a hacker were to take over their account, your loss would be limited.

    Who Touched Your Data?

    Understanding where your data is and who can access it is a great starting point, but you need to monitor actual data access to detect anomalies and unauthorized usage. Given that threats and vulnerabilities are always evolving, you may not be able to stop all of them, but detecting intrusion can allow you to intervene and limit the loss. Companies should audit users who log on to their systems, and track what they are doing, especially if they have administrative access to those systems or have broad access to sensitive data. It’s not that you do not trust them, but blind trust without verification can be exploited—especially by hackers masquerading as them.

    Why Keep Doors Open?

    A bank with broken windows or weak locks on side doors invites intruders. It is critical to lock down your systems by reviewing your configuration settings, patching your systems, closing unused services/ports and locking down critical data. Hackers today have sophisticated automated tools that can quickly scan systems for gaps and vulnerabilities. If they are going to map out your IT systems, don’t you want to scan them and fix them before they come probing? The more exploitable the holes in your system, the faster a hacker’s ROI.

    Why Use Real Data?

    It certainly is easy to test applications against real data, but doing so creates copies of data that your organization was already having trouble protecting. One simple way to reduce risk is to use fake-but-real-looking data for testing and development purposes. This means systematically replacing all occurrences of real social security, credit card numbers, email addresses, financial information and health data with unrelated random data. Using fake data not only limits exposure to the testers and developers, but also mitigates damage should someone gain access to the test system.

    Protecting data isn’t just about setting up the firewall or installing anti-virus software on your endpoints. To most adversaries, these are just speed bumps. Protecting data requires starting from the time of creating data, discovering what you have, knowing where it is stored, enforcing access rights and tracking its usage.

    As custodians of the valuable data that never dies, we need to have a strategy around completing these tasks in a scalable and repeatable manner. Status quo is not an option in an age where breaches are the stuff of near-daily headlines.

    We hope you never become a target of any attacks, but in case you do, understanding your sensitive data and being proactive in protecting it can make the difference between a quick recovery and a drawn-out nightmare.

    — Vipin Samar

  • Achieving Full Disk Encryption and PCI Compliance

    Achieving Full Disk Encryption and PCI Compliance

    Full disk encryption (FDE) is a critical security measure in today’s modern networks. With data security being more critical than ever, many IT admins are wondering how they can enforce full disk encryption across their fleets of cross-platform systems. Many organizations are also subject to compliance regulations including PCI DSS, which require FDE as a part of their compliance requirements.

    What is FDE?

    Full disk encryption locks down a computer’s hard drive when said computer is powered off or at rest. If a computer with FDE enabled is stolen, the only thing the thief will make away with is the hardware; the data on the system will be encrypted and very difficult to acquire.

    FDE programs (BitLocker for Windows, FileVault for Mac) utilize a recovery key as a method of authentication. When a user logs into their FDE-protected system, the drive is unlocked using their associated username and password. But in case a user forgets their password, is locked out or the hard drive needs to be removed and accessed for any reason, an IT admin uses the recovery key to decrypt the drive. Given the crucial nature of recovery keys, IT admins need to store them in escrow; that is, securely stored and categorized in relation to the system it belongs to.

    What is PCI?

    The Payment Card Industry Data Security Standard (PCI DSS) is a compliance regulation that was created to ensure that credit card data is kept secure by companies that handle this critical customer financial information. PCI revolves around securing the cardholder data environment, or CDE, which houses all credit card information that passes through a company under compliance. There are 12 main requirements under PCI regulation, but Requirement 3 deals specifically with data encryption.

    Using FDE for PCI

    At its core, PCI Requirement 3 calls for installing proper security measures to protect data housed in the CDE. It is arguably one of the most important requirements for PCI altogether. FDE is an ideal way to ensure Requirement 3 compliance. By locking down at rest systems, IT admins can prevent unauthorized access due to a stolen laptop or hard drive.

    In regards to encryption, Requirement 3 also demands that cryptographic keys are securely stored and maintained. Using recovery key escrow, IT admins can ensure that only the right people have access to cryptographic keys and also monitor when they’re used for access and who uses them.

    How to Enforce FDE to Achieve PCI Compliance

    When it comes to enforcing FDE across Mac and Windows for PCI compliance, IT admins might find that their options are limited. Many FDE tools on the market are only capable of enforcing either Bitlocker or FileVault—not both. Since many of today’s IT organizations are heterogeneous with regards to system platforms, an FDE solution that can only enforce one or the other simply won’t do and admins would rather not implement multiple solutions to reach the desired end.

    Additionally, IT organizations need their FDE solution to securely store cryptographic recovery keys in escrow. This need limits the list of ideal FDE options even more. At the end of the day, with these requirements, there’s an excellent option that provides IT admins with a low overhead FDE experience suited for PCI compliance. Using JumpCloud’s Policies, IT admins can enforce FDE at scale across their Windows and Mac system fleets, escrowing individual recovery keys safely.

    — Zach DeMeyer

  • Ten Questions Data Professionals Should Be Asking When Moving to the Cloud

    Ten Questions Data Professionals Should Be Asking When Moving to the Cloud

    You have finally decided to move your data into the cloud. Whether it was the ability to leverage the power of cloud compute, the promise of cost-savings or the scalability and flexibility that a cloud data warehouse can bring, it’s important to have a strategy in place. In order to set yourself up for success, here is a list of questions that will help you organize your data and ensure your data migration efforts provide business value.

    What Is the Outcome I Need to Achieve?

    When you are creating a data migration strategy, you need to have an end goal in mind in order to make the best decisions on technology and approach. Simply getting your data into the cloud won’t be enough to take action on that data. 

    How Many Data Sources Do We Currently Have? 

    Once you have your outcome in mind, take a comprehensive inventory of all your data sources before you begin the migration process. It reduces your risk of discovering halfway through the process that you have no access to a data source–or that you forgot to include it in your migration plan. 

    Who Is the Administrator of Each Data Source? 

    It is likely that you may not have access to every single data source that you are looking to migrate. Make sure to find out who can provide you with access to that data, and fully understand your requests. This person will be able to explain the necessary requirements for that data source and will be your contact to help integrate that source into your migration efforts. 

    What Data Is Most Important to My Key Stakeholders, and What Do They Consider Important in Getting that Data? 

    This question might also be: What are the KPIs that drive the business from the data sources? You’ll need to have a good grasp on the metrics that are used for business-critical KPIs so that you have the right data in the cloud to ultimately be transformed for analysis. For example, a retailer might value click-through-rate on emails as a key indicator of attribution for sales data. In order for them to get that information, they would need to provide data from their email marketing system and their eCommerce platform. Keep stakeholders involved in the success and failure criteria of your project so they can help set you up for success. Identify the system of record for the metrics that each KPI is calculated from. Quite often, more than one system in your organization can have a representation for that key metric, but with different values. Align with the related stakeholders as to which is the system of record in those cases. 

    How Can I Show Business Impact Quickly?

    A proof of concept (PoC) in the cloud is always associated with the desire to show results quickly, as the speed and performance that the cloud brings means that you should be able to move faster, right? Asking yourself what you can do to help the business recognize the value of your project can help you assuage any productivity concerns. To create a quick PoC, start by first identifying a small number of typical use cases to test out. Picking a high-value KPI that is calculated from metrics from well known source systems could be a good candidate for that first iteration.

    What Are My Security Concerns?

    Considering that the cloud can house petabytes of data that enterprise companies collect every day, it is safe to assume that some of that information will be sensitive and confidential. Ask yourself if the data you migrate contains personally identifiable information (PII) and if that information is necessary for the project you are working on. In most cases, PII is not needed for analytics work and therefore, you wouldn’t need to migrate that. You might need to know the brand of a credit card to make a data-driven business decision but perhaps not the actual credit card numbers. 

    Who Has Access to My Data Now that It Is in the Cloud?

    If you are migrating sensitive data into the cloud, these are the security and compliance requirements that come into play. How much data security management you entrust to a cloud provider entirely depends on the needs and requirements of your business. There are several different security models, some of which give you more control, some that hand-off that control to cloud providers—it is important to choose the model that works best for your business. Ensure the vendors you use are SOC II compliant and have all the necessary certifications in place to keep your data safe. Work with your organization’s security group on this. They may have defined an overarching Enterprise Cloud Strategy which can help to provide guidance around the acceptable use of cloud resources for your analytics workloads.

    What Do I Do with My Data Once It’s in My Cloud Data Warehouse? 

    Once your data is in the cloud, what do you plan to do with it? Create a strategy to structure your data in the correct way for your business outcome. Different cloud-built technologies can help structure your data for analytics, prepare your data for machine learning or artificial intelligence projects, or perform data cleansing so you have the most accurate data available. It is important to remember that different cloud data warehouses, data integration tools and data visualization products need to complement one another. Make sure you build your stack for your project to ensure success. 

    How Do I Save Costs in the Cloud? 

    In addition to faster time to value, one of the main reasons companies migrate data to the cloud is to save costs. But, how can you ensure you are saving costs while migrating data? You can take advantage of free trials offered by many purpose-built cloud data tools that allow you to allocate, compute and storage as needed. The beauty of a cloud data warehouse is that you don’t need to provision for future workloads. As your needs grow, you can scale up easily and manage costs effectively. Try to avoid using multiple products that do similar things. This will reduce cost, increase adoption of the products and keep your architecture simple.

    Is My Team Equipped to Handle Cloud Migration?

    Cloud data migration is different than on-prem migration and in such, you and your team will be using technology that you haven’t used in the past. To set your team up for success, inquire about their comfortability using the tools you’ve selected and ensure they have the level of access needed to do their jobs efficiently. If there are gaps in knowledge, you can look to provide the training to help them get up to speed and make onboarding as painless as possible.

    If you answer these ten questions, you will be on the right track to begin your cloud data migration project. Keep your business goals in mind and start small—the flexibility of the cloud allows you to scale your project later if needed.

    — Arawan Gajajiva

  • CircleCI Achieves SOC 2 Compliance for DevOps Platform

    CircleCI Achieves SOC 2 Compliance for DevOps Platform

    CircleCI has achieved a SOC 2 compliance rating for the DevOps platform it makes available via a software-as-a-service (SaaS) model.

    Tad Whitaker, security manager at CircleCI, said CircleCI is the first provider of a SaaS platform for DevOps that has invested the hundreds of thousands of dollars required to achieve SOC 2 compliance.

    SOC 2 compliance requires organizations to pass an annual audit based on the Trust Services principles and criteria defined by the American Institute of Certified Public Accountants (AICPA). That criteria evaluate IT environments on everything from the cybersecurity controls they have in place to the integrity of the data management processes employed. A SOC 2-level certification means DevOps teams can have confidence in the fact that their data is being kept completely confidential, said Whitaker.

    With interest in best DevSecOps processes on the rise, Whitaker noted more organizations are starting to ask questions about how data is managed and secured on the cloud services they rely on to build and deploy applications. Cybersecurity professionals who are now participating in those processes are starting to ask challenging questions. To address those concerns, Whitaker said CircleCI created a team within the company to first attain SOC 2 compliance and, now, maintain it.

    That may lead to additional processes and controls being put in place, but DevOps teams can be confident that everything possible is being done to secure their data from prying eyes, including employees of CircleCI.

    A lot of the data being employed to build new applications is among the most sensitive an organization is likely to possess. As organizations embrace DevOps practices to drive digital business transformation initiatives, there’s a much greater need to ensure the DevOps environment is secure end to end. However, most of the DevOps platforms delivered as a service today are not able to validate the level of security they claim to have put in place, said Whitaker.

    It’s unclear how many organizations are going to insist of SOC 2-level certifications before agreeing to develop applications on a specific DevOps platform. However, SOC 2-level certifications are routinely required for cloud service providers so it’s only a matter of time before the same audit requirements are applied to other cloud services. The challenge will come when DevOps teams have to adjust their existing DevOps processes to accommodate the security processes that SOC 2-compliant cloud service providers are required to make.

    In the meantime, the days when DevOps teams could employ cloud services to bypass cybersecurity policies are coming to an end. Cybersecurity teams are finally catching up in terms of figuring out how to enforce cybersecurity policies beyond an on-premises IT environment. Not every DevOps team may appreciate the impact those policies may have on productivity. However, if the alternative is to have sensitive data that DevOps teams are now being held accountable for exposed on the web because of careless processes than the time to come to terms with cybersecurity has finally come.

    — Mike Vizard