staging-devopsy.kinsta.cloud

Tag: IoT security

  • How 5G Mobile Networks Will Change IoT Security

    How 5G Mobile Networks Will Change IoT Security

    Depending on your location, you might have noticed a new 5G icon on your cell phone recently. The roll-out of the new 5G mobile network is largely a positive change for consumers and businesses. The fifth generation of cellular networks (hence 5G) purports to be one of the fastest wireless networks ever created.

    This technology claims to provide more efficient interconnectivity, and faster data transfers between people, objects and devices. All good things, right? But what security risks does 5G represent for the modern age?

    Some cybersecurity experts suggest that new vulnerabilities are versions of problems not entirely flushed out from 4G and even 3G networks. This article will attempt to explore some problems and opportunities that IoT security experts need to be aware of, and how savvy enterprises can be proactive about security in the age of 5G.

    Riding the 5G Wave

    A business’s potential is only as great as the technology they elect, as an organization, to adopt and use. One of the first benefits that 5G provides comes from the additional speed that the network provides. 4G posted average download speeds around 20Mbps. With a fully deployed and optimized 5G network, users should expect those download speeds to reach anywhere from 500 to 1,500Mbps. 

    Raw speed is one thing, being able to harness this type of efficiency is another. A Barclays’ poll recently reported that only around 28% of businesses understand 5G or the practical business applications the network offers. 

    Along with the challenges of leveraging the increased speed of the 5G network for business purposes, another important aspect of 5G education involves the security risks associated with faster technology. We suspect that if only 28% of businesses understand the practical applications of a 5G network, the awareness of potential security risks may be a similarly low figure.

    Getting Up to Speed on G Security

    While 5G touts a tighter grip on security, experts in the space will remind us that some of the concerning holes in the security of 4G, and even 3G, networks have been carried over into the rollout of 5G. Give credit where it’s due, the 5G security wins are associated with the encryption process which improves anti-tracking and spoofing features. This means that would-be criminals have a much harder time tracking and manipulating device connections.

    5G is also more software and cloud-focused than previous versions, which allows for better monitoring so threats can be spotted and mitigated more quickly. 

    While this is good for consumers, it’s not a perfect system by any means. “Stingray” devices can still be used to deploy fake base station attacks, which allow attackers to intercept mobile traffic and potentially manipulate data.

    Downgrade Attacks

    Purdue University and the University of Iowa outlined findings from design issues in the 5G protocol that exposed 11 vulnerabilities that may be exploited by bad actors. Five of these discovered vulnerabilities were carried over from 3G and 4G networks. Notably, a “downgrade attack” which essentially reverts the devices to use old mobile data networks. On top of potentially leading to higher wireless bills, this may allow attackers to track calls, texts or browsing habits on devices.

    If a device is forced to operate in a limited-service mode, an article in WIRED explains how IMSI numbers may also become exposed because of a downgrade attack.

    “One purported benefit of 5G is that it protects phone identifiers, like your device’s ‘international mobile subscriber identity,’ to help prevent tracking or targeted attacks,” stated WIRED. “But downgrade attacks like the ones the researchers found can bump your device down to 4G or put it into limited service mode, then force it to send its IMSI number unencrypted. Increasingly, networks use an alternative ID called a Temporary Mobile Subscriber Identity that refreshes periodically to stymie tracking.”

    Tips to Avoid Security Pitfalls in the Age of 5G

    In the age of the fastest speeds ever seen and nearly ubiquitous connectivity because of the rapid adoption of IoT devices, it’s becoming apparent that a zero trust model could help address security concerns with 5G and beyond. 

    This may require additional education to be available for employees, but an increase in security best practices for endpoint users is something that will benefit an organization tremendously. Zero-trust security models continually check the user’s presence and behavior within a network regardless of whether the user is human or machine. 

    It might seem like a great idea, but adopting the model isn’t a change to be taken lightly. A survey conducted by AT&T about 5G security indicated that just 33% of respondents reported they are currently using multi-factor authentication—the road to zero trust will take buy-in from executives and managers. 

    Sharing the Burden of Security

    The 5G rollout does provide built-in security features, but it should not be viewed as the Holy Grail. An organization will benefit from having a comprehensive security model, but that doesn’t mean they need to single-handedly oversee every aspect of that model. 

    5G is a combined effort that involves network operators and enterprises, and shared responsibility is essential for long-term success. Managed service providers should be considered by companies that may be short-staffed, or don’t have the in-house resources to cover other important areas of security, such as ransomware protection.

    Security within a business can’t exist in a silo, it’s a team sport—make sure you’re on the winning side.

    — Marty Puranik

  • 3 Ways IoT Developers Can Make Their Applications More Secure

    3 Ways IoT Developers Can Make Their Applications More Secure

    When the IoT was still young, IoT application developers got away with making security an afterthought, as they built prototypes and minimum viable products designed to demonstrate the different ways the IoT could be used to transform the way we work, play and live. But the IoT has matured and grown to the point where today, Gartner estimates there were 8.4 billion connected things in 2017 and forecasts there will be 20.4 billion IoT devices deployed by 2020. With this growth has come a massive increase in number and sophistication of IoT security attacks, and the need for developers to make security not just a priority, but a top priority.

    As the IoT hacks of Trendnet’s SecurView camera, St. Jude’s cardiac device and the Jeep Cherokee have demonstrated, when security is not a top priority, successful IoT attacks can cause significant real-world financial, reputational and even human damage.

    While it is impossible to make IoT applications (or any type of software) 100% secure, there are several best practices that IoT application developers can adopt to strengthen the security of their IoT applications. These best practices include:

    1. Following a set of approved cryptographic standards when building applications.
    2. Using static code analysis programs that analyze application code to identify common coding mistakes that can lead to security vulnerabilities.
    3. Instituting a vulnerability management strategy that identifies and repairs known vulnerabilities in IoT applications on a scheduled, ongoing basis.

    These three best practices will not make IoT applications perfectly protected from malicious actors. However, they can significantly reduce an IoT application’s vulnerabilities and attack surface, making it much less likely a developer’s applications will be breached, generating angry customers and negative headlines.

    Follow Approved Cryptographic Standards

    Most developers understand that, if they hope to keep IoT data safe, they should encrypt this data, especially while it is in transit from device to cloud or vice versa. Yet, faced with tight development deadlines, as well as the need to make the most of their IoT devices’ limited bandwidth and processing capabilities, some developers choose to not encrypt their data or use weak cryptographic algorithms that promise to be faster or more lightweight than others but do not provide proper levels of security.

    Experience shows taking encryption shortcuts can result in customers’ data being stolen, an application disabled or other problems. For this reason, developers need to work closely with their security teams to encrypt IoT application data appropriately, following standards and guidelines approved by internationally recognized experts such as the National Institute of Standards and Technology (NIST).

    Choosing to use such approved standards does not have a major impact on IoT application development time, performance or functionality. NIST provides developers with guidelines on how to streamline integration of encryption standards into their applications. They also offer many different standards to choose from, so developers can find one that will provide their application with an appropriate level of security without sacrificing too much in terms of performance or functionality. Yes, it does require some additional work and effort, but if IoT developers want to make security a top priority, they need to make sure they are following approved cryptographic standards.

    Use Static Code Analysis Programs

    Many developers are familiar with static code analysis programs and their ability to discover common coding errors that can lead to bugs that affect software quality. However, these programs also can identify unsafe coding practices such as the use of improperly terminated strings, pointers to freed memory and buffer indexes allowed to go past the end of the buffer. These common coding mistakes create security vulnerabilities malicious actors can exploit in otherwise functional applications.

    There are a variety of static code analysis tools available, both proprietary and open source that developers can use to alert them to coding errors that could create security vulnerabilities. Developers should research which ones best support their security and other code analysis needs, and then ensure that throughout the application development processes—and especially before deploying an application—they use these static code analysis programs to discover any coding errors that might lead to a security breach down the road.

    Again, many developers might be tempted to skip this step, since the problems revealed by the program might prevent them from deploying and commercializing an otherwise functional application as fast as they would like. But, as the examples of IoT application hacks mentioned above demonstrate, cutting corners with security can often result in major problems down the road. If developers are dedicated to delivering their customers IoT applications with robust security, they need to commit themselves to using static code analysis programs to fix coding errors that might make their applications vulnerable to cyberattacks.

    Monitor For and Repair Known Vulnerabilities

    The media pays a lot of attention to so-called zero-day vulnerabilities—those that a software vendor has no prior knowledge about. However, the low-hanging fruit for most attackers is the ever-growing number of known vulnerabilities present in the millions of software components used in IoT applications that haven’t been fixed, either because the user of the component is unaware of the vulnerability or because they have not taken action to update their application to repair the vulnerability.

    All IoT application developers should be aware of the known vulnerabilities their applications might have as result of incorporating third-party software components into their applications, be they open source components (such as a Linux operating systems and associated software) or proprietary components. However, keeping up to date on all the known vulnerabilities in an IoT application’s device firmware, operating system and other third-party software components is not simple. The enterprises that have built these software components, government agencies and other watchdogs often identify as many as 1,000 different vulnerabilities in these types of software components per month.

    Fortunately, there are resources that can help developers stay up-to-date on new known vulnerabilities. For example, the National Vulnerability Database (NVD) is a public resource operated by NIST that catalogues known vulnerabilities in all types of software components, both proprietary and open source. To ensure their IoT applications do not have any known vulnerabilities, IoT developers can compile a security bill of materials (BOM) for their IoT application—a list of all the software components and versions used in the application—and then monitor the NVD for new known vulnerabilities with these components. Alternatively, there are a number of proprietary and open source tools that leverage free APIs to query the NVD database and then scan applications for vulnerabilities either by evaluating their components’ codebases or by discerning versions of exposed services (such as DNS, HTTP/S, NTP, SSH) on network interfaces.

    However, simply being aware of known vulnerabilities does not fix those vulnerabilities. Which is why developers need to not just check for new known vulnerabilities on an ongoing basis, but also have a plan to regularly repair new known vulnerabilities with security updates. Ideally such a plan should allow these updates to be performed remotely (over the air) and automatically. Today, many consumer IoT applications already include an option to enable remote, automatic updates. The commercial IoT applications built by many developers sometimes need more coordination to enable such remote, automatic updates—but this should be the goal. In any event, even if the updates can’t be done remotely or automatically, it is essential that IoT developers have some sort of plan to deploy security updates for known vulnerabilities in their applications in a timely fashion.

    Robust Security Will Enable Future Growth of IoT

    IoT is at an important inflection point. The market continues to rapidly expand, with exciting new agricultural, supply chain, industrial, public safety, consumer and other IoT applications being launched every day. Yet, additional high-profile IoT application breaches could threaten the tentative level of trust businesses and consumers have placed in the IoT, especially as it increasingly is used to collect sensitive data or complete critical tasks.

    To strengthen trust in IoT, developers need to dedicate themselves to making IoT security a top priority. Lip service is not enough–developers need to implement IoT security best practices, including the adoption of approved cryptographic standards, use of static code analysis programs to discover coding mistakes that can create security vulnerabilities and implementation of vulnerability management strategies that regularly identify and repair known vulnerabilities in their applications. If IoT developers make security a real top priority by implementing these and other IoT security best practices, the world’s trust in the IoT will grow and so will their business.

    — Larry LeBlanc

  • How IoT Security Risks Derailing Robotics

    How IoT Security Risks Derailing Robotics

    Driven by advances in technologies such as artificial intelligence and deep learning, the mobile robots market is projected to grow to $54.1 billion by 2023 from $18.7 billion last year, according to Markets and Markets. But for robotics to progress, security for the internet of things (IoT) needs to be addressed fast, before the reputation of the entire industry suffers a permanent setback.

    Every industry segment has a journey to maturity that involves ramping up how seriously it takes security. For robotics, that time has come. Failing to start robotics projects on the right software foundations will see confidence continue to drop, impeding the rate at which new solutions are created.

    The future of robotics rests firmly on the shoulders of the IoT. Robots act as one part of intelligent ecosystems—they depend on IoT to link various sensors and smart meters, and pass data to and from third parties.

    The self-driving car, for example, is a robot orchestrated by various smaller devices and smart sensors. In fact, robots are being created to tackle every conceivable problem. Take the Google-funded RangerBot, an underwater machine designed to track down a species of starfish responsible for coral reef destruction, or Small Robot Company, a startup tackling farming deficiencies with bots that autonomously feed, seed and weed arable crops.

    However, while IoT is an established concept and connected devices are now mainstream, its full potential has not been realized in part because of security concerns. Ninety percent of consumers lack confidence in connected devices, according to a recent survey. These concerns are more than valid, as nearly half of companies are unable to detect when a breach occurs, and only 15% of budgets are earmarked for IoT security.

    With IoT security a lingering weak spot, one major attack within robotics, could have a domino effect on the entire industry. Add to this the verticals that robots are beginning to infiltrate—health care and agriculture, for example—and the threat becomes immediate and very real.

    Rising levels of sophistication within robotics go hand in hand with more targeted and damaging attacks. For example, telesurgery uses robotics to help surgeons perform procedures remotely. A malware bug in this scenario could mean the downing of tools, threatening the patient’s life.

    Researchers at Brown University proved how easy it is to hack robots. The industry simply will not be sustainable without the backing of a secure, connected IoT network.

    Robot manufacturers, therefore, must build with a security-by-design mindset. This begins by selecting a robust operating system from the outset—secure now, but also ready for future market demands.

    Hackers are constantly evolving their activities and businesses must be flexible in their approach to security, shedding the old hardware-centric view of IoT security.

    Software no longer can end when a device is shipped. It must align to the lifespan of a robot and be able to update whenever there is a potential flaw. The world of mobile took many years to get to grips with this. Robotics and IoT developers should learn from their mistakes.

    One way developers can safely build and secure software is through snaps, containerized software packages on an open platform for building and publishing applications to an audience of millions.

    If a security vulnerability is discovered in the libraries used by an application, the app publisher is notified so the app can be rebuilt quickly with the supplied fix and pushed out. This allowsr developers to stay focused on innovation while ensuring the longevity of the robotics hardware.

    It remains unclear where the onus lies for IoT security, with nobody holding anyone else to account. Market constraints often prevent device makers from putting more budget than what is necessary into design security, when there is so much pressure to innovate ahead of competitors.

    These issues need to be solved. Robotics has too much potential to let security concerns stunt their growth.

    — Tom Canning

  • Building a Services and IoT Platform with DevOps, Part 3

    Building a Services and IoT Platform with DevOps, Part 3

    Business needs and IoT demands are taking new dimensions in connecting millions of devices, people, process, tools and systems. With endless possibilities of creating new IoT solutions, DevOps teams are the key players who handle the challenges in successfully rolling out a IoT solution while handling the business, development, operations and infrastructure demands in the background. This article focuses on some of the DevOps best practices to adopt during IoT development, enabling faster time to market.

    DevOps practices to adopt during IoT development

    1. Adopt Security by design – Teams need to be educated and made aware of security threats. Use threat models mitigation techniques such as using authentication; storing secrets separately and protecting those secrets; using tamper-resistant protocols, digital signatures, timestamps, audit trails, encryption, authorization policies, filtering; and running services with least privileges during security design and development.
    2. Shift left security analysis and security testing – Integrate security analysis tools, customize security compliance rules and run security testing as part of continuous integration pipeline, generate security threat reports on vulnerabilities and act on these threat reports to fix issues early in the development phase and minimize the security risks.
    3. Follow security standards during development such as security development life cycle (SDL), which has guidelines and measures for building the software for devices and application components of IoT platform.
    4. Perform code reviews for device software, application software, PaaS rules and configurations, as quality assurance can become a huge risk given the complexity of the infrastructure, millions of devices connecting and dynamic environment configurations. Code review tools need to be integrated to the CI pipeline with pull request code review.
    5. Use the right branching policies in a version control repository, including precommit/preflight builds, pull requests for merging the code changes and access control for maintaining branches and using the right branching strategies, as there will be multiple fragmented development and deployment pipelines for devices and application developments to reduce the overhead. Use distributed repository/central repository with traceability and auditability based on the requirements.
    6. Automate deployments and create deployment pipelines for device development, application development, infra-automation scripts development with build and deployment pipelines targeting for different target endpoints.
    7. Customize the builds and release pipelines to pull the packages from multiple build and deployment pipelines to integrate and deploy as units of deployment.
    8. Plan for frequent release cadences—say, monthly—for application rollouts. Release cadences for firmware update rollouts can be planned for three to six months, as device updates cannot be pushed so often.
    9. Continuously monitor deployments – Use a release management tool for orchestrating the releases and release coordination activities, with gated checks and approvals with a view of what is getting deployed to each environment, as well as traceability and audit.
    10. Enable feedback loops and automated alerts if firmware deployments or application updates fail.
    11. DevOps teams can define key tenets, criteria to be met and standards to be followed for the devices; infrastructure to be provisioned; device protocols usage and standards in connecting to existing/new devices and services. This can reduce the complexity in development and deploying to multiple varied devices by following the same protocols for connectivity and communication.
    12. Train the team of developers, QA and hardware developers on how to do continuous integration for IoT development, follow agile and lean practices and ensure security criteria for all layers of the application and in process.
    13. Adopt user-centric test automation and end-to-end testing approaches and build robust test cases in perspective of testing a complete flow, with devices/services that may not be in your scope but will be part of your overall IoT platform ecosystem.
    14. Create/utilize container based test environments and device simulators coupled with service virtualization for functional testing.
    15. Automated infrastructure provisioning – Use the right configuration management tools to automate the infrastructure along with dependencies to create environments through code instead of provisioning basic VMs.
    16. Use container and cluster management tools such as Docker Swarm or Kubernetes for service discovery, auto-scaling, self-healing and scheduling.
    17. Use RBAC, service accounts and security access controls in the infrastructure templates/scripts that are created instead of individual user credentials to limit the risk of unauthorized users provisioning the environments using scripts. Build security in devices, cloud security, application security and infrastructure automation templates. Use secrets, key vaults, encryption methods and certificates to secure the credentials and access control.
    18. Configure individual build and deployment pipeline jobs for application development and infra-automation development, as there will be a huge development effort involved in automating the infrastructure.
    19. Create infrastructure verification tests with scripting tools such as Python or use testing frameworks such as Pester or any other open-source tools and integrate the infrastructure tests with the CI/CD pipeline. Ensure to run these tests every time the infrastructure is provisioned.
    20. Version-control the infrastructure templates, scripts, user profiles, environment configurations and device configurations apart from source code.
    21. Set up a centralized dashboard of monitoring tools to monitor the clusters, nodes, firewall rules, VMs, applications, devices and services. Feedback should flow back to developers/QA/DevOps teams.
    22. Configure applications to provide logging about exceptions, memory leakages and response times and push the logs to the monitoring tools or the dashboards in monitoring tools.
    23. Use the telemetry from the applications and devices to derive the analytics graphs/trends and set up KPIs/metrics to measure application performance/availability, as well from derive business metrics to set SLAs for DevOps and operations, to improve productivity.
    24. Ensure DevOps teams have close coordination with dev/QA teams of both software and hardware teams, as managing IoT platforms need more skill and expertise in hardware and software in the IoT domain.
    25. Manage legacy and cloud infrastructure with multicloud management platforms, and monitor and optimize the infrastructure usage.
    26. Create a DevOps governance plan/guide, with clearly defined access control policies, access rights for devices, control limits on infrastructure provisioning in different clouds, limits on PaaS/IaaS services to be used, etc., and standardize the process to be followed in DevOps/development/testing/operations, tools, etc.

    Following DevOps practices for application development has become quite streamlined in recent years. However, in IoT, where traditional methodologies and practices are followed in industrial enterprises, adapting to agile methodologies and following DevOps practices coupled with right DevOps-skilled team, tools and expertise can streamline and simplify IoT developments.

    About the Author / Lavanya Subbarayalu

    Lavanya Subbarayalu is Senior Architect working with Technology Office in HCL Technologies. She has expertise in IOT, Azure, DevOps consulting & Microsoft technologies. She is associated with DevOps COE, working on design and Development of DevOps solutions and consulting tools. Connect with her on LinkedIn.

  • Government Legislation Aims to Secure IoT

    Government Legislation Aims to Secure IoT

    The U.S. Senate is making moves to protect consumer interests, data, and privacy with regard to the internet of things (IoT). Sens. Mark R. Warner (D-VA) and Cory Gardner (R-CO), co-chairs of the Senate Cybersecurity Caucus, along with Sens. Ron Wyden (D-WA) and Steve Daines (R-MT), recently introduced bipartisan legislation called the Internet of Things Cybersecurity Improvement Act of 2017.

     

    Addressing IoT Market Failures

    According to a fact sheet released by the senators, “While ‘Internet of Things’ (IoT) devices and the data they transmit present enormous benefits to consumers, the relative insecurity of many devices presents enormous challenges. This legislation is aimed at addressing the market failure by establishing minimum security requirements for federal procurements of connected devices.”

    The proposed legislation drives home a new reality for IoT device manufacturers: While development organizations currently decide to invest in cybersecurity using a cost-benefit assessment, they are ultimately liable for the security of their data and systems.

    The U.S. Senate’s Proposal

    The proposed legislation requires vendor commitments:

    • To ensure devices don’t contain known security vulnerabilities when shipped.
    • To ensure proper disclosure of new security vulnerabilities discovered within their devices.
    • To prepare remediation plans for any IoT device where known vulnerabilities have been discovered.

    The Internet of Things Cybersecurity Improvement Act of 2017 is tied directly to federal government procurement of such devices but Sonatype predicts they likely will extend into private-sector guidelines moving forward. While the legislation is clearly aimed at consumer protections and privacy, it also focuses on quality, safety and regulatory standards applied to every other major manufacturing industry (“Thou shall not ship products with known defects“). It’s commonsensical in other manufacturing industries, and now Congress is directing development organizations to apply similar quality standards for the software it develops and ships.

    Certify IoT Devices are Free from Known Security Vulnerabilities

    The legislation specifically calls for vendors selling IoT devices “to provide written certification that the device does not contain, at the time of submitting the proposal, any hardware, software, or firmware component with any known security vulnerabilities or defects.”

    Notification When New IoT Vulnerabilities are Discovered

    Following the purchase of any IoT devices, the government wants the seller “providing the Internet-connected device software or firmware component to notify the purchasing agency of any known security vulnerabilities or defects subsequently disclosed to the vendor by a security researcher or of which the vendor otherwise becomes aware for the duration of the contract.”

    Ensure Remediation Paths are Available

    Protections go even further in the post-sale period, calling for clear remediation paths. The proposed legislation would require “any future security vulnerability or defect in any part of the software or firmware [of the IoT device] to be patched in order to fix or re-move a vulnerability or defect in the software or firmware component in a properly authenticated and secure manner.”

    20 Vulnerabilities Per Application

    Recently, Sonatype released its “2017 State of the Software Supply Chain” report that shares empirical evidence of the number of known software vulnerabilities that ship in applications—IoT or otherwise. The report found that development organizations building software with unmanaged software supply chains release applications with an average of 20 known security vulnerabilities, six of which had a Common Vulnerability Scoring System (CVSS) rating between 7 and 10.

    Sonatype’s report also reveals how national governments, federal agencies and industry associations are taking action to help organizations improve open-source hygiene and application security practices. In the past year, new guidelines have been introduced from the White House, Federal Trade Commission, Department of Homeland Security, Department of Health and Human Services and the Department of Commerce to improve the quality, safety and security of software supply chains, related to IoT devices and any other application development efforts.

    The Tide Has Turned

    While the proposed legislation is still open for debate, there is clear evidence that those once ignorant or turning a blind eye to such cybersecurity issues are now paying attention—and they are preparing to make significant changes.

    The full text of the proposed legislation for the Internet of Things Cybersecurity Improvement Act of 2017 can be found here.

    — Derek E. Weeks