devopsy.kinsta.cloud

Tag: devsecops

  • Postman Survey: Increased Usage of APIs Results in More Security Incidents

    Postman Survey: Increased Usage of APIs Results in More Security Incidents

    A survey of more than 37,000 developers and application programming interface (API) professionals published this week by Postman, a provider of a platform for developing and managing APIs, suggests that as more APIs are deployed, more organizations are seeing a rise in cybersecurity incidents.

    The survey finds more than half of respondents (51%) reporting that more than half of their organizations’ development effort is spent on APIs. About 20% also noted they are responding to API security incidents or breaches at least once a month at their organization. Overall, more than half (52%) said API security incidents occur less than once a year.

    Kin Lane, chief evangelist for Postman, said that while a lot of the concerns over API security could be classified as “theater” being put forth by providers of API security platforms, it’s clear there is a need for a zero-trust approach to building, deploying and maintaining APIs.

    The bulk of APIs are used primarily to interconnect internal-facing applications and systems, with a subset then used to integrate partners. Only a comparatively small percentage of APIs are externally facing. However, Lane noted many organizations fail to appreciate how quickly an internally facing API can become externally facing over the course of its lifecycle. As such, IT teams need the tools and platforms required to manage and secure APIs as they evolve, he noted.

    In fact, nearly three quarters of respondents (72%) said being able to build APIs remotely is very important to them. That would suggest best DevSecOp practices will need to be extended to API development teams that are often working from home.

    Despite those concerns, however, a full 89% said Investments in APIs will increase or stay the same over the next 12 months to drive, for example, digital business transformation initiatives. However, the survey also suggests most organizations are still coming to terms with API development and deployment. Only 8% of respondents identified themselves as API-first leaders, which Postman identifies as an elite group that produces APIs faster, deploys more often, has fewer failures and recovers sooner when failures occur.

    Lane said the survey makes it clear that while APIs are playing a crucial role in advancing business goals, there is a need for increased visibility as more APIs are deployed across the enterprise. That’s especially critical as more types of APIs employed also continue to expand. Most APIs in use today are based on the REST format, but there are also now APIs based on GraphQL, event-driven architecture and various messaging platforms. None of these newer APIs are going to supplant REST APIs any time soon. Rather, they are being applied to drive additional processes alongside REST APIs, noted Lane.

    It’s not clear how many organizations are adopting a design-first approach to building APIs before they write application code, but as more APIs are deployed, the way IT is managed is rapidly changing. Application services are essentially becoming more disposable so long as the API used to expose them to other applications remains stable. In fact, it’s now only a matter of time before most organizations fully appreciate the degree to which their entire IT strategy now revolves around their APIs.

  • Survey Shows Steady DevSecOps Progress

    Survey Shows Steady DevSecOps Progress

    A survey of 200 DevOps and IT/information security professionals published this week by Mezmo, a provider of an observability platform, conducted in collaboration with the market research firm Enterprise Strategy Group (ESG), finds only 22% report their organization has a formal DevSecOps strategy to integrates security into their software development lifecycle (SDLC) processes.

    Among those that have adopted best DevSecOps practices, however, 60% saw an acceleration in incident detection, while 53% saw a reduction of incidents in production environments.

    Overall, the survey finds 62% of respondents report their organization is actively evaluating use cases for, or has plans to implement DevSecOps.

    Mezmo CTO Rob Fry said the primary challenge organizations face when it comes to DevSecOps remains cultural. In fact, 99% of survey respondents said establishing a culture of collaboration between development and cybersecurity teams is either critical (51%) or important (48%). Building cross-functional DevOps teams that have the required level of security expertise, however, is a major hurdle when there is a general shortage of cybersecurity expertise, noted Fry.

    The survey finds that on average it takes 17.5 person hours to triage and understand security incidents, an amount the survey finds that 82% of respondents desire to reduce.

    However, organizations are also struggling with the sheer volume of data collected by DevOps teams. More than half the respondents (52%) said the variety of data to be captured, analyzed and be acted on throughout the software development lifecycle (SDLC) hinders security efficacy/efficiency. A total of 43% said the scale of data to be captured, analyzed and acted on throughout the SDLC also hinders security efficacy/efficiency.

    Organizations surveyed capture several (54%) or even hundreds (32%) of terabytes per month, with 6% capturing a petabyte or more per month. Well over two-thirds (69%) do not capture certain data sources because of the high cost of storage/retention, which Fry noted is going to be problematic if there is an incident. Log data (35%), followed by metrics (29%) and traces (22%) account for most of that data, the survey finds.

    In all, 84% of respondents said getting the right data and tools to developers is key to achieving success. A full 91% of respondents are using multiple tools to get the most value out of their data. Two-thirds (66%) have dedicated logging analysis tools, while 59% have a security information event management (SIEM) platform. Cloud to two-thirds 64% have a data lake hosted in the cloud, while 55% have one in an on-premises IT environment.

    A full 87% are using open source tools as part or all of their observability stack because they are more customizable. However, 84% noted that over time it will become challenging to manage, adapt and scale with these solutions. Nearly all survey respondents (98%) said they will likely investigate a managed observability solution over the next 12 months.

    The application security issues that plague organizations today have been around for decades, so it’s not likely they will be resolved in a few short weeks. On the plus side, at least, there’s now a lot more awareness of the root cause of the problem than ever.

  • Why DevOps Teams Need Security Engineers

    Why DevOps Teams Need Security Engineers

    In the episode of View with Vizard, Mike Vizard sits down with Om Vyas, chief product officer for oak9, as he explains why security engineers need to become part of every DevOps team. The video is below followed by a transcript of the conversation.

    Vizard: Hey, guys. Thanks for the throw. We’re here with Om Vyas, who’s Chief Product Officer for oak9. We’re gonna be talking about all things related to DevSecOps and cloud security. Om, welcome to the show.

    Om Vyas: Yeah. Thanks for having me, Mike. 

    Vizard: We, of course, have been talking about DevOps for the better part of a decade. And then we decided that the security people couldn’t be left out, but they wanted to have the word “sec” thrown in there to make things a little more confusing, so then we got DevSecOps. And some of them even argue that I guess it should be SecDevOps. But who knows? My question to you is it seems like we’re still struggling with getting this idea across to people. It’s become more important in the cloud era, obviously, ’cause more developers are programming stuff. But what, from your perspective, is the fundamental challenges that we’re seeing with getting people to really implement DevSecOps practices?

    Vyas: Yeah. I think if we take a quick step back, I think you hit it on the head. There’s DevOps, there’s DevSecOps, there’s SecOps. There’s a lotta buzzwords and a lotta different ways that these adoptions are being thrown around. I think fundamentally, my take is DevSecOps or DevOps, it’s first and foremost a cultural transformation. The technology and the people process really come after. So really, one of the biggest challenges is that embracing this notion of being able to work together, being able to have shared responsibility and a collaborative environment.

    If you think about kinda where we’ve come from, and in fear of dating myself, I’ll say that when I used to develop long ago with my DevOps, my development teams, our focus was only towards application development. And then it was like the packaging, the art effects, once they were created, it was like, “Hey, kinda ” the notion around, “Hey, throw it over the wall to IT ops people,” or having formalized security review processes, right? And really, this cultural transformation is, I think a key area where I think a lotta the folks in the organizations, they’re struggling. They’re struggling to embrace the culture of DevOps, culture of DevSecOps.

    And then when you factor in, as you said it yourself in the beginning, that the security people are getting left behind. And what that really means is they don’t have the visibility and they don’t have the automation to be able to keep up with the amount of churn that’s happening with the development, the DevOps. Because the dev teams are using the automation, which is the technology part of this transformation, to really create this velocity in which they are churning over new features, doing rapid deployment into production. Five, seven years ago, we used to do maybe one release a month, one release a quarter. And now, I’m seeing organizations, ours included, where we’re doing tens of releases a day, hundreds of releases a day. So this is really where the security or the “sec” part of the DevSecOps is really struggling to keep up with that velocity and that change.

    Vizard: Does that mean we need to slow down? Or can we build and deploy secure applications just as fast? What’s the tradeoff?

    Vyas: Yeah. I mean, I think maybe slow down is not the right answer. Because I think velocity is really being utilized as a differentiation for a lotta the – lotta the organizations. I think the right answer is – I think, not necessary just slow down to a halt. The right answer in my opinion is really, how do we integration security into the processes of DevOps to truly give them the visibility at the point of time when these changes are happening and then really arm them with the automation that they really need to give them full visibility, give them ability to be able to really quickly identify how that application is changing? How are those new capabilities that are being added, and how is that impacting security of that application? And the sooner we give visibility to security engineering of all of those changes and where security matters in those changes, the sooner we can continue to operate with that velocity.

    Vizard: How do we go about doing that? ‘Cause a lotta the developers, they didn’t really set out to build something that’s insecure. It’s just more often than not, they have a tool that lets them manage a cloud as infrastructure, as code. But then they misconfigure something ’cause they’re not security experts, and maybe a port gets left open or something like that occurs. So how do we lock all that down and how do we kinda tighten that up without necessarily requiring the developer to become a security expert, ’cause that seems unlikely?

    Vyas: Yeah, you’re absolutely right. I think that a developer is not a security expert. And I think if you look at kind of where dev engineering is today, especially with the Cloud Native architecture, especially with DevOps, it’s dev engineering or developers are taking on lot more responsibility, right? But I do think as a developer myself, what I’m interested in is not that I don’t care about security. It’s that what I wanna know is, “Hey, help me understand what I need to do to move fast. What do I need to do? What are the five things or ten things or whatever number of things that are related to security that I can do to not only help my security team, but really quickly move this feature capability from development and implementation to testing and to production?”

    So from that perspective, I think what really also helps is if I have the ability to, within my own workflow, within my own tools – if somebody educated me and gave me kinda the prescriptive guidance of, “Hey, here is all you need to do to ensure that all of these different security aspects of security-related things in this infrastructure’s code that you change. Here’s what you need to be aware of. Here’s what you need to change, and to really help you move forward.” I think that’s what, I think as a developer, I’m looking for. Because again, I have many, many different things that I’m managing today beyond just application code. 

    Vizard: Mm-hmm. How automated can all this get? Seems to me the key to this whole thing is if the developers still need to program the cloud environment, we need to find a way for them to make fewer mistakes, put more guardrails in place, and kinda just gently lock down the environment, I guess, is the phrase I’d say. So what is the challenge, what is the state of the art at the moment?

    Vyas: Yeah. I think it’s interesting. You said “gently lock down the environment.” I think absolutely, right? I mean, I think that developers, what we’re seeing today with a lot of our customers is they want lotta freedom because that freedom will enable them the agility and the velocity that they are looking for. But at the same time, we do need guardrails because they’re important.

    And I think how do we gently lock down the environments? I think that’s kinda the key. I think one way we can talk about this is that when we think about that infrastructure’s code, we’re really talking about codifying the entire environment under which your application is running in the cloud. And what that actually enables us to do is be able to then say, how do we actually remediate? How do we actually focus on automation that doesn’t always just point out all the challenges or all the problems in that code around security? But then taking it that last mile, as I like to think about it, which is actually fixing it for that developer.

    So I think that’s really where the trends are. And I think that’s really where things need to be, is really say, “Hey, I analyzed this infrastructure’s code. I have identified where all of the security challenges are. Here’s how to risk-appropriately secure this code. Because all of this infrastructure’s code is declarative. So it’s predictable in how it can be changed and what the impacts would be.”

    So I think that’s really where it needs to be, is when I look at some of our customers and infrastructure’s code, it’s getting pretty complex, right? So we have customers that have 40,000, 50,000, 60,000 lines of Terraform code. So even cloud infrastructure code or infrastructure code itself is getting pretty complex. So no security engineers or no number of security engineers or even DevOps or developers can actually keep up with understanding, what are all the security implications in this code? So the real answer in my mind is, how do we automate this thing, take it to the last mile, and say, “Hey, here are all the recommended changes in this code as far as the security aspects of it is concerned?” So as a developer, now I can focus on the functional aspects, and I have an automated tool, an automated process, that will really enable to me to then not have to worry about the security aspects of that infrastructure’s code.

    Vizard: And maybe no one ever needs to know how much I don’t know about security. But do you think that we’re gonna see a lot more of so-called artificial intelligence thrown at this problem? And is that part of this automation curve? Or are we making too much of AI and security these days and it’s just gonna require something a little more fundamental?

    Vyas: Yeah. I think the short answer is yes. But I think my opinion is that AI kinda gets thrown around a lot. And I think when we’re talking about some of the deeper learning concepts in AI, we’re talking about some neural network things, I think those things are coming. But I think we still have to recognize that we’re in the infancy stages of this. So I think really to me, it starts with the fundamentals first. Can we actually provide these recommendations, this automation, to really help educate the user, that developer, that practitioner, that is today, lot more often than not is kind of utilizing lotta the modularized code that’s available in the web without really understanding, what are the implications as it relates to their own world or their own applications or their own context?

    And lemme sort of dive in deeper. So not all applications or workloads in the cloud are created equal. So if you are a health care company that’s securing health care applications that’s utilized by your patients, that’s using PII data, their requirements around security may be completely different than if I’m building a marketing website where most of the data that’s on that website is publicly available. Both of those applications are not created equal. So how do we secure those two different applications is actually different.

    So there’s an element of this dynamic nature. There’s element of understanding, what are the requirements of that application? What are maybe the compliance adherence to those applications? So really then, when we talk about securing those two applications, that’s also different. So it’s really what I think about the context behind that application and how you secure that application really becomes important or a focal point of, then what are the recommendations that you’re providing to that end user, that developer, within that infrastructure’s code? So I think that has to take that into consideration.

    And then I think, to your point, it’s not simply just saying, “Hey, here are the ten things you need to do, developer. Go and here’s a tool that will actually remediate it for you.” That’s great. But I think part of it can be used really as an educational tool to really better understand, “Hey, developer, help us a little bit. Help us understand the context of this application. What are, what is it that you’re trying to do?” And then I think once you kind of cover those fundamentals, then I think as we go deeper beyond the infancy stages of this cloud infrastructure journey, then I think what we can do is we can learn behaviors. We can learn from the industry that this developer or this organization is in. And we can say, “Yeah, this is a health care industry vertical or this is a particular type of architecture or workload that’s being deployed in the cloud,” and secured.

    And then I think we can start to get into intelligence around deep learning and other heuristics to say, “Hey, how do we react to then risk-appropriately secure this application,” right? Because otherwise, if we start treating all applications, all workloads that are run in the cloud, in the same way, there’s a lot more that we’re asking of the developer. There might be hundreds of things that we need to do to risk-appropriately secure a health care application that’s using PII data versus we might only need to do a handful of things to ensure that a marketing website that has publicly-available data is secure.

    Vizard: What will be the role of the security team in all of this? Because one of the things that comes to mind is if we are shifting more responsibility or at least the enablement left, then what exactly does the security team need to do to kinda work alongside, then? Or will they just kinda set the policies and the rest of it will be automated?

    Vyas: Yeah. I think, first and foremost, about kinda the role of security engineering today in the DevOps world or DevSecOps world, is really understanding and gaining visibility into what’s happening. Because if you have engineering teams that are deploying tens of times a day into production, they’re fundamentally changing, potentially, the architecture of that entire application. So I’ll give you an example. Today, with lotta the sort of building blocks or the way I like to think about it is cloud service providers are really offering these Lego pieces. So they’re outta-the-box capabilities.

    Now, I can plug in an analytics service into my architecture and seamlessly provide analytics dashboard into my application or into my workload that I didn’t have a week ago. But that fundamentally changes, or it fundamentally has the ability to change, the architecture, and therefore the security implications. So first and foremost from the role of security engineering is really getting the visibility and getting the visibility as early as possible so that they can understand how, fundamentally, this application is changing and what are the security implications of that. So it, and I’ll say for that aspect of it, this is the people process side of embracing DevOps, is really engaging that security engineer as early as having that requirement or having that capability from business that says, “Hey, we need this analytics dashboard,” really getting the security engineering involved as early as possible.

    And from that point forward, again, then it goes back to technology and automation. How can security engineering really understand, what are the implications of adding this analytics service from AWS or some analytics service from GCP or Azure? What does that mean for the security of my architecture? So there might be hundreds of different configurations. There might be thousands of different implications around putting in that one analytics service that’s available outta the box as a feature or service from the cloud service provide. And the reality is no security engineering can actually keep up with that.

    So having a tool that really understands down to the configuration level, what are the impacts or the configurations of that analytic service to securely deploy that service and then what security engineering can do is security engineering can say, “Hey, let me understand the implications and the architecture when my development team is adding this analytics service.” And if we start early, if we get the security engineering involved early, if we enable, then, automation to take away the implications of down to the hundreds of configurations of securely deploying that analytics service away from security engineering, but then give them the visibility, then I think we have a really great starting point to enable all of the teams to work together with the same operational velocity that the dev engineering really desires.

    Vizard: Mm-hmm. What is your best advice to folks? I mean, should I just take all these developers and security people and lock ’em in a room till somebody comes to an agreement? Or is there some more intelligent way to go about this?

    Vyas: Yeah. I think locking everybody up in a room is not the right answer, right? I mean, I think what I’ve seen work really well is there’s lotta different ways to sort of come to a solution. I think there’s no one silver bullet here. But I think depending on the size of the organization, depending on the size of the teams, I think one of the things that should be done, and I’m starting to see some trending around this, is really add a security engineer to the engineering team as a whole so you really have a dedicated security engineer that’s spending part of their time with these engineering teams.

    So typically, we’ve seen, in more of the modern development shops, you see lotta the dev engineering, it started out with just developers in a single team. Then we kinda focused on scrum teams. So there was development teams, there was a product engineering or QA involve.We’ve seen a DevOps engineer or SREs get involved in these teams. And I think, to me, the answer is, again, being able to put that security engineer in these teams, as well, to work closely with the developers, work closely with the SREs. Because then, what will start to happen is that engagement, that early visibility and understanding. So I think that’s one.

    And then I think the other area for lotta the larger organizations where this may not work is I think the notion around excellence centers , so you have visibility across these little center of excellence teams. So there’s cloud ops teams, there’s security teams. It’s really good to incorporate lot of your security engineering and security architects into these cloud center of excellence teams. Because I think then again, it goes back to that visibility, goes back to engagement, and it goes back to helping security teams really understand, what are the different architectures? What are the different capabilities that lotta the dev engineering groups are using today? Is it the serverless architectures? Is it the micro services that are being built with containerized architectures?

    And then what security engineering can start to do is they can start to build these reference architectures or guardrails around 80 percent of the, “Hey – ” recognizing that 80 percent of the workloads across my organizations are built with serverless architectures, as an example, in the cloud, or it might be that containerized architectures in the cloud. And that will really help them start to build these guardrails in an effective way. And then I think, you talked about sort of, early on, gently locking down environments. So I think if we then start to think about, in the DevOps pipeline, how do we incorporate these security automation tools that enable us, both the development teams, the SRE teams, and the security teams, to identify, what are all of the security underpinnings, vulnerabilities, design gaps that we are identifying, be it with the application code, be it with runtime, be it with cloud infrastructure security?

    So it’s really, where possible, building these automated tools within the pipelines without actually blocking the pipeline so that you’re actually what you’re doing is you’re really enabling the development engineering and the DevOps engineering to really start to build in the process around, how do we ensure that all of these security design and the best practices are actually incorporated within the pipeline? And then as the teams learn and grow, then these tools can become those guardrails. So maybe you’re not blocking or completely blocking the pipeline or failing the pipeline at or in the development or sandbox stages, but then you start to guardrail those as that feature capability’s moving through user acceptance testing or staging or before it goes into production. And I think those are some of the key things that can be done to really enable more of this collaborative, but shared responsibility culture that I think is really going to drive lotta the benefits that are needed to build security in.

    Vizard: Hey, Om, thanks for being on the show. It’s all about making sure that if you find a pattern, build a guardrail, and rinse and repeat.

    Vyas: Yeah, absolutely. Thanks for having me, Mike.

    Vizard: All right. Back to you guys in the studio.

  • Contrast Security Adds API Support to Security Platform

    Contrast Security Adds API Support to Security Platform

    Contrast Security has fully extended its vulnerability scanning and runtime application self-protection (RASP) platform to now include application programming interfaces (APIs).

    Company CTO Jeff Williams said the Contrast Secure Code Platform embeds agents directly into code to detect vulnerabilities using a combination of integrated static and dynamic application security testing tools. That approach makes it simple to embed vulnerability scanning and exploit prevention capabilities within a DevOps workflow as an application is built and deployed, he noted.

    In contrast, traditional approaches to application security depend on legacy platforms such as web application firewalls (WAFs) that are deployed by cybersecurity teams to protect applications in a way that doesn’t provide the same level of granular control at the API level, said Williams.

    Contrast Security claims the Contrast Secure Code Platform improves scan times by a factor of ten while fixing defects 45 times faster. It also reduces false positive alerts by being 200% more accurate, the company claims.

    As more organizations start to embrace best DevSecOps practices to better secure software supply chains, many of them are trying to achieve that goal without slowing down the rate at which applications are built and deployed. That approach, however, requires giving developers and DevOps teams the tools needed to build and deploy secure applications without requiring a lot of direct intervention on the part of a security operations team.

    In general, there is also now a lot more focus on API security as more organizations build and deploy microservices-based applications that rely on APIs to interconnect discreet components. Those APIs should be built, deployed and secured by DevOps teams before they are deployed just like any other software component, noted Williams. The current process of building applications is at its core, from a security perspective, fundamentally broken, he added.

    Application security, in general, has always been somewhat problematic. Cybersecurity teams tend to fund the tools and platforms they regularly employ. The assumption is that application development teams will invest in the tools they need to build and deploy applications. Alas, application development teams that have limited cybersecurity expertise assume that cybersecurity teams are securing both the underlying infrastructure and the applications deployed on top of it. As a result, application security is frequently underfunded.

    In the wake of a series of high-profile breaches of software supply chains there are now at least more reviews of application security being conducted. Contrast Security is making a case for securing the entire application, including the APIs, it invokes using agent software that is injected into the application at the time it is constructed.

    It’s not clear to what degree application security issues will be addressed using agent software rather than traditional cybersecurity platforms managed by security operations teams. Responsibility for application security is shifting left toward developers and the DevOps teams that support them, but as long as humans write code, mistakes will be made, said Williams

    The issue, of course, is many of the members of those teams are still focused a lot more on writing code and deploying applications than they are on cybersecurity.

  • Avoiding Security Review Delays

    Avoiding Security Review Delays

    In the summer of 2021, I had lunch with a senior security developer at one of Seattle’s leading tech firms. Even though we were relaxed in the sunny and cool afternoon of the Pacific Northwest, there was no doubt my friend was frustrated. Part of his job was running code through a popular scanning product and then evaluating the results. It was a tough role because he sat outside the team that was developing the code and he was often under pressure to run his analysis within the constraints of their deadlines. 

    All too often, he had to deliver the bad news that the scan had found security issues. But that alone wasn’t why he was frustrated. His issue was that the tool that he was using was taking several hours to complete scans. He’d taken to starting the scan at the end of the week and hoping that it would be complete by Monday morning. The very tool that was supposed to make his job easier was actually a headache.

    This is one of the fundamental challenges of analyzing software systems for security vulnerabilities. All too often, developers and stakeholders focus their project timelines on the functional specifications. Teams work feverishly to rapidly iterate from prototype to finished product. 

    Security concerns are never disregarded, but the culture of “Let’s see if we can get it working the way we want first and button it up later” ends up costing more in the long run because the evaluating and testing cycles take longer. Not to mention that if substantial security problems are found, it can be difficult to remediate them without breaking things that were supposed to already have been completed. This problem is becoming acute in the SaaS world where solutions are being built faster than ever before with little to no security oversight.

    The Right Tools and Software Are Critical

    First, managers and executives need to mandate that the entire software development lifecycle and every environment should have security. Particularly for web-based SaaS tools, any vulnerability that exists is a potential attack vector. Attackers know that going after a dev version might not yield a jackpot, but it might give them access that exposes credentials that work in later versions or identifies a vulnerability that flies under the radar into production.

    Second, automation and tooling are simply the name of the game. Using tools with code repositories, pipeline management and testing frameworks help ensure the elimination of as many potential vectors of error as possible. Security checks should be the same. We can’t always rely on the skills of a developer or an administrator to follow security best practices. 

    We need tools that provide reliable and rigorous checks. Moreover, these tools need to run frequently. SAST scanning should be fast enough that a developer can run it with every save, or at least every commit. Coupling SAST and IAST scanning together is the gold standard for secure development. Every time code is compiled into a dev or test environment, it should be tested to make sure that vulnerabilities haven’t crept in and that the permissions and architecture of the system don’t work at cross purposes to expose vulnerabilities.

    Finally, there is a fundamental issue that must be addressed in every manager’s office. Code quality is not the same as security. Sure, there might be some overlap, but it doesn’t make sense to have 200 rules for code quality and 50 for security. The two things are not equal, and it’s a fallacy to expect that having high-quality code without frequent security checks will ultimately lead to less time spent in security review. Don’t miss the forest for the trees. Make sure security is the team’s top priority.

    Advocating for Security in SaaS

    My friend didn’t have a problem holding teams accountable for the code they’d written. In fact, he relished being able to insist on high standards and was proud that his organization empowered him to do so. That’s exactly what we need in the software industry: Individuals who are unafraid to demand the best from their peers. But it’s imperative that we provide effective tools they can rely on to succeed.

    The problem of security testing delays are not new to software development. It has been well-documented that it can take 640x the money to fix bugs in production, but due to a lack of effective tools this problem has been amplified in SaaS development. A SaaS development environment presents unique challenges that cannot be met by just employing code analysis or configuration testing for SSPM vendors. It requires a holistic view of the environment and the ability to use customization to be effective in the identification and remediation of vulnerabilities. 

    With a comprehensive view, those responsible for security and those implementing it will see security as a necessity to innovate quickly rather than a necessary evil that is put off until last in hopes it can be avoided. Maybe then my friend won’t be as frustrated next time we meet.

  • Putting the Security Into DevSecOps

    Putting the Security Into DevSecOps

    The non-Newtonian fluid that’s composed of cornstarch and water has been around a long time, but Dr. Seuss’ 1949 book was the impetus for what it’s often called today – Oobleck, from “Bartholomew and the Oobleck.” When not under pressure, Oobleck is a thin liquid; when pressure is applied, its resistance increases to the point of being solid. A couple of other examples are quicksand and Silly Putty ™ (for fun, this video shows how resistant Oobleck is against Thor’s Hammer). Company application security is much like Oobleck. When not put under stress, security appears to be a fluid mess of policies, procedures, guidelines and a host of other controls that seem to have no real connection. But when there’s an event of interest, incident or even a breach, those policies and procedures (P&Ps) come together to make their worth known.

    DevOps—What’s in a Name?

    DevOps has been around for a while now, and its definition is akin to a Newtonian fluid: Not well-defined except within each company or organization. This lack of a standard definition has its merits, though; giving each company flexibility in determining what it means for them, and the benefit of maintaining the best of development, security and operations no matter what it is called. Attempts at bringing all aspects of these disciplines together, regardless of the nomenclature used, are both old and recent. It’s a reframe of Shakespeare’s line, “What’s in a name?”

    Security has to be part of the DevOps culture, whether it’s called DevSecOps, SecDevOps, SecOpsDev or just simply DevOps. Creators of software need to go beyond the desire to have a good process and move to understand that customers need the software to be secure in addition to being useful, delivered on time and with a good UX and that the business needs to develop and maintain a positive reputation and avoid breaches to the best of its ability.

    How does one put security into the DevOps process? One approach is to proceed as if the goal is to attain SOC 2. SOC 2 reports hold great value. While not universally recognized (SOC 2 is a US-focused security controls examination), they give useful details about the controls used. While SOC 2 is not on the level of ISO 27001, for international (to the USA, that is) prospects, it still divulges security control details that aren’t present in other standards.

    What if Attestations Are too Expensive?

    AppSec transparency is not only good for improving sales but for mitigating the problems caused by third-party breaches.

    For some vendors, especially newer or smaller ones, something like SOC 2 is on their radar but not yet feasible. Why? Cost–those and other attestations are often expensive. Is it worth it? Yes, but not if the financial expense will put the company at risk. Whether one has achieved SOC 2 or not, potential customers want to see transparency in a company’s security controls.

    In the process of going for SOC 2, there are two advantages: 

    • You’ll improve your security posture.
    • You’ll be ready for when those opportunities roll around.

    Let’s get started.

    Pieces of the AppSec Puzzle

    Actually, let’s back up a bit first. There are some policies that cover multiple areas of the company or product: Infosec policy, risk assessment, vendor management and acceptable use (AUP). These will require full company interaction and arrangement. I want to focus on what you can do, starting today, to improve your product security.

    Here are the policies to work on to put security into DevSecOps.

    • Software development life cycle (SDLC)
    • Incident response
    • Access control
    • Passwords
    • Change management
    • Logging and monitoring
    • System backup and recovery

    Each of these will require, for full effect, more people and departments than just you and your own. But these P&Ps can be directed internally toward your development and production teams; perhaps even IT and security.

    Here’s a list of each policy and its purpose:

    Software Development Life Cycle (SDLC)

    This is one of the first P&Ps to develop. You’re already doing this – just because it’s unwritten doesn’t mean you don’t do it. In the world of customer assurance, if it isn’t written, it doesn’t exist. Make it real and purposeful by codifying what you already do and improving as you go. This is a primary tool for AppSec (which includes web applications and APIs) and is almost solely within the purview of devs, engineers and QA. The product or service provided needs to have this foundational level of control to prevent common forms of attack.

    Incident Response

    This is also high on the list of P&Ps on the list. This is separate from the corporate IR plan; DevOps should have its own plan for dealing with technical emergencies, incidents and breaches. And this plan can be part of the overall company plan.

    Access Control

    Access control includes how users are authenticated and authorized, and includes least-privilege access, multifactor authentication (MFA) and service accounts. Prospects need to know that access to your production environment is well controlled.

    Company Passwords

    Company passwords as a whole are managed by IT and security, and often have a minimum of eight characters, require a certain number of special characters and other industry-standard requirements. But your software environment can go beyond that to enforce more stringent controls.

    Change Management

    Customers need to be aware that the software they bought is changed in an orderly and authorized manner, not through an ad hoc and ad lib process.

    Logging and Monitoring

    This is important for ensuring that activities such as access control and change management in your company have been performed properly, in addition to providing information for forensics in case there’s a breach.

    System Backup and Recovery

    Document and ensure your capabilities to restore data in a timely manner. Things happen; not just attacks—user errors, natural disasters, provider outages and the like.

    The process of each P&P looks something like this:

    It’s a straightforward and natural process, but the simplicity of the ingredients (like cornstarch and water) makes it very easy to overlook its effectiveness.

    Additionally, make these P&Ps available—whether in full or by using excerpts or summaries—to prospects and customers. A major part of driving security is opening oneself up to public scrutiny. This could be via a secure portal, a public-facing page or a ticket/request system.

    BONUS Assessment for Transparency

    Take a look at the Consensus Assessment Initiative Questionnaire (CAIQ) by Cloud Security Alliance (CSA). Level one, which is a free self-attestation, is an often-requested assessment. It’s fairly rigorous and may require you to level up security in your company, but it’s a well-respected and no-cost attestation and is available free for prospects and customers to view.

    The Next Step

    Inserting or improving security in the DevOps process is part of the true DevOps process. It’s a mindset and culture more than a title or official designation–and it’s possible.

  • The Everything-As-Code Revolution and the OWASP Top 10

    The Everything-As-Code Revolution and the OWASP Top 10

    After years of stagnation, the Open Web Application Security Project (OWASP) Top 10 list finally saw some shakeup.

    Most notably, insecure design debuted on the list as the number four security risk to web applications.

    “If we genuinely want to ‘move left’ as an industry, it calls for more use of threat modeling, secure design patterns and principles, and reference architectures,” OWASP says.

    That hits the nail on the head. It’s a great sign for the industry that organizations are adapting and continuing to shift left responsibly, and points toward the everything-as-code future we’ve been imagining.

    This addition by OWASP finally recognizes a key reason why organizations struggle to move the needle on addressing security issues. A lot of security today is reactive and organizations find issues long after they deploy applications, leaving security teams to act as firefighters at a time when there are too few security professionals in just about every industry.

    To effectively move forward, we need a shift in thinking.

    Studies have shown that if organizations addressed these same issues in design, they would eliminate the costs of firefighting and significantly improve developer productivity. It would also free security teams to focus on the strategic needs of security. 

    This change from OWASP recognizes that security needs to have a seat at the table when key software design decisions are made and it requires empowering security teams in the same way the DevOps teams have been empowered to own and manage the application’s security design and implementation. 

    A Unique Inflection Point: DevSecOps

    Security breaches continue to pile up, yet many organizations haven’t reexamined their reactive approach, which ignores the architectural problems causing the issues. We can’t continue to operate this way.

    We need a more dynamic and comprehensive approach to security in cloud-native applications. We need to acknowledge the failure of detecting misconfigurations too late in the development life cycle. It’s impossible to scale that way, and you end up creating too many rules in the process.

    We need more proactive engagement, which can be difficult in an application development world where velocity is king.

    Developers and DevOps teams should view security as trusted partners and engage them early in the development life cycle. They should understand that they have a shared responsibility for security. Security teams should embrace automation that fits into the developers’ workflow and makes their lives easier by democratizing security.

    The Everything-as-Code Future

    If we can continue to shift left responsibly, we’ll keep moving the industry forward in a way that will have ripple effects, including in the OWASP top 10.

    In a perfect world, we would see frameworks and application infrastructure address the input validation issues that make up a large part of the top 10 today. Those issues should be off the list and the top 10 should focus on the systemic issues—like insecure design—that lead to the current list.

    As we move toward an everything-as-code world where the boundaries between the application and the infrastructure blur, OWASP may focus more broadly on everything-as-code, which would include a new class of issues such as cloud code, infrastructure-as-code, pipeline-as-code and security-as-code. While there’s certainly more work to do, that would be a strong signal that we’re moving in the right direction. 

  • Lock Down Your Toolchain

    Lock Down Your Toolchain

    We have done amazing things with Agile and DevOps, increasing IT responsiveness to levels that most people would not have believed and our business counterparts only dreamed of even a decade ago. Think about it—we can check in a single source file and kick off a chain of events that involves half a dozen or a dozen software tools that collectively shepherd an entire application through the development process to deployment. Through all of that, only deployment might require human interaction, depending upon corporate policy. In many places, even deployment does not require a person. Just development.

    We didn’t get to this point by moving slowly, and sadly, we did not get to this point by acting in a security-first manner. Thanks to the security-toxic mentality that DevOps was born in, we have had to go back and try to bolt on security where it was ignored initially. But we’ve largely managed that process. We have tools that handle privileges, monitor connections, scan source, look for vulnerabilities in support software, even scan entire container definitions before the build.

    Know what most of you still don’t have? A truly secure toolchain. This is bad policy. A knowledgeable attacker is going to go after one of the aggregate locations. Places like container management servers that give them access to a lot of resources. Or the toolchain, which gives them access to every bit of software the organization develops. If an attacker wants to do code injection without detection, the toolchain in charge of builds and deploys is it.

    And yet, for ease of use and keeping up with iterations, many of you have credentials for the toolchain stored in easily accessible places so that whichever tool is running the show has access to credentials for each piece of the toolchain. I wish I could say “No one keeps that data in flat files anymore,” But alas, I cannot.

    One of the reasons it is not sufficiently secured is that build toolchains fall somewhere between Dev security and Ops security. That means our teams that came from a development background are not focused on security for the build chain, and our teams/team members that came from an ops background are not focused on the toolchain selected and often initially deployed by developers.

    Which brings me to my recommendation. Put security professionals on the toolchain to verify it is locked down at every step. There are a lot of places for the toolchain to be insecure, not just poorly stored credentials. And the toolchain touches all of IT’s crown jewels.  So make sure it isn’t wide open. If your organization doesn’t have dedicated security staff, bring in consultants to review the toolchain and make recommendations. There are some great security teams for hire out there that will be happy to lend a hand.

    And keep rocking it. Your teams are building and deploying at a rate never seen before—even if DevOps is “slow” at your org, it is still likely faster than its predecessors—for doing anything. So keep working miracles, and lock down your castle’s the inner keep.

  • Future of DevOps: Trends to Watch

    Future of DevOps: Trends to Watch

    Technology is transforming every aspect of industry, and digitalization and automation have flourished in the past few years. DevOps has established itself as an indispensable software development methodology for successful digital transformation.

    According to a recent market survey, the DevOps market will exceed $20 billion by 2026, growing at a CAGR of 24.7% from 2019 to 2026. DevOps has facilitated rapid and dependable software development, delivery, improved quality and higher customer satisfaction.

    DevOps, too, is continuously evolving to meet the changing demands of the corporate environment. Let’s look at the future of DevOps and the trends you should expect to see.

    Serverless Computing

    DevOps teams will see a rise in the adoption of serverless architecture, mainly because of the massive capital and operational costs of server infrastructure. Numerous DevOps groups are working with modular components offering an overview of the pipeline. Moving these modular components to serverless architecture will empower groups to mitigate a few pieces of errands identified with pipeline architecture and focus on deployment and development of the product.

    Serverless computing streamlines overall DevOps operations, including the complete software life cycle, from development to deployment, testing and maintenance in one place. Also, serverless computing reduces the developer’s workload by taking care of server maintenance, such as cloud monitoring and system updates. Other prime USPs include flexibility, reliability, speed and cost-efficiency.

    Microservices Architecture

    Microservices architecture has been gaining popularity as an alternative to traditional monolithic architecture in the IT industry, and this trend is expected to continue. Microservices architecture is a pattern of organizing computer systems into segments that can scale on demand. A microservices architecture pattern is the next evolution of service-oriented architecture (SOA) that structures an application as a collection of coupled services. If one piece of the application fails, microservices make it easy to identify and contain the issue without disrupting the whole application.

    DevOps and microservices architecture enable decentralized teams to innovate rapidly, maintain control over their tech stack and standards, track performance metrics, supervise the development and release cycles and reduce overall consumption time by achieving shorter software release intervals.

    Low-Code/No-Code Applications and Platforms

    To keep up with the demand for new applications and features, many organizations have turned to low-code/no-code development to deploy applications swiftly. Adopting a low-code approach with DevOps is a game-changer. It enables developers to experience higher agility and gives the organization a competitive advantage in the fast-paced, demanding software market.

    Low-code applications allow non-technical ‘citizen developers’ to contribute to software development with the help of visual interface integration. In addition to end users, developers and DevOps engineers are set to play a crucial role in this trend, using low-code platforms and tools that offer drag-and-drop elements and other extensions. These low-code application development tools support every aspect of software development, including app ideation, analysis, software design, code development, quality assurance, deployment and documentation.

    DevSecOps

    Many large enterprises are integrating and automating security into DevOps processes. The transformation from DevOps to DevSecOps is expected to gain even more momentum in the future. According to a forecast, the DevOps market size is expected to reach $5.9 billion by 2023 at a CAGR of 31.2% during the forecast period.

    More companies will embed security controls earlier in the software development cycle to ensure application security. Tools and frameworks will simply integrate with CI/CD pipelines and testing tools will see a rise in 2022. DevSecOps empowers developers to consistently track, monitor and remediate security defects during the various stages of development while improving the speed of delivery and quality.

    Kubernetes and GitOps

    Kubernetes is an open source container orchestration platform emerging as an infrastructure trend on the operations side. Kubernetes will expand further into the software development space in 2022 and beyond. It will ease the task of starting a local Kubernetes cluster on a developer’s machine. Kubernetes security is expected to take center stage as well, through infrastructure-as-code (IaC) scanning.

    GitOps is a Kubernetes-related infrastructure trend that allows developers and IT operators to use Git to manage clusters and deliver efficient, secure applications without misconfigurations. It automates releasing incremental updates, and consistent delivery will enable developers to build, test and deploy software rapidly.

    AI and ML

    Artificial intelligence and machine learning have already transformed the way businesses operate nowadays. In 2022, it is anticipated that AI/ML will further streamline and accelerate every phase of the SDLC. It enables DevOps teams to enhance their performance through intelligent automation, improving feedback and managing alerts.

    Advanced analytical methods like predictive analytics are becoming increasingly important as the market evolves. AI can enable proactive investigation of the DevOps pipeline to identify problems and offer possible solutions. AI and ML integration also enable deep learning, data mining, statistics and modeling, becoming an integral part of your business’ workflow.

    Conclusion

    DevOps continues to evolve and pivot to drive significant IT transformations that directly bolster business goals and objectives. It will assist in enhancing the company’s ability to design, produce, launch and maintain high-quality software solutions. The above trends will help organizations move rapidly beyond automation, focusing on continuously improving outcomes. These trends are catalysts for creating a regular and dependable release pipeline and building better communication between development, IT and business teams.

  • How DevOps Teams Can Defend Against API Attacks

    How DevOps Teams Can Defend Against API Attacks

    Remember when ransomware was the main security threat that DevOps teams needed to worry about?

    Those days are over. Ransomware attacks are certainly still happening, but API security breaches—which increased by a whopping 600% in 2021—are now poised to become the top attack vector for threat actors, according to Gartner.

    That’s the bad news. The good news is that, in many respects, the security practices that DevOps teams already have in place to defend against ransomware can be repurposed to deliver API security, too—with a few tweaks.

    Keep reading for a look at the state of API security today, along with tips on expanding upon DevOps’ existing ransomware defense techniques to protect your APIs.

    The Preponderance of APIs

    Although it may seem surprising that APIs have suddenly become an attacker’s best friend, it’s actually not when you step back and think about how deeply dependent we’ve become on APIs over the past half-decade.

    APIs have been around for a long time. But until relatively recently, APIs were used mostly for specific types of applications, B2B or infrastructure integrations. It wasn’t until the pivot toward microservices and distributed architectures that internal (or east-west) APIs became the glue that holds application environments together and carries information (which is sometimes sensitive) between the components and micro-components of an application.

    As for external APIs, publishing public APIs has become a basic expectation for virtually any business with a software product—to the extent that there are now something like 22,000 public APIs out there as well as several orders of magnitude more internal APIs.

    The result is a world where APIs create potential attack vectors against virtually every application or service. It only makes sense, then, that the bad guys are increasingly focusing on exploiting APIs as a means of obtaining access to things you don’t want them to have.

    From Ransomware Protection to API Protection

    You might think that securing APIs requires fundamentally new security tools and practices. In reality, though, there are extensive parallels between mitigating ransomware risks and mitigating API security risks. And DevOps teams are a major line of defense against these.

    Here’s how to extend an anti-ransomware strategy to an anti-API-exploit strategy.

    Prevent Lateral Movement

    Like ransomware, which propagates from endpoint to endpoint laterally by exploiting flaws and vulnerabilities, API exploits also typically spread laterally across an environment.

    This means that even if you can’t prevent all API (or ransomware) attacks from breaching your perimeter, you can take steps to make it hard for breaches to expand. By detecting malicious activity inside your environment early on, you can stop lateral propagation of the threat before it leads to a largescale compromise.

    Focus on Data Security

    Ransomware attacks and API attacks are both focused on compromising the same crown jewel: Your data. Ransomware attackers want to hold that data for ransom. API attackers—such as those who stole sensitive information from compromised Peloton accounts, or others who breached LinkedIn’s API to scrape data about 700 million users—typically want to exfiltrate it, possibly to resell it or maybe just to harm your business’s reputation.

    Mitigating both ransomware risks and API security risks, therefore, boils down to securing your data. By enforcing strong access controls and segmentation over what both internal and public APIs can do, you mitigate the risk of data exfiltration due to API security breaches.

    Use Behavioral Security Models

    Investing all of your signature-based security controls in attack prevention doesn’t work well for either ransomware or API attacks, especially when they are zero-day or unknown attacks. While you certainly should do what you can to harden your environment, it’s impossible to guarantee that a breach won’t slip past your defenses.

    That’s why deploying behavior-based security models is key to protecting against both ransomware and API attacks. Behavioral security models detect anomalous activity inside an environment, such as unusual types of requests or strange request patterns. By modeling and baselining behaviors and detecting anomalies based on your model, you can prevent attacks from spreading once they are underway.

    Don’t Rely on Perimeter-Based Defenses

    Along similar lines, trying to protect the perimeter of your environment is not a surefire defense against either ransomware or API attacks. Instead, you need to distribute protections across all of your endpoints, applications, services and so on.

    Again, nothing will guarantee that attackers won’t get in. The success of your defense hinges, in large part, on your ability to make it hard for them to escalate their attack from a small-scale breach into one that impacts a wide array of resources.

    Look Beyond the Surface

    Ransomware and API attacks are similar in that both often involve attack methodologies designed to elude common security monitoring tools.

    For example, attackers might try to leverage ports 80 or 443 (the default HTTP/HTTPS ports), which will almost always be open on firewalls. It’s therefore imperative to avoid relying just on standard ports or on encryption to protect API traffic. Instead, you must look deep into the payload, then parse and understand the protocols. It is also important to monitor and collect data from multiple sources, then correlate and analyze them to a get a deeper understanding of what is actually going on within the environment.

    Conclusion

    To be sure, ransomware attacks and API security attacks are fundamentally different in some respects. They involve the exploitation of different protocols and the goals of attackers are usually a bit different.

    But in terms of how attackers operate, what they want to steal (your data) and the limitations of perimeter-based defenses, ransomware attacks and API attacks are actually pretty similar.

    That’s why developers and DevOps teams don’t need to rethink their entire security strategy to cope with the surge in API attacks. Instead, do what you’re already doing to protect against ransomware and use those techniques to help secure your APIs, too.