Protecting your network requires TnT: Training and testing

• Agile development processes are making the problem worse
• You need the right tools, and pervasive testing and training

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 practise, the luckier I get.”
 
Yet when it comes to cybersecurity, nearly half of organisations are solely relying on luck to get them through a cyberattack.
 
There is not enough practice or training in terms of incident response, and testing happens haphazardly, depending on the developer and organisation – which obfuscates baselines and the context necessary to ensure security and resilience.
 
Particularly in terms of testing, we’ve noticed that despite awareness of its importance, bugs and vulnerabilities routinely slip through.
 
In fact, a recent Ixia survey found that 34% of developers have deployed products that have had a few bugs. Worse, 31% said products harboured significant vulnerabilities that required patching later in the cycle when shipped.
 
The problem has been exacerbated by the rapidly growing normalisation of agile development processes.
 
Groups of developers are tasked to build products piecemeal, leading to application development that is often incremental and happens in iterative cadences. Testing and oversight happen at each step of the process, but the segmented nature of the development cycle means that bugs and vulnerabilities often arise when the code is assembled, and are routinely missed.
 
It’s clear that more than a local test – a comprehensive end-to-end test – and relevant training are critical.
 
A change in culture
 

 
Improvement begins 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 tested.
 
It’s a major reason for security incidents, even with multiple layers of security tools.
 
This also requires the right training. Having seemingly secure code and the right security measures is not enough for a strong security stance if proper training is not implemented. Organisations need to learn how to respond.
 
Yet recent SANS Institute research into the incident response capabilities of companies worldwide found that 43% of respondents did not have a formalised incident response plan, and 55% didn't even have an incident response team.
 
This less than vigilant approach to system level security can have worse implications once a product goes live in the network.
 
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 – leaving gaps for threat actors to exploit.
 
Continuous testing and training from the very onset of operation and throughout a tools lifespan are imperative for all employees, especially IT and security pros – even in its simplest iterations.
 
What to look for
 
Successful and continuous testing and training expose 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 (Distributed Denial-of-Service) attack types emerge every day – not to mention it helps keep up with evolving typical application behaviour.
 
More specifically, function and system testing should be at the heart of any programme following the development cycle test process. Quality of service, performance, and resilience all benefit along with security as a result.
 
Some companies take shortcuts, like using internally generated attacks or crowdsourced 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 – a single scenario only protects you from one type of attack.
 
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, the right approach to testing can make networks robust 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.
 
David Sajoto is head of Enterprise Sales, Ixia, Asia Pacific and Japan.
 
Related Stories:
 
Arm and train your cyber warriors on a cyber range
 
Network visibility not just about security, but future-proofing
 
Cybersecurity: Some will choose failure over change
 
 
For more technology news and the latest updates, follow us on Twitter, LinkedIn or Like us on Facebook.