Tag: devsecops

  • Strengthen API Security With These Tips and Patterns

    Strengthen API Security With These Tips and Patterns

    If you haven’t noticed, digital organizations are building more and more APIs. ProgrammableWeb tracks more than 23,000 public web APIs at the time of writing, and the API market is estimated to be worth $5.1 billion by 2023. Building with APIs increases internal interoperability, reduces development time and can extend product functionality tremendously. In short, the value of APIs is rising. However, opening up with APIs brings security caveats that, if not addressed, could result in serious breaches that negate these benefits.

    I recently spoke with Roey Eliyahu of Salt Security to get his take on the top security concerns for API-enabled companies, and how organizations can safeguard their services. In short, he recommends thoroughly cataloging and understanding your API inventory, designing for legal challenges and mitigating OWASP’s top 10 API security vulnerabilities.

    Challenges for API Security

    APIs have been called “the next frontier in cybercrime.” Rightly so, as API breaches continue to pop up nearly every day. Take the recent API vulnerabilities at Cisco Systems, Shopify, Facebook, U.S. presidential campaign apps, and GCP as evidence. The most infamous was likely the Equifax breach—not enforcing formats on incoming API calls resulted in a massive data breach, which cost the company a $700 million lawsuit.

    So, why have API breaches increased recently? Well, a few years ago, there were simply fewer APIs. And, these older services exposed less sensitive data. Nowadays, companies typically have many more APIs. Banking applications, for example, might expose hundreds of highly valuable endpoints that are very appealing to hackers.

    Companies also build APIs for different audiences: A 2020 study by SmartBear found 72% of companies develop both internal and external-facing APIs. These APIs could easily hold hundreds of parameters, and with every new method added, a company’s potential attack surface grows considerably.

    3 Steps To Secure APIs

    To mitigate the above API security issues, Eliyahu suggested three main steps: Understand your API inventory, audit against privacy policies and data privacy regulations, and track the most pressing API vulnerabilities like a hawk.

    Know Your API Inventory

    “You need a great inventory of APIs to know your attack surface,” said Eliyahu. Many API providers document their APIs with OpenAPI definitions. But, these files don’t always match the production realities—they may be manually generated or leave out certain methods. “In every organization, there is up to a 40% gap between APIs that are actually deployed versus what has been inventoried,” he said. By maintaining a clearer API inventory, organizations can avoid unprotected shadow IT.

    Include Legal Auditing

    A change to an API could result in a change in how it collects user information. Updates involving sensitive data could break privacy policies or regulations such as GDPR. “After you have an inventory, you need to map all parameters manually,” said Eliyahu. He recommended performing a legal audit against your API inventory and establishing a repeatable testing process that plugs into a continuous delivery pipeline.

    As API teams release new updates, they must consider security and legal implications earlier on in the development flow. “Now, with CI/CD, these changes have to happen very frequently,” he noted.

    Watch the OWASP API Security Top 10

    There are many known API security gaps. For example, there may not be proper authorization in place, keys could be exposed, unexpired tokens could be hijacked and so on. Thankfully, OWASP has compiled a resource of top API security vulnerabilities, which Eliyahu and many others in the API economy have rallied behind. “The world should move to adopt the OWASP issues,” he said. These vulnerabilities are as follows:

    1. Broken Object Level Authorization
    2. Broken User Authentication
    3. Excessive Data Exposure
    4. Lack of Resources & Rate Limiting
    5. Broken Function Level Authorization
    6. Mass Assignment
    7. Security Misconfiguration
    8. Injection
    9. Improper Assets Management
    10. Insufficient Logging & Monitoring

    Using AI To Go Beyond ‘Whac-A-Mole’

    Plugging these above holes is a good start. However, these are only defensive measures against known patterns; they aren’t helping you keep guard for nuanced attack types. Ideally, security systems should stop cyberattacks before they even get started.

    Yet, Eliyahu recognizes a big gap in how APIs are monitored. Organizations “don’t have proper tools to know who is looking for vulnerabilities,” he said. “Tools are typically not that advanced. They mainly look for injections and known patterns.”

    Imagine a hacker probing an API. They will likely do so by trial and error, testing undocumented endpoints, sending malformed requests and so on. “They need to probe for hours or days before they find something,” said Eliyahu. If an AI could detect these odd attempts in minutes or seconds, IT could significantly reduce risk.

    Security solutions should thus leverage big data and AI to create baselines of typical behavior, then deter malicious activity the millisecond any nefarious probing begins. Eliyahu said such a security AI must consider dozens of behaviors such as, How is the API being accessed? What parameters are being used? What are the relationships between parameters? What is the flow of API calls? What type of data can be exposed?

    Instead of waiting for a breach to occur, an AI-enabled API security monitoring could instantly pause behavior deemed “out of the norm” by referencing a knowledge base that’s constantly refined using machine learning. Because, if you are only blocking malicious actors without knowing how you need to improve API security posture, “you are just playing Whac-A-Mole,” said Eliyahu.

    DevSecOps Requires API Security Forethought

    Mark O’Neil, analysis at Gartner, predicted that by 2021, 25% of organizations with public APIs will have discontinued or rebooted their public API strategy, citing security concerns as a common breaking point. APIs are now at the core of many application developments. Yet, without the proper DevSec proposition, teams risk wasted efforts and costly breaches.

    To summarize, here are our tips on API security:

    • Ensure everything is well-documented: API inventories cannot be audited if undocumented. Shadow APIs increase the likelihood of an attack.
    • Watch the top 10 OWASP vulnerabilities: These points are foundational to API security. Though not a cure-all, they present a starting point.
    • Build a security and legal review process: Ensure APIs are never deployed without the proper security review. Create validation systems that plug into continuous development processes, so new versions are never breaking privacy policies.
    • Each API is unique: Another thing to keep in mind is each API is unique. Therefore, API security monitoring also requires more context into unique business logic.
    • Continuously monitor your APIs: Continuous search for anyone looking for vulnerabilities.
    • Remove deprecated APIs: Remove old API versions. “You need a mechanism to identify and remove old API versions.” Otherwise, “zombie APIs will bite you!”
    • Learn from the attacks you block: Don’t just play Whac-A-Mole. “You need a mechanism to learn from attacks you block.”
  • Survey Surfaces Lots of DevSecOps Friction

    Survey Surfaces Lots of DevSecOps Friction

    A survey of 560 application security professionals and software developers in North America and Western Europe conducted by WhiteSource, a provider of tools for securing open source software, finds there’s a long way to go before most organizations can claim to have fully implemented best DevSecOps practices.

    Only 20% of respondents said their organization had a mature set of DevSecOps practices in place, while 62% said they were improving. Only 18% described their organization’s approach to DevSecOp as being “immature.”

    There is considerable disagreement concerning how long those efforts have been underway. While 60% of security professionals said they have had an application security program in place for at least a year, just over a third of developers (37%) said they are aware of an application security program running for longer than a year inside their organization.

    Regardless of the length of the program, nearly three-quarters of all respondents (73%) said they feel forced to compromise on security.

    Among application security professionals the top DevSecOps challenge identified was vulnerability prioritization (41%), followed by lack of application security skills (35%), budget (34%), lack of cooperation between developers and security teams (31%) and scanning performance (31%). Less than a third (31%) have a formal process in place to prioritize vulnerabilities.

    There’s also considerable disagreement over whether an application security champion gets designated. Many application security professionals said they have one (60%), while only 40% of developers agreed. The survey also finds well over one-third of developers said their organizations (37%) don’t provide any secure code training. A mere 22% of developers said their organizations provide training regularly with another 20% reporting they have tools that allow for “ongoing independent training.” In contrast, only 27% of application security professionals said their organization does not offer secure code training.

    Lilach Aviad, director of product marketing at WhiteSource, said the survey makes it apparent there are still lots of gaps when it comes to DevSecOps. Most organizations have embraced the concept but are still a long way from unifying workflows to better prioritize which vulnerabilities to address first.

    Priorities are even fundamentally different when it comes to what features are most important in an application security tool. Application security professionals prized integration (48%) most of all, followed by accuracy and ease of use ties at 39%. Developers, in contrast, leaned toward accuracy (25%), followed more closely by integration (22%) and ease of use (21%).

    Overall, the survey found the most widely employed application security tools are penetration testing, web application firewalls and application programming interface (API) gateways. The acquisition of these tools is most often justified to achieve either vertical industry regulations (25%) or industry standards (22%).

    In general, Aviad noted when it comes to security there is still a lot of resentment among developers. Too often security tools have been selected by application security professionals with little regard to how those tools might fit within the context of a larger DevOps workflow, he said.

    Obviously, it’s going to take time and effort for most organizations to merge workflows and culture. The good news is that process has begun in a lot of cases. Less clear is exactly how long it will take to complete.

  • VMware Looks to Meld IT and Security Operations

    VMware Looks to Meld IT and Security Operations

    VMware has acquired SaltStack as part of an effort to unify IT and security operations management. The announcement was made during the online VMworld 2020 conference this week.

    SaltStack has developed an open source IT automation platform to automate IT operations. In recent months it has been extended to also address security and compliance management.

    At the same time, VMware released a bevy of updates to its security portfolio, including VMware Carbon Black Cloud Workload. That offering combines vulnerability reporting with workload hardening software for both legacy platform and microservices-based applications deployed on Kubernetes clusters. It also includes elements of AppDefense, which VMware developed to harden workloads running on VMware vSphere platforms.

    VMware also announced VMware NSX Advanced Threat Prevention, which combines NSX Distributed IDS/IPS with malware detection software and network traffic analysis (NTA) technologies acquired from Lastline Inc.

    Finally, VMware announced it has committed to reselling a secure web gateway from Menlo Security as part of the VMware SD-WAN portfolio and formed an alliance with Zscaler to manage security as a service.

    SaltStack provides VMware with an IT automation framework that can be applied across multiple clouds running virtual machines and containers. The current vRealize IT automation framework is optimized for instances of VMware vSphere.

    Tom Corn, senior vice president for the Security Business Unit for VMware, said VMware’s entire approach to security is predicated on making it easier for IT operations teams rather than cybersecurity professionals to implement security controls. There are simply not enough cybersecurity professionals available to implement cybersecurity controls when DevOps teams are rolling out and updating application workloads multiple times a week, he said.

    Cybersecurity teams will continue to define what controls will need to be put in place, but it will be left to the IT operations teams to implement those controls in much the same way responsibility for application security is now also being shifted left as part of best DevSecOps practices.

    Corn said it’s clear IT security is a team sport that requires greater collaboration among IT operations teams, developers and cybersecurity professionals. VMware has been investing in security technologies with an eye toward making it easier for IT operations teams to automate security operations in much the same way any other IT task is being automated, he noted.

    That convergence isn’t going to occur overnight. There are many challenges including culture. Many cybersecurity professionals view IT operations and developers as being equally responsible for many of the root causes of a cybersecurity breach. It may be a while before cybersecurity teams have enough confidence in the ability of IT administrators and developers to proactively address cybersecurity issues before and after applications are deployed in production environments.

    Of course, there’s no alternative. The days of waiting two months or more for a security review as part of a waterfall development process are over. Security, like it or not, needs to become as agile as the rest of IT.

  • GitHub Delivers on Code Scanning Promise

    GitHub Delivers on Code Scanning Promise

    GitHub today announced it is now making available at no cost the open source CodeQL code scanning tool it gained by acquiring Semmle.

    Justin Hutchings, a product manager at GitHub, said the goal is to further adoption of best DevSecOps practices by making it easy for developers to scan for vulnerabilities as they check code in and out of the GitHub repository. It is also designed to be integrated with either GitHub Actions or an existing continuous integration/continuous delivery (CI/CD) platform to enable DevOps teams to create workflows that include code scans, he said.

    For private repositories, code scanning is part of the GitHub Advanced Security suite of tools GitHub makes available via GitHub Enterprise.

    Code scanning also makes it possible to integrate third-party scanning engines via support for the Static Analysis Results Interchange Format (SARIF), which provides a standard for sharing data between SAST tools via a common application programming interface (API). GitHub has thus far partnered with more than a dozen open source and commercial security vendors to allow developers to run code scanning within their offerings, noted Hutchings.

    GitHub claims since it made CodeQL available in beta last May, it has scanned more than 12,000 repositories more than 1.4 million times and found more than 20,000 security issues involving everything from remote code execution (RCE) and SQL injection to cross-site scripting (XSS) vulnerabilities.

    Developers and maintainers fixed 72% of reported security errors identified in their pull requests before merging in the last 30 days alone, reported GitHub. Hutchings noted those efforts represent a major step forward for DevSecOps, given the fact that industry data shows that less than 30% of all flaws are fixed one month after discovery.

    GitHub, along with the open source CodeQL community, has also created more than 2,000 CodeQL queries that DevSecOps teams can employ to scan code for specific types of vulnerabilities. GitHub also noted there already have been 132 community contributions to the CodeQL open source query set.

    Given how nascent best DevSecOps practices are in most organizations, simply making SAST tools available to developers is often a major step forward for many organizations. The challenge has been finding SAST tools that developers want to employ, said Hutchings. Most SAST tools were designed for security teams rather than developers. CodeQL is designed to surface vulnerabilities in a way that makes it clear where developers need to prioritize their remediation efforts, he noted.

    It’s not clear yet to what degree responsibility for security will shift left toward developers. There will always be a need for cybersecurity teams to verify that the proper controls are in place. However, as DevOps teams assume responsibility for security it’s almost certain they will do so on their own terms. The days when cybersecurity teams select the security tools that developers are expected to employ are now all but over.

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

  • The Importance of Digital Certificates to DevOps Teams

    The Importance of Digital Certificates to DevOps Teams

    Certificate management is an important element of ensuring DevOps processes run smoothly

    Organizations are increasingly integrating DevOps into their app development processes. According to Amazon Web Services (AWS), DevOps holds so much promise with organizations because it has the potential to increase the speed and ability to deploy new apps and services. Together, development and operations personnel use extended technology stacks and tooling to automate processes that they’ve traditionally fulfilled manually.

    Organizations want to get the most out of integrating their different teams together under a DevOps model. It’s not surprising, therefore, that DevOps is constantly changing in an attempt to fit the ever-evolving technology landscape, including IT security.

    Sid Phadkar, senior product manager at Akamai, made this point clear to TechRepublic:

    With the rising number of data breaches and increased emphasis on data privacy regulations such as PSD2 and GDPR both in the U.S. and globally, DevOps-savvy organizations will be forced to prioritize diligence in security measures overtime to market in the year ahead. As new regulations are put into place, more application developers will be mandated to build strict security policies directly within code. There will be an uptick in DevOps tools that cater to automating more compliance-related tasks within infosec teams, thus incorporating security and compliance measures into everyday CI workflows.

    The issue is that it’s not always easy to align DevOps with security. Good security practices commonly come into contact with the timely delivery of a new application or a service. Without the right tools to support DevOps, security personnel can’t support developers in a way that they need to be supported. As a result, developers will be more inclined to resist new security practices and find non-compliant alternatives to new processes that slow them down.

    These challenges are of special concern for certificate lifecycle management. Organizations need to secure the DevOps life cycle with PKI via code signing or creating a certificate. But, this implementation of PKI often suffers from poor visibility into certificate life cycles and inconsistent communication with Certificate Authorities.

    Conventional DevOps pipelines also commonly rely on manual requests to obtain trusted certificates. These types of requests undermine the agility of the software development life cycle. Most containers aren’t up for very long, so if those requests take days to complete, the resulting digital certificates will be effectively useless unless the organization slows down its delivery of applications. Such dynamism also makes it difficult for DevOps to manage and monitor those certificates on their own. Team members could therefore look for shortcuts, resort to ad hoc processes or purchase certificates that use multiple cryptographic standards—variations that increase the organization’s security risk.

    These concerns don’t resonate only with industry analysts. They’re also shared by DevOps professionals. In a 2019 survey, 74% of DevOps professionals told Venafi they were concerned that issuing certificates could slow down development. Just over a third (39%) of developers said they should be able to circumvent those policies to meet their service-level agreements, while less than half (48%) of respondents voiced their belief that developers in their organization always request certificates through channels and methods approved by the security team.

    How DevOps Teams Can Best Handle Their Certificates

    DevOps teams can best handle their certificates by automating their certificate management processes. Orchestration tools such as Kubernetes support certificate management via the ACME protocol. Kubernetes stores private keys in the Kubernetes Secret or Hashicorp Vault, thus providing seamless integration for the certificate management system. DevOps teams can also digitally sign their containers with a private CA to help verify a given container as it communicates over a TLS connection.

    Aside from automation, DevOps needs to increase the visibility of their certificates to avoid unnecessary outages. Team members need to be able to renew certificates before they expire and to address improper configurations to make sure that critical services remain up. API-driven automation can help orchestrate their processes involving keys and certificates in an attempt to balance both agility and security.

  • Should Conway’s Law Be Applied to DevSecOps?

    Should Conway’s Law Be Applied to DevSecOps?

    Strictly adhering to Conway’s Law could lead to less innovation and the inability to keep up in a fast-changing market

    When it comes to determining how an organization should be structured, the 1967 Conway’s Law provides a plausible direction that many software companies could follow. However, in today’s ever-changing cloud environment, it is arguable whether it can be used in DevSecOps companies, a quickly growing organization structure. While Conway’s Law is helpful to consider, it should only be used as a guideline and not strictly followed because it can lead to less innovation and the inability to keep up with the fast-changing market.

    What is Conway’s Law?

    Conway’s Law is a term that originated from engineer Melvin Conway’s 1967 thesis paper to Harvard Business Review. In his submission, he wrote that “any organization that designs a system (defined more broadly here than just information systems) will inevitably produce a design whose structure is a copy of the organization’s communication methods.” Based on his observations in the engineering world, he believed that the success of a software is based on the organization’s company structure and communication style. As a result of this paper, software companies began to emphasize collaboration and teamwork and implemented it into the company’s work culture.

    How Can Conway’s Law Apply to the DevSecOps Field?

    Conway’s Law has many valid points. The law emphasizes the importance of a company’s structure and the necessary balance of business and design to ensure a viable product, as the quality of a product “comes from within.” However, there is no right way to organize a company, and it should be structured in a way that makes the most sense for an evolving, cloud-based product.

    In the DevSecOps field, many solutions are run by enterprises that are cloud-based. This means that all the data and networks are stored in remote servers, making it easier for companies to constantly develop new technology and improve existing products. This new norm is redefining the way companies are structured today, and traditional standards cannot be followed. If a company strictly follows Conway’s Law, it will be difficult for them to innovate.

    Here are a couple of takeaways from Conway’s Law that can benefit DevSecOps companies:

    Small Teams With Equal Representation

    Conway’s Law explains that the bigger the team, the higher likelihood of miscommunication and tension, causing unproductivity. Many tech companies, such as Microsoft and Amazon, structure their employees in small teams (around 10-15 members) to oversee and specialize in a specific aspect in the company’s product, but aim to achieve the same business goal. This type of structure allows more leeway to experiment different ideas and quicker response time to fast-changing needs.

    Collaboration is Key

    Some argue that following Conway’s Law may decrease the company’s overall cooperation and lead to small team allegiance. While there is a fine line between small work groups and department cliques, collaboration needs to be a core concept embedded in the company’s organization.

    If the organization’s culture is based on companywide collaboration, it will solve these problems, as collaborative processes and platforms prevent cliques from forming and allow teams to be independent, creative and agile. For example, for security teams to successfully collaborate with DevOps teams, they need to intentionally create solutions that can be embedded with existing DevOps pipelines.

    Conclusion

    While Conway’s Law is an important social contribution to organization principles, it should only be used as a rough guideline because following it too closely can stymie innovation in a fast-changing cloud environment. Conway’s Law highlights the importance of company structure and implies that a successful organization is structured with small teams focusing on one sector of the company, and with consistent collaboration established throughout the company to systematize unification and togetherness.

    As organizations compete for the greatest slice of pie, it is critical for leaders to look inward and ensure internal structures and processes are setting their products up for success.

  • The Role of DevSecOps in Finance App Dev

    The Role of DevSecOps in Finance App Dev

    DevSecOps is critical in developing apps successfully in the rapidly changing and highly regulated finance environment

    One of the most important shifts of the past few years in finance and banking was the movement from primarily branch-based banks to mobile-first banks. While these innovative products simplify the end user experience, they also bring up more security concerns, since digital channels expose a number of vulnerabilities. These apps deal with sensitive user data, such as private financial or personal information, which means that the prevention of any type of breach is of utmost importance.

    The level of security of a finance app is judged primarily on how well digital transactions and personal data are protected online. Even the smallest security concern can mean that users lose confidence in the app and immediately switch to another provider, often leaving negative reviews in the app stores and damaging the reputation of the company. It does not come as a surprise that the finance industry is one of the most regulated industries in the world: finance apps are required to fulfill the strictest security requirements and offer the latest functionalities at the same time.

    Regulatory Concerns in the Finance and Banking Industry

    Not only do finance app companies have to comply with traditional finance regulations, but they also are subject to international and local privacy laws. One example is the EU’s General Data Protection Regulation (GDPR), which came into effect in May 2018 and requires companies with ties to the European market to update their data and privacy policies. This affects the finance and banking industry in a number of ways, especially when it comes to getting consent before processing the personal data of users, the right of the clients to request their data to be erased, and additional penalties for data breaches and for failing to comply with such regulations.

    Another recent example of changing regulations affecting the finance and banking industry in Europe is the Strong Customer Authentication requirement (SCA), implemented in September 2019. According to this regulation, a secure finance app requires at least two forms of independent authentication elements from its users. These can either be a knowledge element: something only the user knows, such as a password; a possession element: something only the user possesses, such as their smartphone; or an inherence element: something the user is, such as their fingerprint.

    Meanwhile, in the United States, the number of potentially applicable regulations make this an even more complex issue. Here, finance app companies might be subjected to a plethora of federal or state licensing or registration requirements and thereby may have to adhere to laws and regulations on both levels, depending on their activity. Providing fintech services in the United States often requires licensing and registration with multiple state regulators including consumer lending, money transmission and virtual currency licenses.

    These examples show the additional challenges finance app companies are facing throughout the already challenging mobile development process. Things can be further complicated when developers have to build an app for a global audience with different requirements per country or region. Such companies often have codebases running in multiple different countries; having to manage this complexity while following a variety of regulations can even cause delays in important product releases.

    Growing Customer Expectations Require a New Approach

    Continuously improving features, maintaining app quality and responding to constantly changing requirements can be a daily challenge for product managers and developers. To tackle these issues, it’s necessary to implement a set of security processes from as early as the planning phase all the way to release—in other words, to create a DevSecOps environment. This can be facilitated by integrating regular information security checks and core security tasks into the software development life cycle to remove previously existing bottlenecks between developers, the security team and the rest of the organization. This approach also helps mitigate risks and allow all contributors to take more ownership and avoid security-related failures.

    A DevSecOps environment in the finance or any sector also enables teams to have full control over their stacks and access management and to be able to monitor any and all access within and outside of their environment at all times. Another step forward is shifting the responsibility of security maintenance from the team to a secure and scalable cloud-based CI/CD platform. Automation early on helps developers focus on what matters the most: optimizing their product and developing new features without having to worry about security-related maintenance tasks. It also leaves more time for parts of the process that are essential for safeguarding quality, such as checking code dependencies, threat modeling and detecting flaws before a release.

    Building the future’s successful apps in this rapidly changing and heavily regulated space will require adopting an agile, technology-forward mindset and organizational change at the same pace. In the finance industry, it’s especially important to make not only DevOps but also DevSecOps integral parts of the software development life cycle. Only this way can vulnerabilities be minimized across all applications and the different parts of the organization. Fintech, finance and banking apps can only remain competitive if they have solid structural support that enables them to securely connect to—and protect—their users.

  • Snyk Acquires DeepCode to Apply AI to DevSecOps

    Snyk Acquires DeepCode to Apply AI to DevSecOps

    Snyk today announced it has agreed to acquire DeepCode as part of an effort to apply artificial intelligence (AI) to DevSecOps.

    DeepCode has developed an interpretable machine learning semantic code analysis tool that scans code anywhere from 10 to 50 times faster than existing approaches. DeepCode currently supports Java, JavaScript, Python, TypeScript and C/C++ programming languages. Developers get started by connecting the DeepCode bot to their GitHub, BitBucket or GitLab accounts or directly within their integrated development environment (IDE). DeepCode then immediately starts reviewing each commit with no additional coding required. The bot is currently free for teams of up to 30 developers.

    Snyk CEO Peter McKay said those machine learning algorithms dramatically reduce both false negatives and false positives as they learn the application environment. That code scanning occurs in real-time, thanks to a Datalog solver developed by DeepCode, which McKay said means code scanning can now keep pace with the rate at which applications are being developed.

    While there’s widespread agreement that more responsibility for application security needs to shift left toward developers as part of any effort to embrace best DevSecOps processes, getting the right security tools into the hands of developers has been a challenge. Developers tend to resent having to wait for security scans to be completed, especially at a time when the rate at which applications are being developed and deployed has been accelerated as organizations embrace digital business transformation more aggressively.

    In effect, code scanning as implemented today is often viewed as a bottleneck. That issue goes away, however, if scanning can occurs in real-time. Armed with that data, it then becomes possible to also prioritize which vulnerabilities to address in code first in addition to in, some cases, automating bug fixes.

    In an ideal world, security will become a natural extension of any quality assurance process implemented by a DevOps team. The challenge right now is bridging a cultural divide between DevOps and cybersecurity teams that have workflows that operate at dramatically different cadences. The more automated the code scanning process becomes at the front end, the fewer security issues will need to be addressed by theses teams as applications are either being deployed or, worse yet, after they are already running in a production environment.

    Fresh off raising an additional $200 million in funding that was used in part to acquire DeepCode, Snyk claims there are already 1.5 million developers using its tools worldwide and that its revenue grew 275% in the last year. Privately held, Snyk claims to have a valuation of $2.6 billion. The next challenge is to expand adoption of Snyk tools across the roughly 24 million developers that are writing code today, said McKay. As part of that effort, Snyk recently formed technology alliances with both Red Hat and Docker Inc.

    Naturally, it may take some time for that goal to be realized. However, with more developers now being held accountable for security, the chances are good that many of them will soon be looking to ruthless automate security in much the same way they are moving to automate every other aspect of IT.

  • Synopsys Report Shows DevSecOps Progress

    Synopsys Report Shows DevSecOps Progress

    A report based on analysis of the software security initiatives of 130 organizations conducted by Synopsys, a provider of static application security testing (SAST) and software composition analysis tools, suggests progress in terms of DevSecOps adoption is being made but there is still a long journey ahead.

    According to the survey results, 121 organizations now ensure host and network security basics are in place, with 73 organizations also monitoring application input.

    However, only 39 organizations said they define secure deployment parameters and configurations, followed by 36 that said they were ensuring cloud security basics and 33 that said they were protecting code integrity. Only 32 had embraced application containers, while 22 employ orchestration for containers and virtualized environments, according to the Synopsys report.

    Using code protection (13), attaching bills of material to application inventory (12) and using application behavior monitoring and diagnostics (7) were even farther down the list.

    Michael Ware, senior director of technology at Synopsys, said the results of the report are an encouraging sign as more software security teams increasingly report into a technology group or CTO rather than an IT security team or chief information security officer (CISO). As the responsibility for application security continues to shift left, IT teams are being reorganized accordingly, he noted.

    More IT organizations are also embedding security reviews within their continuous integration/continuous delivery (CI/CD) platforms as they replace high-friction, out-of-band security tasks with ones that are automatically triggered by events in the CI/CD pipeline, added Ware. That approach also enables organizations to overcome a chronic shortage of cybersecurity personnel that has now become a longstanding issue for most organizations, he noted.

    Longer-term, security will become deeper ingrained in the entire mindset of not just IT teams but also entire organizations, noted Ware. As part of an effort to make the entire organization more resilient to change, organizations are making a more concerted effort to address security issues at all levels of the organization.

    Less clear at the moment is to what degree DevSecOps will be achieved by automating tasks rather than melding workflows. DevOps and cybersecurity teams have distinctly different cultures. As cybersecurity tasks shift left, many DevOps teams will seek to ruthlessly automate those tasks in much the same way they have automated other IT management tasks. In fact, there may come a day when security issues are addressed as a subset of the overall quality assurance process, Ware noted.

    In the meantime, it’s clear much more needs to be done before applications can be considered fundamentally secure. Security issues that stemming from relying on tools to automate the configuration of cloud infrastructure are rampant. DevOps teams clearly need to take more responsibility for security, but cybersecurity teams still need to be able to verify the right policies are being employed. As long as humans write code, there will always be plenty of opportunity for error. The DevSecOps challenge now is to eliminate as many opportunities for that human error to occur as possible.