Category Archives: Software Development

Businesses Losing Customers due to Connected Products Security Concerns

59% of cybersecurity executives at large and medium organizations say that they have LOST business due to product security concerns for connected and embedded devices.

connected product security concerns

45% say that customers want detailed information about what is in their devices, but only 11% of companies have high confidence that they can do that, even if they want to.

Only 27% of people interviewed said that their organizations conduct software composition analysis (what is in it) and only 30% say that they can easily generate a software bill of materials (as required by the new executive order).

So what does it take to develop secure products? More resources (62%), more expertise (60%), industry standards (46%). Only 21% said that their have a security supply chain policy.

connected product security concerns

On top of this, only half of the respondents said their organization check out the security of their products before they ship them.

The good news is that 74% of the organizations either have a Chief Product Security Officer or plan to hire one. In the next two years.

And, last but not least, only 10% have full confidence that they know all vendors in the supply chain for each of its devices.

Ready to buy one of them secure connected devices now?

Credit: Help Net Security

Be Careful What Contracts You Sign

While the details of this are interesting, what is more important is thinking about all of the contracts that you sign.

This is a legal battle that goes back several years.

In one corner is Fiserv, the Fortune 200 +/- financial services software behemouth.

In the other corner is Bessemer System Federal Credit Union, a small community credit union in Pennsylvania.

In 2018 Brian Krebs reported bugs in Fiserv’s platform that allowed one customer to see another customer’s name, address, bank account number and phone number.

So Bessemer FCU did some more testing and found more bugs – security holes.

According to the credit union, Fiserv responded with an aggressive notice of claims, attempting to silence Bessemer if they discussed these security bugs with third parties, including other Fiserv customers.

In the end Bessemer sued Fiserv and Fiserv counterclaimed.

Fiserv said Bessemer breached its contract, among other things, and wanted attorney fees.

Much of the argument seems to be around the security review, which, if accurate, shows that Fiserv’s software is not secure, something other Fiserv customers might want to know about.

Fiserv says that Bessemer just wants to embarrass Fiserv and get out of paying some bills.

Without spending a lot of time reviewing legal documents, it appears that Bessemer was not happy with Fiserv’s response to being notified about the bugs (like in fixing them, soon) and wants to terminate the contract.

Fiserv, appears to want to silence a critic (boy is that failing) and doesn’t want to let the customer out of its contract.

So what does that mean for you if you sign a contract with a vendor? Here are some thoughts.

  • The vendor is going to want you to sign as long a contract as possible and will usually offer you a price incentive to do so. If this is a new vendor, that is likely not a good deal for you. Shorter might make more sense.
  • You should review the reasons that you can terminate the contract and what that termination will cost you.
  • You should look for any clauses that stop you from talking about the vendor’s product quality. This is different than disclosing secrets. While bugs and security flaws may be secret, they should not be covered by these types of contract restrictions.
  • Vendors should have a fixed amount of time to fix serious bugs or you should be able to terminate your contract.
  • The contract should spell out that the vendor is liable for your losses as a result of security bugs. Software vendors will resist this like the plague, but why should you be responsible for their bad software.

The lawsuit is ongoing. It will be interesting to see how this works out. Given this is now in the news, Fiserv might be smart to try and make it go away. Quietly. A trial could be ugly. On the other hand, Fiserv has a lot more money than Bessemer does.

Stay tuned.

But think about those contracts you signed and how you would fare in a similar situation.

On the other side, if you are a software vendor, how would you handle this situation.

Credit: Security Week

Supply Chain Risk in the Software Process

I have been talking a lot about supply chain risk lately and there is a good reason. From open source products with backdoors like Webmin or Rubygems to NotPetya a few years ago which shut down many companies around the world to the recent attacks against SolarWinds or Centreon, supply chain attacks are running rampant.

There is a good reason for this – we have not, historically, paid enough attention to them, so they work very well.

