Bethany Mayer, CEO, Ixia
Bethany Mayer, CEO, Ixia

An observer watching a bunker shot by legendary pro golfer Gary Player was heard to say: “I've never seen anyone so lucky in my life.” The player retorted: “Yes, and the more I practice, the luckier I get.” Yet when it comes to cyber-security, nearly half of organisations are solely relying on luck to get them through a cyber-attack.  

They have the security tools in place, but all too often fail to practice how to use them to the best effect — especially during an attack. Knowing how to respond in the event of a breach has everything to do with practice and conditioned responses, especially when the latest solutions and technologies themselves can be the source of vulnerability.

Yet recent SANS Institute research into the incident response capabilities of companies worldwide found that 43 percent of respondents did not have a formalised incident response plan, and 55 percent didn't even have an incident response team. Further, just nine percent described their incident response capabilities as very effective. The reasons were familiar: lack of time to review and practice procedures (62 percent) and lack of budget (60 percent). 

These are astonishing numbers considering the clear benefits generated from testing a networks' resilience to attacks using realistic scenarios. The tests make networks as robust as possible and prepare IT teams for real-world attack situations, helping minimise response times and the negative impact on the business. As breaches now seem to be coming from every direction, testing needs to come to the foreground, from the development stages to when products sit directly in the line of fire.

A culture based on testing security, not speed

We need to start by changing the culture that minimises security testing for the sake of launch timelines. Too often, the product development team will come together just to be told they need to move up their release date. The habit results in products that walk a thin line of performance, as they may contain unknown security holes due to not being fully vetted. It's a major reason for security incidents, even with multiple layers of security tools, because the security tools themselves can become a source of risk.

This less than vigilant approach to system level security testing can get worse once a product goes live. For instance, updates, patches and configuration changes applied when a new feature is added can reset an organisation's security posture, and this sometimes goes unnoticed. Continuous testing and training from the very onset of operation and throughout a tool's lifespan is imperative for all employees, especially IT and security pros—even in its simplest iterations.

This applies to personnel as well. A recent CompTIA study found that 52 percent of respondents name human error as the leading contributor to security breaches. Training is crucial to avoid having this happen to an organisation. For instance, at previous companies, we used to send internal phishing emails to see who would click. The inevitable victim would get that dreadful pop-up letting them know they failed the test. Once fooled, though, employees became much more aware. It's a simple test, but falling victim to a threat made employees more vigilant to similar attacks in the future.

More broadly, but in a similar vein, network security testing exposes security and IT pros to anomalous activity they'd not be able to recognise otherwise. It's necessary to be able to answer questions like, “What does suspicious activity look like on my network?” or “What security alerts require immediate action?” The more they see, the more refined their eye becomes—it's all about a proactive approach paired with repetition.

Which raises the question, what is considered a good test?  It starts with accurately reflecting the widest range of attack types in live operation. It is also important to create an accurate sandbox to test in so that it can be as close to reality as possible. The more accurate the environment, the better prepared IT and security teams will be. Realistic depictions better prepare employees as new malware, phishing, and DDoS attack types emerge every day—not to mention it helps keep up with evolving typical application behaviour. 

Some companies take shortcuts, like using internally generated attacks or crowd-sourced probes to attack their networks. Just as bad, some have the development team create and run their own test scenarios. While this can give the illusion that everything is good, it creates a false sense of security—one scenario only protects you from one attack type. 

The key is not to stop at the minimum when it comes to security testing and training. Developers spend lots of time building great features; why not spend time training teams on how to use them? Limited or biased tests can easily overlook glaring flaws.

Ultimately, whatever approach an organisation uses, it must ensure security and IT teams are familiar and prepared for any possible threat. Even the best athlete doesn't just walk onto the court or field expecting to dominate; they've practiced for hours against the best to make sure they are ready. Similarly, we can't skimp on rigorously testing security products and training security teams. 

Contributed by Bethany Mayer, CEO, Ixia