A common statement start-up executives make regarding security is that they are in a race to market and if they consciously choose to build in security from the get-go it may slow them down so much as to take them out of the race.
Hence they choose to do little to no security early on (or for several years) – accepting the risk in the hopes that the business first makes it.
Is there a strong challenge to be made against this line of thinking?
As I commented originally in the other question, Security cannot be the primary, or even a principle concern. Sometimes, during certain phases of the startup, you really need to focus on rapidly developing the features needed to drive the product, and patch security as necessary. Security can easily get in the way of operations, employee productivity, and slow down development. Although if yours is a security-related product or business, you might certainly need bulletproof security from the beginning, you really can't generalize and say that all businesses should focus on security from the beginning. (Sony, being large enough, needs to learn a lot of lessons about software development in the new century, not just about security.)
That said, security practices and practical security should be a factor on the mind of all technical employees. Where can you add security without getting in people's way? There's no such thing as 100% secure, so how much security is enough?
Is there a strong challenge to be made against delaying security? No, I don't think so. Unless the industry is regulated by laws.
That's why information security is sometimes similar to risk management. You minimize the risk the best you can (that usually means within budget), you don't totally eliminate it.
So, delaying security is a form of accepting risk. Hopefully, this acceptance only lasts for a short while because when the executives are doing that, they are actually borrowing from the future. When the due date comes, well, let's just say it'd be embarassing, messy, and sometimes even devastating.
More information bout this line of thinking could be found from Veracode:
http://www.veracode.com/blog/2011/02/application-security-debt-and-application-interest-rates/
http://www.veracode.com/blog/2011/03/a-financial-model-for-application-security-debt/
I agree with the executive. If you look at the number of startups that have failed due to a security breach, vs the number of startups that have failed due to losing the race to be first, I think it's clear that the latter vastly outweigh the former.
Startups are all about taking risks to get to the big win. There are so many ways that a startup can fail. Saying that we accept a small probability that the startup fails because of a security breach just isn't that big a deal, if the benefit is that we get to significantly reduce the risk of the startup failing for other reasons.
I think the executive is proposing a plausible strategy: he is saying, we accept some security debt now, in exchange for getting to the finish line faster. This will cost the company later: the company will either have to pay down the security debt later, by re-architecting/re-implementing its systems, or else the company will later be taking a big risk of a serious security breach. But many startups would happily accept that tradeoff. "Pay later, if the startup is a big success" probably trumps "pay now, and possibly make the startup fail".
Here is my advice. Rather than trying to get the exec to change his mind, I would suggest you do two things:
Instill the notion of "security debt". Prepare the groundwork so that if the company becomes successful, you will later have buy-in for paying down the security debt and improving the security of the company's systems.
Right now, focus on cheap security mechanisms that won't slow down the company's ability to get to the finish line. I'm talking about simple things like firewalls, auto-updates, backups, etc. Also, you might brainstorm and develop more sophisticated security solutions or designs in parallel to the team's development effort, so it doesn't slow down the rest of the team -- assuming the company can spare you for that kind of effort.
Parasites will not only ruin your potential revenue streams for products/services, but they will also ruin your early-on brand/reputation, and destroy your ability to market your products/services. They will break your SEO, AdWords, and similar Internet marketing concepts -- which are necessary to build your online presence.
Adversaries automate parasitic infection of websites with botnets and other forms of automation -- making every website a potential target, especially those in start-up mode (because they often rely on third-party hosting/CMS/blog/forum/e-commerce packages, components, services, etc).
Recently I set up an FTP server from home because I work remotely and wanted a way for colleagues and customers to be able to transfer large files to me over night (other side of the world). I was really shocked to discover how many (automated?) attempts are made each week to break in to my FTP server - just a little home server with out advertising. It has convinced me that you can't be paranoid enough - people will try to break in and steal your data or your customer's data. Anything less than doing your best wrt security is a fail
Security is about risk management, which is ultimately a business decision.
You need to help your startup exec understand not only what the risks are, but also what the implementation costs will differ between doing it now and later. Trying to embed security into software after it's released is difficult and far more expensive.
If this is a race to the finish line, then offer solutions that don't impede their progress. Developers and engineers can still build software while you work in parallel to them. Try to find a compromise solution that:
One answer missed so far is around getting security on the agenda as a value-add for the startup. This can be effective, especially in industries which have recently had a highly publicized attack. If the VCs or stakeholders can understand how improved security can help them sell the product r service then it becomes an argument they can understand: profit!
Yes, it can be very difficult to persuade them, and a lot comes down to timing; as I said, it is much easier right after something like the PSN crack to push the concept of security as a value add to a company doing online gaming, but sadly not as easy to use the same example in a different industry, despite the fact that the issue was around compromise of personal data from a customer database, which should be relevant to everyone!
Is the executive cool with running the company without any insurance? If yes, listen to what everyone else has said so far (and run away from this company -- fast), if not, ask them why they are doing it then by not thinking about security.
You can take the practical approach. Take permission and hire a (preferably) junior penetration tester and let him "steal" the most major company secret you have, or find some other major flaw, or even perform a social engineering attack (like sending a malicious pdf file to a secretary). Then present the executive with the findings and focus on reputational damage (that's where startups hurt the most).
Pen & paper scenarios are not quite as effective in demonstrating insecurity as your secrets out in the open. That should convince them to at least think about putting some money in security.
The argument to be made here is not that you are insecure, but the easiness that someone with little experience can break in or find a big fault that could have been avoided with minumim security investment.
You can have balance.
Don't open ANY unnecessary ports, and keep your "admin" stuff restricted to the LAN or from certain known admin IPs. That way at least the stuff you're taking shortcuts on becomes internal only.
Every startup should be expected to follow basic, practical security principles. If you can't invest in security the way you want to, rely on simplicity and a little inconvenience on your part to reduce your attack surface area.
If your exec cannot grasp the concept of IT security as a business risk issue, he is either not the right one for the position itself (because risk management should be a key issue from the beginning) or nobody was able to make him/her aware of this issue.
Knowing and accepting risks is a valid approach, for all businesses.
It's the job of an executive to manage risks. If he thinks that security should be delayed, it's his to make that decision.
That said, you should make sure that it's an educated decision. As always, this needs a as-thorough-as-possible list of threats, likelihood and possible damages that could happen. So for example someone could steal the customer database. Or a backdoor could be installed in your products.
The problem here is that the likelihood is most often unknown or you're in a N*M situation where N is the likelihood and M is the damage and N is many order of magnitude smaller than M. It's like the nuclear plants in Japan: The possible damage is huge but the probability of an incident is really, really tiny. "Once in 100'000 years". That "once" can be tomorrow (and it was in several cases as we all have seen). So in this case, the resulting number if pretty worthless.
What I would do is make sure that the executive is making an educated decision: I would connect his wage with the risk. If he's right, he gets a fat bonus. If he's wrong, the damages should go against his personal wealth, first.
This kind of safety net usually makes sure that people don't take too much risk. But it can also kill your start up since the manager might stop taking any risks.
As pointed out in other answers and comments the two most common arguments for building security in from the start can - probably validly - be rejected in a time-pressured startup environment:
This isn't only an issue with security - it affects other quality metrics like usability and maintainability as well.
There is one argument which is specific to startups - and it may point to where the right balance lies for this environment: What if security concerns require you to make intrusive changes once the product had acquired a significant number of users?
We know that software often ends up being used differently to how the creators had envisaged. It follows that what the designers viewed as key features may not be what the users join up for. This makes judging whether a change will disrupt stickiness or user acquisition very difficult. A design decision which would have been completely acceptable to users as part of the initial product may even cause backlash if it's dropped on existing users of the product.
A review to minimise changes required after the product has users should be salable on this argument. It's probably also the appropriate level of security activity for a startup engaged in a headlong rush to be first to market.
Does this executive fear bad press?
Look at what's happening with Dropbox lately: Dropbox Lied to Users About Data Security, Complaint to FTC Alleges.
I'm sure they're not happy with this sort of attention.
Consider your startup's business model and paint a few bad case scenarios in which lack of security could potentially not just bring bad press, but bring down the business.
When you start a new company, you have no reputation outside of the leaders who may have their previous accolades in tech/biz. As a result, if a startup does have that security breach card fall in front of it, it's reputational damage will be substantial. Places like Sony, TJX, Michael's are huge companies that may be able to sustain such a blow, but if an exec for a startup feels that they can survive a breach as a startup, they have a naive and myopic view on basic risk management. Essentially, in such an event, a small startup would be at the mercy of their competition and the press which could easily overwhelm the minds of their prospective buyers by tainting their image of the startup's ability to protect client or regulated data or simply access to their infrastructure.
