Bringing Security to the IoT

The Palo Alto Networks’ threat intelligence team made some disturbing discoveries when they studied 1.2 million IoT devices in 2020:

• 98% of all IoT device traffic is unencrypted
• 83% of medical imaging devices run on unsupported operating systems

‍Research shows that more than 1.5 billion attacks have occurred against IoT devices in the first six months of 2021. Alarming numbers.

Attackers target devices for many reasons which include

• Stealing information or spying
• Disrupting services
• Recruiting devices into botnets and launching DDoS attacks
• Creating fake data and influencing machine learning

With connected devices, the technologies we create can let attackers not just into users’ emails but into their cars and homes if we don’t secure them properly.

As technologists, it is more important than ever before to pay attention to AppSec processes.

‍

AppSec for connected devices

Traditional security practices don’t work as well for connected technologies as they do for old-school devices.

This is owing to difficulties with firmware updates, lack of control over deployment contexts, and varying standards being adopted.

Security has shifted from being an afterthought to a core design element. Pen testing and automation are still crucial, but the role of security especially for connected devices starts much earlier than that with security-centered design.

As we use and create connected technology features, there are specific adaptations we can make to our SDLC processes to make AppSec work effectively for devices.

‍

Optimizing AppSec processes

IoT technologies bring new and unique challenges along with their capabilities:

‍

Blockchain

Blockchain is a prime example of such challenges. Although it is an important advancement in security user practices and poorly written/used software put blockchain users at three levels of risk:

1. Code vulnerabilities
   Blockchain has two common causes of security gaps:
   • Non-standard network protocols
   • Obscure or intransparent encryption algorithms
2. Platform vulnerabilities
   Blockchain applications typically run on the same hardware and software infrastructure we use every day and are vulnerable to the same types of attacks as any other program.
3. End-user vulnerabilities
   The user-facing edge of a blockchain system is often the gateway for cyber attacks. Stolen cryptographic keys, vulnerable signatures, dictionary attacks, and phishing attempts are ways hackers gain access.

The use of SSL and TLS, implementing application-level strong authentication, and cryptography key vaulting mechanisms are basic practices a blockchain application developer can adopt to make applications more secure.

‍

Services

Microservices and RESTful APIs are vulnerable to attacks due to design flaws.

That can be mitigated through adherence to service-security principles:

• Least privilege: Allow entities to access only what is necessary
• Fail-safe defaults: Assume access denied until authenticated
• Economy of mechanism: Design each subsystem as simply as possible
• Complete mediation: Control access at every point rather than use a cached permission matrix
• Use open design rather than obscure/confidential algorithms
• Separation of privilege: Use granular permissions rather than sets
• Least common mechanism: Avoid sharing state among components
• Give preference to OAuth over basic auth
• Never expose information in URLs 

‍

Containers

Containers come with their own security challenges that can be addressed with best practices:

• Use container images only from signed, trusted registries
• Configure container access profiles with correct access levels
• Setup user access profiles especially for deployment roles
• Use a secure web host or orchestration systems like Kubernetes, Azure, GCP, or AWS.

‍

Autonomous vehicles

Autonomous vehicles are particularly susceptible to cyber attacks as the technology is fairly new and  vulnerabilities are still being discovered.

‍BSI’s  PAS 1885:2018 is a set of standards and guidelines for automotive cybersecurity. Drafted after consultation with experts from various organizations, this standard went through extensive peer and public review before it was established.

‍

ML / AI and big data

Malicious attacks happen with ML processes, especially with big data.

A few common areas of vulnerability:

• Injecting fake data to influence learning
• Untrusted mappers used in MapReduce processes
• Lack of cryptographic protection
• Lack of access control granularity
• NoSQL databases and their lack of focus on security
• Absence of security audits

Using the right platforms, encryption, granular access controls, protecting endpoints, and performing regular audits are a few basic practices that can ensure data stays secure.

‍

Web Application Firewalls

Connected devices are vulnerable to any threats that websites are, as they frequently use HTTP and web technology. Some of the common attacks are XSS and script injection. Best practices like same-origin headers, safe escaping and HTML encoding help defend against these. QA processes like integration and pen testing should be a core part of the SDLC but they should not be the only point of catching security gaps.

‍

What the future looks like

Security starts before QA, dev, or even design as a core priority. Old school best practices like architectural reviews, threat modeling, and audits by industry experts help avoid common threats. Security evolves, but crime evolves too. Cybercriminals employ the same tools and technologies protectors use to improve their effectiveness.

City infrastructure everywhere is getting smarter, and AI-driven decisioning is likely to run more critical systems. Self-driving vehicles and drones are just around the corner. As we step into this connected world as technologists and users, let us remember that security is everyone’s job.

Let us do every bit we can, adopt every standard, perform every audit, and educate as many as we can, as we navigate the opportunities and challenges IoT brings.