Securosis

Research

Securing APIs: The New Application Attack Surface

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:

Share:
Read Post

Enterprise DevSecOps

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:

Share:
Read Post

Understanding and Selecting RASP 2019 Research Paper

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:

Share:
Read Post

Complete Guide to Enterprise Container Security

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:

Share:
Read Post

Understanding Secrets Management

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:

Share:
Read Post

Securing SAP Cloud Environments

Migrating Hana and other SAP applications to a cloud environments is a complicated process, even with the tools and services SAP provides. For many organizations security was primary barrier to adoption. But SAP and other cloud service vendors have closed many security gaps, so now we can trust that the environment and applications are at least as secure as an on-premise installation – provided you leverage appropriate security models for the cloud. But that’s where we often see a breakdown: enterprises are not taking sufficient advantage of cloud security. Additionally, because there is no single model for SAP cloud security, transitioning other business applications to the cloud often results in greater cost, less scalability, and decreased security. From the paper: “Proper implementation is tricky – if you simply ‘lift and shift’ your old model into the cloud, we know from experience that it will be less secure and cost more to operate. To realize the advantages of the cloud you need to leverage its new features and capabilities – which demands a degree of reengineering for architecture, security program, and process,” said Adrian Lane, Analyst and CTO, Securosis. “We have been receiving an increasing number of questions on SAP cloud security, so this research paper is intended to tackle major security issues for SAP cloud deployments. When we originally scoped this research project we were going to focus on the top five questions people had, and quickly realized that grossly under-served the audience needs for a more comprehensive security plan,” continued Lane. “Securing SAP Clouds” covers the division of responsibility between an organization and the cloud vendor, which tools and approaches are viable, changes to the security model and advice for putting together a cloud security program for SAP. We are very happy to announce that Onapsis is licensing this research to help educate customers and Hana users. We thank them for their support, and for their ongoing security research! Download a copy of the paper here Share:

Share:
Read Post

Assembling A Container Security Program

Our paper, Assembling a Container Security Program, covers a broad range of topics around how to securely build, manage, and deploy containers. During our research we learned that issues often arise early in the software development or container assembly portion of the build process, so we cover much more than merely runtime security – the focus of most container security research. We also discovered that operations teams struggle with getting control over containers, so we also cover a number of questions regarding monitoring, auditing, and management. To give you a flavor for the content, we cover the following: IT and Security teams lack visibility into containers and have trouble validating them – both before placing them into production, and when running in production. Their peers on the development team are often disinterested in security, and cannot be bothered to provide reports and metrics. This is essentially the same problem we have for application security in general: the people responsible for the code are not incentivized to make security their problem, and the people who need to know what’s going on lack visibility. Containers are scaring the hell out of security pros because of their lack of transparency. The burden of securing containers falls across Development, Operations, and Security teams – but these groups are not always certain how to tackle the issues. This research is intended to aid security practitioners, developers, and IT operations teams in selecting container security tools and approaches. We will not go into great detail on how to secure apps in general here – we are limiting ourselves to build, container management, deployment, platform, and runtime security issues that arise with the use of containers. We will focus on Docker as the dominant container model, but the vast majority of our security recommendations also apply to Cloud Foundry, Rocket, Google Pods, and the like. 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 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 Share:

Share:
Read Post

Maximizing WAF Value

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:

Share:
Read Post

Understanding and Selecting RASP

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:

Share:
Read Post

Secure Agile Development

If you’ve followed this blog for any length of time, you know we have talked about the troubles of integrating security testing and secure code development practices into and Agile development process. Security is trying to manage risks to the organization, including risks introduced by new technologies such as code. Development teams try to deliver quality code faster, which means jettisoning things that slow them down. Both want customers to be happy and deliver new products and services, but underlying goals of risk reduction and maximized efficiency do not inherently mesh, causing friction. This research paper was conceived as a way to help security people understand and better work with development. We explain what development teams are trying to do, how they want to work, and offer pragmatic advice to help mesh the goals of both organizations into a unified process. And on this topic, we really wanted to give back to the community! We’ve included much of what we have learned with secure code development over the last two decades, as well as things we’ve learned from other development teams, CISOs and security vendors, to provide a simple guide on how to promote security in Agile software development teams. We are also proud to announce that Vercode has licensed this content. It’s not every day that a vendor will back a research paper that does not promote or demystify a product category, but it’s an area we felt security — and developers — could use information on. As this research is geared toward helping CISOs and others build a process, it’s decidedly non-product focused, so we are grateful for Veracode’s help in supporting our efforts to bring this research to you. As always, if you have questions or comments, please contact us at info at Securosis with the ‘dot com’ extension, or simply comment on the blog. You can download the paper here Share:

Share:
Read Post

Totally Transparent Research is the embodiment of how we work at Securosis. It’s our core operating philosophy, our research policy, and a specific process. We initially developed it to help maintain objectivity while producing licensed research, but its benefits extend to all aspects of our business.

