Is it better to perform product management of information security solutions at a large company or at a startup? Picking the setting that’s right for you isn’t as simple as craving the exuberant energy of a young firm or coveting the resources and brand of an organization that’s been around for a while. Each environment has its challenges and advantages for product managers. The type of innovation, nature of collaboration, sales dynamics, and cultural nuances are among the factors to consider when deciding which setting is best for you.
The perspective below is based on my product management experiences in the field information security, though I suspect it’s applicable to product managers in other hi-tech environments.
Product Management at a Large Firm
In the world of information security, industry incumbents are usually large organizations. This is in part because growing in a way that satisfies investors generally requires the financial might, brand and customer access that’s hard for small cyber-security companies to achieve. Moreover, customers who are not early adopters often find it easier to focus their purchasing on a single provider of unified infosec solutions. These dynamics set the context for the product manager’s role at large firms.
Access to Customers
Though the specifics differs across organizations, product management often involves defining capabilities and driving adoption. The product manager’s most significant advantage at a large company is probably access to customers. This is due to the size of the firm’s sales and marketing organization, as well as due to the large number of companies that have already purchased some of the company’s products.
Such access helps with understanding requirements for new products, improving existing technologies, and finding new customers. For example, you could bring your product to a new geography by using the sales force present in that area without having to hire a dedicated team. Also, it’s easier to upsell a complementary solution than build a new customer relationship from scratch.
Access to Expertise
Another benefit of a large organization is access to funds and expertise that’s sometimes hard to obtain in a young, small company. Instead of hiring a full-time specialist for a particular task, you might be able to draw upon the skills and experience of someone who supports multiple products and teams. In addition, assuming your efforts receive the necessary funding, you might find it easier to pursue product objectives and enter new markets in a way that could be hard for a startup to accomplish. This isn’t always easy, because budgetary planning in large companies can be more onerous than Venture Capitalist fund raising.
Working in any capacity at an established firm requires that you understand and follow the often-changing bureaucratic processes inherent to any large entity. Depending on the organization’s structure, product managers in such environments might lack the direct control over the teams vital to the success of their product. Therefore, the product manager needs to excel at forming cross-functional relationships and influencing indirectly. (Coincidentally, this is also a key skill-set for many Chief Information Security Officers.)
Sometimes even understanding all of your own objectives and success criteria in such environments can be challenging. It can be even harder to stay abreast of the responsibilities of others in the corporate structure. On the other hand, one of the upsides of a large organization is the room to grow one’s responsibilities vertically and horizontally without switching organizations. This is often impractical in small companies.
What It’s Like at a Large Firm
In a nutshell, these are the characteristics inherent to product management roles at large companies:
An established sales organization, which provides access to customers
Potentially-conflicting priorities and incentives with groups and individuals within the organization
Rigid organizational structure and bureaucracy
Potentially-easier access to funding for sophisticated projects and complex products
Possibly-easier access to the needed expertise
Well-defined career development roadmap
I loved working as a security product manager at a large company. I was able to oversee a range of in-house software products and managed services that focused on data security. One of my solutions involved custom-developed hardware, with integrated home-grown and third-party software, serviced a team of help desk and in-the-field technicians. A fun challenge!
I also appreciated the chance to develop expertise in the industries that my employer serviced, so I could position infosec benefits in the context relevant to those customers. I enjoyed staying abreast of the social dynamics and politics of a siloed, matrixed organization. After awhile I decided to leave because I was starting to feel a bit too comfortable. I also developed an appetite for risk and began craving the energy inherent to startups.
Product Management in a Startup
One of the most liberating, yet scary aspects of product management at a startup is that you’re starting the product from a clean slate. On the other hand, while product managers at established companies often need to account for legacy requirements and internal dependencies, a young firm is generally free of such entanglements, at least at the onset of its journey.
What markets are we targeting? How will we reach customers? What comprises the minimum viable product? Though product managers ask such questions in all types of companies, startups are less likely to survive erroneous answers in the long term. Fortunately, short-term experiments are easier to perform to validate ideas before making strategic commitments.
Experimenting With Capabilities
Working in a small, nimble company allows the product manager to quickly experiment with ideas, get them implemented, introduce them into the field, and gather feedback. In the world of infosec, rapidly iterating through defensive capabilities of the product is useful for multiple reasons, including the ability to assess—based on real-world feedback—whether the approach works against threats.
Have an idea that is so crazy, it just might work? In a startup, you’re more likely to have a chance to try some aspect of your approach, so you can rapidly determine whether it’s worth pursuing further. Moreover, given the mindshare that the industry’s incumbents have with customers, fast iterations help understand which product capabilities, delivered by the startup, the customers will truly value.
In all companies, almost every individual has a certain role for which they’ve been hired. Yet, the specific responsibilities assigned to that role in a young firm often benefit from the person’s interpretation, and are based on the person’s strengths and the company’s need at a given moment. A security product manager working at a startup might need to assist with pre-sales activities, take a part in marketing projects, perform threat research and potentially develop proof-of-concept code, depending on what expertise the person possesses and what the company requires.
People in a small company are less likely to have the “it’s not my job attitude” than those in highly-structured, large organizations. A startup generally has fewer silos, making it easier to engage in activities that interest the person even if they are outside his or her direct responsibilities. This can be stressful and draining at times. On the other hand, it makes it difficult to get bored, and also gives the product manager an opportunity to acquire skills in areas tangential to product management. (For additional details regarding this, see my article What’s It Like to Join a Startup’s Executive Team?)
Product manager’s access to customers and prospects at a startup tends to be more immediate and direct than at a large corporation. This is in part because of the many hats that the product manager needs to wear, sometimes acting as a sales engineer and at times helping with support duties. These tasks give the person the opportunity to hear unfiltered feedback from current and potential users of the product.
However, a young company simply lacks the scale of the sales force that accommodates reaching many customers until the firm builds up steam. (See Access to Customers above.) This means that the product manager might need to help identifying prospects, which can be outside the comfort zone of individuals who haven’t participated in sales efforts in this capacity.
What It’s Like at a Startup
Here are the key aspects of performing product management at a startup:
Ability and need to iterate faster to get feedback
Willingness and need to take higher risks
Lower bureaucratic burden and red tape
Much harder to reach customers
Often fewer resources to deliver on the roadmap
Fluid designation of responsibilities
I’m presently responsible for product management at Minerva Labs, a young endpoint security company. I’m loving the make-or-break feeling of the startup. For the first time, I’m overseeing the direction of a core product that’s built in-house, rather than managing a solution built upon third-party technology. It’s gratifying to be involved in the creation of new technology in such a direct way.
There are lots of challenges, of course, but every day feels like an adventure, as we fight for the seat at the big kids table, grow the customer base and break new ground with innovative anti-malware approaches. It’s a risky environment with high highs and low lows, but it feels like the right place for me right now.
Which Setting is Best for You?
Numerous differences between startups and large companies affect the experience of working in these firms. The distinction is highly pronounced for product managers, who oversee the creation of the solutions sold by these companies. You need to understand these differences prior to deciding which of the environments is best for you, but that’s just a start. Next, understand what is best for you, given where you are in life and your professional development. Sometimes the capabilities that you as a product manager will have in an established firm will be just right; at others, you will thrive in a startup. Work in the environment that appeals to you, but also know when (or whether) it’s time to make a change.
This cheat sheet offers advice for product managers of new IT solutions at startups and enterprises. To print it, use the one-page PDF version; you can also edit the Word version to customize it for you own needs.
Responsibilities of a Product Manager
Determine what to build, not how to build it.
Envision the future pertaining to product domain.
Align product roadmap to business strategy.
Define specifications for solution capabilities.
Prioritize feature requirements, defect correction, technical debt work and other development efforts.
Help drive product adoption by communicating with customers, partners, peers and internal colleagues.
Participate in the handling of issue escalations.
Sometimes take on revenue or P&L responsibilities.
Defining Product Capabilities
Understand gaps in the existing products within the domain and how customers address them today.
Understand your firm’s strengths and weaknesses.
Research the strengths and weaknesses of your current and potential competitors.
Define the smallest set of requirements for the initial (or next) release (minimum viable product).
When defining product requirements, balance long-term strategic needs with short-term tactical ones.
Understand your solutions key benefits and unique value proposition.
Strategic Market Segmentation
Market segmentation often accounts for geography, customer size or industry verticals.
Devise a way of grouping customers based on the similarities and differences of their needs.
Also account for the similarities in your capabilities, such as channel reach or support abilities.
Determine which market segments you’re targeting.
Understand similarities and differences between the segments in terms of needs and business dynamics.
Consider how you’ll reach prospective customers in each market segment.
Engagement with the Sales Team
Understand the nature and size of the sales force aligned with your product.
Explore the applicability and nature of a reseller channel or OEM partnerships for product growth.
Understand sales incentives pertaining to your product and, if applicable, attempt to adjust them.
Look for misalignments, such as recurring SaaS product pricing vs. traditional quarterly sales goals.
Assess what other products are “competing” for the sales team’s attention, if applicable.
Determine the nature of support you can offer the sales team to train or otherwise support their efforts.
Gather sales’ negative and positive feedback regarding the product.
Understand which market segments and use-cases have gained the most traction in the product’s sales.
The Pricing Model
Understand the value that customers in various segments place on your product.
Determine your initial costs (software, hardware, personnel, etc.) related to deploying the product.
Compute your ongoing costs related to maintaining the product and supporting its users.
Decide whether you will charge customers recurring or one-time (plus maintenance) fees for the product.
Understand the nature of customers’ budgets, including any CapEx vs. OpEx preferences.
Define the approach to offering volume pricing discounts, if applicable.
Define the model for compensating the sales team, including resellers, if applicable.
Establish the pricing schedule, setting the priced based on perceived value.
Account for the minimum desired profit margin.
Product Delivery and Operations
Understand the intricacies of deploying the solution.
Determine the effort required to operate, maintain and support the product on an ongoing basis.
Determine for the technical steps, personnel, tools, support requirements and the associated costs.
Document the expectations and channels of communication between you and the customer.
Establish the necessary vendor relationship for product delivery, if necessary.
Clarify which party in the relationship has which responsibilities for monitoring, upgrades, etc.
Allocate the necessary support, R&D, QA, security and other staff to maintain and evolve the product.
Obtain the appropriate audits and certifications.
Product Management at Startups
Ability and need to iterate faster to get feedback
Willingness and need to take higher risks
Lower bureaucratic burden and red tape
Much harder to reach customers
Often fewer resources to deliver on the roadmap
Fluid designation of responsibilities
Product Management at Large Firms
An established sales organization, which provides access to customers
Potentially-conflicting priorities and incentives with groups and individuals within the organization
Rigid organizational structure and bureaucracy
Potentially-easier access to funding for sophisticated projects and complex products
CrowdStrike just acquired Payload Security, the company behind the automated malware analysis sandbox technology Hybrid Analysis. Jan Miller founded Payload Security in 2014. The interview I conducted with Jan in early 2015 captures his mindset at the onset of the journey that led to this milestone. I briefly spoke with Jan again, a few days after the acquisition. He reflected upon his progress over the three years of leading Payload Security so far and his plans for Hybrid Analysis as part of CrowdStrike.
Jan, why did you and your team decide to join CrowdStrike?
Developing a malware analysis product requires a constant stream of improvements to the technology, not only to keep up with the pace of malware authors’ attempts to evade automated analysis but also innovate and embrace the community. The team has accomplished a lot thus far, but joining CrowdStrike gives us the ability to access a lot more resources and grow the team to rapidly improve Hybrid Analysis in the competitive space that we live in. We will have the ability to bring more people into the team and also enhance and grow the infrastructure and integrations behind the free Hybrid Analysis community platform.
What role did the free version of your product, available at hybrid-analysis.com, play in the company’s evolution?
A lot of people in the community have been using the free version of Hybrid Analysis to analyze their own malware samples, share them with friends or to look-up existing analysis reports and extract intelligence. Today, the site has approximately 44,000 active users and around 1 million sessions per month. One of the reasons the site took off is the simplicity and quality of the reports, focusing on what matters and enabling effective incident response.
The success of Hybrid Analysis was, to a large extent, due to the engagement from the community. The samples we have been receiving allowed us to constantly field-test the system against the latest malware, stay on top of the game and also to embrace feedback from security professionals. This allowed us to keep improving at rapid pace in a competitive space, successfully.
I’m personally committed to ensuring that the community platform will stay not only free, but grow even more useful and offer new capabilities shortly. Hybrid Analysis deserves to be the place for professionals to get a reasoned opinion about any binary they’ve encountered. We plan to open up the API, add more integrations and other free capabilities in the near future.
What stands out in your mind as you reflect upon your Hybrid Analysis journey so far? What’s motivating you to move forward?
Starting out without any noteworthy funding, co-founders or advisors, in a saturated high-tech market that is extremely fast paced and full of money, it seemed impossible to succeed on paper. But the reality is: if you are offering a product or service that is solving a real-world problem considerably better than the market leaders, you always have a chance. My hope is that people who are considering becoming entrepreneurs will be encouraged to pursue their ideas, but be prepared to work 80 hours a week, have the right technology, the feedback from the community, amazing team members and lean on insightful advisors and you can make it happen.
In fact, it’s because of the value Hybrid Analysis has been adding to the community that I was able to attract the highly talented individuals that are currently on the team. It has always been important for me to make a difference, to contribute something and have a true impact on people’s lives. It all boils down to bringing more light than darkness into the world, as cheesy as that might sound.
This cheat sheet outlines tips for reversing malicious Windows executables via static and dynamic code analysis with the help of a debugger and a disassembler. To print it, use the one-page PDF version; you can also edit the Word version to customize it for you own needs.
Overview of the Code Analysis Process
Examine static properties of the Windows executable for initial assessment and triage.
Identify strings and API calls that highlight the program’s suspicious or malicious capabilities.
Perform automated and manual behavioral analysis to gather additional details.
If relevant, supplement our understanding by using memory forensics techniques.
Use a disassembler for static analysis to examine code that references risky strings and API calls.
Use a debugger for dynamic analysis to examine how risky strings and API calls are used.
If appropriate, unpack the code and its artifacts.
As your understanding of the code increases, add comments, labels; rename functions, variables.
Progress to examine the code that references or depends upon the code you’ve already analyzed.
Repeat steps 5-9 above as necessary (the order may vary) until analysis objectives are met.
Common 32-Bit Registers and Uses
Addition, multiplication, function results
Counter; used by LOOP and others
Baseline/frame pointer for referencing function arguments (EBP+value) and local variables (EBP-value)
Points to the current “top” of the stack; changes via PUSH, POP, and others
Instruction pointer; points to the next instruction; shellcode gets it via call/pop
Contains flags that store outcomes of computations (e.g., Zero and Carry flags)
F segment register; FS points to SEH chain, FS[0x30] points to the PEB.
Common x86 Assembly Instructions
Put the value 0xB8 in EAX.
Put EAX contents on the stack.
Remove contents from top of the stack and put them in EAX .
Put the address of variable EBP-4 in EAX.
Call the function whose address resides in the EAX register.
Increase ESP by 8 to shrink the stack by two 4-byte arguments.
Shift ESP by 0x54 to make room on the stack for local variable(s).
Set EAX contents to zero.
Check whether EAX contains zero, set the appropriate EFLAGS bits.
Compare EAX to 0xB8, set the appropriate EFLAGS bits.
Understanding 64-Bit Registers
EAX→RAX, ECX→RCX, EBX→RBX, ESP→RSP, EIP→RIP
Additional 64-bit registers are R8-R15.
RSP is often used to access stack arguments and local variables, instead of EBP.
When analyzing malware or performing other security research, it’s often useful to tunnel connections through a VPN in a public cloud. This approach helps conceal the analyst’s origin, contributing to OPSEC when interacting with malicious infrastructure. Moreover, by using VPN exit nodes in different cities and even countries, the researcher can explore the target from multiple geographic vantage points, which sometimes yields additional findings.
One way to accomplish this is to set up your own VPN server in a public cloud, as an alternative to relying on a commercial VPN service. The following tutorial explains how to deploy the Algo VPN software bundle on DigitalOcean (the link includes my referral code). I like using DigitalOcean for this purpose because it offers low-end virtual private server instances for as little as $5 per month; also, I find it easier to use than AWS.
Algo VPN Overview
Algo is an open source software bundle designed for self-hosted IPSec VPN services. It was designed by the folks at Trail of Bits to be easy to deploy, rely only on modern protocols and ciphers and provide reasonable security defaults. Also, it doesn’t require dedicated VPN client software for connecting from most systems and devices, because of native IPSec support.
To understand why its creators believe Algo is a better alternative to commercial VPNs, the Streisand VPN bundle and OpenVPN, read the blog post that announced Algo’s initial release. As outlined in the post, Algo is meant “to be easy to set up. That way, you start it when you need it, and tear it down before anyone can figure out the service you’re routing your traffic through.”
Accepting default options for the droplet should be OK in most cases. If you’re not planning to tunnel a lot of traffic through the system, selecting the least expensive size will probably suffice. Select the geographic region where the Virtual Private Server will run based on your requirements. Assign a hostname that appeals to you.
Once the new host is active, make a note of the public IP address that DigitalOccean assigns to it and log into it using SSH. Then run the following commands inside the new virtual private server to update its OS and install Algo VPN core prerequisites:
Set up the username for the people who will be using the VPN. To accomplish this, use your favorite text editor, such as Nano or Vim to edit the config.cfg file in the ~/algo directory:
Remove the lines that represent the default users “dan” and “jack” and add your own (e.g., “john”), so that the corresponding section of the file looks like this:
After saving the file and exiting the text editor, execute the following command in the ~/algo directory to install Algo software:
When prompted by the installer, select 5 to install “to existing Ubuntu 16.04 server”.
When proceeding with the installer, you should be OK in most cases by accepting default answers with a few exceptions:
When asked about the public IP address of the server, enter the IP address assigned to the virtual private server by DigitalOcean when you created the droplet.
If planning to VPN from Windows 10 or Linux desktop client systems, answer “Y” to the corresponding question.
After providing the answers, give the installer a few minutes to complete its tasks. (Be patient.) Once it finishes, you’ll see the “Congratulations!” message, stating that your Algo server is running. Make a note of the “p12 and SSH keys password for new users” that the message will display, in case you need to use it later.
Configuring VPN Clients
Once you’ve set up the Alog VPN service, follow the instructions on the Algo website to configure your VPN client. The steps are different for each OS. Fortunately, the Algo setup process generates files that allow you to accomplish this with relative ease. It stores the files in under ~/algo/configs in a subdirectory whose name matches your server’s IP address.
For instance, to configure your iOS device, transfer your user’s Apple Profile file that has the .mobileconfig extension (e.g., john.mobileconfig) to the device, then open the file to install it. Once this is done, you can go to Settings > VPN on your iOS device to enable the VPN when you wish to use it. If at some point you wish to delete this VPN profile, go to General > Profile.
If setting up the VPN client on Windows 10, retrieve from the Algo server your user’s file with the .ps1 extension (e.g., windows_john.ps1) and the file with the .p12 extension (e.g., john.p12). Then, open the Administrator shell on the Windows system and execute the following command from the folder where you’ve placed these files, adjusting the file name to match your name:
This will import the appropriate certificate information and create the VPN connection entry. To connect to the VPN server, go to Settings > Network & Internet > VPN. If you wish to remove the VPN entry, use the PowerShell command above, replacing “Add” with “Remove”.
Additional Considerations for Algo VPN
Before relying on VPN to safeguard your interactions with malicious infrastructure, be sure to confirm that it’s concealing the necessary aspects of your origin. If it’s working properly, the remote host should see the IP address of your VPN servers, instead of the IP address of your VPN client. Similarly, your DNS traffic should be getting directed through the VPN tunnel, concealing your client’s locally-configured DNS server. One way to validate this is to use whoer.net, comparing what information the site reveals before and after you activate your VPN connection. Also, confirm that you’re not leaking your origin over IPv6; one way to do that is by connecting to ipv6leak.com.
You can turn off the virtual private server when you don’t need it. When you boot it up again, Algo VPN software will automatically launch in the background. If running the server for longer periods of time, you should implement security measures necessary appropriate for Internet-connected infrastructure.
As you use your Algo VPN server, adversaries might begin tracking the server’s IP address and eventually blacklist it. Therefore, it’s a good idea to periodically destroy this DigitalOcean droplet and create a new one from scratch. This will not only change the server’s IP address, but also ensure that you’re running the latest version of VPN software and its dependencies. Unfortunately, after you do this, you’ll need to reimport VPN client profiles to match the new server’s IP address and certificate details.
Startups are the innovation engine of the high-tech industry. Those who’ve participated in them have experienced the thrill and at times the disappointment of navigating uncharted territories of new ideas. Others have benefited from the fruits of these risk-takers’ labor by using the products they created.
What’s it like to contribute at an early stage of a startup? Below are my reflections on the first few months I’ve spent at Minerva so far. I joined this young endpoint security company as VP of Products not too long ago (and I’m loving it). I’ve outlined some takeaways in a generalized form that might benefit others in a similar position or those that are curious about entrepreneurial environments.
Situational Awareness: Where Am I?
When you come into a company—large or small—you already have some idea regarding the type of the organization you’re joining. Your understanding is incomplete at best. After all, it’s is based on your perspective as an outsider, and is informed mainly by the company’s official external communications (website, brochures, job posting) and the interactions you’ve had during the interviewing process.
Of course, you’ll learn as much as you can about the firm before deciding to come on board; validate all your assumptions and fill in the gaps in your understanding after starting the job:
If the company is small, this quite literally means taking the time to speak with as many of your new colleagues as possible, not only to start getting to know them, but also to understand their perspective on the company’s successes and challenges. Who are these individuals, what do they do, and how might you be of help?
Similarly, talk to the board members: What are they most excited about? What are their biggest concerns? What do they expect of you? In what ways might they be able to help you in meeting those objectives, on the basis of their expertise and connections? How involved do they want to be in the company’s operations and your activities?
In addition, understand the mindset of the company’s customers and partners. What do they appreciate the most about the firm? Where do they see opportunities for improvements? How do they collaborate with the company today? How might you assist them in the short and long term? Where might they help you?
At this initial stage on your involvement with the company, you still have the benefit of easily asking questions that later might sound silly. At the moment, it’s also easier to let yourself say “I don’t know, but I’ll find out” when you face a question you cannot answer. You’re gaining situational awareness, starting to understand your tools and priorities, getting to know the people, and adjusting the mental model you’ve built while you were still an outsider to the firm.
I had the benefit of participating in Minerva’s Advisory Board prior to becoming an employee. This allowed me get to know some of my future colleagues and confirm that we’ll get along, as well as to make sure that we’re aligned on the company’s direction. Still, only after spending several weeks immersed in the company’s day-to-day activities did I truly begin to feel like I knew where I was and I was doing there.
Takeaways: It takes longer than you might expect to feel fully engaged and productive with the new team. Do your research beforehand, but accept that you can only see a sliver of the actual company. Interact with others as much as possible, but leave time for reflection.
Self-Discovery: Who Are We?
If you’re joining a startup’s executive team, there’s a good chance that it’s entering a new phase of its life cycle. In the case of Minerva, I came on board as the company was preparing to enter the US market. It was starting to build a sales force and formalize its go-to-market strategy. The firm has been in existence for three years by that time, which allowed it to build the underlying framework and several product components. It gained feedback from early customers, assembled the R&D team and was ready to make itself known to the world.
After establishing an executive team, the startup will likely be looking to learn from its experiences so far and determine the direction for the next stage of its development. Since you’re new to the effort, you’ll need to begin by learning about colleague’s impressions and ideas before voicing your own. However, don’t wait too long before sharing your opinions. For the next few weeks you still have the fresh perspective that allows you to empathize with outsiders—customers, analysts, partners, investors—in a way that’s very difficult to do once you’ve formally integrated into the collective.
Lots of frameworks exist for helping you and other members of the executive team determine the business strategy. You can start with SWOT analysis, which, as Wikipedia summarizes, encourages you to understand the following aspects of your firm:
“Strengths: characteristics of the business … that give it an advantage over others
Weaknesses: characteristics of the business that place [it] at a disadvantage relative to others
Opportunities: elements in the environment that the business … could exploit to its advantage
Threats: elements in the environment that could cause trouble for the business”
It will likely take many brainstorming sessions, informal conversations, emails and adviser interactions to understand and verbalize the way in which your solution is related to other products your ecosystem. What problems are you solving and, most importantly, what are you not trying to tackle? What’s your competition? Why should customers care about you? What will industry analysts think? Once you’ve figured this out, know you’ll need to adjust as the company and the market evolves.
As with any self-reflective experience, determining who you are and how you hope to be perceived by others is both challenging and exhilarating. Engaging in this exercise forces you to ask tough questions about yourself. You also need to tap into your inner optimist to envision a future in which you’ll succeed despite, or perhaps because, of the challenging road ahead.
In the case of Minerva, the company developed a unique way of combating evasive malware. However, having a strong technological base alone is insufficient: we needed to determine how to explain not only what we do, but why customers would benefit from the solution in a way that they cannot with the existing security layers. How are we related to baseline anti-malware tools? What about the “next-gen” players? (For more on this, see my Questions for Endpoint Security Startups post.)
Takeaways: Harness the external perspective you have after just joining the firm to introduce new ideas and challenge the old ones. Recognize that marketing and management frameworks are just suggestions for how to devise a business strategy. Be realistic about market dynamics and possibilities, but remember the need to stay optimistic when embarking upon new ventures.
Once you’ve understood where and who your company is, you’re ready to explain this to others. That means making your presence known in the targeted markets, as you begin to fill the sales pipeline and close deals, and as you continue to develop your product. You’re not only interacting with prospective customers directly, but are also working with industry analysts and other influences, educating them about your existence and value proposition, and soliciting feedback regarding the vision for your product.
Your company probably has a budding sales force, which you need to equip with the tools they’ll use when explaining the value of your solution. Depending on your specific role, you might be tasked with creating, contributing, or providing feedback on internal documentation that summarizes the results of the earlier self-discovery process to keep everyone in the company informed and marching to the same beat. Ditto for external-facing collateral, such as the company’s website contents, brochures, whitepapers, etc. Much of the documents the company developed in its earlier stages might need to be revised, retired or expanded.
External communications are about persuasion: you need to convince others to pay attention to your ideas and solutions, which often entails changing their perspective and challenging their assumptions.
You’re passionate about the benefits of your technology; yet, organizations are cautious of newcomers. Moreover, the market is dominated by the rhetoric of the incumbents, which requires the new entrants to clearly articulate how they fit into the existing marketplace and educate prospects about seeing through the marketing hype. To be heard, a young company must engage in persuasive communications as it builds up its core customer base and establishes a reputation. As a member of the executive team, it’s up to you to make this happen.
As I write this, Minerva just announced the closing of a Series A funding round. Encouraged by the enthusiasm of early adopters and the feedback from prospects, we established a sales team, formalized product roadmap plans, and updated the company’s marketing collateral. A lot of my time is spent speaking with prospects, customers, analysts, partners and, of course, colleagues, in addition to continuing to enhance the product.
Takeaways: Understanding your product’s value and your company’s strategy is only part of the battle. Persuading others to support you in this endeavor requires lots of external communications (see How to Be Heard in IT Security and Business). Be ready to spend lots of time writing papers, creating and editing slide decks, drafting and answering emails, speaking on the phone and meeting with people one-on-one and at industry events. And continue to deliver upon product roadmap commitments.
“Zero-day” is the all-powerful boogieman of the information security industry. Too many of us invoke it when discussing scary threats against which we feel powerless. We need to define and disambiguate this term before attempting to determine whether we’ve accounted for the associated threats when designing security programs.
Avoid Zero-Day Confusion
I’ve seen “zero-day” used to describe two related, but independent concepts. First, we worry about zero-day vulnerabilities—along with the associated zero-day exploits—for which we have no patch. Also, we’re concerned about zero-day malware, which we have no way of detecting.
These scenarios can represent different threats that often require distinct countermeasures. Let’s try to avoid confusion and FUD by being clear about the type of issues we’re are describing. To do this, in short:
Use “zero-day” as an adjective. Don’t use it as a noun.
This way you’ll be more likely to clarify what type of threat you have in mind.
The term zero-day (sometimes written as “0day”) appears to originate from the software pirating scene, as @4Dgifts pointed out to me on Twitter. It referred to cracked software (warez) distributed on or before its official release date; this is outlined on Wikipedia. By the way, if you like leetspeak, writing “0day” is fine when addressing technologists; stick to “zero-day” if your audience includes executives or business people.
Zero-Day Vulnerabilities and Exploits
Let’s start with zero-day vulnerabilities. I came across the following reasonable definition of this term in FireEye’s Zero-Day Danger report, which is consistent with how many other security vendors use this term:
“Zero-day vulnerabilities are software flaws that leave users exposed to cyber attacks before a patch or workaround is available.”
Along these lines, a zero-day exploit is one that targets a zero-day vulnerability.
I’ve encountered numerous articles that ask “What is zero-day malware?” and then confuse the matter by proceeding to discuss zero-day exploits instead. Even FireEye’s report on zero-day vulnerabilities, mentioned above, blurred the topic by briefly slipping into the discussion of zero-day malware when it mentioned that “code morphing and obfuscation techniques generate new malware variants faster than traditional security firms can generate new signatures.”
To avoid ambiguity or confusion, I prefer to use the term zero-day malware like this:
Zero-day malware is malicious software for which there is no currently-known detection pattern.
The word “pattern” includes the various ways in which one might recognize a malicious program, be it a traditional signature, a machine learning model, or behavioral footprints. I think this definition is consistent with the type of malware that Carl Gottlieb had in mind during our discussion on Twitter malware variants that don’t match a known identifier, such as a hash.
Another “zero-day” term that security professionals sometimes use in this context is zero-day attack. Such an assault is reasonably defined Leyla Bilge and Tudor Dumitras in their Before We Knew It paper:
“A zero-day attack is a cyber attack exploiting a vulnerability that has not been disclosed publicly.”
However, what if the attack didn’t involve zero-day vulnerabilities, but instead employed zero-day malware? We’d probably also call such an incident a zero-day attack. Ambiguity alert!
Unless you need to be general, consider staying away from “zero-day attack” and clarify which of zero-day concept you’re discussing.
Avoid the Ambiguity, Save the World
Why worry about “zero-day” terminology? There is an increasingly-acute need for infosec designs that account for attacks that incorporate unknown, previously-unseen components. However, the way organizations handle zero-day exploits will likely differ from how they deal with zero-day malware.
By using the “zero-day” as an adjective and clarifying which word it’s describing, you can help companies devise the right security architecture. In contrast, asking “What is zero-day?” is too ambiguous to be useful.
As I mentioned when discussing fileless malware, I am especially careful with terms that risk turning into industry buzzwords. My endpoint security product at Minerva focuses on blocking unknown malware that’s designed to evade existing defenses, and I want to avoid misrepresenting our capabilities when using the term zero-day. Perhaps this write-up will help my company and other security vendors better explain how we add value to the security ecosystem.
What’s the deal with “fileless malware”? Though many security professionals cringe when they hear this term, lots of articles and product brochures mention fileless malware in the context of threats that are difficult to resist and investigate. Below is my attempt to look beyond the buzzword, tracing the origins of this term and outlining the malware samples that influenced how we use it today.
Frenzy for Fileless
The notion of fileless malware has been gaining a lot of attention at industry events, private meetings and online discussions. This might be because this threat highlights some of the deficiencies in old-school endpoint security methods and gives new approaches an opportunity to highlight their strengths.
Indeed, according to Google Trends, people’s interest in this term blipped in 2012 and 2014, began building up toward 2015 and spiked in 2017.
This pattern corresponds to the publicly-discussed malware that exhibited “fileless” capabilities in the recent years, and with the burst of research and marketing publications that appeared in 2017.
What is Fileless Malware?
Let’s get this out of the way: Fileless malware sometimes has files. Most people today seem to be using the term fileless malware in a manner consistent with the following definition:
Fileless malware is malware that operates without placing malicious executables on the file system.
This definition accommodates situations where the infection began with a malicious script or even a benign executable on the file system. It also matches the scenarios where the specimen stored artifacts in the registry, even though Windows keeps registry contents on disk. It applies regardless of the way in which the infection occurred, be it an exploit of a vulnerability, a social engineering trick, or a misuse of some feature.
Though initially fileless malware referred to malicious code that remained solely in memory without even implementing a persistence mechanism, the term evolved to encompass malware that relies on some aspects of the file system for activation or presence. Let’s review some of the malicious programs that influenced how we use this term today.
2001-2003: Code Red and SQL Slammer
The notion of malicious code that resides solely in memory certainly existed prior to the 21st century. Yet, it wasn’t until the highly-prolific Code Red worm left its mark on the Internet in 2001, did the term fileless malware enter the general parlance. The earliest public reference I could find dates to summer 2001, when Kaspersky Labs published an announcement that quoted none other than Eugene Kaspersky:
“We predict that in the very near future, such ‘fileless’ worms as Code Red will become one of the most widespread forms of malicious programs, and an anti-virus’ ineffectiveness in the face of such a threat simply invites danger.”
A year and a half later another worm—SQL Slammer—spread like wildfire by exploiting a vulnerability in Microsoft SQL servers. Robert Vamosi, writing for ZDNet in 2003, described this malware as “file-less” and mentioned that it resided “only in memory, much as Code Red.”
“Malicious code that is not file based but exists in memory only… More particularly, fileless malicious code … appends itself to an active process in memory…”
The original definition of fileless malware was close to the English meaning of the words that describe malware that remains active without leaving any files.
2012: A Bot That Installed the Lurk Trojan
The next fileless malware reference I could locate appeared nearly a decade after Code Red and SQL Slammer worms. In 2012, Sergey Golovanov at Kaspersky Labs presented his analysis of a bot that didn’t save any files to the hard drive, explaining that:
“We are dealing with a very rare kind of malware — the so-called fileless malicious programs that do not exist as files on the hard drive but operate only in the infected computers RAM.”
The unnamed specimen exploited a client-side Java vulnerability and operated solely in memory of the affected javaw.exe process. Sergey mentioned that the bot was capable of installing the Lurk banker trojan.
Earlier that year, Amit Malik at SecurityXploded published an educational write-up, explaining how to achieve “in-memory or file-less execution” of a Windows program without saving it to disk after downloading it from the Internet.
2014: Powerliks, Angler, Phase Bot
A month later, security researcher Kafeine documented an Angler exploit kit infection that exhibited fileless characteristics. The attack targeted a client-side Java vulnerability and operated solely in memory of the affected javaw.exe process. In a related future occurrence, Angler began installing Bedep downloader in 2016 that, according to Palo Alto’s Brad Duncan, “is installed without creating any files because it is loaded directly into memory by the exploit shellcode.”
2014-2015: Duqu 2.0, Kovter
In mid-2015, Kaspersky Labs published details about an advanced adversary that operated in 2014-2015 using a sophisticated malware platform that the vendor called Duqu 2.0. The attack utilized a Windows vulnerability to install stealthy malware that remained solely in memory of the infected host. It did not implement a persistence mechanism. Instead, the researchers explained, the attackers targeted servers with high uptime and then re-infected the systems that got “disinfected by reboots.”
2016: PowerSniff, PowerWare, August
In mid-2016, Josh Grunzweig and Brandon Levene at Palo Alto Networks documented a malicious program they dubbed PowerSniff. The infection began with a Microsoft Word document that contained a malicious macro. The in-memory mechanics of this specimen resembled some aspects of Kovter and involved a PowerShell script that executed shellcode, which decoded and executed additional malicious payload, operating solely in memory. PowerSniff had the ability to temporarily save a malicious DLL to the file system.
A couple of weeks later, Mike Sconzo and Rico Valdez at Carbon Black described a ransomware specimen they called PowerWare. Like PowerSniff, PowerWare began its infection with a Microsoft Office document that contained a malicious macro, which ultimately launched PowerShell that continued the infection process without placing malicious executables on the file system.
Another fileless malware sample that utilized Microsoft Word macros and PowerShell was documented later in the year by Proofpoint. It was named August. According to the researchers, the specimen downloaded a portion of a payload “from the remote site as a PowerShell byte array,” executing it in memory without saving it to the file system.
2017: POSHSPY, etc.
In early 2017, Kaspersky Labs described an unnamed incident where adversaries stored Meterpreter-based malicious code solely in memory. The only file system artifacts were legitimate Windows utilities such as sc (to install a malicious service that ran PowerShell) and netsh (to tunnel malicious network traffic).
Several months later, Matthew Dunwoody at Mandiant described another sophisticated attack that involved fileless malicious code. Named POSHSPY, the specimen used Windows Management Instrumentation (WMI) capabilities of the OS to maintain persistence and relied on PowerShell for its payload. The specimen had the ability to download executable files, which it would save to the file system. Matthew concluded that:
By “living off the land,” this adversary implemented “an extremely discrete backdoor that they can deploy alongside their more conventional and noisier backdoor families, in order to help ensure persistence even after remediation.”
The incidents above highlighted the powerful capabilities available to intruders even when they rely solely on built-in benign programs to execute malicious payload on the infected systems.
Alternatives to Saying “Fileless Malware”
Sergey Golovanov’s 2012 article mentioned above originally used the term fileless malware. Interestingly, it has been revised and now uses the term bodiless malware instead. Kaspersky Labs experimented with saying bodiless malware as late as 2016, but it seems to have returned to fileless malware in other writeups in 2017.
Speaking of the terms that didn’t take off… The notion of Advanced Volatile Threat (AVT) gained some buzz in 2013 after, according to Wikipedia, being coined by John Prisco of Triumfant Inc. The short-lived AVT moniker popped up in Byron Acohido’s USA Today article in 2013 in reference to a backdoored version of Apache software. According to Pierre-Marc Bureau, who was at ESET at that time, the backdoor left “no traces of compromised hosts on the hard drive other than its modified” web server binary.
In contrast, a reasonable alternative to the term fileless malware was introduced by Carbon Black in its 2016 Threat Report. The report used the phrase non-malware attacks. Writing on the company’s blog a few months later, Michael Viscuso explained the meaning of this term like this:
“A non-malware attack is one in which an attacker uses existing software, allowed applications and authorized protocols to carry out malicious activities. Non-malware attacks are capable of gaining control of computers without downloading any malicious files, hence the name. Non-malware attacks are also referred to as fileless, memory-based or ‘living-off-the-land’ attacks.”
I like the idea of saying “non-malware attacks” for incidents that rely solely on legitimate system administration tools and other non-malicious software. This is the scenario that some people describe as living-off-the-land. In contrast, I might prefer to say “memory-only malware” if I need to point out that malicious code is never saved to disk, perhaps because it was injected into another process. I’m even OK with saying “fileless malware” when bringing focus on persistence mechanisms that avoid placing traditional executables on the file system.
Unfortunately, nowadays the terminology has been commingled, and we’re probably stuck with the term “fileless malware” to describe the various scenarios outlined above, despite the term’s ambiguity. Alas, human language is imprecise and always-evolving. (If we all spoke C#, perhaps the world would be a better place.)
I care about this terminology because I’m trying to avoid buzzwords and empty phrases when describing the capabilities of the anti-malware product for which I’m responsible at Minerva. It runs alongside other endpoint security tools and blocks all sorts of sneaky malware, regardless whether its payload touches disk. I’m often asked how we handle fileless malware; I decided to perform the research above to better understand how and when I should use this term.
As much as I look forward to change sometimes, I am often hesitant to forego the familiar despite recognizing the risks of becoming too comfortable in the same job. Fortunately, I’ve come across an opportunity to take on a new role that matches all three professional objectives I defined for myself:
Contribute towards advancing the practice of information security.
Grow commercial businesses whose value is tied to securing information.
Help organizations in their fight against malicious software.
I’m joining a young anti-malware company Minerva Labs as VP of Products. I’m taking on this role not only because it’ll allow me to curtail the effectiveness of malware on endpoints, but also because I love the character and ingenuity of the people that built Minerva. The position will allow me to continue teaching malware analysis at SANS Institute and maintain the REMnux toolkit, which is consistent with the above-mentioned objectives.
Why Minerva Labs?
Minerva’s underlying technology is focused on controlling how malware perceives its reality. What if you could fool malware into thinking it’s running in an analysis sandbox, causing it to stop executing to avoid revealing its true nature? What if you could make ransomware believe it’s encrypting files while blocking the encryption and backing up the user’s files? What if you could simulate the presence of infection markers that malware checks to avoid infecting the system twice?
I’ve written about similar ideas before (immunization, ransomware), yet dreaming up ideas is the easy part. The folks at Minerva actually managed to create products that make it feasible to employ such deception-based approaches in the real world. I’m joining them to continue evolving this platform and the technologies that could be built upon it.
I was also impressed by Minerva’s attention to the practicality of deploying their products in production. Extremely lightweight agent; no reboots to install or upgrade; no irrelevant alerts. Strengthen the security architecture without expecting the enterprise to overhaul it. Not only work alongside existing anti-malware solutions, but also help them reach their full potential.
Oops, is this starting to sound like a sales pitch? Sorry, I felt inclined to explain my reasons and share my excitement about this step in my professional journey. It’s kind of a big deal.
Getting to Know Minerva
By the way, Eddy Bobritsky, Minerva’s CEO, recently participated in the Startup Security Weekly podcast. This interview, which you can watch below, explains Minerva’s objectives and gives you a chance to hear from some of the people behind the company.
If you are working to better protect your organization’s systems and have a wish-list for ideas you’d like to see in an anti-malware solution, let me know. What would you like to see in an innovative endpoint security product? What’s your take on the way Minerva positions its approach? I’d love to hear your thoughts. Also, if you want to get to take a closer look at our products, I’ll be glad to schedule a discussion and arrange a demo.
Read Full Article
Read for later
Articles marked as Favorite are saved for later viewing.
Scroll to Top
Separate tags by commas
To access this feature, please upgrade your account.