Choosing a company to partner with for your next application or network security assessment can feel like eating a red jelly bean. They all look pretty much the same and some are exactly what you want, but some are definitely not. Large companies offer the comfort of an established process and previously satisfied customers, but over time the experts who once worked there tend to move on and the quality of the service falls. And of course, large companies need rigid processes and strictly defined service offerings to keep their workload manageable, which means you need to conform to their expectations. Small companies have the flexibility to adapt to your needs, but it can be hard to assess their skills.
Meristem offers the following three reasons why working with us WILL be the red jelly bean you’re looking for.
Detailed Reports
Naturally Meristem commits to performing a high-quality test, but when a report comes back with just a couple of low-risk findings, how can you tell the difference between your application/network being awesome and a tester that only spent a couple of hours working on the test? Meristem’s answer is to ensure that the report describes the test that was performed in terms of the specific details of your application or network. The process of really trying to find vulnerabilities will teach us a lot about your architecture, and that will be visible in the report, whether in the descriptions of effective controls or vulnerabilities.
More importantly, when we do identify vulnerabilities, the recommendations will be tailored to what we know of your environment. We may not be able to tell you exactly how to fix the problem, but we’ll be a specific as possible. Also, the evidence included with each finding will be descriptive enough that the developers or system administrators will be able to replicate the test and know when they have fixed the issue.
Want proof? Check out a sample High Finding and Medium Finding.
All-Technical Team
Sometime soon Meristem will grow to the point where we will need dedicated non-technical staff. But for now, you have the advantage of being able to ask technical questions at every point of the process and judge the quality of the answers. If you don’t like what you’re hearing, you can call off the engagement before signing on the dotted line.
Value Pricing
Again, because Meristem is currently a boutique-shop, we don’t have the overhead of a larger company and our prices reflect that. You’ll be getting the services of testers that have been at the top tiers of large consulting companies, without paying the large consulting company price.
Have another concern? Is there twist to the testing services you need? Feel free to reach out to
At the Denver OWASP meeting in October, Mark Hoopes vented about the marketing claims made by application security vendors. By examining the fundamental technical capabilities that several families of tools have to offer, he challenges some of the more outrageous claims made. You never know who might have developed a game changing technology, but by focusing on the typical limitations of the technology, you can ask the right questions to cut through the marketing and get to the useful details needed to make an informed tool buying decision. The slides of the presentation are shared here.
The calendar shared at DEF CON 31 and BSides Las Vegas is a collection of application security vulnerabilities observed on multiple pentests or that simply caught our eye. No one application is expected to have all, or even many of the vulnerabilities, but over the course of a year, by considering each one, a web application developer should pick up a few new tricks and hopefully will avoid at least one potential bug in their own code. The art was generated using DALL-E with a prompt that had some loose connection to each vulnerability. Some of them more loose than others.
Feel free to use some or all of the images. Our only ask is that the Meristem logo remain part of the finished product. Enjoy!
To get a quality application assessment, you'll want to provide more than just the URL of your website. Sure that's all an attacker usually starts with, but an attacker can spend months working on a chosen target, or scan the whole internet looking for a specific vulnerability they know how to exploit. For an assessment, the more information provided to the tester, the more efficient they will be and the more value you'll receive from your investment.
Meristem typically conducts at least two meetings prior to the actual start of testing. The first meeting is to get an understanding of what your application does and how it does it so that the testing scope can be agreed to and a Statement of Work written. To facilitate that conversation, Meristem uses the questionnaire below. While most of the information can be gathered during the meeting, knowing what's going to be asked, or even providing the information ahead of time helps to keep the meeting short and productive.
Once the Statement of Work has been agreed to, Meristem will work with you to gather all of the information needed to actually execute the assessment. This includes network access to the testing environment, credentials to sign in, and contact points to be used at various points of the engagement. Again, this questionnaire can be completed outside of a meeting, or during the pre-assessment kickoff meeting. Knowing what information, and by extension what preparations, need to be made helps keep the project on schedule.
Questionnaire 2 - Assessment Preparation
Both questionnaires contain field helps and of course Meristem is available to answer any questions that may come up.
Determining the quality of the assessment you receive can be tricky. Was the report short because the application is secure or because the tester cut corners? Are there no high findings because they don't exist or because they were missed? One method of judging the quality of the test is to take a good look at the level of detail in the findings that were written. Do they describe your environment specifically or do they look like they were copied from somewhere? A good finding should contain details that not only show that the the tester spent time examining your application, but also provide your developers with instructions on how to find, and how to start fixing the vulnerability.
The findings below are examples of how Meristem approaches writing a finding. These come from an open source application (findings from a previous contract would be a breach of confidentiality), but are representative of findings we commonly report. Each finding begins with a description of the way the application works, discusses the mechanics of the vulnerability, outlines potential abuse cases, and provides recommendations on how the vulnerability can be addressed in this specific application.
There are certainly findings that are common and where a standard write-up provides all the detail necessary, but if the top severity findings do not contain details that reflect the details of your environment specifically, then you have reason to question the thoroughness of the assessment.
Materials from "Gaps in the Magic: Exploiting Security Edge Cases in Rails"
Presentation Slides
Download "EdgeCasesInRailsSecurity.pdf"
Workshop Applications
Rails SQLi Workbook |
A multi-tenant Rails application that allows users to explore Active Record methods vulnerable to SQLi. | https://github.com/Meristem-Infosec/rails-sqli-workbook |
Marshal Bank |
A Rails application that mimics the account registration process of a bank. It is vulnerable to unmarshalling attacks. | https://github.com/Meristem-Infosec/MarshalBank |