As software engineers, we are tasked daily with choosing third-party libraries, tools, and services to integrate into our company’s products. Unless we make a special effort, those choices are consistently under the influence of various subconscious biases. Some stem from the society we live in and cultural norms. Others depend
At Forter we develop an online, low latency fraud prevention service. We started out with a single real time system, but as throughput increased, we gradually decided to offload more and more jobs to run periodically. This varies from sophisticated anomaly detection systems to detect new types of fraud, to
Do You Trust Your Front-End Tests as Much as We Do?
Consider the following scenario: A critical bug has been detected on your web application overnight and a fix must be deployed quickly. How fast can it get to production during off hours?
How much do you trust your tests’ coverage? How
Elasticsearch has always been good to us at Forter. It’s truly reliable. It’s damn good at searching, and it’s a solid distributed application as well. It balances a cluster relatively quickly, and it is easy to configure and easy to backup/restore, etc., but… we were haunted by an issue which
Get your team engaged in a heated debate about an opinionated subject
(in this case Versioning and Dependency management)
No one should expect services to be perfect. Bugs happen, and they get exploited. Employees make mistakes, accept bribes, etc. We know these things and account for them when choosing to use a third-party solution. That said, finding out that one of your providers suffered a breach is every customer’s
Tests provide confidence. They provide confidence during development, in new deployments, and continuously in production (monitoring). Flaky tests, on the other hand, fail or pass for the same configuration,
So you are working at a startup, and you have been wondering at what point should you start looking into security considerations and compliance? Which technical debt should be postponed for a later stage, and which systems should be hardened this instant? What are the main considerations?
Technical debt gets piled up, and in many cases it is easier to pay later rather than now. For example, if you are using ElasticSearch without username/passwords, you should double check your firewall settings. After round-B your startup would probably have the manpower and budget to properly secure the ElasticSearch cluster.
Startup culture is a bit more difficult to change "later". Let's take a trivial example. Developers that are used to pushing code without code review, would complain that peer review would bog down the development, and it might even smell "too corporate" for them.
So which security considerations are relevant at an early stage?
What security concerns were raised by customers willing to pay for your product?
What are the security expectations in your industry (Medical, Finance, Enterprise)?
What are the target market (country) regulations (Data Privacy, Data Residency)? Europeans are known to have tougher regulations. Different US States have different regulations.
Which tools and policies would not hurt your team's morale.
How long would it take you to prepare a security risk plan (see example at the bottom of this document)?
What is the impact of Intellectual Property theft, business plans theft, bitcoin/ec2 theft, losing all your data ? How would it affect your sales, customers, investors?
How can you protect against a data breach?
How can you reduce the exposure after a data breach?
We grouped together the expected security recommendations by the different phases a start-up goes through. The more money and data the startup handles, the bigger the investment in security:
Did you ever attend a talk – in a conference, a local meetup or simply listening to an interesting podcast on your commute to work – and felt so inspired, that you couldn’t wait to get back to work and try it out?
It rarely happens, but I’ve listened to some
