Daily Archives: November 24, 2020

State of Software Security v11: Key Takeaways for Developers

We recently released volume 11 of our annual State of Software Security (SOSS) report, which analyzes the security activity and history of applications Veracode scanned during a one-year period. Giving us a view of the full lifecycle of applications, that data tells us which languages and vulnerabilities to keep an eye on, and how factors like scanning frequency can impact your remediation time.

This year???s report also explores the idea of nature vs. nurture when remediating flaws and improving security. In other words, which security factors do developers like you have control over, and which are completely out of your hands? You likely have no control over the size of your organization and even the size of your application (???nature???), but you can ???nurture??? factors like frequency and scanning via API to improve security efforts.

Read on for key takeaways from SOSS v11 and for more information on what you can do to give your application security (AppSec) a boost.

Using SAST through API improves remediation time

It should be no surprise that the right combination of tools and integrations with frequent scanning means more effective flaw remediation. Data from SOSS v11 backs that up; when running static analysis (SAST) scans through API, organizations can remediate flaws 17.5 days faster on average.

Remediate Faster???

Efforts like more frequent scanning, pairing dynamic analysis (DAST) with SAST, implementing a steady cadence, and using Software Composition Analysis (SCA) with SAST can help you remediate more vulnerabilities faster and keep your security in check. On the flip side, higher flaw density or a larger application greatly slows the remediation process by more than 50 days ??? especially for larger legacy, applications.

Information Leakage is the most common flaw??ヲ

??ヲwith CRLF injection, cryptographic issues, and code quality close behind. These four most common flaws didn???t change between last year???s report and this year???s report, which means they???re likely not going anywhere anytime soon and important to keep an eye on. ツ?

Common Flaws???

For developers, knowing the most common flaws is critical to understanding how they???re introduced, how to prevent them, and how to fix them quickly to ???nurture??? your situation. That???s especially important for the most high-risk vulnerabilities, such as Injection flaws like CRLF and SQL that reign supreme on the list of OWASP Top 10 Web Application Security Risks.

Open source creates an expanding attack surface

You work hard and you work fast. Projects don???t slow down or wait for you to write code from scratch, which is why so many developers like you rely on open source libraries and third-party code to speed up production. But there???s a problem: open source code, though used virtually everywhere, creates a wider attack surface for threat actors. And even trickier, some languages more heavily utilize open source libraries, which means applications written in those languages inherently carry more risk.

Expanding Attack Surface???

The chart above, where each dot represents 1 percent of applications in each language, highlights how many applications have code composed of open source libraries. You???ll notice that Java applications are a big offender as they cluster to the right, indicating that they???re almost entirely written in third-party code (which is accurate: we know that most Java applications are 97 percent third-party code).

Some languages like JavaScript and Python are curious, though, forming a barbell with clusters at both ends. This indicates that applications tend to be either mostly written in-house, or mostly composed of third-party libraries. Far-left clusters for C++ and PHP indicate that those codebases are mostly written in-house, with .NET showing the most even spread to indicate that these developers are more flexible with open source libraries.

C++ and PHP have a high number of severe flaws

In a standalone report, we broke down flaw frequency by language and found that C++ and PHP are offenders for high (and very high) severity flaws. C++ came out on top, with 59 percent of C++ applications having high and very high severity flaws, while an equally worrisome 53 percent of PHP applications also have severity flaws.

High Severity Flaws???

On a positive note, we found that just 9 percent of JavaScript applications have high or very high severity flaws with Python close behind at 10 percent. For a detailed breakdown of flaw frequency by language, read the standalone report here.

Fewer scans mean drawn out remediation time

On the surface it may seem like scanning a few times a year or even once per month is enough, but the numbers say otherwise. We know from our own customer data that more frequent scans can drastically reduce the amount of time it takes to close your found flaws and secure your applications.

Scan Frequency???

As shown above, scanning just 1 to 12 times per year results in a remediation time of 217 days ??? which means more flaws can pile up, adding to security debt and diminishing AppSec efforts. On the other hand, if you scan weekly or even daily, your time to remediate drops around or below 70 days. Though there are a variety of things that can impact the ???nature??? of your application, scanning frequency and cadence are both in your control to ???nurture??? as a developer.

For more information from our SOSS v11 findings, download theツ?full report.

