Recently, a series of Distributed Denial of Service (DDoS) attacks took down hundreds of websites in the US, including giants like Netflix and Twitter, and knocked nearly a million Deutsche Telekom customers offline. The Mirai botnet—whose name means “future” in Japanese—was the source of the attacks which, when taken with the broader trend toward cyberattacks “as-a-service”, may prove to be a bellwether for the Internet in 2017. As more and more vulnerable “things” get connected, we could be setting ourselves up for wave upon wave of disruptive cyberattacks hammering the public and private infrastructure on which we increasingly depend.
Dysfunctional Future
The reality is that the current security state of Internet-enabled devices is often pretty parlous. Some of the devices enslaved in the DDoS attacks against service provider Dyn, which led to all those websites going down, were Digital Video Recorders (DVRs) with hardcoded, default passwords. Even if a user had the knowledge and wherewithal to change the password, they couldn’t which created a perfect opening for Mirai.
In a market where many manufacturers operate on a “stack ‘em high, sell ‘em cheap” model, it’s easy to embrace time to market and lower per-unit costs and baulk at redesigning products for better security. The risk of this approach, however, is damage to the corporate reputation, the alienation of customers, and a corresponding loss of business as people move to more reliable or trustworthy products.
It All Starts with the Design
With this in mind, security and security lifecycle must be as much a part of the product design as the physical shape and other features and functions. This may sound daunting given that it implies even more pressure on already tight margins but it doesn’t need to be as costly as it sounds. John Overbaugh at infoSecure.io has some great pointers for Secure SDLC on a Shoestring to get things started.
It’s also important to keep in mind that a failed security audit in the verification stage of the product lifecycle will lead to late-stage design and engineering changes at best and at a delay in shipping at worst. As any program manager can explain, those types of problems are the most expensive (with the exception of having to redesign and reengineer a product after it has shipped). Incorporating security earlier in the product lifecycle keeps costs down and mitigates risk to program schedules and milestones.
Content from our partners
Empower the People Who Write the Code
Security in design won’t pay dividends if it fails in implementation and it’s clear that many developers could improve their secure coding skills. Providing support and training to the folks whose fingers are on keyboards should be considered an investment in the product.
Improving Cryptography
Poorly implemented crypto is just as bad as no crypto at all, as we’re sure people banging on your door will be keen to let you know when devices have been breached and everything has gone to pot.
Software engineers need to consider cryptography as a matter of priority, but it is often and easily overlooked. The Cryptopals Crypto Challenges are a great way to help developers hone their skills. These challenges consist of eight exercises which not only help create a practical understanding of cryptography in software, but also help teach how to identify, exploit, and then avoid cryptographic weaknesses.
Getting cryptography right is fairly fundamental and will ultimately make the difference between whether products are viewed as reliable and become high sellers or a reason for being sacked. It might not rank up there with slick industrial design or amazing user experience but cryptography is like the foundations of a house: it needs to be absolutely solid.
Value of Penetration Testing
Like the Cryptopals Crypto Challenges, a penetration testing course can arm developers with the knowledge required to understand vulnerabilities and the various points of penetration that cyber miscreants might try to exploit. These range from poor authentication, to insecure network services, to insecure web interfaces, to unsanitized database inputs, and more.
It is inevitable that your code will eventually become the target of Red Team, so understanding how they operate and being able to utilize some of their tactics is a valuable tool for creating less vulnerable software.
Play Defence On the Network
The power and the peril of IoT devices is, of course, their network connectivity. Those
not directly responsible for these devices still have an obligation to prevent the network from becoming a weapon in the modern arsenal. The Internet Society’s Mutually Agreed Norms for Routing Security (MANRS) offer a simple framework for improving network security. MANRS outlines four principles and the second one, preventing 
traffic with spoofed source IP addresses, should be adopted by everyone who is responsible for a network. As a case in point, the Mirai botnet driven DDoS attacks—which broke muiltiple records for sustained traffic rates—could easily have been mitigated if traffic from spoofed addresses had been dropped closer to the Internet edge.
Network segmentation is another important option to consider. Vulnerable IoT devices provide an attack surface and pivot point for attacking other parts of the infrastructure. Network segmentation is not a trivial undertaking but it’s an essential tool to protect enterprise resources from potentially dangerous IoT devices. You might already have a guest network in place that provides Internet connectivity while blocking access to enterprise resources. This is a good start but IoT devices may need access to some enterprise resources whereas guests—by definition—don’t.
As IoT becomes increasingly popular, users will bring new devices onto the network that certainly won’t need cart blanche access. Of course, you can introduce policies and put down a firm ‘no’ when it comes to plugging Internet of Things devices into the network. But as the mobility surge vividly illustrated, employees—and even entire departments—will adopt the dynamics of a herd of wildebeasts, completely trampling over policies they perceive as interfering with their productivity. Companies can be absolutely militant about “no meaning no” but with an estimated 50 to 200 billion IoT devices in play by 2020, IT organisations will inevitably be overwhelmed.
With this in mind, employing tools like Network Access Control (NAC) to dynamically categorize and assign access privileges to devices joining the network will guard against the herd like inclinations of employees. Over time you can then decide what resources should be accessible on the IoT network. Ultimately, an IoT network should fit somewhere between your outright-trusted enterprise network and what you use for guests.
The Real Consequences
The Mirai botnet attacks were inconvenient but ultimately, relatively harmless. But what would happen if Mirai was targeted at critical infrastructure? The attack that crippled service provider Dyn consisted of an estimated 100,000 devices. What will happen when a botnet comprises millions of devices?
Imagine the consequences of an IoT based attack on a retail chain in which all of its Point of Sale terminals were unable to process payments. What about the consequences of DDoS attack that uses hundreds of connected refrigerators in a hospital? Doctors, who rely on Wi-Fi for communications don’t receive the information they need and critical patient data from medical monitoring equipment is lost in the deluge.
Of course, you can argue that ‘what if’ scenarios are endless but as you read this, script kiddies and cyber-criminal gangs are already drastically expanding their control over vulnerable IoT devices. These devices are conscripted for malicious purposes and can be contracted in DDoS-for-hire services. If IoT vulnerabilities aren’t addressed everyone will pay a price, from device manufacturers, to businesses and end users.
.