Here is a new attack that works against the software development process.

Security researcher Alex Birsan posted a blog on February 9th that detailed how he used dependency, or namespace confusion to push malicious proof of concept code to organizations like Microsoft, Apple, Tesla, Uber and others. It is not because these companies are stupid. They are not. It is because we are not paying enough attention to the problem.

The good news is that he is a good guy and wasn’t trying to take down the world.

I am not going into total-geek with details of why this attack works, but right after the vulnerability was announced, hundreds of copycats were released into the wild. And still are being released – knowing that some companies will ignore or not understand the problem and remain vulnerable, potentially forever.

Not surprisingly, the root of the problem is the tradeoff between security and convenience.

The problem is that if the bad guys are sophisticated, developers will not detect the problem because their malicious code won’t activate until a trigger event happens and all of the normal functionality works correctly.

The researcher who launched the test attack called the results simply astonishing. I don’t think the copycats were launching mock attacks.

For more details on how this attack works, read the article here.

Security News for the Week Ending December 4, 2020

France Says it is Going Ahead with Digital Tax

France has been complaining that U.S. companies (mostly) have not been paying their fair share of French taxes since they are not selling widgets that delivered in France, so they came up with this digital tax, a 3% tax on digital services delivered in France. They held off for a while trying to get some sort of international tax agreement, but that does not appear to be happening, so they are moving forward with the tax. Only affects companies doing business in France with revenue more than 25 million Euros. Is this the wave of the future? Credit: Cybernews

FCC Chairman Pai to Step Down on Jan 20

Ajit Pai announced that he will step down from the FCC on inauguration day rather than having the new President fire him, which is almost guaranteed. Pai, a former telecom industry lawyer and lobbyist, said that he may try to create some rules in his remaining two months in support of the President’s efforts to hurt Facebook, Twitter and similar companies. Those rules would likely be reversed on the day after inauguration, so it is not clear why he would waste taxpayer money doing that, but that is Washington for you. Credit: CNBC

How Many Phishing Sites?

Since the beginning of this year, Google has flagged 46,000 web sites EACH WEEK as phishing sites. That is over 2 million so far, this year. This is a 20% increase over last year and the year is not over. Hackers can buy as many sites as they want, but, in part, they are looking for “look alike” sites – sites with a zero swapped for an Oh or an “L” swapped for a “1”. But also, they just take over sites with bad security. There is almost no way to track that, but I can say from personal analysis, that there are way more of the second kind than the first kind. Credit: KnowBe4

Docker Malware – Its a Thing

Docker containers are the darling of the development world – light weight and easy to deploy; self contained and OS agnostic, supported in the cloud – everything that developers want.

Three years after the first Docker malware showed up, it is now common. Malware gangs are now targeting Docker and Kubernetes.

Many of the attacks – surprise – are due to misconfigured Docker servers, leaving them exposed to attack. It appears that we in IT never learn. Just because tech is delivered slightly differently, the basics still apply.

To make a point, researchers looked at images publicly available in the Docker Hub. 51% had critical vulnerabilities and 6,500 of the images tested could be considered malicious.

You can wait until you are compromised or you can get ahead of the freight train. Credit: ZDNet and Dark Reading

Even Before Dust Settles on Swiss/CIA Deal to Subvert Encryption …. Another One

Even before all of the investigations are complete of the CIA’s compromise of Crypto AG and selling compromised encryption hardware to both our friends and enemies so we could spy on them, another story surfaces. Apparently Crypto AG was not the only one. Now the Swiss media is reporting that the CIA controlled another Swiss crypto company, Omnisec. The Swiss politicians are going crazy and calling for executions in the public square. Stay tuned, but assume your crypto has been compromised. By someone. Credit: Security Week

Default Passwords on Gov Websites – What Could Go Wrong?

You would think that in 2020 we wouldn’t have to tell people not to use default passwords.