Small Businesses are Counting on Their MSPs this Small Business Saturday

This November 28 may be the most important Small Business Saturday since the occasion was founded by American Express in 2010.

As early as July, nearly half (43 percent) of small businesses had closed at least temporarily, according to a study published in the Proceedings of the National Academy of Sciences. Research also suggests that 30 percent of small businesses expect to exhaust their cash on hand before year’s end. Eighty-eight percent have already spent the funds allocated to them by the U.S. government’s Paycheck Protection Program loan.

While hopes will be buoyed for some by recent positive developments in the search for a vaccine, uncertainty and hard times no doubt still lie ahead. That’s why Webroot encourages advocates and partners to shop small this November 28. For our customers, we aim to be a source of support and sound consultation as we recover together.

Challenges and opportunities for small businesses and MSPs

Many of the small businesses affected by COVID-19 are among Webroot’s clientele. Many more, especially managed service providers, count small businesses as their most important customers. We’ve heard from many who are suffering from lost contracts following office closures, fewer onsite projects, disappearing budgets for business development projects and a general slowdown of new business.

Others are witnessing a shift in the work they do and the services most in-demand. For some, COVID-related challenges have presented opportunities to step up and offer services made necessary by new realities. Unsurprisingly, the already trending adoption of cloud infrastructure has quickened its pace in the age of remote work.

“We’ve had to speed up migrating some clients on-premise file servers to online cloud solutions,” according to Russell Harris, a support engineer and project manager at Maya Solutions Ltd., a UK-based MSP specializing in Apple product support

For David Yates, president of Geeks R Us, a West Coast provider of various technical services, the shift to remote work was the push some of his customers needed to leave physical servers behind.

“A few clients who were reluctant to move to the cloud have now embraced it. This was the impetus that they needed to finally migrate away from on-premise servers,” he said.

Many MSPs have also taken it upon themselves to guide their clients through the transition to remote work, especially in terms of security.

“We’ve had to shift to more cloud, VPN and helping our clients work remotely,” says Nathan Hardester, a telecoms administrator with Whidbey Tech Solutions, a Washington-based MSP.

Cybersecurity education is another opportunity for MSPs looking to help small business clients up their cyber resilience. We know that many office workers are overly confident in their ability to detect a phishing attack, so MSPs should position themselves as educators. Already, in the COVID-era, some are finding themselves do exactly that.

Asked what’s changed at Maya Solutions since the pandemic, Harris responds “needing to provide additional training on online safety due to many working from home on their own devices.”

Making it through together

Many MSPs—often small businesses themselves—rely on their small business clients run for their success. And on this Small Business Saturday, small businesses need us all more than ever. Despite the challenges, there are opportunities for MSPs to step up and guide their clients through the changing way we work.

For more tips on staying cyber resilient through COVID-19 and beyond, stay tuned to our Community threat and check out these tips for MSPs looking to help small businesses bounce back.

The post Small Businesses are Counting on Their MSPs this Small Business Saturday appeared first on Webroot Blog.

FinTech Threat: The Malicious Insider

Whether motivated by personal financial gain, revenge, dissatisfaction, or the desire for respect, one of the biggest threats to your organization is sitting right underneath your nose. Out of the whopping 41,686 security incidents and 2,013 data breaches profiled in the 2019 Verizon Data Breach Investigations Report, 34% involved internal actors (Verizon LLC, 2019). The individuals composing your organization are a great asset, but it's evident they can also pose a tremendous threat.

NIST AI System Discovers New Material

When the words “artificial intelligence” (AI) come to mind, your first thoughts may be of super-smart computers, or robots that perform tasks without needing any help from humans. Now, a multi-institutional team including researchers from the National Institute of Standards and Technology (NIST) has accomplished something not too far off: They developed an AI algorithm called CAMEO that discovered a potentially useful new material without requiring additional training from scientists. The AI system could help reduce the amount of trial-and-error time scientists spend in the lab, while

IoT Unravelled Part 2: IP Addresses, Network, Zigbee, Custom Firmware and Soldering

IoT Unravelled Part 2: IP Addresses, Network, Zigbee, Custom Firmware and Soldering

