Tag Archives: self defending

Return on investment for hackers

Declan O’Riordan, head of security testing, T&VS
You’re a criminal. You want a good return on your investments. Actually I hope the former statement is false but expect the latter is probably true. When it comes to cyber-attacks there appear to be some methods that are far more likely to succeed than others. Let’s take a look at some figures revealed by Verizon.

In their sample of 63,437 incidents (i.e. events that adversely affects the information assets), physical theft and loss of IT assets such as laptops accounted for 14% of all incidents. You might expect a corresponding 14% of breaches (i.e. confirmed data compromise) to be caused by physical theft and loss. Actually, the number of associated breaches is less than 1% due to effective security measures such as user authentication and data encryption. Insider misuse is a common problem at 18% of all incidents, but again the number of successful breaches is considerably lower at 8%. The lesson here for attackers is that some malicious actions provide a poor rate of return and are best left to opportunists.

TVS-SB002-Threat_incident_v_breach_Verizon

Which types of attack offer a good chance of success? It’s difficult to analyse how much preparation goes into a typical web application attack, since some are far more crafted than others and successful criminals tend to keep their trade secrets secret. One thing we can see is that while web application attacks amounted to a mere 6% of incidents, they led to a whopping 35% of all effective security breaches in the sample. That is by far the largest percentage for any type of threat. Is is unsurprisingly a strong growth area for attacks.

Are there any threats that provide a better chance of breaching security? Yes, several. Both Point of Sale (POS) intrusions and card skimmers featured in less than 1% of incidents each but led to 14% and 9% of breaches. The greatest probability of success of all threat types comes from the most organized of malicious parties: cyber-espionage. Whereas amateurs and hacktivists might mess about with Denial of Service attacks (3% of intrusions, 0% of breaches), the hard-core cyber criminals work in well-organised project teams with clear objectives. Cyber-espionage accounts for 1% of incidents but 22% of breaches!

What lessons can honest parties learn from this? I would suggest we target our defence spending according to the current most serious threats. Clearly web applications need to be designed, developed and tested to be more secure. The security of POS and card payment systems leaves much to do, especially in securing devices, locking down hub-and-spoke retail domains, and reducing trust in systems with external access. As for cyber-espionage, the spies will be looking for weaknesses in every area, and that means a wholesale improvement in making people more aware, putting secure processes in place, and configuring the technology to do what the customer wants and not what the spy wants it to do!

 

Free white papers on how to start building and testing secure web applications.

The purpose of these documents is to set out good practice for avoiding security vulnerabilities on any Web Application project and they include:

            – An explanation of Web Application Security Development and Testing

            – Guidelines for developers and testers to reduce the top ten application security risks

Download your free white papers now.

 

Free Executive Briefing / Webinar on Internet Security (20 January 2015).

If your company writes or uses software connected to the Internet this briefing will inform you of the security threats you face, your responsibilities in respect of those threats and practical suggestions on how to discharge those responsibilities.

Register for the Executive Briefing here.

Security should be built in, not added later…

By: Declan O’Riordan Head of Security Testing, T&VS

declan-oriordan-thumbnail

Prologue: It was the best of security, it was the worst of security and based on true events…

Project A had a team that learned how to design, code, and test security into their application from start to finish. The secure application provided all the functionality customers wanted, and none of the vulnerabilities hackers aim to exploit.

Project B hoped for the best. The designers assumed users would only submit data that could be trusted, and anyone using the system was a trusted user. The developers decided there was no point in trying to build self-defending applications – “because hackers will always get in anyway”… Continue reading