devopsy.kinsta.cloud

Tag: application security

  • Game On: Secure Coding Virtual Summit 2021

    Game On: Secure Coding Virtual Summit 2021

    Agile organizations are looking for ways to win at security without slowing down their release cycles. That’s where DevSecOps comes in. The days of a hands-off security approach for developers are over. Organizations implementing DevSecOps to integrate security into their DevOps framework are able to release secure software faster. Developers test code for potential security vulnerabilities earlier in the pipeline to fix security issues in real time to avoid costly delays.

    At Secure Coding Virtual Summit 2021, industry-leading AppSec and DevSecOps practitioners, analysts and visionaries will come together to share their best pro tips and power ups to level up your code security. The agenda for the virtual event, taking place March 24 from 10 a.m. to 6 p.m. ET, features a mix of topics including AppSec, threat modeling, API security, container security, case studies and more.

    The most brilliant security luminaries from OWASP, Okta, Microsoft, Secure Code Warrior, WhiteSource and many other well-known IT companies, will discuss:

    • How to level up your secure coding strategies
    • How to run an AppSec program with open source projects
    • The best practices for securing your APIs, the attack surface of an API and common authorization problems
    • The concept of threat modeling, its objectives and its role in the SDLC
    • How to transform developers into security people
    • How easy (or not) it is to get a container or Kubernetes cluster hacked on purpose
    • How to create an AppSec pipeline with containers in a short period of time (demo)

    This year’s Secure Coding features outstanding industry leaders, such as:

    • Vandana Verma Sehgal, global board of directors at OWASP
    • Simone Curzi, cybersecurity principal consultant at Microsoft
    • Keith Casey, API problem solver at Okta
    • Matias Madou, CTO and co-founder at Secure Code Warrior
    • Matthew Coles, senior principal product security engineer at Dell
    • Sarah Young, security architect at Microsoft
    • Chris Romeo, CEO and co-founder at Security Journey
    • Dr. Phillipe de Ryck, web security expert and founder at Pragmatic Web Security
    • Richard Greenberg, founder and CEO at Security Advisors LLC
    • Izar Tarandach, principal security engineer at Squarespace
    • Jeroen Willemsen, principal security architect at Xebia
    • Shiri Ivtsan, director of product at WhiteSource
    • Justin Hutchings, director of product management at GitHub
    • Matt Tesauro, senior partner at 10 Security
    • Matthew Butler, principle engineer at Laurel Lye

    Attendees will have access to useful resources and will be able to interact with sponsors to power up their secure coding strategies. There will be live Q&A chats with keynote speakers to get your burning questions answered. Attendees will also have the opportunity to hunt for Easter eggs to boost their player score for a chance to win a PlayStation 5.

    To see the full agenda and to register, please visit the Secure Coding website.

  • Application Security and Continuous Observability with DeepFactor

    Application Security and Continuous Observability with DeepFactor

    Today’s modern applications are becoming increasingly complex and released more frequently than ever before, therefore increasing security, privacy and compliance risks. How do you identify the security and compliance risks hidden in your application before you deploy it to production?

    Continuous observability enables DevSecOps teams to observe millions of application telemetry events and find runtime security, compliance and privacy risks within the DevOps pipeline, while providing AppSec teams the ability to set guardrails and have continuous visibility with every build.

    In this TechStrong TV interview with DeepFactor Founder and CEO Kiran Kamity, we discuss the concept of observability and how to apply it for security and compliance. We also talk about the increasingly important role of AppSec and DeepFactor’s new Observability-as-Code API, which enables DevSecOps engineers to leverage observability functionality in their CI pipeline and gate builds.

    The video of the conversation is below, followed by the transcript. Enjoy!

    Transcript

    Mitch Ashley: I have the pleasure of being joined by Kiran Kamity, who is founder and CEO with DeepFactor. Welcome, Kiran.

    Kiran Kamity: Thank you, Mitch.

    Ashley: Great to have you. We’re gonna be talking about observability, super-hot topic, but before we get there, tell us a little bit about yourself, a little bit about your background, and then a little bit about DeepFactor.

    Kamity: Awesome, yeah. I came to the Bay Area about 20 years ago. I did my undergrad at the Indian Institute of Technology in India in Chennai, and then I came here to Stanford for my grad program. Once I came to the Bay Area, you get addicted to the entrepreneurial spirit, you never leave, this becomes your home. Happened to most people—happened to me as well.

    So, the Bay Area is my home, and I’ve had a mix of enterprise and infrastructure cloud computing, virtualization, and DevOps/AppSec kind of background over the last 20 years. I’ve done two companies as a Founder, which were acquired by other companies like Citrix and Cisco. My first company, RingCube Technologies, was acquired by Citrix. We built a container run time for the Windows Operating System before the Docker days. This was acquired by Citrix in 2011, so I was responsible for some of the product teams at Citrix after the acquisition.

    Then the bug bit me again, and I started ContainerX, which was a turnkey containers in a box type company, which was acquired by Cisco, and it’s now called Cisco Container Platform. While at Cisco, I was Head of Product for the Cisco Cloud Business Unit, which included container—container networking, OpenStack, and some of the other initiatives that they had.

    During that time, as I was looking at what to do next and analyzing the market, a lot of the learnings came to the following. There’s a lot of momentum that has happened so far in cloud native architectures, DevOps, et cetera. And the learnings were that the next wave of innovation is going to be as DevOps becomes DevSecOps. And that’s why I started DeepFactor, and we believe that the next wave of innovation in the world of DevSecOps is observability.

    Ashley: That’s something I both relate to and also am just fascinated by other entrepreneurs is that story of, you’re working on what you’re doing now and you’re still kinda looking at, “Well, what’s the next thing coming up, and what might I go do next?” and then you go off and solve the next problem.

    Kamity: Yeah, absolutely.

    Ashley: Start another company to do that—like you said, you get the bug, it’s kind of a fever. [Laughter] It definitely is.

    Well, cool. We’re talking about observability, and it does seem to be the hot topic of kinda late 2020, early 2021. So, let’s first start with kinda how did we get there—get here? How did we get to this place where suddenly observability is a thing and not only a thing, but important to a lot of people?

    Kamity: Yeah. Just to qualify it a little bit, our focus at DeepFactor is applying the concepts of observability for security and compliance, which is truly novel, and there’s very few companies that are trying to do that.

    Ashley: True. Observability can mean just sort of the next elevated monitoring, right?

    Kamity: Exactly.

    Ashley: So, you’re [Crosstalk] around security.

    Kamity: So far, a lot of the observability plays have been in the logs metrics tracing. Applying the concepts of observability, truly as the next generation of evolution of APM. But at DeepFactor, we’re leveraging the concepts of observability for identifying security and compliance risks in your applications before they go to production.

    So, to answer your question about how did we get here, let’s take a step back and analyze what has happened over the last few years, with respect to application development, right? Apps have become a lot more complex than they have ever been today. I mean, think about it—a common application is made of a bunch of different languages. You have a Java service, you have a Node.js service, and you have Angular in the front end, you have lots of different pieces, you have a database, et cetera.

    You have a lot of third parties—third party libraries that are baked into your services, third party components that are not built by you such as Nginx and MySQL and MongoDB, et cetera, that become part of your application.

    Ashley: A lot of open source, right, in that stack.

    Kamity: A lot of open source. Applications are now also being deployed in a bunch of different ways. You have applications that are not containerized, still mainstream. You have containerized applications, you have full on Kubernetes applications, and you have land applications as well, so the deployment of applications has become complex as well.

    So, in this world of applications becoming a lot more complex than they’ve been, what essentially happened from a security perspective is that the attack surface area of your application has significantly increased. It is the highest it’s ever been so are, and it’s only gonna go that way.

    Let’s take a look at a few other trends that have bene happening in industry. The velocity of releases—that has gone up as well due to DevOps. You’re no longer building or releasing an application once at three months, once at six months. You’re releasing that multiple times a week with DevOps, and different companies are different aspects of that spectrum, there.

    Now, when things are more complex and they’re being released at such a rapid pace, there is no way humanly possible for your AppSec teams to find all of the security risks and compliance risks that lie in your application before they deploy to production. At the same time, the risk of these issues being in production is higher than it’s ever been. If you think about it, the sophistication of the bad actors has increased significantly as well over the last few years, and therefore, the nature of the breaches, the size of the breaches, and the damage that they can cause has increased as well. Coupled with that, privacy concerns have increased, resulting in standards like GDPR and CCPA and all of those things emerging as well.

    Now, in such a landscape, you’ve got to automate identifying the security and compliance risks that are hidden in your application before you deploy your application to production. And that is where the current tools of just code scanning or identifying issues based on signatures or just DAST scanning your application, et cetera, don’t cut it. You need something that watches your application while the application is actually running in both pre-production environments as well as in a canary deployment of minimal production deployment before you release it to your broader production deployment.

    And in that environment, you’ve got to be able to watch the millions of events that are happening inside your application, take that data, analyze and find the needles in the haystack, and therefore determine where the security and compliance risks are and pass on all of this information with rich evidence such as stack traces, metrics, and whatever it takes to fix these issues back to the developers. And a lot of this has to happen in a seamless manner that is nicely tied into your DevOps kinda pipeline, and that’s where observability applied to security and compliance comes in, and that’s exactly what we call continuous observability at DeepFactor.

    Ashley: Interesting. I know, talking with you previously and kinda hearing about DeepFactor, you all talk about start left, not shift left—this idea that, really, it starts from the beginning, not, “Let’s kinda push it as far left as we can.”

    Kamity: Yeah, absolutely. If you think about it, we’ve had operator specific tools emerged in the last five years with respect to security. So, you’ve had container security tools that identify issues in your Kubernetes configuration or your Docker configuration or vulnerability scanners that identify issues in your host operating system if you’re deploying your app in a VM.

    Now, those are all the types of insights. Are there any misconfigurations that could lead to security issues that are very relevant for the Ops people? And those tools are coming up with the idea of shifting left, because you need to find these configuration issues before you go to production so that the Ops people can deploy these applications properly.

    But when it comes to developers, their agenda is not securely deploy your application. They don’t care, honestly, about how you’re Docker or Kubernetes is configured, for the most part. They care about what is in their application, securing at the source. And when the agenda for Dev teams is to secure at the source, then all you care about is—what is my application doing, whether it’s my application or some third party that I brought in, or just my interpreter itself when it is running? And can I identify the risks involved and understand my attack surface within the application ahead of time? And that’s why we call it start left.

    So, we think that operators care about shifting left. Developers should truly care about starting left.

    Ashley: Yeah, it’s interesting, because your point about code scanning and DAST approaches to security is, from a code standpoint, you do wanna be writing a secure code, so it’s a valid thing, of course, to be doing. But you mentioned Lambda, you mentioned, of course, infrastructure as code, essentially, where all this is dynamic, right, in our environments today, and more so, not less, every day, right?

    Kamity: Yes.

    Ashley: Every day, it gets to be more dynamic. Now, you’re really talking about the whole context of the environment with the application. Kind of, if you thought about it in the network, you’d say all seven layers, right? If you think about it in the security stack of software, it’s application plus all of the other things, right?

    Kamity: Yes.

    Ashley: It’s interesting what—how do you find people are accepting this idea of run time information being provided with context, you know, this rich information you were talking about, is that something new to developers or like, “Oh, my gosh, I’ve been waiting for this forever” or, “Well, this is really cool. Look at—let me see what I can do with it”? What’s more the experience that developers have?

    Kamity: Yeah, so, I think different organizations react differently to something like this. The old way of thinking is—oh, developers don’t care about security or compliance.

    Ashley: I’ve never met a develop that wants to write insecure code or unsecure code. [Laughter]

    Kamity: Exactly, right? That is exactly what’s happening now where, given the consequences of shipping insecure applications and given the need to be more and more secure at the source, I think developers—and just simply because it’s just not humanly possible for your AppSec teams to identify all these things. Given the talent shortage of the AppSec skill set as well, it is, the responsibility if identifying these risks has to be borne by the developers. Because at the end of the day, the developers are the ones that are writing the code and you’ve got to make sure that you’ve shipped secure code.

    Engineering leadership and AppSec teams in various organizations that we’ve been working with have been fully accepted. In fact, they’re fully aware. In fact, a lot of them want this kind of concept, it’s just the lack of tooling today. Because if you think about the current tools that are available, they’re doing the best they can with the existing set of tools.

    I mean, they’re scanning the code, they’re trying to scan the application from time to time—but those tools don’t lend themselves well, nicely into seamless integration into your CI pipeline, and therefore, giving developers the insight about, “Hey, here’s where we saw your application did this.” That can only happen with observability tools like what we’re building, because we watch every thread of every process of every service in your application when it is running in test and even canary deployment in your part of production before you deploy that thing widely to a larger section of production. And that is the kind of insight developers do care about.

    What we have gotten repeated feedback as we have been building this product with a few development partner type enterprises so far is that, the insights that we have needs to be enriched with richer evidence information so that developers can actually take that evidence information and directly go fix the problem. So, we’ve augmented our insights with stack traces wherever appropriate. You know, obviously, the good old things like CVE numbers and things like that, we have that.

    But what we focus more on is not just giving you a list of CVEs, but complementing the insights that your software composition tools give you by giving you run time usage information of that CVE. For example, we can tell you if a tool like Snyk will tell you there are 250 vulnerabilities in your application, DeepFactor will tell you, “Hey, there are 250 vulnerabilities according to what Snyk is telling you. Fifteen of those things have been used by your application at this time, when your application was executing here, ad here is the function, here is the call stack.”

    So, that will make it easy for a developer to go, “Okay, now I don’t have to get overwhelmed with fixing all of the 250 things or adding that to my backlog, I can actually prioritize which ones to fix first, because that’s what my application is actually doing.” It’s not about the whole thing that has been checked into your source code, it is what your application’s actually doing that will help you catch the more important things. It’ll help you also reduce the number of alerts that can inundate you.

    Now, with all of these changes, the rich evidence, reducing the number of alerts, and to the point, alerts based on what your app is actually doing, developers are finding it more and more meaningful, our insights. And as we grow the company, that’s gonna be our primary focus.

    Ashley: That’s always been the challenge with vulnerability scanners and code scanners is, yes, I get all of those results. What of those are real? Yes, they’re all theoretically possible. I may not be using it in a way that actually exposes me to that CVE, that vulnerability.

    But what you’re saying is, you’ve actually detected the use in the application or the software stack of something around that CVE that’s worth looking at. Hopefully, you’re cutting down on the number of things that are actually, they go look at. You can ignore the rest, if you will, or at least know that they’re much less likely to be an issue.

    Kamity: Yeah. We do not give you too many alerts. We give you the alerts that are relevant for your application because we watch the millions of events that are happening in your application in every part of your application, across various layers of the stack—like, system caller interface, library calls that your application has made, network behavior, web and API, all of that.

    And based on that data, we treat it as a data problem. So, we take that data and then we try to identify anomalies and detect that these are the risks that lie in your application from a security perspective, and this is how it maps into compliance. So, we will tell you that these are the security risks in your application and in our next module of the product, we’re gonna tell you that this can hurt your PCIDSS, and here’s the number, basically.

    Ashley: Mm-hmm. It definitely is gonna improve your relationship with the security and compliance team, right? If you’re solving these problems before it gets to them, they have to ask, “Well, did you do anything about this? Are we susceptible?”

    Kamity: Yeah.

    Ashley: Talk a little bit about—so, where in the tool chain and the workflow pipeline, where do you fit? Where does DeepFactor play?

    Kamity: Yeah. The best way to think of us is, if you take a step back, if you are thinking about your DevSecOps initiative in total, you want to plug in into a bunch of different points from a security perspective into your CI pipeline. Your developers write code. The next step should be you try to find risks in your code. That’s where the SaaS tools come in, they find the risks that are there in your code.

    Then you create your build artifacts—let’s say, your executables, your container images, and whatnot. Then you try to find risks that lie in your build artifacts. That includes your code, any third parties that you’ve compiled together and created your services. It’s still static, though. You’re not running them yet. Tools that allow you to identify risks in your build artifacts could be container scanning tools, like image scanning tools that scan your container images and find issues or software composition analysis tools like Snyk and Black Dock and tools like that. These tools find vulnerabilities that exist in your components after they’ve been built.

    Then you run your application, you’re testing your application. Either you’re testing it in a test environment or you’ve deployed and you’re testing it in a minimal configuration of your—like, a canary deployment in your production. During that time, you’ve flicked DeepFactor on. DeepFactor doesn’t require any changes to the code of your application; you’re simply running your application.

    And that’s where we’ve built a significant amount of IP. You know, my Co-founder, Mike Larkin, he’s the CTO, he’s the father of the OpenBSD hypervisor. And our senior engineering leadership members came from Qualys and FireEye, having been in the area for 20 plus years working on security products, each.

    So, we’ve created something that involves zero touch, pretty much. You don’t have to touch your application at all, you simply run a command called DFCTL, just like KubeCTL, we came up with DFCTL. So, you do DFCTL, run your app; or DCFTL, run your container; or you drop it into Kubernetes. We have a webhook admission controller that you simply drop into Kubernetes, and then any pod that you want to be monitored, you simply can specify a config file and that pod gets monitored automatically with DeepFactor.

    Now, the way DeepFactor inserts itself is completely behind the scenes. It’s language agnostic. You don’t have to worry about, is it Java, is it Node.js—DeepFactor figures out that it’s Java or Node.js and does some specific things and finds out more information.

    So, you simply run this, your application is running in your test environment or your minimal production environment, DeepFactor observes everything that it’s doing. When the tests are done, it tells you—you throw your automated tests at it while your application is running, just like normal. And then when it’s done, DeepFactor gives you all of that information about what insights have been found and what’s the evidence information that’s pointing to the insight. Is the issue or the risk presenting the attack factor lying in the code that you wrote? Is it lying in a third party that you brought in, or is it at the interpreter level itself? All of them are risks as far as the attacker is concerned that could be exploited, so you need to be aware of where your risks are.

    Ashley: Now, are developers putting in some library calls or DeepFactor code into their application stack as well, then? Is that how you’re getting into the software, knowing what’s happening inside as well as outside?

    Kamity: Actually, that’s the beauty of our IP, and we’ve filed a few patents in that area. Developers do not need to write any code to change, or change anything in their application. You simply enter DFCTL and run your app and DeepFactor inserts itself into the application at your run time, completely seamless to the developer, and when it’s done, it unplugs itself and your application and gives you all the insights.

    Ashley: Wow. That sounds pretty cool. I can imagine that’s a big plus for developers. [Laughter] Yet something ls they don’t have to debug, right?

    Kamity: Exactly, yeah. That’s the significant part of our IP.

    Ashley: You know, it’s interesting you mentioned your team comes from a number of other security companies that have been around for a while—you know, you mentioned Qualys and others starting in the scanning, the vulnerability management space some time ago; that’s about when I got into security, too.

    What do you think we’ve learned from those types of companies and those experiences that we’ve sort of changed our perspective about where we are today, just given—yes, we have much more complexity in software, much more porous security issues, but what have we learned from all of that security scanning that’s helping us?

    Kamity: Yeah, no, I think there have been numerous, numerous learnings, and the learnings have evolved over time as the landscape of application development has changed as well. You know, you’ve had tools in the past that were designed based on the applications of the past. But tools of today and tools of tomorrow are different, because the applications of today or the applications of tomorrow are definitely trending in a different direction.

    One example of the thought process itself is that, you know, when things are in single digits or a lesser number, it’s okay to have manual scanning, manual testing, once in a while test it and then find information, which is kinda the old kind of scan once in a while, identify it, or bring in a pen tester once in three months, you know, check some boxes and get it done kind of thing.

    Those are all great and they’re still relevant even now. What has become even more important is why you do those once in a while scans and checks. You’ve got to make sure that you get in the habit of securing at the source. You can no longer imagine that your infrastructure or the perimeter is gonna secure your application properly. You’ve got to make sure that you build your application securely to start. And that fundamentally has changed the kind of tools that we need to build in order to equip the developers who build applications to secure at the source.

    At the same time, I think the role of AppSec has become even more important than it has ever been. Because, you know, sometimes I keep getting asked, “Oh, are you saying that developers should use these security tools? That means the AppSec teams are no longer relevant?” That is totally wrong, because AppSec teams, their job is increasingly more relevant. Because if you take a step back and you look at the number of attack vectors that are there in your application, we just talked about how your pipeline should be architected—secure at the source, making sure that you scan your code, scan your builds, test your running applications, and identify risks in all of these areas—who ties them together? Who comes up with this overall strategy? Who comes up with that triaging process and passing the evidence back to the developers, identifying which ones are important and which ones are not?

    All of that should come from the AppSec person in the team—AppSec or if AppSec is assimilated into your DevOps and we call it the DevSecOps person, that’s the role of this person is to make sure that he or she is the shepherd of your CI pipeline from a continuous security perspective and then feeds all of that information back to the relevant parties. Some of that could be your developers, some of that could be to your engineering leadership, and some of that could be to your security leadership.

    Ashley: Mm-hmm.

    Kamity: That is how I see the organizations of tomorrow shaping up, learning from what has happened over the last 15 years to 20 years of innovation in this area.

    Ashley: I think that makes a lot of sense. Otherwise, (a) we’re just throwing tools at it, everybody’s doing whatever and who knows whether that’s helping us improve and improve security. And you mentioned the data coming out of it, right? That can also be used for continuous improvement, continuous learning, what are trends that are happening in our application?

    Suddenly we’re seeing much more of this technique or this architecture or this environment being deployed that, you know, not always do the security people have exposure to that early on in the process. So, it’s a good way just to know what the heck is goin’ on and then also, you have an idea about how all of your security tools, developer or non-developer, fit into an architecture that makes sense.

    Kamity: Yeah, exactly. I mean, imagine flipping a switch and identifying, “okay, these are all the touch points that my application has and these are the millions of things that it’s doing” and condensed very well to, “these are the red dots in that whole story, and this is where your risks lie.” That’s powerful, and I think it’s the AppSec person’s job to set all of that up and make sure that a framework is created and then say, any time something that comes up, you know, make sur that you pass it on to the developer with the appropriate evidence and work with the engineering team to decide.

    Because when you have so many different services and so many different languages, the AppSec people, especially because they’re already short staffed, cannot possibly know everything about the business logic of the application, resulting in those decisions that could have been made to bring in component X and component Y and whatnot.

    Ashley: Mm-hmm. You know, Kiran, one of the things that I’ve said over time is that security people need to get a greater understanding of software architecture. They don’t need to have to be developers, right, that’s not what their skill set is, nor necessary their desire. But you can’t treat security as this hard outer shell, you know, we just keep making it smaller and smaller. And now all you’ve got is thousands or hundreds of thousands of small outer shells and now you’re not securing anything, any more.

    It seems like the AppSec team can play a really important part of helping bridge that gap of what are we doing specifically, what are the architectures that we’re using, what might be some of the security risks that maybe a security engineer is just not fully up to speed on or trying to keep up to speed on as it’s changing?

    Kamity: Yeah, absolutely. Imagine the power of flipping the observability switch and the AppSec person going and saying, “Hey, Dev team, we noticed that in this particular piece of your code, you’re using an API that has been deprecated by the operating system” or, “In this particular piece of code, you’re invoking memory improperly, because this tool is showing me exactly what was done when this particular area of memory was allocated with the wrong permissions. Or, “This is an area of code where your interpreter is doing something wrong. Is it possible for us to go change the version of the interpreter that we’re using, maybe upgrade it to the latest version or put a patch?” Or, “Do we need to, in order to mitigate this thing, assuming that there’s no fix in the interpreter, do we need to go put something in our WA in our infrastructure to block the particular attack from happening?” Or, “Should we report this problem upstream to Java itself, the Java community itself, so they can go fix the problem in there?”

    So, lots of different things that could be done once the AppSec team is empowered with this much rich information about what’s happening in the application.

    Ashley: You know, something I don’t know that we talked enough about, we talked about how rapidly and how quickly we’re delivering software applications now. The environment of the software, the API calls we’re using, the libraries, the services, interpreters—all of that is changing in parallel very quickly. Sometimes you don’t feel like you have time to keep up with it, or that’s all you do is spend your time keeping up with that, not kinda delivering business value.

    I think folks that are maybe not involved too deeply in the software creation process really realize not only the complexity but how much change there is to deal with. There’s a lot that goes into that. We talk about technical debt or backlog or whatever—it’s a lot more than that, there’s much more to it. [Laughter]

    Kamity: Absolutely, there’s a lot more than that, and I think having an informed security team as well as, you know, coupled with a structure and the right tools baked into your pipeline, which results in informed Dev team, can result in goodness overall. You’ll end up identifying security and compliance risks earlier in your Dev cycle. You’ll end up fixing those things earlier, and therefore, you will end up shipping a much more secure application, and it’s a cycle. Every time more developers check in code, you know, this kind of identification happens automatically, and you end up identifying more and more risks and fixing more and more things, resulting in more and more secure applications into prod.

    Ashley: Mm-hmm. Awesome. Well, what are some things folks might have access to you can help them get started? Obviously, they can download HIV testing product or get involved that way. Do you have some other tools or things that they might be able to use to make it approachable to get into this kind of an approach?

    Kamity: Yeah, they can go to DeepFactor.io to check out the product, understand more about the product. And if they want to get started, they can either download the community edition that is now free for 10 user teams or less. If you need any help with setting up the product, you can reach out to our Customer Success person.

    We’re also giving away a free DevSecOps Risk Assessment to companies that are working with us as we expand our organization more. This will help any engineering team or any security team to get a free assessment of what DeepFactor can find in their applications so that they will be able to identify, “Okay, these are the kinds of things DeepFactor finds, and it’s useful for me and here’s where I need to go next” kind of thing.

    So, that DevSecOps Risk Assessment is completely free. Contact us, hello@deepfactor.io or just go to the website to learn more.

    Ashley: Awesome, great. I know you’re also speaking at the Cybersecurity 2021, I think you have a couple of sessions there, right? The dates are March 4th and 5th for that event.

    Kamity: Yeah. We have a couple of speaking sessions at Cybersecurity ’21. We have a virtual booth there as well, so do check us out. There is a—you know, our team can answer any questions or even try to explain to you or help you understand what DeepFactor can do and identify in your application.

    Also, today, we’re launching Observability-as-Code. It’s a new module that we’ve created, and a product that allows people to bake in observability into their CI pipeline, similar to how Infrastructure-as-Code enables DevOps and DevSecOps folks to spin up, spin down infrastructure in their CI pipeline itself and other related scripts. You can do, now, the same thing with observability for security and compliance with DeepFactor. So, you can use our API, we have a Swagger doc ready, you can use our API to invoke DeepFactor as part of your CI pipeline, get the results, triage the results, use that results to block, if there’s any P1s you want to block the _____, you can do that. You can do things like that with the Observability-as-Code API that we just announced.

    Ashley: Excellent. Well, I hope folks will check you out. I think it’s a great path to be going down, and I’m sure developers appreciate writing more secure code, but completing an application that’s more secure that they’re involved in developing.

    So, Kiran Kamity, great to have you here, CEO and founder, co-founder—I guess founder [Laughter] of DeepFactor.io. And be sure and check out the speakers that you all have at Cybersecurity 2021. It’s a great conference and we look forward to hearing more from you, there. Thanks for joining me today. Great to talk with you.

    Kamity: Thank you much. Appreciate the opportunity.

    Ashley: You bet.

    Kamity: Bye.

  • BluBracket Community Edition of Secrets Discovery Tool now Available

    BluBracket Community Edition of Secrets Discovery Tool now Available

    BluBracket today announced general availability of a community edition of a tool that employs machine learning algorithms to discover passwords, tokens and other security vulnerabilities in code.

    Prakash Linga, BluBracket’s CEO, said application secrets stored in code enable cybercriminals to compromise applications in ways that can impact an entire software supply chain. The community edition of the company’s namesake tool scans commits to determine if any new risks were introduced, and will then block the staged files from being committed. It works with any continuous integration/continuous delivery (CI/CD) platform or integrated development environment (IDE) that supports pre-commit hooks, including VSCode, Jetbrains IntelliJ and PyCharm.

    Developers are then presented with a risk score based on the number of secrets discovered in their code. For example, an active token for Amazon Web Services (AWS) would receive a high score, while a a password in a test environment would be rated low.

    The Community Edition of BluBracket can be accessed via GitHub. The free version of BluBracket can be employed to scan up to 10 repositories and sharing reports in real-time, covering more than 50 types of secrets that might be employed using any programming language.

    Linga said BluBracket also cuts down on false positives by combining machine learning algorithms with a built-in rules engine. In contrast to open source tools, BlueBracket generates far fewer false positives, said Linga.

    Linga said the Community Edition is intended to help foster adoption of DevSecOps best practices among individual developers, in hopes that when those developers are hired, their organizations eventually license the full instance of BluBracket. The company views its tools as being complementary to both tools that surface vulnerabilities in code as well as secrets management platforms, which are often not employed as widely within an organization, Linga said.

    In the wake of recent high-profile breaches that embedded malware in widely-distributed applications, there’s increased focus on securing software supply chains. In some of those instances, Linga said, it’s probable cybercriminals discovered passwords and other secrets that were inadvertently exposed in code.

    However those breaches were enabled, it is apparent cybercriminals are becoming more adept at exploiting a weakness in one application to inflict maximum damage across an entire environment. It’s hard to say exactly what role secrets discovery is playing, but cybercriminals tend to prefer the path of least resistance when it comes to exploiting application vulnerabilities.

    Of course, the hope is that adoption of DevSecOps best processes will reduce the number of breaches by shifting responsibility for cybersecurity further left toward developers. However, that’s difficult to achieve without finding the simplest way possible of getting the security tools required into the hands of the developers that need them most.

  • AppDynamics Partners With Cisco to Secure Application Runtimes

    AppDynamics Partners With Cisco to Secure Application Runtimes

    AppDynamics today announced its agent software, which it provides as part of its observability platform, now has the ability to enforce application security policies.

    Developed in collaboration with the security business unit of parent company Cisco, the Cisco Secure Application offering, available from AppDynamics, can detect attacks, identify deviations in application behavior and block attacks automatically.

    Gregg Ostrowski, a regional CTO for AppDynamics, said the goal is to make it simpler for IT teams that employ AppDynamics for monitoring and observing their IT environments to also embrace DevSecOps best practices. In effect, IT teams can now piggyback security for application runtimes on their existing investment in AppDynamics, Ostrowski said.

    The AppDynamics approach provides the added benefit of easy integration with the Cisco security tools to improve collaboration between DevOps and cybersecurity teams, Ostrowski said. Security details correlated with the application topology make it easier to share context in a way that identifies the actual business relevance of any security event, he added.

    As organizations accelerate digital business transformation initiatives, Ostrowski said the need to embrace DevSecOps best practices is becoming more urgent. The level of risk attached to these types of projects is significantly higher than with previous generations of applications, Ostrowski said.

    While most organizations appreciate the need for greater application security, there’s a debate about how best to achieve that goal. There’s general agreement that developers need to be more involved. However, shifting responsibility for application security to the proverbial left often comes at the expense of developer productivity. AppDynamics is making a case for enabling IT teams, that may already rely on its application performance management (APM) platform, to enforce policies defined by the cybersecurity team.

    Of course, there’s still a need to provide developers with the tools required to write more secure code in the first place. The debate is over how involved in the cybersecurity management process developers need to be after applications are deployed in a production environment.

    Arguably, the goal should be to enable both teams to accomplish their respective tasks in a way that doesn’t require a constant stream of meetings and updates. In the event a vulnerability is discovered, it’s critical for security teams to determine the threat level that vulnerability represents. Otherwise, remediation of that vulnerability will be just one more item in a long list of patches that developers are already working on.

    Regardless of approach, there are now myriad ways to improve overall application security. In effect, the same defense-in-depth approach that IT organizations have relied on to secure network perimeters can now be applied to application security as applications are both constructed and deployed. The most significant challenge is not so much finding the tools required to improve application security, as defining the processes through which best practices can be consistently applied.

  • Approaching Security as a Fundamental Element of Software Development

    Approaching Security as a Fundamental Element of Software Development

    How we really integrate security into the SDLC? What are some of the best practices around secure software?

    In this episode of TechStrong TV, Jill Britton, director of compliance, and Stuart Foster, product manager at Perforce, joined us to discuss how to improve application security by making security a fundamental component of the software creation process.

    The video is immediately below, followed by the transcript of the conversation. Enjoy!

    Transcript

    Mitch Ashley: I have the pleasure of being joined buy a couple of folks that I’ve talked with before on a webinar and a few other videos. Jill Britton and Stuart Foster from Perforce. Welcome to you both.

    Stuart Foster: Thanks for having us, Mitch. 

    Jill Britton: Thanks.

    Ashley: Let’s start off with some introductions. Since you’re ahead in the time zone here, Jill, how about you go first?

    Britton: Okay, thanks. I’m Jill Britton. I’m the director of compliance for static analysis tools here at Perforce. I look after areas regarding coding standards, functional safety standards, security standards, anything in that area.

    Ashley: Excellent. Stuart, you want to introduce yourself? Tell us about Perforce, too. 

    Foster: Sure, yeah. I’m Stuart Foster. I’m a product manager for our static analysis products, both Klocwork and Helix QAC. And a little bit about Perforce, we help with enterprise development and DevOps at scale. We have a lot of various tools that help accelerate development projects in terms of your planning. So we have project and portfolio management tools, requirements management tools. We have things that help in the create area of the DevOps infinity circle for issue management version, asset management, code review. We have static analysis. We have various functional test case management and things like that that also fit in the verify. And we have a lot of tools that are here to drive your product at a high quality to market. 

    Ashley: Excellent. Excellent. Well, very timely conversation at least here in the U.S. with security of software, in this case distribution with the SolarWinds situation. We’re not going to be talking about that, but strongly the topic of secure applications is right in there, right at the top of the list. Let’s first start, I know we’re going to get into some coding standards and some things like that to equip people with some things that they can use. Maybe we first start with DevOps is more than just – and shift-left is more than just, okay, let’s start having meetings or talk on Slack with the security people and then suddenly we’ve shifted left. You know, there’s a lot more to how we really integrate security into the process of creating software. Maybe, Stuart, if you want to start sharing some of your thoughts about that and of course, Jill, get your perspective as well. 

    Foster: Sure, yeah. I mean you think about DevOps, you think about agile development and it’s the ownership of code; but outside of simply delivering functional requirements for your products, your applications, you know, a lot of teams are just thinking about security. So there’s a necessary to build that in directly. And what that leads you in to is selecting tools, selecting processes to ensure that you’re kind of baking in the security into your pipelines and making it automatic. That starts with thinking about coding standards and things like that. So there’s plenty of secure coding standards that you can focus down on. I think Jill has a couple of words for that.

    Ashley: I’m sure you do. Go ahead, Jill.

    Britton: Oh, I have many, many words on that. The important thing is that you pick the standard that you are going to be comfortable with, that you are going to be able to apply. If you’re supplying a product to a supplier, you will probably be told which ones to use. But you’ve got I think that cert – oh, where, it’s from Carnegie Mellon University. They’ve been looking at security for many years now and it builds up and it also takes experience from both academia, tools, developers, actually anybody who wishes to contribute and then of course it is looked at all the contributions. So this good security standard because it is there.

    But connected to that you’ve got the Common Weakness Enumeration so administered MITRE, and that is actually just a collection of vulnerabilities that have been seen and proved in the field. So you’ve got this whole wealth of experience and you want to avoid doing what the problems other people have seen. That’s where these kind of standards come in. CWE I would argue isn’t a coding standard. It’s more a measure. You know, have I seen this problem? Have I got this problem? And there’s another related set of numbers, let’s put it that, which is common vulnerabilities and that’s even further down the line. Before you even get to see weaknesses, there are vulnerabilities and you just have to use this information in your own developments. Don’t do what somebody else has already done is kind of the way to look at it in security in particularly. 

    Ashley: It isn’t like we don’t know how to create secure software. We do but we kind of do the same thing over and over, the same mistakes, right? 

    Britton: That’s right. 

    Ashley: Sometimes just out of not knowing and sometimes just human error. Sorry, Stuart, you were going to jump in there too. 

    Foster: I was going to say, so effectively one of those, CWE is effectively describing issues that are not necessarily related directly to a language; and the other ones are specific rules that you follow to ensure that you don’t run in to these types of vulnerabilities or weaknesses, right?

    Britton: That’s right. That’s it.

    Ashley: Yeah, there are specific things that are in Java, PHP, you know specific languages that are very well used, very popular of course. Go ahead, Jill.

    Britton: No, the thing is when you look at the CWEs, they are categorized to languages or to systems or just to general sort of areas; but there are then what they call the lists. So you’ve got a list for C and a list for C++ and there’s a list for Java. Then you also have a top 25. Now a top 25 may or may not apply to your own product, but it’s always worth having a look. If those ones don’t apply, there’s another sort of secondary list. It’s emerging, and you could look there. There’s always something to check against for any sort of software.

    Ashley: Are most of the things on that list you find have been there for a while? SQL injection, buffer overflows, things like that? Or do they tend to be newer things? Are we seeing the same things over or would we find a lot of new things?

    Britton: It’s a variety. You do see the same ones over and over again. There are some weaknesses that were on the 2011 list and are still in the 2020, but there are new vulnerabilities as new types of development come in and you get more skilled hackers really. You’ve always got to consider that the hacker is always one step ahead.

    Foster: And you kind of see that these standards or these top 25 lists, they change after every couple of years and they spend their time kind of reviewing the vulnerabilities that have been found in opensource projects and other places and kind of give them a weighting. So while you may see the top 25 have a pretty similar overlap between multiple years, their rankings change. So it kind of shows to you that in general software is becoming more secure but not as secure in these new areas. So you see some vulnerabilities lower and the new ones come up at a higher rate. I think it also depends on where software development is currently is in terms of market. What’s the new hotness? Is it Internet of Things connected to software? Is there a new language coming out that has never been attacked? So you see the priorities change on these top 25 lists.

    Ashley: Let’s step back for a moment. How would a development team or developer – I assume most folks are probably familiar with at least CBEs or some things like that, but maybe they haven’t dived into the top 25 for CWEs. What’s the best way to do that? Is it just go out and read about them, educate yourself? Do people, do development teams like, okay, I’m gonna dive into this and research a little bit more and I’ll share with you or how do people apply this to their teams?

    Britton: Well, there’s several ways they apply it. Sometimes they just hear about it, something like we’re doing talking today; and they go, oh, is this going to be relevant to me. And look, it’s a few things. As I said, sometimes a supplier specifies the angles to have proof that you’ve checked against this. And of course the static analysis tool, we can map checkers and messages against these vulnerabilities and these weaknesses so that we can show your code is exhibiting these features. But it’s really important to know what you’re going to be looking for and then do something about it as the static analysis tools can show you, yes, you’ve got this vulnerability but really it’s not off point just leaving there. You must do something about it.

    Ashley: You know, it’s interesting. So many, not everyone of course, so many of the vulnerabilities are about input, right, to a user interface of some type, web, OS command, mobile device. It’s a lot about neutralizing, dealing with the input that you’ve received, making sure that they’re not injecting something that they shouldn’t, getting access to a directory, all kinds of things like that. So it’s things that apply across multiple technology stacks and multiple applications. So generally speaking it’s not like this is a skill you’re going to use on one app and then you have to relearn it for the next app. You carry that stuff with you. It’s part of your skillset you build as a software engineer. 

    Britton: Yeah, it’s education, isn’t it? You know, it’s just everybody gets more and more experience of this type of issue. It’s not that long ago that security wasn’t at the heart, but now it is.

    Foster: And if you think about it, you know there’s kind of different levels of maturity in terms of security, right? You start developing because you know you have some types of vulnerabilities and you start working towards that. But if you think more longer term about your projects and how they might be very important IP or pieces of software that are embedded over time, it becomes more important to think about security because, you know, being able to fix some issues that you know about versus following a secure coding standard to ensure that the reliability, the strength and hardening of your software to begin with means that years down the line when somebody has integrated your piece of software into some type of embedded system that can never be touched, then you’re lowering the risk of there being vulnerabilities permanently out in the market for a very, very long time. So that becomes kind of the second level maturity when you’re developing and thinking about developing more secure software.

    Ashley: Now you mentioned, I forgot which one of you mentioned something about you might encounter something under a contract with the customer that requires specific security standards. One example I know that you all deal with quite a bit is ISO 26262 for automotive industry. Here you’re dealing with safety of course as well as security. Talk a little bit about how something – do the industry-specific standards really kind of go off the reservation to do something really different or are they building on what we do generally in software and then applying it to their specific domain?

    Britton: We could take ISO 26262 which is for vehicles. It’s very much good practice. It’s nothing totally off the scale. They recommend for software the use of a coding standard. You are allowed to use any coding standard you like, but then there are specific categories of software violations that you need to be able to detect so whatever you do. MISRA is sort of the classic for 26262 because it was developed for vehicles. But you have other industries with very, very similar requirements from software and now we’re moving into the scale of security. Back to vehicles again, it’s ISO 21434 which isn’t out yet; but that also requires the use of a coding standard and the violations they’re looking for are still very, very similar. It’s the same type of things. Quality software is what we’re always looking for.

    Foster: Because as I kind of mentioned a minute ago, you think about a car, that’s a big rolling embedded system that’s more or less permanent once it’s complete and it’s really hard to fix later. So you can understand how security as an oops, we’ll go back and fix it versus security as a process becomes more important. That’s exactly why ISO 21434 is becoming a thing or will becomes a thing once it’s releases. But we already have customers in industries looking at it and following along and understanding what that impact is going to be because to connect the cars was a big rolling computer.

    Ashley: You know, this is a little bit kind of parallel to just creating software but not too long ago I went through a web trust audit and very much like a standard like you’re describing it is do you have a process, do you have something that you follow, should follow, and do you follow it and do you have evidence of that. So many of the standards are just the technical details of what you should do to write pure code. It’s do you have the processes around that and are you following those and in some cases you do an audit. Necessary if you want a WebTrust, for example, certification or others. So it’s not just writing secure code, it’s if you say you’re going to do it, then you have to do it and demonstrate that you’re doing it and have some form. So what I’m saying is it’s really an investment that you’re making by writing secure code following some of these standards, but then that’s going to help you down the road meet other requirements. 

    Foster: Yeah, it makes it easier when you’re trying to implement say ISO 27001 which is information management security management requirement compliance thing. And there’s controls in there and what you’re talking about per the audit is putting in controls for your business and there are various areas in those controls that in many ways relate to the software that’s developed within the company. So yeah, by following some of these security standards you’re in essence helping with those controls later when/if you go and certify your company as that type of ISO requirement.

    Ashley: You know, Jill, I know you deal a lot with governance and some compliance and things like that. What are some of the best practices around secure software? We’ve touched on quite a few already but are there some other thoughts on other best practices to help people move up that maturity scale?

    Britton: Well, it’s a very basic part of any process really. Choose your metrics. How are you going to actually measure and see how you are progressing through your process? And similarly to software weaknesses, when you get your metrics, what are you going to do with them? There’s no point in collecting a whole collection of them and saying, yep, we’ve got our metrics. What does it mean? Does it mean that we have got 27 security violations last week? Oh, great, we’ve got a number. But what are we going to do about those 27 or so security violations? Again, it’s back to process. What is your process? What is an acceptable level of these metrics? And you can have metrics working all the way through the cycle right from requirements to development and test. You can actually have measures of how you are progressing through your cycle.

    Foster: And also what you find when you look at a lot of these security standards and their vulnerabilities, they have kind of the impact likelihood, cost to remediate, potential issue or risks that you see in the market when one goes out. So alongside that, a lot of the standards as well have kind of a risk scale or a prioritization that helps you – gives you an idea of where to start. And then in terms of the process, it’s not always a matter of running a tool or trying to follow these standards and trying to fix all the bugs. It’s important to start somewhere. What we typically call it is baselining where you kind of know your current quality of your software as it is right now, and the point is to start following a security standard and stopping new vulnerabilities from being introduced, and then you can go back and start working on the prioritization of what to fix to start cleaning up. Right?

    And also when you look at it and it seems insurmountable, you might want to spend some time looking at your past kind of customer weaknesses that were found or bugs that were found and kind of understanding in addition to what the standard is important, looking at what types of vulnerabilities you’ve produced or have reported back and focus there. That’s a good start, you know? You know kind of what your developers’ training weaknesses are and then you can implement kind of teaching, learning, training processes as well to help getting your development team more comfortable, more experienced in dealing with these types of issues. 

    Ashley: Sometimes also building on what you said, it can help bring to light other issues along the process like, for example, we keep getting libraries introduced into code that we don’t realize are there and they show up as a security vulnerability. Okay, well, let’s go fix that part of the process too so we know that those things are there and when updates happen they go through some defined process. Another one might be it’s not just new things we find but also repeats, things we consistently find, occasionally over and over whatever frequency. Okay, if we’re fixing them but how do we stop introducing them? What are good ways to help that? It might be education tools, et cetera. Lots of ways to do that. So to both of your point, to your point too, Jill, don’t ask questions you’re not going to do something about the answer, right? 

    Britton: That’s right. That’s exactly right.

    Ashley: So you have to take action on it and of course that’s ultimately why you’re doing it. You’re not just going through the motions to meet some paper standard because that will catch up with you very quick if you do something like that. 

    Britton: _____. It will. You’re absolutely right.

    Foster: Just buying yourself technical debt and risk.

    Ashley: Yeah, exactly. And it will catch up with you. How do you introduce this to some people words like process, standards, compliance, audits, anything with an ISO in front of it? Those kinds of things just sort of kick up the you’re cramping my style here, right? You’re putting a damper on my ability to be creative and write code. I’m bring a little bit hyperbolic, but not everybody reacts to those things favorably. How do you position this with organization so that it’s not just a dreaded thing we have to do, there’s actually really business value to it and it’s good for you and your career?

    Britton: Well, the whole thing with following a process is the developers can be involved in this process and then go through their careers excel help develop this process. But the process shouldn’t be stifling. It should never stifle the creativity. The whole idea of the process is tell me what you do and how do you prove that’s what you do? Okay, that’s fine. Now maybe how can we tweak it and do a little better? It’s the pro thing of continuous improvement that comes up in all the audits.

    We’re actually ISO 9001 certified. So we’re all going through this on a regular basis. You know, but we’re not trying to stifle our developers. They will say, “Well, okay, we have this process. It’s not quite working for us. Can we make some modifications?” We go, yeah, looks fine. We talk to the necessary people and usually it’s absolutely fine. So we involve the developers all the way through and they will then follow it because it’s their own process. 

    Foster: Yeah, I think the goal is the least amount of friction and introducing it over time. And as Jill said, there’s continuous improvement, right? It’s a long-term goal. It’s not something that’s done once and you get over the big hump of pain and it’s a ton of crunch work. It’s just something that you do over time. You look at agile development, right? People do standups. There’s processes, you know. There’s a level of documentation and planning that isn’t overly annoying. You know, the goal of DevOps is to automate a lot of those finicky processes so that they’re fast, they’re repeatable, they give time back, right? They report information back as quickly as possible so that they can be resolved quickly, right? That’s just lowering the friction, the pain of going back and fixing a feature or some sort of development commit, right? And then you’re just layering on another check layer of security, right? And it should be painless. It should be easy.

    As you mature over time, then the quality is going to get better and that goes back to the metrics that Jill was mentioning, not just having a number but seeing that number go down. And then having your teams be able to see that kind of dashboard or information as a feedback mechanism to say, you know, you can visually see the qualities improving. You know, customer reports of issues from the field are going down because our quality is going up. Why? Not just because of security but because of all the automation and the unit tests and checks that you have written and you’ve made the effort to produce better quality code and it’s going to pay dividends. 

    Ashley: I like the idea of tying it a continuous improvement process whether you label that as quality or other things because you can apply that to your DevOps process, to your tool chain, to the quality of your code, safety, security, making compliance easier for you, just improving your overall how you write software, maybe workflows and things like that. So you can make some of these compliance activities or standards activities really part of just maturing your organization and getting better at what you do, working on the organization as well as in it.

    Question for you, how do things like the privacy laws, you know, GDPR, CCPA for California, do those fall into this realm as well? Do they impact the developers as we’re talking about the use of customers’ information and of course we’re handling that in the applications? Is that something developers need to be that familiar with or is that more of the marketing department that are sending e-mails to people?

    Britton: It’s not greatly down with the developers, but it really depends on the type of data that they’re handling. Looking at the tools that Stuart and I work with, we’re not getting/bringing in external tools because it’s a static analyst tool. So we’re not looking at that. But when you get to things in the field, the developers have to be aware if they are going to be handling personal information and they then do have to have GDPR and that has to be included into any process – how are we going to handle this.

    Foster: Yeah, and there are coding rules that, you know, try to help with these types of things. You know not having hard coded secure passwords, not using magic numbers, various levels of encryption that should be written, or warnings that you’re using an outdated type of like encryption in your software, the ability to handle unvalidated inputs and outputs. Things like that are going to help cover some of the requirements for GDPR. So you need to kind of understand how your system is interacting with other systems and securing your APIs and all things like that. So it’s not just your piece of software at that point. Your developers need to be aware as to how your software is going to be used and implemented and how it’s going to communicate with other pieces of software or systems. 

    Britton: That brings us back to the weaknesses we were discussing earlier because there are weaknesses that actually cover that type of data.

    Ashley: Exactly.

    Britton: What are you doing with it.

    Ashley: Vulnerabilities in our software could lead to the loss of data. That could be a violation of those privacy laws of course, as well as other impacts, whatever it was. Well good. This has been a lot of fun. I’ve really enjoyed talking with you about this aspect of creating secure software. We’ve mentioned static code analysis and tools a little bit. I know this isn’t a commercial about Perforce, but would one of you just kind of position for us where in the process of what we talked about today where Perforce really plays in kind of your specialty in this area?

    Foster: Yeah, sure. So in terms of our product which our static analysis products, both Klocwork and Helix QAC, we fit in many different areas of kind of a development pipeline and process. We exist to make sure vulnerabilities are found while the developer is currently typing their code on their desktop. We also fit in for gated checks and quality checks in your SI/CD pipelines so we can quickly report back issues and also your typical if you’re running a nightly on a server or if you’re deploying checks and building your software in the cloud and provision instances and any sort of thing like that. We’re basically available anywhere. So we help you shift left as far as you want. We provide those security checks anywhere just for the ability to drive what I would call continuous compliance. 

    Ashley: Excellent. Great. Well, Stuart, Jill, it’s been a lot of fun talking with you and hope everyone – wish you the best in your journey on creating even more secure software. We’ll speak with you again soon. Take care. 

    Foster: Awesome. Thanks, Mitch. 

    Britton: Thanks.

  • Set DevOps Free With Modern Application Security

    Set DevOps Free With Modern Application Security

    Development teams increasingly use technologies like cloud computing and microservices, in conjunction with DevOps principles, to innovate faster and remain competitive.

    But such progress comes at a cost. The fast pace of DevOps has left security teams scrambling to keep pace and install appropriate security guardrails. Traditional security practices used to occur in the final stages before release. The rapid release cycles of agile software development often make this difficult, if not impossible.

    The speed of development is outpacing the rate at which security teams can check configurations and scan for vulnerabilities, especially as developers now outnumber security professionals 500 to 1 and modern application environments represent a vast attack surface.

    The pressure to keep up, and do so securely, has led to a gradual reframing of DevOps as DevSecOps, where security is “shifted left” and introduced earlier in the software development life cycle.

    Unfortunately, while most businesses understand the intent of DevSecOps, they are still unsure how to translate that intent into action. In fact, just 14% fully integrate security throughout the software development life cycle.

    Recent research also shows that, while 65% of security teams report shifting left, less than one fifth are doing the scans necessary to verify that shift is actually happening. The same report suggests that most security teams don’t have the processes in place to monitor and protect cutting-edge application technologies, such as microservices, APIs and cloud native/serverless.

    This lack of visibility leaves security organizations blind when problems surface in production. The longer vulnerabilities go undiscovered in the development cycle, the more costly they are to fix. A study by IBM System Science Institute suggests that fixing a defect found during implementation can cost six times as much as one identified during early design phases. A defect uncovered in production can cost 100 times as much. Even more disturbing, nearly half of enterprises admit to deploying vulnerable applications, just to meet tight deadlines.

    It’s clear that compliance and security oversight are often overlooked, and even deliberately avoided, in favor of faster, more frequent deployments.

    The Great DevOps-DevSecOps Divide

    One of the most significant issues lies with developers’ ingrained perceptions. In the past, teams worked independently, with rigidly scheduled handoffs between distinct phases of development. Security operations (SecOps) teams often introduced security functions during the final stages of the development and release process, which resulted in delays.

    Successfully putting the “Sec” into DevSecOps depends on changing older cultural biases, reinforcing the need to embrace security and empowering teams with the right tools and automation to make smarter decisions without slowing down the entire organization. In essence, DevOps and security teams are all aiming for the same goal – a high-quality, timely product. The difference lies in how they measure and define “high quality” and “timely”.

    The truth is, development won’t be slowing down any time soon. Thirty eight percent of developers now release monthly or faster, and 54% of containers live for five minutes or less. Viewing security as a separate entity bolted onto the code, instead of a key feature that must be embedded end to end, slows down development processes and reduces efficiency.

    Delivering Speed and Security

    The core questions organizations must answer to improve application security are: What makes it easier for DevOps teams and application security teams to collaborate? And what does built-in security really look like?

    For organizations that want to improve their DevOps security, here are some tips:

    • Automate security as much as possible. Invest in security solutions that can be automated and embedded directly into the CI/CD pipeline. This makes it easier to secure applications without sacrificing development speed for the sake of security. Adopting technologies like static code analysis, dynamic analysis and penetration testing reduces risks and alerts developers to potential problems. There will never be enough security professionals to handle all security issues on their own, so use automation whenever possible.
    • Build security as a guardrail, not a gate. Provide appropriate guidance and tooling, so that security becomes a guardrail rather than a gate. For example, ensuring that DevOps teams have access to templated policies enables them to align applications with security requirements from the outset, without adding unnecessary time to development. Applications and security policies can also be tested as part of the CI/CD pipeline, so they are checked like any other functional specification. In short, it’s important to provide developers with everything they need to create and test applications with the appropriate security controls applied, or they won’t do it. Empowering development teams with a better understanding of security and self-service compliance reduces vulnerabilities and risks to the organization. Developers always want to move faster, so make it possible for them to “speed” safely.
    • Enable more proactive responsibility. The average developer cannot be expected to have the level of expertise necessary to stay current with all the latest security trends—they have enough trouble keeping their programming skills up to date. Reduce complexity and make it easier to gain developer buy-in by selecting solutions that provide simplified, easy-to-understand insights within the CI/CD feedback loop.
    • Make security adaptable, scalable and reliable. Secure applications with solutions that offer consistent, centralized and self-service security for any environment. For example, AI-driven security policy engines are one way to enable the adaptability necessary to support rapid change in applications resulting from CI/CD methodologies. Being able to adapt security policies in response to the latest attacks and identify dependencies makes it easier to assess risk and take action faster.

    The dawn of frictionless and adaptable security

    Security can no longer be an afterthought, bolted on to a process. Today, integrated security must become a normal part of any DevOps implementation. Making security frictionless and adaptable enables development teams to power ahead without fear. Modern application security can be a robust support system that empowers organizations to reach their business goals securely.

  • What Is AppSec? An Overview

    What Is AppSec? An Overview

    An estimated 84% of security incidents happen at the application layer. And, with the number of cybersecurity threats steadily rising year-over-year, application security (AppSec) has become absolutely essential.

    Application security refers to finding, fixing and preventing cybersecurity vulnerabilities throughout the entire development life cycle. By enforcing application security measures, you are able to ensure that weaknesses and vulnerabilities in your software are identified and dealt with as soon as possible in development before they can become serious security breaches. This also helps to keep the overall costs low and enables you to deliver a secure, reliable product on time.

    AppSec Best Practices

    In order to ensure that your application is secure against security threats and vulnerabilities, you must enforce application security best practices. While you and your team may have application security best practices that are specific to your own process, we recommend that you consider also using these best practices:

    • Conduct an application security risk assessment to effectively identify potential security vulnerabilities and weaknesses.
    • Eliminate—or, if elimination is not possible, mitigate—the security vulnerabilities and weaknesses that were identified in the risk assessment.
    • Examine open source and third-party software for security vulnerabilities. Properly address any weaknesses that your examination may have uncovered.
    • Use AppSec tools such as SAST and DAST.
    • Provide your team with application security training.

    By adopting the above best practices, you can be assured that you and your team will have a strong application security process.

    AppSec Tools

    As previously mentioned, one of the most effective ways to ensure application security is to use AppSec tools.

    The most common AppSec tools are:

    • SAST: A static application security testing (SAST) tool analyzes your code as it’s being written in order to detect and report weaknesses that can lead to security vulnerabilities.
    • DAST: A dynamic application security testing (DAST) tool enables you to identify security errors, runtime issues and environment-related issues later in the development of your software.

    By using these AppSec tools together, you are able to ensure application security throughout development.

    Important Secure Coding Standards for AppSec

    In order to effectively enforce application security, you should use secure coding standards to efficiently identify, prevent and eliminate software vulnerabilities.

    The most important coding standards for application security include:

    • CERT
    • CWE
    • DISA STIG
    • OWASP
    • ISO/IEC TS 17961

    A static code analyzer should be used early in development to effectively enforce coding standards to ensure effective application security.

    To read more, please visit: https://www.perforce.com/blog/kw/what-is-appsec

  • Speed and Security: How to Find a Balance in Development

    Speed and Security: How to Find a Balance in Development

    Time management can help developers realize the necessary combination of security and speed in application development

    As software continues to create competitive advantages and market differentiation for organizations focused on successful digital transformation, developers will continue to be measured by how fast they can develop and release code. Business leaders encourage DevOps teams to push the pace of innovation to deliver features quickly while leveraging the newest technologies to gain any available advantage in the market. As a result, development and operations teams work at breakneck speeds to meet the deadlines of short and frequent development life cycles.

    Security teams, however, are not measured by speed but rather by certain metrics of success, such as whether they achieve a certain security rating or reduce the number of incidents. Traditionally, security sets corporate standards and best practices centrally and tries to enforce them across the enterprise. With DevOps teams becoming increasingly distributed and decentralized, these conventional security methods no longer work and have actually slowed down security and/or blocked the software development process. Security tries to keep pace, but with numerous disparate reports to review and too many results to manage, they inevitably fall behind. In the rush to catch up, either critical vulnerabilities are overlooked or frustration sets in when releases are delayed.

    Developer and security teams both know the importance of delivering secure software but struggle to find the right balance. Let’s take a look at some strategies that can help ease the tension between DevOps and security teams and create a happier work environment, where safer code is delivered to the market.

    Incorporating Time Management for Speed and Security

    Consider implementing the following time management strategies to make life easier for developers:

    Integrate AppSec in the DevOps Pipeline: Application security scanning should be incorporated early and often within the DevOps pipeline. While this statement may sound like a broken record, the days of running scanning tools independent of your pipelines are gone. Studies have shown the earlier you detect an issue, the easier it is for developers to fix—with as much as 50% time reclaimed over late-stage remediation. By including AppSec in the pipeline, you ensure all issues are identified as quickly as possible. This effort will not only improve the quality of your software but also free up more time overall for developers to write code and create cool features. Sounds like a win-win for both teams.

    Incorporate automation as much as possible: DevOps teams should look to leverage automation when implementing application security wherever possible. Many of the steps for securing your software development process are repetitive. For AppSec to be successful, the steps must work within the developer’s world and along with the other tools developers love. Developers look for tools that help them move faster.

    Here are some areas where application security automation can unburden developers from repetitive tasks:

    • Use AppSec tools that can be easily tied into your DevOps toolchains. As a matter of fact, a developer may not even need to know what security tools are being run, only that they are executed on every run of the pipeline.
    • Automate the ingestion and correlation of the security findings. There will often be a boatload of redundancies between the findings from different security tools (i.e. SAST versus DAST versus SCA) and the potential compression ratios can be in the order of 10-50:1. There are tools to automate this process and dramatically simplify making sense of all the data. The onus shouldn’t be on the developer.
    • Once a security issue has been identified, it should automatically create a ticket in the ticketing system that developers use today. We all know developers don’t like being forced to use a new tool. Give them the findings in the system they are already familiar with.

    Tailor security training for your teams: Security training is a great way to reduce the number of security findings within an organization, which in turn frees up developers to work on other pressing issues. However, most security training is ad hoc and not tailored to meet the needs of the development teams. Even the most basic security testing can provide baseline metrics that enable security teams to recommend tailored training for development teams. These sessions can focus on areas that teams struggle with or areas known to be susceptible. Training is also a great way to develop security champions within the development teams, dedicated professionals who have shown to improve the overall security posture and awareness of organizations. Security champions—and the programs they advocate—have the power to improve both AppSec and relationships among people, a sentiment endorsed by 84% of industry professionals.

    Summary

    Developers know the importance of security and truly want to deliver safe code in the timeframes they are being judged on. By incorporating the strategies outlined above, they will have a fighting chance to reach the lofty goals set by the business, while releasing higher quality and more secure code. Security teams need to meet the developers in their world and help enable application security to be automated and work at the speed of DevOps.

  • Dynatrace Adds Security Module to Observability Platform

    Dynatrace Adds Security Module to Observability Platform

    Dynatrace announced today it is adding a module to provide continuous runtime application self-protection (RASP) capabilities to its observability platform.

    The Dynatrace Application Security Module leverages existing Dynatrace tracing and artificial intelligence (AI) technologies to detect threats in real-time and then apply appropriate policies to automatically secure applications.

    Andreas Lehofer, chief product officer for Dynatrace, said that with the rise of highly dynamic microservices-based applications, the time has arrived to extend the company’s platform into the realm of application security. In contrast, there aren’t typically as many changes to monolithic applications to justify adding a security module to an application performance management (APM) platform, he said.

    Lehofer said the Dynatrace Application Security Module has also been designed to reduce false positives by only surfacing alerts concerning code that is actually running. Rival RASP platforms will detect modules and start generating alerts about libraries that may be present in an application environment but are not actually employed, said Lehofer.

    The Dynatrace Application Security Module working with the Smartscape topology mapping and PurePath tools for analyzing code also make it possible for DevSecOps teams to better understand dependencies between microservices, he added.

    At the core of the Dynatrace approach to DevSecOps is its OneAgent software for application instrumentation, which collects data and feeds it back to an observability platform that includes an artificial intelligence (AI) engine dubbed Davis. As the Dynatrace Application Security Module continues to evolve, IT organizations should expect Dynatrace to apply AI capabilities to application security more broadly, Lehofer said.

    The ability of DevSecOps teams to automatically remediate applications that are discovered to have significant security issues depends on their ability to roll back applications after they have been deployed. Most IT organizations at the moment still have to manually roll back an application after it’s been deployed, he noted.

    Longer-term it’s not clear to what degree AI might advance DevSecOps; however, the more automated the process of identifying vulnerabilities becomes, the easier it should be to automate remediation.

    In the meantime, as the observability capabilities of platforms such as Dynatrace extend into application security, the easier it should become for organizations to embrace best DevSecOps practices by employing a module that is added on to an existing APM platform.

    Dynatrace, of course, is betting microservices-based applications will increase the adoption of its observability platform. Historically, IT teams tended to employ an APM only to instrument their most mission-critical applications because of the costs involved. However, as IT environments become more complex in the age of microservices, platforms that can observe all the dependencies that exist in a distributed computing environment are now critical. Extending that platform to include application security further extends the economic case for investing in an observability platform.

    It may be a while before most organizations reach a level of DevSecOps maturity that requires continuous observability, but as responsibility for application security continues to shift further left, it’s now only a matter of time before more automation is applied.

  • Survey Sees Long DevSecOps Ahead

    Survey Sees Long DevSecOps Ahead

    A survey of 250 developers working at leading technology companies paints a bleak picture of the current state of application security with 85% admitting applications on average have 10 or more vulnerabilities, with nearly half saying they have on average more than 20 per application.

    Conducted by Contrast Security, a provider of an observability platform for security, the survey also finds nearly 50% of application security tools are not integrated into the continuous integration/continuous delivery (CI/CD) pipelines.

    Contrast Security CTO Jeff Williams said it’s clear most organizations have a long way to go before best DevSecOps practices become commonplace. In the meantime, the level of disruption being caused by the need to remediate vulnerabilities remains high. The survey finds 88% of respondents need to stop development work to remediate vulnerabilities at least once a week, with nearly 80% spending too much time triaging and diagnosing application security alerts.

    Nearly three-quarters of respondents also noted their organizations cannot find highly specialized application security experts.

    On the plus side, more than one-third of respondents (36%) said at least one application security metric is among their top four performance measurements. Most (63%) have also deployed an interactive application security testing (IAST) solution.

    Most importantly, 77% of respondents said they want more application security training.

    Williams said ultimately DevSecOps will require an observability platform capable of capturing metrics that are meaningful to developers. Contrast has launched an observability platform for IT security teams that borrows DevOps principles to streamline the management of cybersecurity.

    Achieving and maintaining security is complex because application data flows in and out of disparate systems running in the cloud and on-premises IT environments. IT security teams are forced to navigate a multitude of application programming interfaces (APIs) that have varying degrees of dependencies to ascertain what’s actually occurring in their extended IT environments.

    Contrast enables DevOps teams to instrument their applications with security sensors, which Williams said enables the Contrast Application Security Platform to aggregate data flows spanning multiple applications. That approach also eliminates silos spanning application security testing (AST), software composition analysis (SCA) and runtime application self-protection (RASP) tools installed across an enterprise, said Williams.

    It’s not clear to what degree DevOps teams will add agents specifically to instrument applications to gather security data. However, as more responsibility for application security is shifted left toward developers, it’s apparent legacy approaches to securing applications are being found wanting.

    In the meantime, it’s still early days as far as DevSecOps is concerned even for technology companies, much less the average enterprise. Most IT organizations are just getting started down this path. The issue most of them are coming to terms with is the degree to which they need their DevOps and cybersecurity teams to collaborate. While there may be a need for a lot of interaction between these two teams early on, there may come a day soon when DevOps teams eventually reach a level of proficiency that makes security a natural extension of any quality assurance process.