In part 1, I deliberately kept everything really high level because frankly, I didn't want to scare people off. I'm not ashamed to say that the process of getting even the basics working absolutely did my head in as I waded through a sea of unfamiliar technologies, protocols and acronyms. I wish I'd had just the fundamentals down pat before going deeper and that was my intention with the first part of the series.

So, peeling back that next layer, the whole IoT space isn't just about devices that get their own IP address on your network and talk over TCP (or UDP). Many of them do (such as the Shelly switch in part 1), but then there's the whole Zigbee space as well. Let's drill into all that and then go deeper into custom firmware and soldering too.

IoT and IP Addresses

So, what happens when you start filling your home with IoT things? You end up assigning a lot of IP addresses; here's what it looks like in Ubiquiti's UniFi dashboard:

IoT Unravelled Part 2: IP Addresses, Network, Zigbee, Custom Firmware and Soldering

Clearly, I have a long way to go before exhausting available IPV4 addresses on this subnet so that's not something that worries me right now. Plus, all my IoT devices are on their own Wi-Fi network and it'd be dead simple just to start assigning those devices IPs from a different subnet (more on that in part 3 about security). IPV6? It's rare to see in IoT devices today, but there are many compelling reasons that make a lot of sense to see broader support in the future.

For the most part, the IoT devices in my home simply take their IP address from the DHCP server and I never think about it again. There are, however, occasions where you end up getting tied to specific IP addresses. For example, here's how the downlights in my office are configured in HA courtesy of the Wiz integration:

IoT Unravelled Part 2: IP Addresses, Network, Zigbee, Custom Firmware and Soldering

Then, one day, the lights stopped working. Why? They worked fine in the native Wiz app, why were they dead in HA? Back into the UniFi dashboard, down to the Wiz lights and... ah:

IoT Unravelled Part 2: IP Addresses, Network, Zigbee, Custom Firmware and Soldering

Because they're dynamically assigned an IP address, at some stage the lights had restarted and got themselves new ones. The fix, however, was easy:

IoT Unravelled Part 2: IP Addresses, Network, Zigbee, Custom Firmware and Soldering

I got to thinking more about IP address reservation (which is what you see above where the same IP is always assigned by the DHCP server) versus static IP address (where the IP is set in the client itself), after having to totally rebuild my network. (If you're interested in what happened, I covered it in detail in weekly update video 216.) There's a good overview of the two approaches here but in a nutshell, central management is always preferable. It means it's very easy to jump into the UniFi dashboard and get a quick list of all the fixed IP addresses in the network (it's under "Insights"):

IoT Unravelled Part 2: IP Addresses, Network, Zigbee, Custom Firmware and Soldering

The kids' Nanoleaves also use reserved IPs because like the Wiz lights, the HA integration needs a hard-coded IP address for the device. Having easy access to configurability such as this at the network layer is really essential, so let's delve into that network layer and talk about good gear.

Good Network Gear is Essential

As you're probably starting to gather from this series (and you'll see more of this as it progresses), you find yourself spending a lot of time troubleshooting problems. Why can't I see a device? Why can only some clients see a device? Why is the device slow to respond? Why have I started drinking so much since beginning my IoT journey? Having good visibility into my network configuration has been absolutely essential in helping answer those questions.

I've been a vocal proponent of Ubiquiti's gear for many years now and it's an absolutely essential part of my IoT world. (Disclosure: I bought every piece of equipment in that original blog post. Since then, they've sent me a bunch of gear.) For example, when I look at my network topology today, I can easily see everything that's connected to everything else:

IoT Unravelled Part 2: IP Addresses, Network, Zigbee, Custom Firmware and Soldering

I've named each and every device I've added to the network and given it a descriptive icon so that at a glance, I can get a really good idea of how everything is tied together. I can easily block a device from talking to the internet, throttle its connection, see which online services it's communicating with and access a whole host of other information about it. For example, just today I was trying to identify one pesky device I hadn't named earlier on and now had no idea what it was:

Turns out it was my daughter Elle's Amazon Echo Dot.

The Wi-Fi network is the foundation on which the IoT network is built. Investing in that was the best thing I could have done in advance of joining all the things to my network. But not all IoT is IP-based, far from it. Let's jump into Zigbee.


