Some Generic SIEM Requirements to Ponder
Being tasked with selecting a Security Information and Event Management (SIEM) tool for your organization can be a bit overwhelming. I’ve been there and chosen poorly (in my last life)! The questions you need to ask the SIEM vendor you are buying from are limitless as every customer’s needs are different and the business drivers range from “check-box” compliance to actual enterprise incident handling and response.
Numerous customers have approached me with what they thought were straight Log Management (LM) requirements, since they have only ever had the luxury of manual log review using the “Grep”, “Awk”, “Sed” approach or “spreadsheet Kung Fu”, while others have the budget and want to “boil the oceans”. There are hurdles with both approaches, while the former may be the way to “grow” into a mature concept such as a SIEM tool and the latter will never be outgrown.
In fact, before you can perform real-time analysis on all of the logs to detect threats as they occur, you need to capture all of the event data from the plethora of heterogenous event sources and store the logs in a centralized location. Therefore, I believe log management is an essential part of SIEM because, with the right tool, 100% of your logs are readily available with automated archiving and retention. Additionally, since you have mandated all of the logs from the various technologies to be sent to your central facility, the teams that manage the devices will need an easy-to-use tool that will allow them to do their day-to-day tasks such as troubleshooting network issues, application development debugging, long-term investigations and possibly the last six months of an employees activity for HR or litigation purposes.
Regardless, you should have a strong command of what it is you need SIEM for and use vehicles such as Request For Information (RFI) or Request For Proposal (RFP) to rate each vendor on the top mandatory requirements vs. the “nice-to-have’s”. For this purpose, I have compiled a list of questions that you may determine to be useful when creating your vendor ratings criteria. Here are what I believe to be essential 70+ requirements for the ultimate SIEM and Log Management tool:
Essential Tools Every SE Needs
I have only been doing the SE gig for three years now and I have learned a lot from my own mistakes or from other SEs I work with. Here’s a compilation of things that I regard as being the “trade-craft” for Sales Engineers:
Laptop: Your company will probably outfit you with your own laptopwith enough juice to run a VMWare demo and PowerPoint slide deck simultaneously, while projecting your desktop onto a presentation screen. Make sure you do the regular maintenance so your system will keep up with the demands. There’s nothing more frustrating than being in the middle of a 3 hour demo and your system freezes for no reason and you have to reboot, thus delaying the demo and creating a 10 minute window when the customer loses interest in what you are presenting. Additionally, if your company allows you to claim business related expenses, drop the cash on a solid-state drive for your demo VMs and install the maximum amount of RAM your laptop can handle.
SIEM Sales Engineer Top 5 Trial Tips
In my role as an SE there are many challenges during the sales cycle that need to be addressed and I have had my share of dents and bruises because I didn’t adhere to any part of the 5 tips I’ve detailed below. These are my top 5 tips that have been instrumental in making trials run smoothly:
Scoping: Winston Churchill once said “Let our advance worrying become advance thinking and planning”. Too often in my early days as an SE would I anticipate all that could go wrong on a trial because I didn’t have enough experience with what could go “right”. Once you have a few successful trials under your belt you begin to see the trends and tasks that are most effective.
One of the best tools in preparation for any product trial is the Proof of Concept (POC) scoping call. Arrange a quick conference call with your prospect and ask them to extend the meeting to all of the various technology and security stake-holders in their organization. During the call, establish the duration, shipping addresses for equipment, contacts, event sources, success criteria, use cases, custom content, etc. My company has actually devised a POC scoping document that must be filled out before any equipment gets shipped to the prospect and anyone books their travel.
Finally, you have to accommodate for scope creep and the best way to do this is to limit the scope up front. You will have a lot on your plate, especially if it’s only a 5 day POC. Then, while you are on site during the trial you are going to create excitement about your product (if everything goes as planned).
Come Prepared: Not only does this include printing out the POC scoping document, configuration guides and address/contact for the site, but this also includes any work you can get done prior to the trial. Some such tasks are; map out each of the use cases and how you plan on satisfying the criteria; If there are custom rules, reports and dashboards, use demo events to pre-create this on your laptop to minimize how much effort you’ll spend on developing this in front of the customer (risking how complex the product is to use).
There are many other preparation steps including: building the necessary integration into unsupported event sources and; scheduling other teams for a WebEx session during the POC to speak about product roadmaps, customer support, customer success, advanced use cases, to name a few.
Ask For Help: This point lends itself to the “preparation” phase, whereby you may discover during the scoping exercise that there is a difficult event source to connect to or use cases that you don’t have the first clue on how to address. Reach out to the SE thread by email or call other SEs direct who may be senior and may have encountered this complexity in the past. At the very least, request assistance from the product support team and perhaps schedule either onsite or remote assistance during the POC so that the issues can be addressed with some extra hand-holding. In some instances, speaking with the prospect and suggesting alternatives may be the answer. This job is about being abreast of all sorts of technology and you must be humble and resourceful to be successful.
Be a Consultant: We are not just representing the product sales team in our roll. We are teachers, mentors, architects, IT specialists, project managers, to name a few of the required roles during a POC. We must advocate the value proposition as well as provide guidance of how our system is going to retrofit into an existing enterprise environment. Schedule planning sessions with the architecture, security planning and compliance teams during the POC to whiteboard the proposed design and capture as much data as possible. Share planning questionnaires, proposed diagrams, key differentiators, use case matrixes, product installation documents and anything else you feel would benefit the prospect in determining that you are an authority on Log Management and SIEM technology. We are the authority on SIEM and we are not just there to let the prospect put our feet to the fire and satisfy use cases – we are their to inform them on making the right decision.
Share the Wealth: The final point here is one of the most overlooked aspects amongst SEs and is instrumental in your development. Great responsibility comes with being a specialist in your profession. Whether you’ve created custom content or worked day and night fixing a problem, you need to share this with other SEs. Beyond the obvious point of helping your colleagues be successful is the paradox “you can’t keep it unless you give it away”. What this means is that some of the most complex concepts need to be articulated for you, yourself, to truly understand how they work. When sharing content or templates you’ve created it forces you to figure out how to deliver your ideas in a way that can be easily digested by your peers. The more you do it, the more you will master your profession.
These tips are by no means the silver bullet for being successful during trials but they have worked for me and as you can tell, the center around being prepared and having all of the facts.
Good luck and happy selling!
Gary Freeman
Getting them to drink the Kool-aid…
I have to say that one of the most incredible feelings is walking away from a demo or presentation knowing that the audience got what our product does and how flexible it is to deploy. I just get a rush when technical folks start drinking the kool-aid and ask questions or regurgitate our product’ terminology. Even better is one of your prospects has done their homework and starts advocating the benefits or the value proposition to their own colleagues!
I work with a product that is a niche product that is both software and hardware and has many flexible options. The sky’s the limit and when a serious prospect starts formulating how our solution will retro-fit their environment and helps you map out the architecture before the meeting is finished, you know there’s no denying the fact they are onboard and ready to get their hands dirty with your product.
In one such engagement recently, I walked into the room, one immediate credibility with the tech team as had been on the other side of the table with the same pains before doing a Sales Engineering role. I opted not to do “death-by-PowerPoint” and went straight to the white board and started mapping out their requirements and architecture while explaining the product and features at each tier of the design. Customers respond well to a reference architecture as it provides a mapping to their existing infrastructure and allows them to absorb your infiltration of product knowledge in digestible chunks.
Some of the things I do to engage them are:
- Ask them tons of questions about thier pain and what they are doing to deal with the problems today
- Let them come up to the whiteboard and draw their architecture
- Build trust with the technical folks but also try to deliver the techno babble to the middle ground (there are always non-tech people present who’ll get bored if you don’t engage them)
- Offer to give them whitepapers, admin guides, specs, etc – techies love to read!
- Let them take you off script and drive the demo (show them what they want to see)
- Manage difficult questions by qualifying the purpose for knowing the answer
Being an SE lets me sell, train, demostrate, propose, design and essentially talk people into buying a solution to suit their needs, but the job is so much easier when I’ve established a repore with the right people.
- Mom’s Meals issues “Notice of Data Event”: What to know and what to do
- S3 Ep149: How many cryptographers does it take to change a light bulb?
- Using WinRAR? Be sure to patch against these code execution bugs…
- Smart light bulbs could give away your password secrets
- “Snakes in airplane mode” – what if your phone says it’s offline but isn’t?
- S3 Ep148: Remembering crypto heroes
- FBI warns about scams that lure you in as a mobile beta-tester
- “Grab hold and give it a wiggle” – ATM card skimming is still a thing
- Crimeware server used by NetWalker ransomware seized and shut down
- S3 Ep147: What if you type in your password during a meeting?