By acting on this trend early you will be able to turn your SaaS security prowess from just a differentiator into a barrier to entry for lucrative enterprise sales in your industry. This is because enterprise buyers are still in the infancy of cloud software adoption and this gives you the first mover advantage of setting the bar high so that only the best among your competitors actually have a chance to compete with you.
Despite statistics like that above, the really interesting piece of anecdotal evidence is that many enterprise cloud buyers still are still not bringing up all their security questions during the sales process. But they are considering all of them after your sales meetings have ended.
The only solution to this is to get your cloud software security in a position where you lead the security discussion during sales calls, rather than let it hang as another one of those proverbial elephants in the room.
Why are enterprise buyers' concerned about cloud software security?
You might be forgiven for thinking that enterprise buyers' extra emphasis on the security of their cloud vendors is just part of their standard buying journey. While that is true to an extent, statistics like this are alarming enterprise decision makers into thinking long and hard before committing to cloud software solutions:
Think about just how many open source technologies your cloud solution uses and you will understand the magnitude of the problem above. Enterprise buyers' apprehension also stems from how their cloud vendors respond to security vulnerabilities when they are found:
How are your team's response times when security vulnerabilities are found? The upside to the introspection that you're doing now is that you will have an target list of security processes that your team needs to fix.
What security questions stop enterprise buyers from buying your cloud software?
Some of the cybersecurity vulnerabilities may seem trivial to you, but we find them in almost every web application penetration test that we conduct for our clients. It will be worth your while to pay attention to these vulnerabilities in your own cloud software (as reported in the Top Threats to Cloud Computing: Egregious Eleven report):Q1. How is my data protected?
The report notes that "data is becoming the main target of cyber attacks," which is quite different to ransomware attacks that take over an application and allow hackers to demand a princely ransom. Buyers are increasingly questioning who has access to their data and where it is stored - a question that you may already be familiar with if you sell to enterprise or government customers.Interestingly, the report notes that "encryption techniques can help protect data, but negatively impacts system performance while making applications less user-friendly." This is not a view that we've encountered ourselves for our cloud-based continuous software testing software. This statement is also curious because the secure encryption technologies that our AppSec
Q2. How are you managing changes to your environment?
Hackers these days wait for small windows where your cloud environment may be ripe for hacking. These windows usually present themselves when your teams ship new versions to your production environments. This is why it's so important to have robust change management processes that include regular vulnerability assessments and penetration testing.The traditional model of conducting an annual vulnerability assessment or penetration test and just using it as a "tick-box" exercise is outdated. Instead, you need to implement a continuous vulnerability assessment and penetration testing protocol that gives your cloud software regular protection.
If you don't have this expertise within your team and your external penetration testing partner doesn't offer it, talk to us about our subscription-based pentest-as-a-service plans, which include access to application security tools that help you automate developer-led security.
Q3. Do you have a security architecture strategy?
Most SaaS/cloud software companies that we talk to only think about security after a product or new version has been built. This report makes it clear that this is no longer acceptable practice in the minds of enterprise decision-makers.You're right, it's not easy to re-architect your software. But, it is a lot easier to help your team think about security from the design stages of new feature builds, rather than trying to retrofit security controls once the new features have gone live.
If your team has never undertaken a security review, it's worth doing it now, instead of after you get hacked.
Q4. How does your app protect my data beyond a password?
If you didn't already know, password-only authentication systems have proven easy fodder for even novice hackers over the years:
The common behaviour with enterprise users is to assume that all their data is sensitive. Whether it is or not is not worth arguing. The point is you have to prove to them that you understand their concern by providing them with not only 2-factor authentication (2FA), but multi-factor authentication (MFA).
It really is a non-negotiable in this day and age. If your application has already been penetration tested then your external penetration testing partner should have already pointed this out to you.
Q5. How do you prevent account hijacking?
In short, how many layers of security do you have in place to slow, frustrate and hopefully stop hackers? In software cybersecurity terms account hijacking is best prevented through defence-in-depth measures. Defence-in-depth was a strategy used by smart military leaders to slow their enemy and to give them time to launch a counter-attack.Playing offence in application security is a dangerous, and potentially illegal, business. But that doesn't mean that you're helpless. In fact, you should use the mechanisms below to slow down and eventually halt hackers when they breach your system:
- Firewalls to control and monitor incoming and outgoing network traffic
- Web application firewall (WAF) to minimise the chances of hackers exploiting unknown vulnerabilities in your application
- Security information and event management (SIEM) systems to identify anomalies across multiple systems
- Identity and access management (IAM) solutions for authentication and user management to make sure only the right individuals get access to the right applications and services and nothing else.
Q6. How do keep my data safe from your internal teams?
Great question and one that most SaaS teams would just assume happens automatically. "We only hire trustworthy people, so why would anyone from our team want to access your data?" Right?Wrong!
These statistics are the source of enterprises' worries about your team. The only way to convince them that you have mitigated this insider threat is to show them your information security and security incident management policies and procedures.
Don't stop there though. You should prove that your staff are trained to follow them too.
Q7. How secure are your APIs?
It's not enough to simply answer this question with a glib, "our APIs are pen tested regularly." In our interconnected digital world, APIs are proliferating faster than the speed at which a seahorse pops out its offspring. This has many advantages, particularly for minimising complexity and convenience, but also creates a security headache.How many of our APIs are tested for security vulnerabilities before they are shipped to important (and demanding) customers? How does your team ensure that every one of your APIs has been catalogued and tested for security vulnerabilities?
You should consider managing this risk by employing standard and open API frameworks like the Open Cloud Computing Interface (OCCI) and Cloud Infrastructure Management Interface (CIMI).
Q8. What are your decision-making criteria when selecting cloud partners?
Enterprises realise that your cloud software probably doesn't work in an independent and unconnected silo. You probably host it on AWS/Google Cloud/Azure - brands that are well known for prioritising your and their own security.But what about the other cloud services that you integrate with to deliver your solution? If you use APIs to offload some of your app's workload, how do you know the API provider follows best-practice security protocols?
Enterprise buyers want to understand how you select and verify your cloud partners' security posture? The best way of demonstrating this is to list the external services you integrate with and to list the security controls that they have demonstrated to you before you integrated their service into your cloud application.
Q9. What controls do you have to ensure my team doesn't misuse the data collected by your cloud software?
This is the flip-side of question 6. When we first ask this question of our clients the most common answer is, "we have different user roles to solve this."While that's not the wrong answer, it is an incomplete answer that makes you look less than stellar. Here's the right way of answering this question:
- We design all user roles to follow least privilege principles;
- We ensure that all activities, no matter how seemingly inconsequential, are logged.
- These logs are available for download to users who need them for security, audit and operational purposes.
- Our external penetration testing services partner thoroughly investigates our user access controls to ensure that role traversal is not possible.
Q10. Will you do our security analysis for us?
This is not a question that a customer will ask you and it DEFINITELY shouldn't be a question that you ask your customers and prospects - no matter how tempting the financial saving might be for you.
Why, you ask? Well, would you invite your family and friends to your wedding and ask them to pay for their meals and drinks?
I didn't think so!
But most importantly
Q11. Do you have security accreditations like SOC 2 or ISO 27001?
Most SaaS companies think about these accreditations AFTER they've become a bottleneck to completing more enterprise deals. This is a natural thing to do given that there is always a tension between investing in growth and investing in security.
But this is a chicken and egg situation that results from accreditations like these being sold as mere tick-box or rubber stamping exercies.
Whereas in reality, getting SOC 2 certification or ISO 27001 certification is the start of your journey to building a culture of software security in your development teams.
As we know, cultures take a long time to build. Particularly when established norms and methods need to be changed. So even though it might take you 6-12 months to gain these security certifications, that time is likely to be well spent when you look at it as a longer-term investment that will not just grow your sales, but also increase your team's security capability.
Download our Cheat Sheet For Building Unhackable Apps to understand the minimum security configurations for SaaS applications. It could just save your product and your company from much embarrassment and even the loss of you and your team's livelihood.
It probably will also help your SaaS land your next (or first) big enterprise customer.
