Безопасность ИВ - вопросов всё больше (РусКрипто 2016)
•Download as PPTX, PDF•
1 like•198 views
... а потом грянул MIRAI
Recommended
Recommended
More Related Content
What's hot
What's hot (15)
Similar to Безопасность ИВ - вопросов всё больше (РусКрипто 2016)
Similar to Безопасность ИВ - вопросов всё больше (РусКрипто 2016) (20)
More from Alexey Kachalin
More from Alexey Kachalin (20)
Безопасность ИВ - вопросов всё больше (РусКрипто 2016)
- 1. 1 1 ptsecurity.comptsecurity.com Качалин А.И. "Безопасность IoT: чем выше ожидания - тем больше вопросов"
- 2. 2 2 ptsecurity.com 2 Безопасность ИВ – интересная тема • Моделирование атак на автомобильную бортовую сеть и дорожную инфраструктуру • Анализ угроз ИВ (РусКрипто) • Прогноз возможных сценариев атак на ИВ ( PHDays) • ИБ ИВ (РусКрипто)
- 3. 3 3 ptsecurity.com 3 ИВ – что есть, что будет? • Взрывной рост «объемов» • 6,5 миллиардов устройств в 2016 (+30% за год) • 21 миллиард устройств в 2020 • Прогнозируемость технологического развития? • Интеграция в существующие ИТ • Концепция «Операционных Технологий» • Рост и эволюция (параллельно с ростом объемов) • Развитие экосистемы и стандартов • Новые бизнес-модели – потребность в новых типах устройств, высокая динамика
- 4. 4 4 ptsecurity.com 4 (Без)опасная архитектура ИВ Как может быть построена и проанализирована модель угроз с учетом ИВ? Точки рассмотрение ИБ: • С т.з. «вещей» • С т.з. ИВ-шлюзов • Маршрутизаторов • Смартфонов • С т.з. Облака? • С т.з. Корпоративного сегмента
- 5. 5 5 ptsecurity.com 5 Архитектурные проблемы ИВ • Метаданные • Объем хранилища и место хранения данных • Форматы и структуры хранения данных – соответствующие задачам • Процедуры внесения и обработки данных превносимых устройств • Гибкие процедуры интеграции и трансформации данных • Требование к качеству данных: доверие и контроль • Конфиденциальность данных • Масштабируемость, эластичность • Физическая распределенность и перемещение устройств
- 6. 6 6 ptsecurity.com 6 Типы устройств ИВ: «палка о более чем двух концах» • Функциональность устройств ИВ • Класс 1: Простые сенсоры, приводы • Класс 2: с возможностью хранения и первичного анализа данных • Класс 3: Сложные устройства (близки к полноценным серверам) • По возможности взаимодействия с физическим миром • Устройства сбора данных (сенсоры) • Устройства воздействия (приводы) • Устройства вывода данных (дисплеи) • Устройства, совмещающие функции сбора и вывод данных
- 7. 7 7 ptsecurity.com 7 ИБ-Прогноз погоды: весна ИВ • Ещё более* ускоренные и небезопасные практики разработки • Дополнительные* сложности в обновлении • Меньшая* видимость аномалий для пользователя • Больше* объектов защиты/для атаки ---------------------------------------------------- Временное окно уязвимости – в 1,5-2 раза больше * По сравнению с тем как плохо сейчас «классическим» ИТ
- 8. 8 8 ptsecurity.com Безопасность ИВ – как 20 лет назад в «большом ИТ» • Сеть • Приложения • Мобильные устройства • Облака + ----------------------- ИВ Примеры ИБ неуспехов ИВ • 10/10 security systems accept ‘123456’ • 10/10 security systems with no lockout • 10/10 security systems with enumeration • SSH listeners with root/“” access • 6/10 web interfaces with XSS/SQLi • 70% of devices not using encryption • 8/10 collected personal information • 9/10 had no two-factor options • Unauthenticated video streaming • Completely flawed software update systems https://www.rsaconference.com
- 9. 9 9 ptsecurity.com 9 ИВолюция атак • Атаки на процедуры работы экосистемы: процедура утраты контроля над устройством и блокирование акаунта • Открытость физическому доступу: сброс в небезопасное состояние • «Вещь посередине»: не только прослушивание, но и «выполнение действий» • Запрет ухода в ждущий (энергосберегающий) режим
- 10. 10 10 ptsecurity.com Поверхности атак ИВ • Экосистема • Обмены в экосистеме • Память устройства • Физические интерфейсы • Веб-интерфейсы • Прошивка • Сетевые сервисы • Интерфейс администратора • Локальное хранилище данных • Веб-интерфейс доступа к облаку • Интерфейс подключения сторонних компонентов • Механизмы обновления • Мобильное приложение • API доступа вендора • Сетевой трафик • Аутентификация/Авторизация • Конфиденциальность/приватност ь • Аппаратные манипуляции(сенсоры)
- 12. 12 12 ptsecurity.com 12 Время ИВ: что на в твоих часах? • Данные: почта, соц.сети, смс, звонки • Информация о владельце: пульс, перемещения • Возможность доступа • К мобильному устройству • В Интернет (WiFi) и учетные данные • Прошивка и приложения • Данные приложений • Средства аудио-, видео- записи
- 13. 13 13 ptsecurity.com 13 А что авто? Гонка продолжается Прогнозируемые угрозы: атаки на бортовую сеть (мультимедиа) и взаимодействие с дорожной инфраструктурой Превентивные меры: невозможность доступа к контуру управления Развитие и усложнение бортовой сети автомобиля Демонстрация возможности полного контроля над бортовой сетью автомобиля через технологическое подключение Демонстрация возможности удаленного доступа для управления мультимедиа и функциями управления Запрет входящего трафика Отзыв 1млн автомобилей на обновление программных и аппаратных компонентов Демонстрация возможности исполнения кода через аудио-диск (уязвимость в проигрывателе) Обход запрета входящего трафика
- 14. 14 14 ptsecurity.com 14 Зачем угонять один автомобиль, если можно угнать целый корабль автомобилей? HITB Con: DR. MARCO BALDUZZI, KYLE WILHOIT, ALESSANDRO PASTA: Hey Captain, Where’s Your Ship? Attacking Vessel Tracking Systems for Fun and Profit • Изменение всех характеристик корабля: позиция, груз, название • Создание несуществующих кораблей: «иранский корабль с ядерным грузом у берегов США» • Создание подложных навигационных объектов (буйков, маяков) • Задание ложных регионов спасательных операций • Вброс ситуации «человек за бортом» - тревога в радиусе 50км • Подложный прогноз погоды
- 15. 15 15 ptsecurity.com 15 Открытые вопросы ИБ ИВ • Бурное развитие технологий • Проблемы совокупности технологий • Возвращение старых проблем • Проблемы масштабов, разнородности и мобильности устройств • Неизвестный ландшафт угроз, уязвимостей, атак • Проблематичность • Скорость разработки решений ИВ • Проклятие минимально-жизнеспособного продукта (MVP)
Editor's Notes
- Информационная безопасность IoT обсуждается уже не первый год (да и не первое десятилетие – начиная с безопасности подключенных к Интернет кофеварок в 90-х). Сейчас одновременно происходит два процесса: увеличение многообразия устройств (и их совместное использование) и свойственное сегменту потребительской электроники ускорение разработки и повторное использование компонентов. Сложившаяся ситуация порождает широкие возможности для атакующего по целям и возможностям осуществления атак. В докладе будет представлен обзор трендов развития IoT в части разработки и использования и, как следствие – дополнительные проблемы информационной безопасности, о которых скоро предстоит беспокоиться в рабочей и личной жизни. Качалин Алексей, Руководитель Expert Security Center, PT
- Describe — Capabilities to Understand Meaning and Usage of Information Assets Implication 1. Metadata Metadata is critical to ensuring proper use, governance and value from information assets; and getting complete metadata on all information assets involved in IoT solutions will present challenges. In IoT environments, metadata representing data lineage (sources, flow, usage and so on) will become increasingly difficult to collect and represent, given the highly complex and distributed architectures that many IoT solutions exhibit. Metadata can be held in the "things" themselves, making a completely centralized approach to metadata management impractical or unnecessary. In addition, capturing metadata about new data types (sensor, device and machine data) becomes challenging when schemas and other artifacts may not be readily available or understood by existing metadata-related tooling. Organizations will be challenged to discern how to map from the metadata models representing new data types in the IoT space, to existing IT systems. This will be critical for linking IoT platforms and other IoT technology components to applications used for performance management, operational processes and other business activities that must adapt to behavior in the IoT. In addition, collection of metadata about access, usage and behavior with IoT information assets will be critical to ensuring the enactment of proper information governance. Master data management capabilities interjected into IoT solutions will be valuable in ensuring a clear linkage between, and understanding of, relationships across IoT data and traditional data sources (see "Mastering The "Things" In The Internet of Things"). Action Items: ■ Review existing metadata management strategy and tools; identify available metadata sources representing the breadth of information assets in IoT solutions; develop plans to fill gaps (manually, for example); and use metadata accessibility as an evaluation criteria for IoT platform and solution providers. ■ Consider where and how to maintain the metadata, including scenarios such as distributed storage of metadata to compensate for offline devices. Organize — Capabilities to Suitably Structure and Position Organize — Capabilities to Suitably Structure and Position Information Assets Implication 2. Storage Capacity and Location With the volumes of data generated by IoT solutions, existing storage capacity can be quickly overwhelmed. A limited ability to cost-effectively scale existing storage approaches will create a bottleneck. In addition, with the highly distributed architectures required for most IoT solutions (many things, many places where data is generated, many platforms on which data is processed, and many consumption points to which data must be delivered), the historical approach to centralized collection of data is under pressure. Organizations must support a more distributed data architecture, because IoT solutions are inherently distributed; they must also apply more proactive approaches to determining what data to keep, and where (rather than assuming everything must be persisted). The nature of the IoT solution architecture (thing-centric, mobile-centric, gatewaycentric, cloud-centric, or enterprise-centric — see "Build Your Blueprint for the Internet of Things, Based on Five Architecture Styles") will increasingly drive the choice of storage locations. Action Items: ■ Rethink information architecture with a reduced focus on centralized repositories and increased openness to distributed architectures. Implication 3. Data Persistence Format and Structure While demand for alternative data persistence formats and structures — beyond the capabilities of traditional relational database management systems — has been growing as a result of all big data activity, the IoT will bring requirements to yet another level. The volume and pace of inserts resulting from IoT-generated activity (particularly in heavy industrial solutions where thousands of sensor readings per second must be captured, or consumer-related solutions where millions of individuals using "things" are constantly generating data) can create performance bottlenecks and latencies for traditional persistence approaches. Newer persistence mechanisms (such as Hadoop and NoSQL DBMS) or specialized data stores supporting spatial and time-series data may be required in order to handle the pace and volume of IoT data — as well as the widely varying (and sometimes unknown) structure driving schema-on-read scenarios (see "DBMS Characteristics for the Internet of Things"). Action Items: ■ In database/DBMS modernization activities, consider the role and importance of Hadoop and NoSQL approaches to data persistence in order to meet scale and diversity requirements. ■ Ensure vendors offering IoT solutions or IoT-related technology components have made suitable choices of persistence technology that can handle the scale of planned IoT solutions. Integrate and Share — Capabilities to Ingest, Combine, Transform and Provision Information Assets Implication 4. Data Ingestion The simple concept of capturing streams of data generated by things will create challenges for the current integration capabilities most organizations have in place. Both the "always on" nature of some IoT data sources (for example, sensors on manufacturing equipment running 24/7) and the unpredictable availability of others (such as the periodically connected sensors on various consumer devices) create a different paradigm. Traditional data integration tools and architecture are not suited to handling environments with such widely varying and unpredictable SLAs, and may therefore increase the risk of event or message loss. Action Items: ■ Identify new sources of data required for IoT solutions and classify them as to their temporal nature (streaming, event-oriented, occasional, for example). ■ Review data integration infrastructure and tooling to identify gaps in supporting the various latency types, in particular for streaming ingestion Implication 5. Data Integration and Transformation The repertoire of data integration paradigms must expand to include real-time and event-driven (variable latency) support. Capabilities for event processing, to parse the streams of IoT data being ingested and filter for events and patterns of interest, must become a core competency of the integration infrastructure. In addition, IoT will require expansion of integration capabilities to be able to transform and combine diverse data types of both streaming and bulk/static nature — joining traditional structured data with data of a less-structured or complex-structured variety (for example, the time-series data commonly captured in the operational technology environments prevalent in industrial IoT solutions; see "Data Integration Architectures for Synergies Between IT Systems and Operational Technologies"). These are not capabilities inherent in the data integration designs and architectures residing at the center of most current information infrastructures. The real value of IoT data will be realized when it is combined with other data to provide richer analytic insight, cause an action to occur or amplify the value of other information assets. Action Items: ■ Classify IoT data sources by degrees of structure, and identify sources that fall outside the range of transformation and aggregation capabilities in the infrastructure currently in place. ■ Seek to add capabilities for complex-event processing (CEP) embedded within data integration architectures, in order to support identification of key events and correlation of data points across streams and other source types. Implication 6. Data Movement and Delivery IoT solutions depend on seamless, rapid and reliable flows of information across all the extended components of an IoT architecture. IoT solutions will have to deal with scenarios where events are lost or missing (due to device failures) or, potentially, duplicated. Information leaders working on IoT initiatives must determine how data will move from thing, to gateway, to cloud, to enterprise application and beyond. This will require support for multiple communication protocols and formats. Existing bulk-batch-oriented infrastructure supporting current analytic needs will not be suitable for the lower- and variable-latency nature of many IoT solutions (for example, collection of data from consumer wearable devices that are not always in an active mode), and must now be extended to deal with data in a streaming and event-driven fashion. In addition to handling data with variable latency requirements, data integration architectures and tools must adapt to new interface types and APIs (for sourcing data from devices and gateways and enabling sharing of data between them). ■ Start to build knowledge of emerging IoT-related standards for APIs and connectivity, as well as common data formats and semantics existing in early IoT platforms and solutions. ■ Evaluate data integration technology providers based on their alignment with relevant standards, knowledge of IoT concepts and trends, and plans to include IoT-related capabilities. Implication 7. Data Quality With data being generated by many things, and those things being (or attached to) increasingly critical physical assets or even people (for example, connected healthcare devices), making sure the data is trustworthy in the context of usage is paramount to accurate condition monitoring, managing performance and monetization of IoT data itself. Most enterprises have taken a reactive or tactical approach to monitoring and controlling data quality in traditional environments, and such approaches will be ineffective for IoT. Identifying and compensating for gaps in data or corrupted data (from faulty devices), and tracking trends in data quality levels across streams of data will be required. Data quality capabilities in place in current infrastructures are often focused on data "at rest" (in databases) or at entry points in traditional IT systems. Action Items: ■ Identify quality levels required for specific IoT data sources and use cases, and common or expected types of data quality flaws. ■ Evaluate approaches for embedding data quality controls into ingestion processes (for example, using CEP technology to identify patterns of low quality in data streams), as close as possible to the point of data creation. Implication 8. Data Privacy and Security Privacy and security of IoT data were the top inhibitors cited by respondents in a recent Gartner survey of organizations exploring IoT solutions (see Figure 2). Consumer-oriented IoT solutions (for example, connected homes and vehicles) will often collect and process data about behavior, lifestyle, location, health and other personal attributes. Privacy and security of such data must be a paramount consideration in IoT solutions. Capabilities for tracking, encryption and access control to sensitive data must be built into the information infrastructure at all points where IoT data is generated, stored, processed and delivered (driven by well-formed information governance policies). Likewise, industrial IoT solutions, while not likely to be dealing with sensitive personal data, must include strong data security (see "What Securing the Internet of Things Means for CISOs") — in order to avoid downtime or failure of critical infrastructure and processes, which could potentially lead to massive costs or loss of life (for example, in industries such as transportation, Scale and Distribution: Enabling the Information Infrastructure to Cope With IoT Demands In addition to the common capabilities categories, the IoT poses two additional key challenges for information leaders in deploying and managing an effective information infrastructure that can operate at the magnitudes of complexity and scope that IoT solutions will demand. IoT use cases drive new SLAs for scale and distribution. While the ICF is not use-case-specific, the information infrastructure needs to be adapted to meet this new range of SLAs. Implication 9. Scale IoT means "more," in a variety of different directions. This includes massive growth in data volumes under management, the number of endpoints ("things" in IoT solutions) that must be tracked and connected, and higher pace of data flow across those endpoints and the rest of the infrastructure. Many current information infrastructures lack the processing capacity and flexible capabilities to grow across the scope of environments that IoT solutions will bring. They will require substantial investment in computing capacity and/or a shift toward more modern technologies (such as NoSQL for data persistence) in order to scale to the levels required for the IoT. Action Items: ■ Consider the role of elastically scalable computing infrastructure, such as cloud computing, to support the critical capabilities of the information infrastructure. ■ Review processes for the operation and administration of information Implication 10. Distribution Not only will data in IoT solutions be spread across devices, gateways and repositories in the cloud and on-premises, but the processing of that data may happen in any and all of those same locations — many devices will be powerful enough to perform sophisticated computation on the data they generate and/or have the need to house and process data locally for autonomous behavior. Information infrastructure capabilities must be adept at managing many pieces of information spread over a wider and more diverse landscape of platforms than ever before. Ensuring reliable distribution and consistency of business rules applied to the data in all locations, then monitoring the execution of those business rules, adds additional layers of complexity. Action Items: ■ Embrace hybrid architectures — with data and processing on that data being located "on device" — in IoT platforms and in traditional on-premises and cloud-based environments. ■ Plan for disaggregation and resiliency of workloads that can be broken into components and run anywhere. ■ Focus on monitoring and manageability — IoT architectures will be the opposite of monolithic, and this increases the challenges of monitoring
- https://www.owasp.org/index.php/OWASP_Internet_of_Things_Top_Ten_Project#tab=IoT_Attack_Surface_Areas
- http://www.trendmicro.com/vinfo/us/security/news/internet-of-things/carjacking-by-cd-research-shows-how-spiked-song-can-hack-a-car
- http://blog.trendmicro.com/trendlabs-security-intelligence/vulnerabilities-discovered-in-global-vessel-tracking-systems/
- “Internet of Things” security is hilariously broken and getting worse Shodan search engine is only the latest reminder of why we need to fix IoT security. by (UK) - Jan 23, 2016 6:30pm AST Shodan, a search engine for the Internet of Things (IoT), recently launched a new section that lets users easily browse vulnerable webcams. The feed includes images of marijuana plantations, back rooms of banks, children, kitchens, living rooms, garages, front gardens, back gardens, ski slopes, swimming pools, colleges and schools, laboratories, and cash register cameras in retail stores, according to Dan Tentler, a security researcher who has spent several years investigating webcam security. "It's all over the place," he told Ars Technica UK. "Practically everything you can think of." We did a quick search and turned up some alarming results: A sleeping baby in Canada Expand gallery to full size The cameras are vulnerable because they use the Real Time Streaming Protocol (RTSP, port 554) to share video but have no password authentication in place. The image feed is available to paid Shodan members at images.shodan.io. Free Shodan accounts can also search using the filter port:554 has_screenshot:true. Shodan crawls the Internet at random looking for IP addresses with open ports. If an open port lacks authentication and streams a video feed, the new script takes a snap and moves on. While the privacy implications here are obvious, Shodan’s new image feed also highlights the pathetic state of IoT security, and raises questions about what we are going to do to fix the problem. Of course insecure webcams are not exactly a new thing. The last several years have seen report after report after report hammer home the point. In 2013, the FTC sanctioned webcam manufacturer TRENDnet for exposing “the private lives of hundreds of consumers to public viewing on the Internet.” Tentler told Ars he estimates there are now millions of such insecure webcams connected and easily discoverable with Shodan. That number will only continue to grow. So why are things getting worse and not better? The curse of the minimum viable product Tentler told Ars that webcam manufacturers are in a race to bottom. Consumers do not perceive value in security and privacy. As a rule, many have not shown a willingness to pay for such things. As a result, webcam manufacturers slash costs to maximize their profit, often on narrow margins. Many webcams now sell for as little as £15 or $20. "The consumers are saying 'we're not supposed to know anything about this stuff [cybersecurity]," he said. "The vendors don't want to lift a finger to help users because it costs them money." Further Reading Police body cams found pre-installed with notorious Conficker worm One of the world's most prolific pieces of malware is found in cams from Martel. If consumers were making an informed decision and that informed decision affected no one but themselves, perhaps we could let the matter rest. But neither of those conditions are true. Most consumers fail to appreciate the consequences of purchasing insecure IoT devices. Worse, such a quantity of insecure devices makes the Internet less secure for everyone. What botnet will use vulnerable webcams to launch DDoS attacks? What malware will use insecure webcams to infect smart homes? When 2008-era malware like Conficker.B affects police body cams in 2015, it threatens not just the reliability of recorded police activity but also serves as a transmission vector to attack other devices. "The bigger picture here is not just personal privacy, but the security of IoT devices," security researcher Scott Erven told Ars Technica UK. "As we expand that connectivity, when we get into systems that affect public safety and human life—medical devices, the automotive space, critical infrastructure—the consequences of failure are higher than something as shocking as a Shodan webcam peering into the baby's crib." Admiring the problem is easy. Finding solutions is harder. For his part, Tentler is sceptical that raising consumer awareness will be enough to solve the problem. Despite tons of press harping on about the privacy implications of webcams, it’s pretty clear, according to Tentler, that just telling people to care more about security isn’t going to make a difference. Instead, he argues it's time to start arm-twisting vendors to release more secure products. FTC to the rescue? When it comes to strong-arming manufacturers, government entities like the US Federal Trade Commission (FTC) may be able to help. Ars UK spoke with Maneesha Mithal, associate director of the FTC’s division of privacy and identity protection, and she was quick to mention several examples where the organization went after at-fault companies. In recent years according to Mithal, the FTC has prosecuted more than 50 cases against companies that did not reasonably secure their networks, products, or services. The FTC takes action against companies engaged in deceptive or unfair business practices, she explained. That includes IoT manufacturers who fail to take reasonable measures to secure their devices. “The message from our enforcement actions is that companies can’t rush to get their products to market at the expense of security,” she said. “If you don’t have reasonable security then that could be a violation of the FTC Act.” In addition to the precedent-setting enforcement action against TRENDnet, the FTC also issued security best practices for IoT manufacturers back in January 2015, urging them to bake in security at the design phase rather than bolting it on as an afterthought. Vendors should train their employees in security best practices, the FTC said. Such practices could be a "defence-in-depth" strategy to mitigate risks, pushing security patches to connected devices for the duration of the product life cycle, and so forth. This is all sensible, top-notch security advice. The FTC even followed up with an official guidance document in June and a series of workshops for businesses on improving their security posture. Erven told us that these new guidance documents are a warning to businesses to improve—or else. "The thing that really does come next after guidance is regulation, if they don't pick up their game and implement [the official security guidance]." It may already be too late to avoid regulation. Mithal told Ars that the FTC has asked Congress for federal data security legislation that would give the commission the authority to seek civil penalties for companies that don’t implement reasonable security. Rather than mandate highly prescriptive, technology-specific legislation (for instance, “you must use this firewall and that kind of encryption”), the FTC seeks a process-based approach that will remain valid even as technology continues to advance. A Which? for IoT security Many people we spoke to for this story were leery of too much regulation since it could discourage further innovation in the IoT space. But as an alternative, could a Which? (UK) or Consumer Reports (US)-style rating system help IoT manufacturers solve the problem without regulation? One such solution would be for a trusted industry or government body to rate the security of devices. This would help consumers make an informed decision about what products to buy in the same way that Euro NCAP or the US National Highway Transportation Safety Administration (NHTSA) uses a five-star safety rating for cars. You don't have to be an car engineer to make sense of a car safety rating. Why should you have to be a computer security expert to make sense of IoT security? "The solution has to be driven by customer awareness to security," Erven argued. "In order for an informed consumer to make a decision, they have to have an understanding of the security posture among devices." I Am The Cavalry, a group of concerned security researchers focused on critical infrastructure, is working on a five-star rating system for consumer IoT. The rating system will give consumers the "quick ability to check device security without having to understand the technical details." Security researcher Brian Knopf is leading I Am The Cavalry’s charge for a simple security and privacy rating system for IoT devices, which he hopes to release early in 2016. He shared with Ars some of the preliminary criteria that IATC will use to judge devices: Security Secure by Default No default passwords shared between devices, or weak out of the box passwords. All passwords should be randomly created using high quality random number generators. Advanced features used by small percentage of users should be turned off (VPN, Remote Administration, etc.). Secure by Design Firmware should be locked down so serial access is not available. Secure Element (SE) or Trusted Protection Modules (TPM) devices should be used to protect access to the firmware and hardware. All GPIO, UART, and JTAG interfaces on the hardware should be disabled for production versions. NAND or other memory/storage mediums should be protected with epoxy, ball sockets (so the memory cannot be removed and dumped), or other methods to prevent physical attacks. Self-contained security The devices should not rely on the network to provide security. Rather, the device's security model should assume the network is compromised and still maintain protection methods. This can be done with prompts to the users to accept handshakes between devices trying to access other devices on their networks. Communication between devices should be encrypted to prevent MitM attacks and sniffing/snooping. Privacy Consumer PII not shared with manufacturers or partners Usage data on individual consumer is never shared with partners or advertisers. Anonymous data for buckets of users on usage patterns is acceptable as long as it's proven to not be traceable back to the individual consumers. Data collection policy, type of data collected and usage of data is clearly documented on site. Vendors will be invited to submit their pre-production devices for testing, Knopf said, along with the star rating they are applying for. Researchers will then test the devices to ensure they meet the manufacturer’s claims. “The vendor would then receive a preliminary test report that they could respond to, either to fix items before production or accept the rating,” he explained. “The final report would then be posted online for any consumer to review, or security tester to validate.” Knopf said the program would not depend on the willing participation of manufacturers. Independent researchers would also be welcome to test off-the-shelf IoT devices against the criteria and post the results on the I Am The Cavalry website. This, he hopes, will encourage manufacturers to improve their products. Enter the Pentagon The US Air Force is funding a similar, unrelated initiative. Peiter “Mudge” Zatko is a member of the high-profile L0pht hacker group who testified before Congress in 1998, and since he's gone on to head cybersecurity research at the Defense Advanced Research Projects Agency (DARPA) before joining Google in 2013. In June, Zatko announced he was leaving the search giant to form a cybersecurity NGO modelled on Underwriters Laboratories. The new initiative, Cyber Independent Testing Laboratory (CITL), won a $499,935 (£350,000) contract from the US Air Force in September to create a “Consumer Security Reports,” according to a report by Inside Cybersecurity. Mudge declined to comment for this article, instead referring us to the interview with Inside Cybersecurity: “Our intention is to provide [consumers] with the information and tools they need, in a non-partisan fashion, and without profit incentives getting in the way of providing unbiased and quantified ratings of the software and systems they are purchasing,” Zatko said. “Think of this as a cybersecurity parallel to nutritional facts on food, energy star ratings on appliances, or vehicle information guides in the windows of new cars.” [...] “The IoT is a part of this environment,” he continued. “We will include analysis and comparative ratings, on the robustness and security in software, for IoT devices as well as more traditional operating systems, applications and services.” Mudge told Ars that "The procedures and methodologies will be made public in 2016. It includes firmware for IoT." Last week in an interview with the Council on Foreign Relations (CFR) blog, he identified four goals for CITL: Consumers having the ability to comparatively distinguish safe products from unsafe, secure from insecure; Pressure on developers to harden their products and engage in defensive development practices; The ability to quantify risk; and Take away low-hanging fruit, such as the more insecure product development practices, and thus begin to devalue parts of the exploit market. Mithal said the FTC was aware of the efforts by both I Am The Cavalry and CITL, and the group welcomed initiatives that educate consumers about security. “My concern,” she said, “would be that companies should bake in security whether consumers shop on that basis or not. The onus shouldn’t be on the consumer to figure this out.” But will these efforts stop attackers? Some combination of regulatory stick and rating system carrot seems likely to increase IoT security across the board. The Internet is a minefield of accidents and adversaries, and reducing opportunistic malware infection, like preventing Conficker.B infection of police body cams, is low-hanging fruit. But unlike the electrical appliances Underwriters Laboratories has traditionally tested for safety, or even Euro NCAP's safety ratings that have encouraged car makers to manufacture safer vehicles, both regulation and cybersecurity product ratings seem powerless to stop determined attackers. When Mudge announced his plan to form CITL back in June, security researcher Rob Graham went so far as to call the plan a “dumb idea”: It’s not the same quality problem UL is about accidental failures in electronics. CyberUL would be about intentional attacks against software. These are unrelated issues. Stopping accidental failures is a solved problem in many fields. Stopping attacks is something nobody has solved in any field. In other words, the UL model of accidents is totally unrelated to the cyber problem of attacks. Graham affirmed his critique in a Twitter direct message to Ars. “UL doesn’t test systems for somebody deliberately trying to attack them,” he wrote. He also argued that CITL “adds a lot of bureaucracy for little value.” Mitigating risk is not the same as eliminating it. But until someone figures out to deal with deliberate attacks, the problem of insecure IoT devices looks set to get worse before it gets better. Erven said it best: “Our dependence on technology is growing faster than our ability to secure it.” So buckle up, kids, we’re in for a bumpy IoT ride over the next few years. And while you're at it, put a password on that webcam in your kid's bedroom. No one wants to unexpectedly show up in search results. J.M. Porup is a freelance cybersecurity reporter who lives in Toronto. When he dies his epitaph will simply read "assume breach." You can find him on Twitter at @toholdaquill. This post originated on Ars Technica UK