Going beyond Open Source Research, and a far cry from the traditional syndicated research model, we think it’s the best way to produce independent, objective, quality research.

Here’s how it works:

  • Content is developed ‘live’ on the blog. Primary research is generally released in pieces, as a series of posts, so we can digest and integrate feedback, making the end results much stronger than traditional “ivory tower” research.
  • Comments are enabled for posts. All comments are kept except for spam, personal insults of a clearly inflammatory nature, and completely off-topic content that distracts from the discussion. We welcome comments critical of the work, even if somewhat insulting to the authors. Really.
  • Anyone can comment, and no registration is required. Vendors or consultants with a relevant product or offering must properly identify themselves. While their comments won’t be deleted, the writer/moderator will “call out”, identify, and possibly ridicule vendors who fail to do so.
  • Vendors considering licensing the content are welcome to provide feedback, but it must be posted in the comments - just like everyone else. There is no back channel influence on the research findings or posts.
    Analysts must reply to comments and defend the research position, or agree to modify the content.
  • At the end of the post series, the analyst compiles the posts into a paper, presentation, or other delivery vehicle. Public comments/input factors into the research, where appropriate.
  • If the research is distributed as a paper, significant commenters/contributors are acknowledged in the opening of the report. If they did not post their real names, handles used for comments are listed. Commenters do not retain any rights to the report, but their contributions will be recognized.
  • All primary research will be released under a Creative Commons license. The current license is Non-Commercial, Attribution. The analyst, at their discretion, may add a Derivative Works or Share Alike condition.
  • Securosis primary research does not discuss specific vendors or specific products/offerings, unless used to provide context, contrast or to make a point (which is very very rare).
    Although quotes from published primary research (and published primary research only) may be used in press releases, said quotes may never mention a specific vendor, even if the vendor is mentioned in the source report. Securosis must approve any quote to appear in any vendor marketing collateral.
  • Final primary research will be posted on the blog with open comments.
  • Research will be updated periodically to reflect market realities, based on the discretion of the primary analyst. Updated research will be dated and given a version number.
    For research that cannot be developed using this model, such as complex principles or models that are unsuited for a series of blog posts, the content will be chunked up and posted at or before release of the paper to solicit public feedback, and provide an open venue for comments and criticisms.
  • In rare cases Securosis may write papers outside of the primary research agenda, but only if the end result can be non-biased and valuable to the user community to supplement industry-wide efforts or advances. A “Radically Transparent Research” process will be followed in developing these papers, where absolutely all materials are public at all stages of development, including communications (email, call notes).
    Only the free primary research released on our site can be licensed. We will not accept licensing fees on research we charge users to access.
  • All licensed research will be clearly labeled with the licensees. No licensed research will be released without indicating the sources of licensing fees. Again, there will be no back channel influence. We’re open and transparent about our revenue sources.

In essence, we develop all of our research out in the open, and not only seek public comments, but keep those comments indefinitely as a record of the research creation process. If you believe we are biased or not doing our homework, you can call us out on it and it will be there in the record. Our philosophy involves cracking open the research process, and using our readers to eliminate bias and enhance the quality of the work.

On the back end, here’s how we handle this approach with licensees:

  • Licensees may propose paper topics. The topic may be accepted if it is consistent with the Securosis research agenda and goals, but only if it can be covered without bias and will be valuable to the end user community.
  • Analysts produce research according to their own research agendas, and may offer licensing under the same objectivity requirements.
  • The potential licensee will be provided an outline of our research positions and the potential research product so they can determine if it is likely to meet their objectives.
  • Once the licensee agrees, development of the primary research content begins, following the Totally Transparent Research process as outlined above. At this point, there is no money exchanged.
  • Upon completion of the paper, the licensee will receive a release candidate to determine whether the final result still meets their needs.
  • If the content does not meet their needs, the licensee is not required to pay, and the research will be released without licensing or with alternate licensees.
  • Licensees may host and reuse the content for the length of the license (typically one year). This includes placing the content behind a registration process, posting on white paper networks, or translation into other languages. The research will always be hosted at Securosis for free without registration.

Here is the language we currently place in our research project agreements:

Content will be created independently of LICENSEE with no obligations for payment. Once content is complete, LICENSEE will have a 3 day review period to determine if the content meets corporate objectives. If the content is unsuitable, LICENSEE will not be obligated for any payment and Securosis is free to distribute the whitepaper without branding or with alternate licensees, and will not complete any associated webcasts for the declining LICENSEE. Content licensing, webcasts and payment are contingent on the content being acceptable to LICENSEE. This maintains objectivity while limiting the risk to LICENSEE. Securosis maintains all rights to the content and to include Securosis branding in addition to any licensee branding.

Even this process itself is open to criticism. If you have questions or comments, you can email us or comment on the blog.