Alrighty, first things first: It's Zigbee, not ZigBee. I'm a stickler for details like this and it was driving me nuts seeing both stylisations all over the place but as of 2017, the "b" is lowercase (because I'm a stickler I kept scrolling back through zigbee.com on archive.org until I worked out when it changed). The Zigbee standard is maintained by the Zigbee Alliance, a group of companies responsible for shepherding it in the right direction. Zigbee uses the IEEE 802.15.4 standard and it's worthwhile understanding why, especially as compared to having devices just communicating directly over Wi-Fi:

IEEE standard 802.15.4 intends to offer the fundamental lower network layers of a type of wireless personal area network (WPAN) which focuses on low-cost, low-speed ubiquitous communication between devices. It can be contrasted with other approaches, such as Wi-Fi, which offer more bandwidth and require more power. The emphasis is on very low cost communication of nearby devices with little to no underlying infrastructure, intending to exploit this to lower power consumption even more.IEEE 802.15. 4 is a low-data rate wireless personal area network and is the PHY and MAC layer used by many IoT protocols, such as ZigBee, and WirelessHART.

In other words, the value proposition is low power consumption and low cost at the expense of bandwidth. But that's just fine for devices like this:

In fact, it's perfect for devices like this because they can be battery powered (they run on a standard CR2032) and get a couple of years of life and they only need to transmit a few simple values at a relatively low frequency.

Let me divert on a quick tangent for a moment: Zigbee isn't the only low-power, low-bandwidth standard out there and as I went through my travels, many people also suggested various Z-wave devices. I went all in on Zigbee primarily because the Aqara devices are great (more on them soon) and I already had Philips Hue units I could use as range extenders (more on that soon too). I may well end up with Z-wave devices in the future as well and I'd be remiss not to mention them here, but at present I haven't needed to diversify beyond Zigbee.

But Zigbee ain't Wi-Fi so you can't just buy a little device like the one above and connect it to an existing network, it needs a hub that can talk 802.15.4 to do that and suddenly, we're back into proprietary land again. For example, both the little temp sensor above and the motion sensors I discussed in part 1 are made by Xiaomi and I could always buy the Aqara Hub and connect them up:

IoT Unravelled Part 2: IP Addresses, Network, Zigbee, Custom Firmware and Soldering

But then what about other Zigbee devices from other manufacturers? For example, I've got a bunch of Philips Hue lights in the house and they run over Zigbee, do I really want to end up with a Philips Hue hub (which I actually already had and has an HA integration) plus an Aqara hub (which also has an HA integration) plus whatever other devices I end up with and their own hubs as well? Not really, which brings me to the ConBee II Zigbee sniffer.

ConBee II, The Universal Zigbee USB Gateway

HA alone can't read from Zigbee devices and as already discussed, they also can't drop directly onto your Wi-Fi hence the need for a hub. What folks tend to do is go for a "CC2531 stick" which can "sniff" Zigbee traffic. CC2531 is a chipset made by Texas Instruments (check the date on that resources, this goes back over a decade) that appears in a whole heap of cheap units sold as "Zigbee sniffers". But there was one particular model that came up time and time again after I posted that earlier tweet with the temp sensor; without prompting, many people directed me to the ConBee II, a little USB stick with a CC2531 chip that can talk IEEE 802.15.4 and implements the Zigbee protocol. See how that ties all these new things together? 😊

Here's the unit:

IoT Unravelled Part 2: IP Addresses, Network, Zigbee, Custom Firmware and Soldering

The ConBee II is produced under the Phoscon brand, a name I mentioned back in part 1 in relation to the deCONZ integration. I picked one up off Amazon for A$78, plugged it into the USB port of the Raspberry Pi running HA then configured it all by following this great guide which takes you through the entire journey. When I went through that process only 6 months after that post was written, there were quite a few bits that were out of date (namely where things are located within the UI), but it was still easy to follow. Once done, all the mechanics are now there to join up all the respective bits of the Zigbee network:

IoT Unravelled Part 2: IP Addresses, Network, Zigbee, Custom Firmware and Soldering

The next problem is that in my case, I ended up with a single USB sniffer stuck into a Raspberry Pi inside a server rack inside a large walk-in cupboard inside a garage at the bottom of a large 3-story solid brick construction house. You can guess what comes next...

Extending Zigbee Range with Repeaters

In fairness to the ConBee II, it did an admirable job under the circumstances and indeed its range is a big selling point:

Thanks to its power-amplifier, the ConBee II has an outstanding range. This lets the signal pass through 2–3 rooms or floors, depending on the construction type.

But it wasn't enough. I continually found temp sensors (which I now had in every single room) not being available so clearly something had to give. Fortunately, one of the joys of Zigbee is that - and I'm going to quote here - "all mains powered Zigbee devices, such as lights and sockets, act as repeaters and can route the signal". This is again from the Phoscon page on the ConBee II which they illustrate as follows:

IoT Unravelled Part 2: IP Addresses, Network, Zigbee, Custom Firmware and Soldering

This creates a mesh network enabling you to expand the Zigbee range as more (mains powered) devices are added. That's all good in theory but in practice, well, let me just drop a discussion I had with my good mate Scott Helme in right here as he was going through his own HA build:

IoT Unravelled Part 2: IP Addresses, Network, Zigbee, Custom Firmware and Soldering

I wanted to include this discussion in its original candid state because it perfectly illustrates the frustrations I raised in part 1: this is still a "maker" world where even people who live and breathe tech day in and day out continue to hit hurdles. I found multiple references around the web about the IKEA repeaters not playing nice with Xiaomi devices, yet when I looked at my own Zigbee network, I saw this:

IoT Unravelled Part 2: IP Addresses, Network, Zigbee, Custom Firmware and Soldering

I can see plenty of devices connected to "Range Extender 1" in the garage! But no devices connected to "Range Extender 2" in the master bedroom. There are too many devices spread out over too large an area for this to be a mere coincidence, is it simply that one range extender doesn't want to connect and one does? I've ordered another couple just to see what happens, but I continually get the feeling that this whole effort raises more questions than it answers...

A quick sidenote on those Philips Hue devices in the Zigbee map above: per my discussion with Scott, I had to unpair them from the Hue Bridge and then pair them in deCONZ just like all the other Zigbee devices. Consequently, I can no longer use the Philips Hue app to manage, say, the two Hue Go units on my desk. As I said in part 1, the native apps are often richer in functionality than what HA provides and that's the case here too. I have several Hue light strips around my fireplace, one behind my TV and one behind the perimeter of a massive mirror in my entertainment room. I want the family to be able to manage these directly via an easy to use app hence I haven't moved them over to deCONZ. That means they don't form part of the Zigbee mesh network in the image above, but they're also in locations where there's plenty of coverage already. My office really needed more coverage (it's several floors above where the ConBee II is located) and it's only me who manages them hence their presence on the deCONZ network.

