How we battled automated cyber attacks

Written by Ivy Young, Trade Ledger

http://tradeledger.io/

Do you think security incidents will never happen to your Fintech company? Do you think start-ups are too small to be the target of cyber attacks?

Your answer to both questions should be no.

Two thirds of small UK businesses were attacked by hackers in the past two years. Unfortunately, Australia is facing similar threats, if not worse, but unfortunately there is limited data available locally. Our team was recently subjected to an automated attack on our web application. By sharing our experience, we hope you will develop some new and valuable perspectives relating to cyber security. The risk is real, no one is immune to cyber security threats.

Battling automated attacks

It was a perfectly ordinary Thursday. Right at noon, while a few of us were passionately discussing about various frontend web application frameworks, suddenly, one of our Slack channels went off uncontrollably. Multiple error messages per second were sent to the channel suggesting invalid characters contained in web requests.

When we all gathered around a screen to inspect the alerts and try to identify the cause, just as our CEO returned from his telephone meeting to our pod with brisk sense of urgency, asking “What are these alerts about? My phone has been buzzing like crazy for the last 2 minutes!”

The following 30 minutes were intense. There were lots of great questions asked, answered, discussed and researched with team efforts.

Some of the critical ones are:

· What system components are affected?

· Are affected systems host or transmit any confidential data? If yes, are these confidential data in clear text or encrypted?

· What kind of log do we have and can we access them?

· What’s the nature and source of those web requests?

· What information is disclosed in our responses? Are there any systems compromised?

· Are they from bad bots or manual attacks? Can we blacklist by IP address or port?

· Do we have enough elasticity to handle spiked traffic?

· Do we need to contact any external parties, i.e. customers, security partners, technology providers, or authorities?

· What could have we done anything differently to better prevent automated attacks and improve our visibility to our environment and response procedures?

There has been a lot more work undertaken by the team following the 30-min investigation. The key thing is that we are certain that only our testing environment was targeted, no confidential information or system information is compromised. It’s a proud moment for us knowing that we have kept our customer promise for security.

By tracing the source IP address, it seemed that compromised Internet of Things (IoT) devices in Australian local networks were slaved to launch those attacks. We believe they are intended to scan for known vulnerabilities in popular web application frameworks and underlying infrastructure, which was not in our environment. The attackers moved on after 8.5 minutes probably because they didn’t get any valuable response from our systems.

Our resilience-oriented strategy

What’s important is for us to continue to operate and grow securely in such a rapidly evolving and hostile cyber environment, is our commitments and actions to implement a resilience-oriented security strategy.

Everyone should assume that you will be compromised one day. Instead of being stuck in a denial mode, prepare for failure, focus on building up your capabilities to achieve total visibility, fast detection and response to minimise potential damage in the event of a security incident.

Key takeaways

There are a few tips that you may find useful for your security management from our recent bot attack experience.

1. Understand the difference between a security event, incident and data breach

Knowing the difference in three key terms and classify events correctly are absolutely critical in defining appropriate actions in response to those events.

A security event is defined as any observable occurrence relating to information security in a system or network, according to the National Institute of Standards and Technology (NIST).

The attacks that we experienced are one type of adverse security event. They happen to networked systems all the time, but do not always cause negative or significant consequence that could qualify them as incident or data breach if you are well prepared or very lucky. It’s absolutely crucial for every business to know whether you have the capability in detecting them in the first place.

A security incident is a security event that compromises the integrity, confidentiality, or availability of an information asset. Based on our investigation, these attacks have not escalated to incidents or data breaches, as no systems or data is compromised.

If a security incident meets specific legal definitions, per state and/or federal breach laws, then it is considered a data breach. For example, Australia’s Privacy Act 1988 (cth) and NSW State Privacy Laws. All businesses should prepare yourself for the new mandatory data breach notification legislation coming into effective from 22nd February 2018. If you have not done anything, action now!

2. Do not disclose information about your web application frameworks and underlying technologies

One of the primary purposes of automated attacks is vulnerability scanning before exploitations and crafted attacks take place. Every piece of information that attackers can gather about your environmnet increases your risk exposure. In fact, this is how one of Big Three credit bureaus Equifax got hacked due to apache struts vulnerabilities back in March 2017. This breach exposed sensitive personal identity data of 145.5 million individuals (mostly Americans and some Canadians and British citizens).

3. Log everything and monitor in real-time with alerts

Visibility is critical for effective defense against cyber attacks and prevent events from escalating to incidents and breaches. You will find integration with Slack for notifying abnormal system behaviours and being able to access and exam logs from application, web servers, load balancers and other infrastructure are your best friend when you are under attack.

4. Don’t panic and execute your incident response plan

Don’t panic should be Rule Number 1 when you find yourself under attack. Remember you have an incident response plan covering steps such as containment, eradication and recovery. Oh, you don’t have one? Make one now, a practical one, and train everyone about it!

5. Know your security limitations and blind spots

Application layer attack are common threats for web applications. One typical misperception is thinking network based firewalls and intrusion detection mechanisms can defend against application layer attacks. Instead, you should evaluate Web Application Firewall or other relevant security measures. Open source solution ModSecurity from the OWASP ModSecurity CRS Project could be a good candidate.

Fight cyber threats together

We are part of the Stone & Chalk Community and believe that together as a community we can be stronger. Trade Ledger’s services are closely integrated with financial institutions and we often handle sensitive customer data. We’re sharing our attack experience because we hope it will help the fintech community be better prepared for such attacks. We also firmly believe that sharing of threats and security intelligence across the community is the best form of protection and hope other fintech’s will follow our lead in sharing.

Cybercriminals are coming for us. We need more collaboration and knowledge sharing for developing pragmatic cyber security solutions that allow us to innovate at speed. Trade Ledger is delighted to be one of the early contributors in building a secure and innovative community.

Written by Ivy Young, the security gun at Trade Ledger.

Like what you read? Give Stone & Chalk a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.