The proliferation of IoT devices in the workplace presents a huge security risk and if new research from ForeScout Techologies is anything to go by, organisations are ill-prepared to deal with this rise and the associated threat. Even worse, by the time some of the IoT devices reach businesses, they are already vulnerable due to the lack of industry regulations and current approach to development. In order to stem the security issues with IoT applications and devices, there needs to be a step change in the development process. It has simply never been more important that these devices and platforms be developed securely in the first instance.
Businesses are not ready to secure IoT
There is no doubt that IoT is on the rise; Gartner has estimated that there will be 6.4 billion connected things globally by the end of this year and projects that figure to reach 21 billion by 2020. So for every ten IoT devices today, there will be approximately thirty in just four years time. But the poll from ForeScout clearly suggests that businesses are not prepared to deal with these devices with 85 per cent of the 350 IT professionals surveyed saying that they weren’t sure if they could detect an IoT device as soon as it connects to the network. Of course, as soon as an infected device connects to the network, the security of the entire network is compromised.
Developers are not measured on how securely they code
Unfortunately, because of the lack of any regulation or industry standards, and the nature of how IoT applications and devices are developed, security is not always a priority either for the developer or for the decision makers within these businesses. The priority is to keep up with, or get ahead of the competition; to achieve this, businesses simply can’t afford to be late to market. As such, developers are measured on how fast they can code rather than on how securely they can code. This results in security being ‘bolted on’ once the application is fully developed but at this late stage, it’s often too late to rectify the situation and fix insecure code.
The Software Development Life Cycle (SDLC)
The normal process for the SDLC has 5 main stages: design, development (coding), testing, deployment, and maintenance. As you can see, testing is conducted late in the cycle. In many cases, code is written, passed to another team and then checked for security vulnerabilities very close to release times by black box methods such as pen-testing. Checking this late means it can take longer for coders to re-code to fix any bugs or vulnerabilities as they are simply not as familiar with the code as they would have been when they first wrote it.
A difficult decision
When this happens, it results in pressure on the senior management teams in businesses to release a new version that isn’t fully patched because there just isn’t enough time to fix it. Furthermore, business leaders often choose to get the bugs in the code that will impact the user experience fixed rather than the vulnerabilities in the code that could present an attack surface for a hacker. When there isn’t time to do both, the cost of delay, in a competitive market, is sometimes deemed too high and vendors choose user experience over security.
It doesn’t have to be this way
But if business leaders changed their approach to the development process, they wouldn’t have to make these difficult decisions. By employing white-box testing methods such as Static Application Security Testing (SAST) and moving testing earlier in the process, businesses can test for flaws and vulnerabilities on a continuous basis, understand the potential risks in the code early on and put developers in a position to start addressing vulnerabilities in the same way they address functional bugs, transforming an SDLC into a Secure-SDLC (sSDLC).
The automated testing process
With the continuous testing of the sSDLC, every change to the code is automatically analysed so developers are notified once any vulnerabilities are found which means businesses get information early enough that they don’t have to make tough decisions. These newer SAST solutions used in the sSDLC also allow incremental scanning so developers can test the relevant or modified pieces of code for security flaws rather than run a full, time consuming scan every time a new version of the code is released. Some of the new generation of SAST solutions are even able to reduce the developer’s mitigation effort and reduce remediation time by pinpointing specific junctions in the data flow of the application’s code so developer’s can mitigate multiple vulnerabilities with a single fix. In many cases, this can reduce the remediation time by up to 80 per cent.
Overall, by bringing testing to the start of the development process and making security the core of the SDLC, businesses save time, developers learn to write safer code and ultimately, IoT devices and applications become less of a security risk.