One final thing on the whole Zigbee piece: I'm seeing a lot of feedback about people having problems with deCONZ and switching over to ZHA instead:

The Zigbee Home Automation ("ZHA") integration seems to be quite highly regarded and if I'm honest, I've had a lot of problems with deCONZ. When I look at it within HA now, there's a bunch of devices that have lost the carefully crafted names I provided them with when originally pairing them:

IoT Unravelled Part 2: IP Addresses, Network, Zigbee, Custom Firmware and Soldering

This happens over and over again and to be honest, I just need to bite the bullet, kill deCONZ, set up ZHA and manually re-pair every single Zigbee device in the house 😭 To be clear, this isn't breaking the HA references to the devices in any way, it just screws up their representation within deCONZ and subsequently, the earlier network map as well.

But for the most part the Zigbee stuff has been great, especially those Xiaomi Aqara devices. Let's drill into them now.

Xiaomi Aqara

I want to devote a section of this post specifically to Xiaomi Aqara as these are great little devices that I now have all over the house. Before I get to the devices themselves, a bit of disambiguation around the names you'll see used here:

  1. Xiaomi is the Chinese company that makes the gear
  2. Mi is an abbreviation of their name (their website is literally just mi.com)
  3. Mijia is a brand name owned by Xiaomi (you would have seen it on the Aqara hub image earlier on)
  4. Aqara is a brand name owned by Xiaomi

Bottom line: Aqara is the name you'll see me using here as that's what's on the devices I've been buying (plus I can spell it more reliably than Xiaomi!) They're cheap, reliable and in my view, pretty slick looking little units. Earlier in this post I showed one of the temp sensors (pro tip: the round ones are an earlier generation, the square ones are newer and also do air pressure as well as temp and humidity), and in part 1 I showed the motion sensors which trigger lights when it's dark. Beyond those, I've used a number of proximity sensors so I know when doors are open or shut:

In part 1 when I showed my Apple Watch opening the garage door, this is achieved by defining a cover in HA. A cover, uh, "covers" stuff so blinds, shutters and garage doors, for example. When you think about a cover like a garage door, there's really 2 things you want visibility or control over:

  1. Is it open or shut
  2. Open or shut it

The proximity sensor answers the first point and the Shelly from part 1 answers the second point. Combined, they enable me to glance at my watch, see the state of the garage door and then change that state.

I also picked up a few Aqara buttons to do, well, anything:

These are simple triggers that can be used in automations. For example, I have one at the bottom of my stairs that can turn off a bunch of lights with just a single click. Those lights normally come on just before sunset but if I want to manually turn them on, that's just a double-click on the same button. Neat!

And inspired by others, I even attached a vibration sensor to my letterbox:

There are plenty of Zigbee devices out there, but I wanted to call out Aqara in particular as they've just been so damn reliable. Only once have I had an issue with any of the couple of dozen devices I have in the house, and that was just the letterbox vibration sensor shipping with a near-flat battery.

I put a temp sensor in each room right at the beginning of my HA journey. It was simple, cheap and immediately gave me useful data I could start doing stuff with:

IoT Unravelled Part 2: IP Addresses, Network, Zigbee, Custom Firmware and Soldering

So pro tip: if you want to get into HA and IoT in a meaningful way, start here and work up. Those temp sensors are cheap, useful and give you a means of dipping your toe into the IoT water in a pretty low-friction way. Chuck in some motion and proximity sensors and there's a bunch of stuff you can do right away without spending much.

Let's now move onto something completely the opposite of low-friction and get our hands much, much dirtier.

Flashing Custom Firmware and Soldering

I propose that we all need to find our own paths in terms of just how dirty we want to get our hands when playing with IoT. For many, the whole idea of running a Raspberry Pi with community driven software you configure with YAML is a step too far. For others, it's just the beginning with many people going down the path of, per the heading above, flashing custom firmware onto devices and soldering wires. In fact, this is the path I was originally going to head down for my garage door by following this video:

I bought all the bits, downloaded the firmware flasher, wired it all up per the instructions yet still, found myself lost:

I then discovered that contrary to the instructions, RX shouldn't go to TX, it should go to RX and right there at that moment, I'll be honest: I lost my shit. Why is this so hard?! Why do I need to modify the firmware of such a simple little device?! And why do I then find myself holding a burning soldering iron just to open my freakin' garage door?!

To be fair to the folks that enjoy living in this world, I can see the attraction and I have great respect for those with the skill and patience to take this path. Tasmota is enormously popular open source firmware designed for ESP8266 devices which is the chipset many IoT products run (including a bunch of the lights in my house). But for me, it's a step too far and an unnecessary one at that given how easy it eventually was to achieve the same result with a Shelly that requires no custom firmware, no soldering and has no exposed circuitry:

The most complex part of this entire approach was reading the garage door opener manual and referring to the terminal block on the back of the unit:

IoT Unravelled Part 2: IP Addresses, Network, Zigbee, Custom Firmware and Soldering

And per the manual:

O/S/C INPUT is used for the connection of a wired switch (momentary contact). This switch can then be used to open, stop or close the door.

All the garage door automation needed to do was close the circuit between the COM and OSC terminals via the Shelly which is then powered via the 24V terminal. The point I'm trying to make is that there's a heap that can be done without going down to the custom firmware and soldering layers and I wish I'd known that before I got started. This, to my mind, is the "happy path" I referred to in part 1.


This post mostly boils down to "have a decent network, get Aqara Zigbee devices and avoid custom firmware and soldering unless you really want to go in that direction". It feels obvious now to summarise it so succinctly, but it took a lot of trial and error to reach those conclusions. Tomorrow in part 3, it's time to talk about security and oh boy, there's a can of worms right there!

Lastly, and as I mentioned in the conclusion to part 1, Scott and I will be doing a live stream on Friday where we discuss how we've both approached the whole IoT piece. It'll be candid, direct and we'll definitely be taking questions too so come join in then via the video below 👇