Channel: CodeSection,代码区,网络安全 - CodeSec
Viewing all articles
Browse latest Browse all 12749

The future of network-connected device security


Wireless functionality has improved workplace efficiency and organisations are no longer restricted by cabling access. Unfortunately, many of these devices are poorly secured and rarely have their firmware updated.

The vulnerabilities in internet of things (IoT) devices have led to smart devices being part of botnets and incidents such as cardiac devices being vulnerable to hackers.

“The proliferation of IoT devices with poor security posture has increased the attack surface for threat actors dramatically,” says John Sheehy, vice-president of ioActive . “Compromised devices can be used by threat actors for anything from listening in on conversations and harvesting sensitive data, to cryptomining and jumping to traditional IT systems.”

Incidents where hackers have been able to exploit poor device security to obtain sensitive data have resulted in significant reputational damage, as happened to vTech in 2016. Such incidents could now under the Data Protection Act 2018 see companies fined.

As such attacks have become more frequent, the UK government has decided to step in. Earlier this year, the Department for Digital, Culture, Media and Sport (DCMS) published the Secure by Design report and later the Code of Practice for Consumer IoT Security a guidance document advising on the best practices for securing IoT devices.

These guidelines are currently voluntary and are broken down into thirteen steps, as follows:

No default passwords all IoT device passwords should be unique and not resettable to any universal factory default value. Implement a vulnerability disclosure policy all companies that provide internet-connected devices should provide a public point of contact as part of a vulnerability disclosure policy in order that security researchers and others are able to report issues. Disclosed vulnerabilities should be acted on in a timely manner. Keep software updated software components should be securely updateable. Updates should be timely and not impact on the functioning of the device. An end-of-life policy shall be published for end-point devices, which explicitly states the minimum length of time that a device will receive software updates. Securely store credentials and security-sensitive data any credentials shall be stored securely in services and on devices. Hard-coded credentials in device software are not acceptable. Communicate securely security -sensitive data, including any remote management and control, should be encrypted in transit, appropriate to the properties of the technology and usage. All keys should be managed securely. Minimise exposed attack surfaces all devices and services should operate on the ‘principle of least privilege’; unused ports should be closed, hardware should not unnecessarily expose access, services should not be available if they are not used and code should be minimised to the functionality necessary for the service to operate. Software should run with appropriate privileges, taking account of both security and functionality. Ensure software integrity software on IoT devices should be verified using secure boot mechanisms. If an unauthorised change is detected, the device should alert the consumer/administrator to an issue and should not connect to wider networks than those necessary to perform the alerting function. Ensure that personal data is protected where devices and/or services process personal data, they shall do so in accordance with applicable data protection law. Device manufacturers and IoT service providers shall provide consumers with clear and transparent information about how their data is being used, by whom, and for what purposes. This also applies to any third parties that may be involved. Where personal data is processed on the basis of consumers’ consent, this shall be validly and lawfully obtained, with those consumers being given the opportunity to withdraw it at any time. Make systems resilient to outages resilience should be built into IoT devices and services where required by their usage or by other relying systems, taking into account the possibility of outages of data networks and power. As far as reasonably possible, IoT services should remain operating and locally functional in the case of a loss of network, and should recover cleanly in the case of restoration of a loss of power. Devices should be able to return to a network in a sensible state, rather than in a massive reconnect. Monitor system telemetry data if telemetry data is collected from IoT devices and services, such as usage and measurement data, it should be monitored for security anomalies. Make it easy for consumers to delete personal data devices and services should be configured such that personal data can easily be removed from them when there is a transfer of ownership, when the consumer wishes to delete it and/or when the consumer wishes to dispose of the device. Consumers should be given clear instructions on how to delete their personal data. Make installation and maintenance of devices easy installation and maintenance of IoT devices should employ minimal steps and should follow security best practice on usability. Consumers should also be provided with guidance on how to securely set up their device. Validate input data data input via user interfaces and transferred via application programming interfaces (APIs) or between networks in services and devices shall be validated.

The definition of a “timely manner” is incident-specific. However, 90 days is the standard for completion.

Industry reactions have been broadly positive, with HP and Centrica agreeing to abide by these recommendations. However, some recommendations are easier to implement than others.

“At the high level, the specific requirements outlined in the code of practice are exactly what needs to happen,” says Sheehy. “The challenge I see is that the devil is in the detail.”

No default passwords and a vulnerability disclosure policy are fairly easy for organisations to implement, but ensur

Viewing all articles
Browse latest Browse all 12749