Frankly Speaking - Building products for security engineering
Guest post by Dave Cole, CEO/founder of OpenRaven
I’m excited that Dave Cole, CEO/founder of OpenRaven, has decided to guest post on my blog! He’s had an illustrious career having been the product leader at major security companies, such as Crowdstrike and Tenable. He’s discussing a topic that I’ve personally passionate about and have had many exchanges with Dave on.
Please check out OpenRaven if you haven’t! It’s a modern, cloud-native product that helps discover and classify data across clouds.
Intro
Somehow, after over 20 years, I remember the configuration screen for the Foundstone scanner. It offered me a variety of options for finding machines, from obscure ICMP and UDP settings to a variety of TCP scans. In every way, products like this were emblematic of how we built security products in the 90s and through the early 2000s. We assumed the person using the tools were tinkerers. Explorers were likely to be more disappointed that they couldn’t change the name of the SNMP community string they were scanning for than they would be frustrated by a bunch of technical jargon in the UI.
Times changed. Threats like Blaster, Slammer, and Nimda along with a wide variety of spyware, adware, and other threats thrust security from the esoteric to the mainstream. Spam and phishing made security awareness training mandatory, forcing cybersecurity to become a business problem versus something the IT people worried about. And security products changed as a result. We got alerts. A metric ton of alerts that shouted loudly at whoever had the misfortune of seeing them that this was a product of compelling value. And we had role-based access control for every poor soul who needed to partake in the alert extravaganza. More of an exec type? Dashboards. Miles of reports and pie charts as far as the eye could see.
In fairness, some of the products did prevention and quietly did their work with little configuration or fuss. For every ultra-noisy DLP product, there were battalions of firewalls and antivirus toiling away largely in silence. Prevention was the infrequently achieved holy grail: it was always requested, typically delivered, and rarely used except by the truly brave or those who had less to lose from a (perhaps routine) false positive than a breach.
In spite of what you may have seen on the show floor of RSA this April, we’ve entered a new phase of cybersecurity product design. One that signals the emergence of security engineers and hands-on architects as the dominant personas. You can see this plainly in the domain of cloud security where the practitioners are decidedly more technical as well as API and software security. How does one meet the needs of the current and future generations of security professionals? The rest of this post explores the primary implications, starting with how the next generation of products will be purchased and deployed.
Marketing & Sales
Classic security go-to-market trumpets the deep expertise of the organization. The incomparable network of intelligence backing the products. The infallible AI underneath the hood. The brilliance of the founders. This tired approach is far too common and fails a basic test: How does any of this help me get things done faster/better/cheaper?
We are moving from a “trust us” sales and security model to one based on transparency. Engineers don’t want to know how great you feel about your solution and team, they want to know what it is and how it works. Plainly stated. An example is the landing page for Vault from HashiCorp which states: “Manage access to secrets and protect sensitive data. Create, store, and secure access to tokens, passwords, certificates, and encryption keys.” Very little sex appeal, but 100% signal and I now have the confidence of knowing exactly what it is and how it can help me. Bullseye.
This doesn’t mean we’re moving to a world dominated by open source, automated trials, or the other mechanisms of product-led growth (PLG). PLG is a wonderful model when it works, but it is decidedly rare and may continue to be so due to the sensitivity of a free offering having access to your data, identities, endpoints, etc. It’s unclear how we overcome those objections and I’m not sure that we should. Nonetheless, some of the best aspects of OSS and PLG can be readily borrowed by even conventional products, such as making documentation a first-class citizen and available to prospects who want to dig deep before making a purchase.
Pricing & Purchasing
Since the early days, we’ve often preferred buying products from partners who would make sure we got a fair price, a few options to choose from, and someone to help out if the vendor disappeared. This is not the prevailing model in the cloud nor the future of cybersecurity. Even the value-added resellers agree they’re moving to sell managed services en masse and downplaying their role in selling products.
The role of the channel in making products easy to purchase (e.g., having legal terms negotiated with one company vs. many), is being absorbed by the cloud service providers. AWS, GCP, and Azure are only too happy to add more to your monthly bill, take margin from vendors, and in the process pay down the amount you might ultimately owe them as part of an agreed-upon enterprise discount program.
So who helps ensure you’ve made a great choice? Shorter term contracts, hands-on testing, and easier integration significantly reduce the stakes of any purchase decision instead of relying on the opinion of a 3rd party. And how can you be certain you’re being quoted a fair price? That’s harder to answer. And even more difficult given that there can be surprising costs related to how cybersecurity products harness cloud services. Those API calls are not free if they’re happening in your infrastructure. Further, your own platform design can pose unexpected obstacles. I know of a situation where a CISO recently spent around $1M for a CSPM, only to be blocked in his deployment by a cloud architecture design whereby they simply could not handle the additional DNS-related API calls. Painful.
Is the emerging model better or worse? It’s simply different. Shorter cycles with our CSPs as resellers and pricing that feels more opaque than ever before. The way forward here for those building products should be focused on pricing and cost transparency so that the full operational expense of the solution is understood at the time of purchase.
Setting Up
Nothing says the 90s more than the months of deployment services that accompanied SAP, Peoplesoft, and large-scale security deployments. Long gone are the days when it was ok for products to require extensive professional services that exceed the software license cost. In the emerging model, services still have a role but a reduced one that focuses on customization vs. setup and configuration. Managed services have eroded the services market as well— if you’re going to need significant services to get underway, perhaps it’s better to hand it off instead and let someone else run it.
The natural partner of Security Engineering is DevOps instead of the longstanding relationship security teams have had with IT. They’re the gatekeepers for the deployment and typically stakeholders in the results as well. And be warned, they can smell a “lift and shift” on-premises product from a mile away. A security product that requires DevOps to grant it an aggressive amount of permissions to operate is perhaps even worse. This not only puts the sponsoring security engineer in an awkward spot but it also creates considerable risk. Vendors: threat model your own product: what would happen if it was compromised? Is the cure worse than the illness?
Steady State & The Automation Mandate
In the early days of security, we borrowed significantly from our IT brethren. It saved us time and made it easier to get along with them as partners. Similarly, security engineering takes cues from site reliability engineers and DevOps in general. Importantly, they share a strong aversion to toil: the time and effort spent on repetitive, manual tasks that do not add value. The antidote to toil is automation (and more occasionally, outsourcing).
Designing security products for automation requires not only solid APIs but also documentation to go with them. Further, it means there are audit logs so that you can determine what happened with the automated workflow. Just because no one was looking, doesn’t mean we don’t ever need to look. It just means no one wants to have to stare at a console or require a person to make something mundane happen.
While security engineers tend to avoid consoles, this does not mean that they don’t appreciate a good UI and never want to log in. Setup and configuration are typically faster if it has a solid user interface to guide it. And following setup, a console can “earn” its logins by providing unique value that saves security engineers time and effort. A good example of this is the attack path visualizations offered by EDR vendors, interactive query builders that simplify searching, and maps like the one we’ve built at Open Raven that simplifies viewing an environment, making it easier to spot anomalies. How can you gauge whether the UI is worth the investment? Prototype it in Figma and then ask a security engineer whether or not it will save them time and effort.
Reporting Out, Reporting In
In this final section, we run close to a contradiction. A product that has no built-in reporting is going to fall short as it requires more effort to understand and share results. Conversely, a product has to equally assume its data is going to be combined with other security data as part of the broader security communications effort. Both are necessary.
Increasingly, there isn’t one “right” way to report inside a product or flow data out to a SIEM, data lake, etc. The key to meeting customer needs lies in flexibility, or stated another way, a lack of hard-coded assumptions. This means filters and format options take priority over aesthetics for reporting. A familiar query language and/or a query builder for built-in searching. And for sending data out of a product? We had a lot of success at CrowdStrike with a firehose API and since my time there I’ve had requests (and delivered) everything from a dedicated Snowflake database to AWS EventBridge and a dump to a parquet file. What’s required here? A strong general-purpose option, a solid underlying architecture, and a sense of humor.
Takeaway: a Confession
Exactly zero products I’ve built over the years have done an excellent job across all these areas. And I’m sure there are plenty of other criteria that could be added to the list. Everything from the threat landscape to the regulatory environment is constantly shifting in cybersecurity— this has a direct impact both on our jobs and the tools we rely upon. Even before the current AI boom, the rate of change was breathtaking. Vendors, it’s time to revisit our assumptions about who we’re building for and what they truly need.
 | A guest post by
|