You would certainly think that we wouldn’t have to tell government IT folks not to do that.

But if you thought that, apparently, you would have thought wrong.

We are still telling end users to change the password on their WiFi router. And on their Internet modem or firewall. But those are consumers.

We recently did a penetration test for a client. The client has a lot of locations.

For the most part, their Cisco ASA firewalls were secure.

Except for a couple of them.

Which still had the default password. At that point, we owned their entire network.

Fast forward to last month. The FBI said, privately, that foreign actors had successfully penetrated some government networks and stole source code.

Now we are getting at least some of the rest of the story. We still don’t know which agencies were hacked and what was stolen, but we do know how.

SonarQube is an open source application to help companies or agencies improve code quality through continuous static code analysis.

But if you put that on a public facing web site and you don’t change the default password – which is a really hard to guess “admin/admin”, you kind of have a problem.

I don’t understand enough about how SonarQube works, but it seems to me that it SHOULD NOT be exposed publicly and it probably should not be on production servers.

Here it is, at the tail end of 2020 and we are still telling people – IT people – to change the freaking password.

And security folks have been talking about this specific problem with SonarQube for a couple of years now and not just inside the gov.

Come on folks – get with the program. Hopefully what was stolen was not too sensitive but the fact that they are not telling us who was hacked and what was stolen probably means that it was sensitive. Credit: ZDNet

Is Your Mobile Phone App Secure? Probably Not!

More than three-fourths of mobile banking vulnerabilities can be exploited without physical access to the phone.

A new report from Positive Technologies has a number of sobering facts:

  • 100 percent of mobile banking apps contain code vulnerabilities due to a lack of code obfuscation.
  • NONE of the mobile banking apps tested had an acceptable level of protection
  • Attackers can access user data on almost all tested apps
  • In 13 out of 14 apps, hackers can access data from the client side
  • Half of the banking apps studied were vulnerable to fraud and funds theft
  • Hackers were able to steal user credentials from five out of seven banks tested

And the list goes on.

From the perspective of being a user of apps, this is a bit disconcerting.

From the point of view of being a company who may be developing apps, this is a bit of a wake-up call.

If you think about the amount of developer support that big banks have and they are still not developing secure apps, what does that mean for small to medium size companies that do not have that infrastructure?

As a user you are kind of dependent on the developers to do it right and it does not appear that the developers are doing such a good job at that. You can look at reviews, but that is of limited value.

If you are using the apps for your company, you can and should test the application’s security and if the app contains sensitive data or acts as an interface to sensitive data, that is probably not optional.

If you are writing apps or, just as importantly, paying others to write apps on your behalf, there are, at least, two things to do.

Make sure the development team has a well implemented secure software development lifecycle (SSDL) program. Don’t just trust the developers when they say sure, we do. Verify that. If you need help either developing or testing a secure software development lifecycle, give us a call.

Second, if you are not already conducting application penetration tests for every major release of applications that you develop or have developed for you, you need to start doing that. Yes, that costs money. But so does having a breach. If your app accesses data of California residents, remember that they can now sue you for $750 per record compromised without showing that they were damaged.

A 1,000 record breach equals a $750,000 liability. Not counting attorney’s fees and reputation damage. You can do a lot of testing for that amount. 1,000 records is a tiny breach. You are not Capital One, but their breach exposed 105 million records. You do the math.

The maturity level of developing apps today is similar to the maturity level of developing web software in around the year 2000. That alone should scare you.

Some questions you can ask your development team:

  • Do you have a dedicated software testing staff?
  • Are they trained to test software for SECURITY FLAWS or only for functionality?
  • Are you using automated testing tools?
  • Are your developers trained to develop software securely?
  • Does the development team have a security development manual? Something that is written down and part of their business process?
  • Who signs off on the security of apps before release? What is their security expertise?

The evidence is that app security is not so great. What are you doing to improve it? Credit: SC Magazine