Application security incidents are happening much more than we care to imagine and, it is having a huge impact on peoples privacy and data security. Making sure you have an incident response plan in place to deal with an application incident is vital.

Below we look at ways of dealing with an application security incident and what you need to do to make sure you get on top of any future potential hacks. Application security incidents will happen if security is not your number one priority and an incident can cause serious damage and scrutiny for any company. Accusations will be made and blame will be cast but the most important thing is how you respond.

You’ll be surprised at the number of scripts and spiders out there probing and reporting back on systems that aren’t fully protected – just waiting to penetrate the least effective system and cause some serious upheaval to businesses. We always recommend integrating developer-driven security into your strategy to prevent application security incidents.

‘Developer-Driven Security; the practice of building secure applications starting in development; a phenomenon where engineers take the lead in securing their source code’

Should you find yourself on the end of an application security incident here’s what your incident response plan should cover:

Assess how the hackers got in.
Check the full extent of the damage, go down to skeleton staff and turn systems off. You need to identify how the hackers got in and what data was accessed, you also need to identify, very quickly, what holes still exist and you can’t do this with staff around you trying to go about their daily tasks. Make sure you take screenshots, save infected files, save log files, save anything and everything incriminating – this is all part of collecting evidence that is required for your incident report that will need to be sent to authorities.

Make sure you disclose the breach.
Make sure everyone is aware of the breach – normally this type of disclosure will be made by senior management, you can help them by providing the following information that should be passed along to users.

  • How the issue was discovered
  • Which systems were impacted, when, and for how long
  • What data was breached and whether it included their PII, passwords, credit card info, etc.

The type of data breach will mean different things to different users and their teams within the business. Make sure everybody knows the full extent of the hack and the scope of the damage caused. Making sure the breach is disclosed is the best way to show that you are on top of the problem and not a victim of it.

Patch security holes.
Once your systems are quiet it’s time to work out how the breach happened and how you can fix it. Every application is different and finding and patching the problem should be your absolute first priority before any further damage can be done. You might have luck starting from the exploited data/access layer and working backwards. It’s likely that clues will present themselves if they haven’t already.

Make sure you are prepared for any future hacks.
Hopefully, there will never be a ‘next time’ but, you can never say never, hackers are extremely tenacious and will go after what they want. Once you have been hacked it is important to use your findings to protect yourself in the future and implement a security-centre approach to development.

  • Below are a few key questions to ask yourself:
  • How can the code be made secure?
  • Can any static content be moved to CDN?
  • Is your authentication strong enough? Can it be improved?
  • Can your monitoring and logging be strengthened?
  • What human factors can be improved?

It is also incredibly important that you educate your employees on the hazards of opening the wrong type of email attachments – just one click and your entire network can be infected with a worm, trojan horse or worse. Using the time for training and education after a security breach is an opportunity that shouldn’t be missed – it’s a time when the business and staff are sensitive to the issue and are more than likely going to listen and they have seen the impact a breach can have first hand. Human error is inevitable but it can be avoidable.

The latest Mirai botnet attack has shown that even trusted IP addresses can be turned against us.

‘Mirai (Japanese: 未来, lit. ‘future’) is a malware that turns networked devices running Linux into remotely controlled bots that can be used as part of a botnet in large-scale network attacks. It primarily targets online consumer devices such as IP cameras and home routers’.

It’s time to seriously consider your applications and it’s code and how you intend to protect them from these ever-increasing, super smart hackers who take no prisoners. Please take the time to carefully consider all of your options and how best to protect your systems, your business and your reputation. For any advice, our dedicated IT support team are on hand.