Research

The way applications are built, deployed, and maintained in most organizations is being disrupted. Macro changes include the ongoing cloud migration disrupting the tech stack, new application design patterns bringing microservices to the forefront, and DevOps changing dev/release practices. As we’ve been slowly navigating this sea change, the common thread across these changes is increasing reliance on Application Programming Interfaces (APIs). APIs have quickly emerged as the most attractive and least- protected target within new applications because they have access to critical data and services. In this paper, Securing APIs, we work through how application architecture and attack surfaces are changing, how application security needs to evolve to deal with these disruptions, and how to empower security in environments where DevOps rules the roost. So you are better prepared to protect whatever applications look like moving forward. Our research is licensed by forward-looking companies that realize the importance of educating their communities on the rapidly changing technology landscape. We thank our friends at Salt Security for licensing this report. Our research is done using our Totally Transparent research methodology. This allows us to do impactful research while protecting our integrity. You can download the paper (PDF). Share:

This is our latest iteration on how to build a DevSecOps program. This research paper is the result of hundreds of hours of research and several hundred conversations with Fortune 1000 firms on the challenges companies face and the problems they are most interested in tackling. We go deep into covering all phases and facets of secure application development. And we did a complete reversal on the naming convention; from DevOps to DevSecOps. It became obvious during our calls that despite the idealism involved with leaving ‘Sec’ out of the title, security is getting short shifted and it needs to be called out. From the paper: In our 2015 work “Building Security Into DevOps” we embraced the idea that security was an equal partner and there was no reason to call out security specifically. In hindsight, this was wrong. The fact is security practitioners are having a much harder DevOps journey, and they are the ones struggling, and they are the ones who need a roadmap on security integration. Stated another way, practitioners of DevOps who have fully embraced the movement will say there is no reason to add ‘Sec’ into DevOps, as security is just another ingredient. The DevOps ideal is to break down silos between individual teams (e.g., architecture, development, IT, security, and QA) to better promote teamwork and better incentivize each team member toward the same goals. If security is just another set of skills blended into the overall effort of building and delivering software, there is no reason to call it out any more than quality assurance. Philosophically they’re right. But in practice we are not there yet. Developers may embrace the idea, but they generally suck at facilitating team integration. Sure, security is welcome to participate, but it’s up to them to learn where they can integrate, and all too often security is asked to contribute skills which they simply do not possess. It’s passive-aggressive team building! This is a major re-write of our 2015 research work and we hope you will find it beneficial. And we wanted to thank Veracode for licensing this content. Our licensees are what makes it possible to bring this paper to you free of charge! You can download a copy of the research here: Enterprise_DevSecOps_2019_V2.FINAL_.pdf Share:

So what is RASP? Runtime Application Self-Protection (RASP) is an application security technology which embeds into an application or application runtime environment, examining requests at the application layer to detect attacks and misuse in real time. RASP functions in the application context, which enables it to monitor security – and apply controls – very precisely. This means better detection because you see what the application is being asked to do, and can also offer better performance, as you only need to check the relevant subset of policies for each request. There is no lack of data showing that applications are vulnerable to attack. Many applications are old and simply contain too many flaws to fix. You know, that back-office application that should never have been allowed on the Internet to begin with. These applications are often unsupported, with the engineers who developed them no longer available, or the platforms so fragile that they become unstable if security fixes are applied. In most cases it would be cheaper to re-write the application from scratch than patch all the issues, but economics seldom justify (or even permit) the effort. Other application platforms, even those considered ‘secure’, are frequently found to contain vulnerabilities after decades of use. Heartbleed, anyone? New classes of attacks, and even new use cases, have a disturbing ability to unearth previously unknown application flaws. We see two types of applications: those with known vulnerabilities today, and those which will have known vulnerabilities in the future. But the real audience for this technology is developers who want to build security into their applications. As more and more software development shops embrace automation, RESTful APIs are no longer optional. Security need to be as automated and agile as development teams. Tooling that can both embed into the application stack for scalability and deployment, as well as help isolate which bits of code are truly vulnerable, are needed more than ever before. RASP is getting to be a mature product class and delivering security in the development pipeline and in production. You can download our 2019 updated version of our Understanding and Selecting RASP paper on the link below: Share:

Our newest paper, A Complete Guide to Enterprise Container Security, is a full update of our previous research on container security. A lot has happened over the last 18 months, which prompted a significant rewrite of our original content. As more organizations accept that containers are now the common media for applications, the platform focus is shifting to containers, with steps taken at each stage of the container lifecycle to ensure what actually goes into production is fully tested. To give you a flavor for the content, we cover the following: Containers scare the hell out of security pros because they are so opaque. The burden of securing containers falls across Development, Operations, and Security teams – but none of these groups always knows how to tackle their issues. Security and development teams may not even be fully aware of the security problems they face, as security is typically ignorant of the tools and technologies developers use, and developers don’t always know what risks to look for. Container security extends beyond containers to the entire build, deployment, and runtime environments. And the container security space has changed substantially since our initial research 18-20 months back. Security of the orchestration manager has become a primary concern, and cloud deployments change the entire focus, which cause organizations rely more heavily on the eco-systems to deploy and manage applications at scale. We have seen a sharp increase in adoption of container services (PaaS) from various cloud vendors, which changes how organizations need to approach security. We reached forward a bit in our first container security paper, covering build pipeline security issues because we felt that was a hugely under-served area, but over the last 18 months DevOps practitioners have taken note, and this has become the top question we get. The rapid change of pace in this market means it’s time for a refresh. If you worry about container security this is a good primer on all aspects of how code is built, bundled, containerized, and deployed. We would like to thank Aqua Security and Tripwire for licensing this research and participating in some of our initial discussions. As always we welcome comments and suggestions. If you have questions please feel free to email us: info at securosis.com. Download a copy of the paper here: Securosis_BuildingContainerSecProgram_2018.pdf. Share:

If you’ve worked in IT or development you have seen it before: user names and passwords sitting in a file. When your database starts up, or when you run an automation script, it grabs the credentials it needs to function. The problem is obvious: admins and attackers alike know this common practice, and they both know where to look for easy access to applications and services. With growing use of automation and orchestration, largely in response to Continuous Integration build processes and fully programable cloud infrastructure, we are automating many traditional IT task to speed up processes. Together they have compounded this problem. From the paper: >Developers have automated software build and testing, and IT automates provisioning, but both camps still believe security slows them down. Continuous Integration, Continuous Deployment, and DevOps practices all improve agility, but also introduce security risks — including storing secrets in source code repositories and leaving credentials sitting around. This bad habit leaves every piece of software that goes into production is at risk! All software needs credentials to access other resources; to communicate with databases, to obtain encryption keys, and access other services. But these access privileges must be carefully protected lest they be abused by attackers! The problem is the intersection of knowing what rights to provision, what format the software can accept, and then securely provision access rights when a human is not — or cannot — be directly involved. Developers do integrate with sources for identity — such as directory services — but are usually unaware technologies exist that helps them distribute credentials to their intended destinations. Content licensed by CyberArk. The full paper is here: Securosis_Secrets_Management_JAN2018_FINAL.pdf Share:

We talk frequently about the importance of having the right people and processes to make security effective. This is definitely true for Web Application Firewalls (WAF), a fairly mature technology which has been fighting perception issues for years. This quote from the paper nets it out: Our research shows that WAF failures result far more often from operational failure than from fundamental product flaws. Make no mistake — WAF is not a silver bullet — but a correctly deployed WAF makes it much harder to successfully attack an application, and for attackers to avoid detection. The effectiveness of WAF is directly related to the quality of people and processes maintaining them. The most serious problems with WAF are with management and operational processes, rather than the technology. Our Maximizing WAF Value paper discusses the continuing need for Web Application Firewall technologies, and address the ongoing struggles to run WAF. We also focus on decreasing time to value for WAF, with updated recommendations for standing up a WAF for the first time, what it takes to get a basic set of policies up and running, and new capabilities and challenges facing customers. We would like to thank Akamai for licensing the content in this paper. As always, we performed the research using our Totally Transparent Research methodology. You can download the paper (PDF). Share:

So what is RASP? Runtime Application Self-Protection (RASP) is an application security technology which embeds into an application or application runtime environment, examining requests at the application layer to detect attacks and misuse in real time. RASP functions in the application context, which enables it to monitor security – and apply controls – very precisely. This means better detection because you see what the application is being asked to do, and can also offer better performance, as you only need to check the relevant subset of policies for each request. From the paper: There is no lack of data showing that applications are vulnerable to attack. Many applications are old and simply contain too many flaws to fix. You know, that back-office application that should never have been allowed on the Internet to begin with. These applications are often unsupported, with the engineers who developed them no longer available, or the platforms so fragile that they become unstable if security fixes are applied. In most cases it would be cheaper to re-write the application from scratch than patch all the issues, but economics seldom justify (or even permit) the effort. Other application platforms, even those considered ‘secure’, are frequently found to contain vulnerabilities after decades of use. Heartbleed, anyone? New classes of attacks, and even new use cases, have a disturbing ability to unearth previously unknown application flaws. We see two types of applications: those with known vulnerabilities today, and those which will have known vulnerabilities in the future. But the real audience for this technology is developers who want to build security into their applications. As more and more software development shops embrace automation, RESTful APIs are no longer optional. Security products that only offer partial functionality from their API interface, or only provide SOAP-based APIs, fail to meet current market requirements. To add value for development teams, security needs to be fully integrated with the application and the build process that constructs it. As applications leverage the cloud and virtualization, and embrace micro-service architectures, it has become clear that security needs to function as, auto-scale with, and replicate alongside, applications. RASP meets these requirements as few other security products can. Its key value is that users who need it can fully integrate it into the context of their environment, with their particular needs and process. We would like to heartily thank Immunio for licensing this content. As always, if you have comments or questions, you can either post them on our blog as a comment or email us at info at Securosis, appending dot com. Download here: Understanding and Selecting RASP Share: