Making your Security Story Work for You: How to Not Trigger Sales Objections

While I make my living doing security and the benefits are obvious to me, I've come to the realization that most of the time security and privacy don't sell consumer products or services. While good security won’t make the sale, weak security can concern customers and create sales objections.

If your core customers are large, mature shops, they'll ask some pointed questions about your security. If you're doing the right things, you can show them that your product or service isn't a substantial risk to them. If you can't, you may not keep the business.

However, telling your security story to smaller businesses and non-power user customers can be a tricky business.  They are concerned about security and privacy, but are not experts.  Your approach to explaining your program needs to be accessible to them and meet them where they are. 


My favorite analogy is that of the ice cream shop.

You visit an ice cream parlor.  You want to buy an ice cream cone.  At this point, it's the proprietor's sale to lose. They might not have your first choice, but you've come this far, you are going to buy some ice cream. You look at the tubs, read the names and muse over flavors.  You even decide if you need chocolate sauce or jimmies.

Then you read the sign hanging above the counter:  "Our ice cream is guaranteed 90% free of broken glass"

This ice cream shop wanted you to know about the security of their product.  But now, you may not be buying ice cream there. In fact, instead of imagining how good the ice cream will taste, all you can think of is the glass that you might be hidden in your ice cream.  And now, each time you buy ice cream from here on out, you'll be looking for some guarantee that your sweet treat is also glass free.

In a way, talking about your security program is similar.  You need to tell your customers your security story.  The mature shops that understand the details will understand why you’re telling them that your ice cream is 90% glass free.  But how to do this in a way that doesn’t trigger concern or objections from those who don’t understand why glass would ever be part of the ice cream making process.


How do you explain security to your customers?


First and foremost, don't assume your customers are ignorant or uninterested.  They’re smart enough to consider your product or service, just not expert enough to understand the how of security.


They need a jargon-free approach that puts what you’re doing in context. Explain why you have these controls and how they benefit from your actions.


The WHY:  Explain why you do security, but explain it in an accessible voice.

Convey why you protect their data.  Convey that do not do security because you're afraid of a regulator or a lawsuit, but that it's your business imperative.



"We understand that we hold your valuable, sensitive information. We'd like to explain what we do to keep that information confidential, accurate and available to you. We do this because we know that without you, we have no business."


The HOW: Explain what you're doing and how it keeps them safe.  Make it meaningful for them.

It's not just what you do, but how it benefits the customer. There's no need to explain every part of your program, but you're going to want a few highlights- how you hold their data, any external audits you've passed and perhaps what else you do. Here's another example: 

"We monitor our own networks for unusual or unauthorized activity. We collect that information so we can see if someone's trying to log in as you from an unusual location or time. This lets us know if someone's trying to pass as you. This lets you know if you need to change your passwords". 


Often, a simple explanatory page on your site can help you turn your security program/story into something that soothes customer concerns and prevents sales objections. You get or keep a customer and you get paid. Perhaps you should buy some ice cream in celebration.


Small startups, pursuing big customers

You’re at a startup- a great idea, smart developers and an attractive website. You’re leveraging modern technology at its best- mobile aware, scalable cloud architecture. You’re offering other businesses a force multiplier to help them compete.

Small shops are great to work in. You’re more likely to see the big picture and be able to at least talk to senior management.  You can be nimble, rapidly developing your product and can pivot your product or services as the market demands. Every sale is a shared victory.

You tend to work quickly and without a lot of formality, because that just gets in the way of doing awesome things.

Getting big clients’ logos on your website is definitely in the ‘doing awesome things’ category. But the sales cycle will be more than convincing the buyer that your tool will help them do awesome things. They’re going to have some pointed questions about how you develop your tools, store their data and operate your business. You’re going to have to show them that your tools, while awesome, aren’t going to put their data, reputation and business at risk.

Security as sales objection

I’ve been at more than a few sales meetings as a company’s security expert. I can’t think of any time that a vendor’s security made a sale. I can think of times when a vendor’s poor security prevented an otherwise successful sales effort. I’ve also watched vendors promise crash security improvements to save a big sale. This can be a mistake.

Know your environment and the industry expectations before promising.  If you do know how mature your program is, you can do a gap analysis between your current program and what your potential customer wants.

A bit of searching will give you an idea of what it will take to get compliant with those requirements. Factor that into the cost of servicing the customer while determining your price.   

Entering regulated markets

If the cost of uplift is greater than the likely net profit, you’ll want to determine if you can or want to pursue more business in the customer’s industry. This way, it’s not a one-time expense, it’s a capital investment. Be careful, though.  I’ve seen customers insist on standards more restrictive or plain inappropriate for their industry. A decision to enter into a market with high overhead should be made after you know the cost of meeting that industries’ standards.

Keeping the business

Remember the promises you made to keep the customer’s data secure? They’re going to check up on you. You’ll get questionnaires and if you’re lucky, site visits and interviews. You’ve got to go through the process every year to keep the business.

Reading these questionnaires may make you feel inadequate. You may be tempted (or pressured by a salesperson) to answer ‘Yes’ to many of the answers, in the hopes that they’ll not ask any follow up question. Resist this temptation. Honestly claiming to have weak but improving security is better in the long run than falsely claiming to be strong.

Here’s why:

1.  If you lie about something that can be easily verified, assessors will assume that you’re also lying about other things.

2.  If you look over the contract you signed with your customer, you’ll likely find that intentional mis-statements constitute a material breach of the contract. You’ve given them grounds to cancel the agreement and walk away.

3.  They may talk to other potential customers in the industry.

Assuming you’re trying to do the right thing within a reasonable budget, what will that big customer be looking for?

Talking about your program and Brown M&Ms.

Having the right controls is a good start, but showing your customer that you’re worrying about the right things will convince them that you’re not a risk they need to worry about. They could crawl through your infrastructure, but that’s expensive and time consuming for all concerned. Instead, they’re looking for the absence of brown M&Ms.

The quickest and easiest way to show them that you’re doing the right things is your policy kit and your ‘artifacts of compliance’. A customer’s information security or risk management people can look at these in an hour or two.

Policy Kit

The policy kit consists of the statements that govern your IT and security programs. It’s made up of policies and standards.

To explain quickly, policies are high level documents describing the goals of your program. Standards describe the benchmarks and requirements the program is expected to meet. Procedures are formal descriptions for someone to follow. As an analogy. I’m supposed to eat a good breakfast every morning.

Policy: I shall eat a healthy breakfast. We don’t get too specific on what a good breakfast is, since my dietary needs (like your regulatory or technical needs) may change from time to time.

Standard: A ‘good breakfast’ does not consist of coffee and Funyuns. A ‘good breakfast’ shall have no more than 30% of the Recommended Daily Allowance of fats, carbohydrates and proteins. This is expected to be modified on a more regular basis, in case the availability of certain foods changes or we learn more about nutrition.

Artifacts of compliance

These are the documents that show that you’ve been doing what you say you’re doing in the policy kit. Exceptions to the rules are noted, as well as one-off incidents.  If you say you track patches, you can produce a log. If there’s that one kiosk system that still runs on Windows XP, it’s in your exceptions spreadsheet. The customer’s risk management people are looking here to

If I occasionally miss breakfast or eat fried Oysters Benedict instead of a healthy breakfast , I should note my non-compliance with the Breakfast Policy. This makes my “I almost always eat good breakfasts” easier to believe if you see when I don’t.

This may seem officious, but it’s not. An assessor wants to quickly identify where they have concerns. They’re looking for big risks to them that might not be obvious.    

Brown M&Ms

Ok, so you’re wondering about brown M&Ms. It’s a clever story that bears repeating. In the 1980’s, phones were on walls and a rock band named Van Halen trucked around a massive stage set, which required significant infrastructure at the venue to support. The contract rider would specify what they needed, but often nobody would convey the requirements to the technical staff at the venue. The band’s advance people didn’t have time to double-check everything, so they added a ‘there will be a bowl of M&M candies in the dressing room, but all the brown ones must be removed’ clause in the middle of the technical specifications.  

This provided a simple check. If the bowl contained brown M&Ms, the band knew that someone didn’t read the requirements. In a way, the risk management people at the large company are doing the same thing with your policy documents and artifacts of compliance. Instead of having to do a deep investigation, they just want to decide if they have to do a more detailed look or let the show continue.

If you’re able to quickly hand over your policies, standards and proof that you’re following them, you can show a much larger company that you understand what they’re looking for.

And one sales objection goes away.


Securing systems you're planning on replacing

We get used to working around limitations in our tools, because that's what we have to work with. If you’re considering migrating your email, Customer Relationship Management (CRM) or Enterprise Resource Planning (ERP) package to a new platform, it’s like buying a new family car- planning for a new future while minimizing your existing expenses.  

Deciding to get rid of that old clunker

There are a couple of steps between idly musing about an ideal new system and actively working on it. Replacing old systems, whether they be cars or applications isn’t an instant process. It starts with the realization that your current situation is untenable in the long run- the car that might not start in the morning or the unsupported application that has needed new functionality for a while.

Repairs, patches and workarounds might be sufficient to keep everything working for a while, but you're taking a risk that the workaround, well, doesn't. Pretty soon, you're doing convoluted things, like running old browsers on a Citrix instance to let your users work with that antiquated CRM. Or you're keeping a spare, charged battery in your trunk in case that electrical fault drained the battery.

Eventually you realize that you're spending more money and effort to keep an unreliable system operating and you start the process of moving on. In order to get buy-in, you have to get requirements from stakeholders.  Everyone will have a wish list for the shiny new possibility. A substantial number ofthe items on the wish list will be negatives- the back seats won't be sticky, the CRM won't require different screensfor contact information and current orders.   

And in this bright shiny moment, you get a reprieve. You'll answer complaints with "we're going to replace that system and everything will be wonderful when it happens". Every trouble ticket or change request will be an impetus to get the replacement live.

Doing this without a workable lifecycle management process is going to be a bumpy ride. To speed the new project, available staff, money and focus will be yanked away from supporting and securing your old system to go to the roll-out of the new one.  

Yet your business relies on the old one. Your critical data runs through it. Losing confidentiality, integrity or availability is still A Bad Thing (tm). You need to spend time, money and effort to keep it safe enough enough while you finish its replacement.

If we can go back to the car analogy, you’renot paying for a new paint job or transmission. You still pay for gas and lock the doors. Brakes and tires will have to be replaced to keep you and your family safe.

How do you determine security expenses to pay for and what to skip for your infrastructure? I’ll break this down by phases:

Planning- This phase starts with deciding to consider replacing your enterprise system and ends with the start of implementation. You’re getting requirements from your stakeholders and comparing vendors for systems and implementation.  You have drafted budgets and timelines.

During this phase, you want to continue normal efforts in securing and maintaining your existing systems. Keep performing the usual patching, testing and evaluation activities. You may find some places to economize by ending or reducing support contracts, but make sure you can still get security and reliability patches.

You’re also going to want to ensure that you’re maintaining these systems from the operational side as well. Make sure you’re keeping track of current users, validating backups and ensuring the accuracy of your data.

So far, so good.

Implementation- This phase starts once you’ve signed contracts and ends with the rollout. You may find that the budgets and timelines you created during the planning phase range from optimistic to laughable.

This is the time you’ll have to be careful. As the implementation phase stretches, you’ll be looking for budget and staff time to throw into preparing the new system. It’s all to easy to say “It’s a small risk to leave the old system unpatched for a month or two”.  


Fight that urge. One or two months can turn into six as the implementation drags on. That’s time that your crucial system is vulnerable. Keep maintaining those systems like you rely on them, because you do.

Rollout- Your new, shiny system is ready for your users. Every staff and consultant will be needed to make sure the rollout goes well, lest users be unhappy with it.

This is when you can start slowing down. You may want to hold off on application patching and maintenance for this phase, if only to reduce the risk that a patch makes data unavailable.

If you do an overlapped cutover, where some users keep access to both systems for reporting or historical reasons, you’re going to want to maintain the system as if it was still in the Implementation phase, until you no longer need it.

If the cutover isn’t overlapped, you’re going to want to prepare the system for archival. You’ll need to determine how long you need to keep the data. Check with your policy or legal counsel to identify when you no longer need to keep the data around.

You don’t want to just keep the data. You need the capability to make it viewable again. If the system needs a certain operating system or application to operate, keep that on-hand just in case. This may be as easy as saving an image of the virtual machines that supported it or as difficult as keeping old hardware around.

Just because it’s archived doesn’t mean it’s inaccessible. That data may still be sensitive. You’re going to want to track it and put appropriate controls around it to make sure you don’t suffer a breach.


All this may seem to make a cutover more difficult than it needs to be. But instead, these steps will keep your systems, data and organization safer through the entire project lifecycle.

If you’re a more mature shop, consider how well your lifecycle management policies and procedures

And one fewer worry about your data is a good thing during a crucial rollout.

iPhone Spyware Trident Exploit Chain

On August 25thApple released iOS 9.3.5an update to iOS devices which addresses 3 CVEs known as the Trident Exploit Chain: 

CVE-2016-4655: Memory Corruption in Webkit – A vulnerability in the Safari WebKit that allows the attacker to compromise the device when the user clicks on a link. 

CVE-2016-4656: Information leak in Kernel – A kernel base mapping vulnerability that leaks information to the attacker allowing him to calculate the kernel’s location in memory. 

CVE-2016-4657: Kernel Memory corruption leads to Jailbreak – 32 and 64 bit iOS kernel-level vulnerabilities that allow the attacker to silently jailbreak the device and install surveillance software. 

 These vulnerabilities were used in combination in an attempt to deploy "lawful intercept" spyware onto the iPhone of a noted human rights campaigner in the UAE.  Specific details of this case can be found on Citizenlab

And a technical analysis and blog post can be found on Lookouts website.

Leviathan recommends that all iOS users update to 9.3.5 as soon as possible.  When a 0-day exploit of this kind is patched, a wide range of groups will embark on reverse engineering the patch to recreate the exploit for reuse.  The mean time from patch release to a recreated exploit is ever shortening meaning that the chance of encountering an attack in the wild becomes more and more likely as the exploit becomes more widely available.

LastPass and How to Respond to Zero Day Vulnerabilities


It’s nerve-racking to read that a product that your company relies upon has a critical zero day vulnerability. Do you scramble for a new solution, wait for a patch or just panic? Making important application decisions based on social-media rumblings isn't usually the best way to run an IT shop. In some ways, this is like driving down the road when your car starts making an unusual sound. It might not be time to consider buying a new car, but you do need to assess the situation.

Take, for example, the recently identified issues with LastPass (herehere and here). How should you react?

Vuln Specific Steps

In this instance, the vulnerability is isolated to the LastPass Firefox addon and a patch has already been issued. All versions of LastPass 4 prior to 4.1.21a are vulnerable and should be updated immediately.

If your organization uses LastPass, consider your use case:

  • Could any of your users have the an affected version installed?
  • Who is using it and what credentials do they have stored in it?
  • If you have logins to important business resources such as:
    • cloud providers (AWS, Rackspace),
    • organizational social media (Facebook, Twitter, Instagram) or
    • SaaS providers (Office 365, Salesforce),

... you need to take action.

Assuming you do have important credentials stored in LastPass and users that may be on Firefox, consider taking the following steps to reduce your risk.

First, audit logins for suspicious activity and evidence of compromise: All cloud services can give you basic information about successful logins.

You should look for logins from unusual IPs, browsers, device OSs and times.

  • Don't have any Swedish end-users?
  • A login from a Linux box when you don't support Linux?
  • Perhaps you should contact the user by an alternative method and investigate.

We're including links to common service providers to find recent login information:

If you find suspicious logins... have that user do a password changing party for any stored logins in their password manager. It may be reasonable to also investigate activity logs to see what a potential attacker did with the access. If you suspect more than a login occurred, it may be time to start a breach investigation process.

Another method to find compromised logins can be performed by searching your outgoing traffic for ex-filtrated logins. Check your web proxy logs for attempts to pass logins. If you can grep them, the regex to discover passwords to "" being ex-filtrated using this method would look like this:


Monitor LastPass' website... for a patch and patch all affected systems as soon as reasonably possible. LastPass has already issued an update to address the Firefox vulnerability so ensure that your users are on the most recent version – 4.1.21a.

And for the next time...

...there's always a next time. Vulnerabilities are discovered in commercial and open-source software on a regular basis. Although each vulnerability will require specific treatment there are some lessons which can be learned from incident response disciplines which can be applied broadly.

The first step to facing the issue the next time is knowing your environment. Understand what operating systems and applications your organization relies upon.

The second step is having a good current list of vulnerabilities on the software and systems you rely upon. Depending on your time and money budget, consider SecurityFocus' bugtraq, vendor disclosure lists for your products, Threatpost, Ubuntu Security notices or filter Twitter for the applications you rely upon.

Once an organization is made aware of (detects) an issue such as the current issue with LastPass, they can take steps to:

  • Assess possible impact to the organization. Using information which is to hand, such as vulnerability write-ups, an organization can determine the impact, or potential impact, that a particular issue holds for them. For example determining what kind of data is held or accessible via the compromised system. In this case it is passwords, so determining what it means to you, as an organization, if those passwords have been lost. Does the application hold all your passwords, just a subset, do affected systems use 2FA, are they internet accessible, etc?


  • Determine exposure. In many cases it is possible to retrospectively determine if you have fallen foul of a particular sort of attack. For example if there are any particular URLs that are an indicator if compromise, and the organization uses a proxy for internet access; searching the proxy logs is a quick way to determine the likelihood that the organization has been exposed.


  • Short term (temporary) steps to minimize exposure. There may be some "bandaid" fixes which can be put in place to temporarily reduce or stop an issue which is in progress until such point as some sort of permanent remediation can be put in place. In many cases this may not be a technical countermeasure but a procedural one, such as not using an affected system but using an alternative.


  • Long term remediation. Typically when an issue arises, sooner or later there will be a fix (hopefully!). Often this is in the form of a software patch, configuration change or other mitigation. In most cases this will be the preferred fix to any shorter term fixes deployed mid-crisis, and should be assessed for wider deployment so that short term fixes can be removed.


  • Cleanup. Once an issue has been contained and remediated there may be a number of cleanup actions required. Hosts may need to be rebuilt, passwords changed, cryptographic material reissued, etc. What cleanup is specifically required will depend on the nature of the incident and the potential exposure.


  • Lessons learned. It is always useful to hold a lessons learned session with the key stakeholders and subject matter experts after an issue has been resolved. It allows an organization to reflect on what worked well, what did not work so well, and to make positive changes to processes, procedures, staff training, and overall preparedness.


Moving forward

The best time to consider buying and implementing new or updated security controls are before you need them. The second best time is after the smoke clears. You likely have support from your users and management to implement the changes you believe you need. A final consideration is to ensure all your controls are in place, not just the 'one thing' you recently had to worry about.

Bulk ASLR Data Analysis

Bulk ASLR Data Analysis

Hello from the Lotan team at Leviathan!

We recently looked at a sample set of 80,000 crashdumps from a production environment and decided it was time to look at some data we have in aggregate. Lotan's core focus is detecting stage one attacks (shellcode) in crashed processes. To achieve this goal Lotan has to process the bulk of the data contained within a memory image. One of the most interesting components of these process images is the information about loaded modules from Windows processes.

The Cobbler’s Children and source code integrity, or why your source code repositories need better shoes.

I’m reminded of the saying ‘The Cobbler’s children have no shoes’. We consider our customer facing products more important than our internal ones.


Of course we do, right? Our bills are paid by our customers and we’d like more of them, so an hour or dollar spent to improve their experience is easily justified.  However, allocating resources to internal processes and systems gets a different response.  You want to spend how much to do what?  Internal processes, systems and tools have to pass greater scrutiny to be “justified”. Since it’s “all in the family”, internal tools don’t have to be as pretty, well documented, reliable or secure, right? 

Oh, and doing it “right” just takes too much time.  “Just get it done instantly, if not sooner.”


DevOps is one way of making the development process faster and cheaper. Unfortunately, it’s all too easy to let it devolve into anarchy. Doing DevOps  the right  way is harder. It’s so much easier to spool up an instance of $Whatever_Tool_You_Need_Right_Now to fix some issue before a release than to plan for what you need and document what you’re doing. Sure, you might be using the same tool as some other developer or team, but hey, when it’s faster and easier to just create your own instance instead of coordinating systems, faster and easier often win out. Documentation and hardening, when done by yourself, just take too much time.


The result is something I call the ‘Sergeant Schultz approach’ –IT worries about enterprise wide systems directly under their control and leaves the development environment alone until forced to pay attention, when it may be too late.


These systems may have been quickly stood up and aren’t being fully protected by your controls. You’re not watching logs, tracking users, remediating vulnerabilities to ensure stable, hardened systems.


A loss of availability in on these systems is annoying, but obvious.  It may slow development but it won’t permanently affect your business.  

But a loss of confidentiality and integrity can affect the enterprise as a whole. A source code leak might reveal some trade secrets to a competitor. A loss of integrity can be far worse.


Imagine an development server not benefiting from the full protection of your controls.  A malicious or negligent user can modify code for your mobile app, web app or device OS, creating a stability issue, back door or jackpot condition.


Discovering a back door or jackpot condition prior to code release is merely embarrassing. Remediating the issue post- release opens the company to loss of market share and goodwill. If the parade of horribles doesn’t have your attention, consider the possibility that the jackpot condition is a negative one. Remember the Therac-25, where a radiation therapy device sometimes overdosed patients? That was mere negligence. Imagine what a malicious party could do.


Ok – so I’ve stated the obvious – it’s easier to do it fast and loose than to take the time to plan things out.  However, it IS possible to reduce the risk of compromise, even in a fast moving DevOps environment.  By using the following 4 steps, you will greatly reduce the risk of a catastrophic loss of integrity, with reasonable amount of effort expended.


We recommend the following:


Inventory tracking: IT should have, as a minimum, visibility into the DevOps environment- instances, users and permissions. If you have a SIEM or log management tool, have the instances report up to it.


Identity management: Each user with write capability should have their own credentials. Ideally, these are referenced back to the firms LDAP/AD user store. If you can, require the use of 2FA to reduce the risk of credential compromise.


User tracking: Every change to source code should map back to a specific human user.


Pre- built images: When feasible, systems should be standardized and centralized. Consider offering pre-hardened VM images with  favorite development tools to offer developers so they don’t have to roll their own.



We don’t need to make our tools as nice as what we offer our customers, but they need to be good enough. Your kids don’t need Louboutins, but they do need good enough shoes.


For the curious:


Guidance - Flash Vulnerability CVE-2015-5119

During the Hacking Team breach which came to light earlier this week, a large quantity of Hacking Team's internal data was posted online.  Some of this data pertained to a 0-day (a vulnerability which the vendor is not aware of) in Adobe Flash (versions 9 through to (CVE-2015-5119) which allows an attacker to execute code on a victims computer if they browse to a website with a malicious flash file embedded. 

Guidance - OpenSSL Vulnerability CVE-2015-1793

This morning, OpenSSL released details of a vulnerability (CVE-2015-1793) affecting OpenSSL versions 1.0.2c, 1.0.2b, 1.0.1n and 1.0.1 for client connections; listening servers are unaffected unless they validate client certificates.  Anyone can issue themselves a certificate for any domain and the OpenSSL library will not notice, allowing someone to impersonate a server and pass TLS/SSL based checks.  The vulnerability allows an attacker to use a leaf certificate as if they were a Certificate Authority and issue rogue certificates to themselves.