Iot devices are the new emerging world .. roughly 10 billion such devices are in our daily lives at this moment, and this number is expected to multiply quickly. What are these devices – look at your wrist, your home thermostat, your TV, your lighting, the HVAC at your office, the traffic (ground and air) systems, and billions of more internet connected sensors around the world.
IoT hacked, weaponized
Most recently, and publicly, an online journalist website was taken down with the use of commandeered consumer IoT devices (about 500,000). This was not hard, and can easily be replicated by anyone with about an extra 10 hours on their hands (and a bit of legal protection). The analysis linked below is rich and worth diving in, but I wanted to highlight a different view point:
- First, White Label risks, if you are branding a chip, gadget, component, software package, and such from another business – YOU must ensure the technology is up to your standard. Secure, high quality, safety to the user and an enjoyable experience. Liability risks would be interesting to explore, but beyond those costs …
- Second, customer experience ruined with your device / service. If you had a vulnerable piece of technology (because you didn’t vet it), and then every device you sold was suddenly rebooting, not working, ruining that vital NetFlix binge, etc …. how do you think consumers will react? Not a pleasant scene given how hard we each work to build beautiful customer experiences with our products.
- Finally, this problem won’t go away. Everyone of those vulnerable (500k!!!) devices will ALWAYS be vulnerable given that the weaknesses were hard coded (permanently written into the product), and cannot be changed. Not a fun recall process and with so low margin, how many will actually mandate it / be required to do so / who is looking over this fast and loose area of products?
- I firmly believe we can do better, must do better, and will either be be given the chance or mandated to do just that. How are others vetting these processes? How could all of these white label sourcing / procurement teams have caught this sooner? How complex would it have been to detect and validate? Given the amount of successful attacks on this single product, it seems quite easy to have accomplished. Tongue and cheek, I’d recommend my book that I wrote for my family, How Not To Be Hacked, as it highlights specifically NEVER to leave default passwords – but in this case, the vendor made them permanent.
Let’s do better together and make richer experiences. The only true solution to stopping these zombie IoT Devices will be for carriers to block them wholly on the wire, Internet-Bricking / Banishing them to an offline world.
The culprit behind the KrebsOnSecurity.com and OVH attacks is traced back to one white-box DVR manufacturer, China-based XiongMai Technologies. The company sells white-labeled DVRs, network video recorders and IP camera circuit boards and companion software to a large number of vendors who in turn use the technology in their own products, according to Flashpoint blog post on the DDoS attacks posted Friday.In the case of XiongMai Technologies, it made the fatal error of using a default username “root” and password “xc3511” combination on each of the 500,000 devices used in the DDoS attacks.
Source: When DVRs Attack: Post IoT Attack Analysis | Threatpost | The first stop for security news
What does it take to transform your application development from Waterfall to Agile to DevOps to CI/CD? A lot … but at some point, all of the gears, gadgets, widgets, and funding won’t make the possible happen without one thing. A culture to holding integrity – to the code, to the doing what you know is right. Simply put, leadership and air cover matter a whole lot in the beginning to change.
I love this quote below from Bharat Mediratta on how ultimately they made automated testing (ahem, Security, Integrity, Code Quality, Privacy, and Compliance) a mandate for everyone – no one could submit code that broke the application (pipeline).
What did they do precisely, what is that magic bullet?
They created a hard line: no changes would be accepted into GWS without accompanying automated tests. They set up a continuous build and religiously kept it passing
Source: The birth of the automated testing culture at Google
There is so much to learn and we can do it together – see Gene Kim’s current works the DevOps Handbook, and join his knowledge dropping newsletters to get more insights.
Thanks Gene for building our Tribe (Seth Godin would be proud),
Bruce is by far the most prolific writer and researcher in security. He states things as they are and frames challenges brilliantly. Please check out his site, bookmark it, and be sure to read the comments – they are shockingly worth your time. He recently posted about DDos and the profiling with an aim to perhaps, Take Down the Internet.
While that requires our attention, there is a call out on – what can we do? Well, I see one immediate takeaway as it applies to your business, safety, and ongoing prosperity … but first a quote from the article:
The attacks are also configured in such a way as to see what the company’s total defenses are. There are many different ways to launch a DDoS attack. The more attack vectors you employ simultaneously, the more different defenses the defender has to counter with. These companies are seeing more attacks using three or four different vectors. This means that the companies have to use everything they’ve got to defend themselves. They can’t hold anything back. They’re forced to demonstrate their defense capabilities for the attacker.
Source: Someone Is Learning How to Take Down the Internet – Schneier on Security
So if someone is employing multiple attack methods they are testing your defenses … that begs the question:
- Do you have your own internal threat intelligence shored up to be smart and effective in this area?
- Is fraud a risk and are you able to identify these risks from different angles?
- Are you data mining all of your logs (across the enterprise if you are so large) for such findings and nuggets of importance?
- Are you capturing the right data to conduct such an analysis – it requires a bit of deep integration across IT and your product teams AND your suppliers
So much can be managed with a bit of insight and action … please help keep our Internet operational, pleasant, and your business available.
On demand free security tool that can integrate with your application pipeline or simply post deploy. I am big into finding the highest efficiency methods, and why not augment your brilliant human security experts with this tool to get a head start?!
Many others and this addresses a specific aspect of risk, but heck this is an active project and worth considering in your larger application development security strategy!
The OWASP Zed Attack Proxy (ZAP) is one of the world’s most popular free security tools and is actively maintained by hundreds of international volunteers*. It can help you automatically find security vulnerabilities in your web applications while you are developing and testing your applications. Its also a great tool for experienced pentesters to use for manual security testing.
Source: OWASP Zed Attack Proxy Project – OWASP
One exciting area I have been digging into is the mixing of risk management and application portfolio development. As we see greater and greater abstraction of services (software eating world), we also have an ever increasing dependency on a multitude of developers, service providers, start-ups, legacy tech companies, and many other institutions.
If you are in application development and list of the pipeline deployment technology and all of the interacting systems, you’ll easily list out 30+. Each of these have the potential of impacting your business, your customer experience, and ultimately your viability as a product.
I found this third party risk management point of view to be insightful (full transparency, I work for this firm), and recommend a review from the application perspective. It is dated, but insightful. I particularly like the risk stratification highlights on page 7 that include:
- Volume of transactions
- Concentration associated with service
- Sensitivity risk of the data vendor has access
- Compliance & regulatory risks
- Customer & financial impact
- Location of vendor (privacy impacts)
- Previous data or security breaches
- Extent of outsourcing performed
- Performance history
Read more here
Deep diving on how risk strategies apply to the DevOps, IoT, and Cloud environment of product spaces these days. Mitre always has been a favorite of our industry and a valuable reference. The core methods we developed can be re-applied with a bit of customization and reflection. I wanted to highlight the monitoring aspect from the article linked here, as it is sometimes more insightful to see where you want to be and work backwards. Here you can create a new framework that eliminates prior biases from other fields, while leveraging proven processes and methodologies.
Include risk monitoring as part of the program review and manage continuously. Monitoring risks should be a standard part of program reviews. At the same time, risks should be managed continuously rather than just before a program review. Routinely review plans in management meetings.
Review and track risk mitigation actions for progress. Determine when each action is expected to be completed successfully.
Refine and redefine strategies and action steps as needed.
Revisit risk analysis as plans and actions are successfully completed. Are the risks burning down? Evaluate impact to program critical path.
Routinely reassess the program’s risk exposure. Evaluate the current environment for new risks or modification to existing risks.
Source: Risk Mitigation Planning, Implementation, and Progress Monitoring | The MITRE Corporation
There is every indication that this attack was launched with the help of a botnet that has enslaved a large number of hacked so-called “Internet of Things,” (IoT) devices — mainly routers, IP cameras and digital video recorders (DVRs) that are exposed to the Internet and protected with weak or hard-coded passwords.
Krebs site was brought down with a Denial of Service attack that was 2x larger than any ever done before (approximately). As highlighted above, the majority of this was executed leveraging IoT devices that were sold and or setup insecurely. I am not pointing fingers here, but this if anything must be a clear call to action to all of us in the consumer business to address these massive cybersecurity concerns at their inception (within the product development cycles and the core components (Raspberry Pi I am looking at you .. open source libraries, you too). Note most of those devices are on the consumer end of the “who is responsible for updating, patching, securing, and cleaning up” ownership spectrum.
We are developing and deploying code at scale and currently there are 10 BILLION Internet connected devices (IoT), and this is only going to radically increase. Now is our chance to protect the stability of our connected world, ensure the safety of our families, and maintain the integrity of our life dependent services.
Curious … on the IoT scale problem? Check out this fun Infographic from Verizon chock full of stats across industries. This is not F.U.D., but a challenge for us to ensure the platforms we are creating can be sustained, and those associated freedoms – such as Krebs excellent work, can persevere.
Source: The Democratization of Censorship — Krebs on Security