Tag Archives: Vendor Risk Management

Another Open Source Software Supply Chain Issue

Lets combine all the possible cyber risk concerns into one sentence.

A bug in an open source library used by major IoT vendors is raising the spectre of software supply chain/vendor risk management issues for all developers.

The vendor in question is Axis Communications.  Whether you know it or not, you have seen their security cameras across the country including in high profile places like airports and stadiums.  That is the IoT part.

The open source part is a library that Axis and tens of thousands of other products use called gSoap.  gSoap is available on Sourceforge and has been downloaded 30,000 times in 2017 alone.  Since a developer or developer’s company only has to download it once to use it in hundreds of products, the scope of use of this software is unknown, but large.  Given the number of cameras that Axis alone sells, it likely affects millions of devices.

The bug, called Devil’s Ivy,  is going to be very difficult to stamp out.

For developers, they have to understand their software supply chain.  Axis, for it’s part, is at least trying to spread the word about the problem.  There is a patch available.

But then there is the supply chain issue.  You or I might have an IoT (or other) product that uses this library, but there is no easy way for us to know whether we do or not.  The vendor who downloaded the library and then integrated it into their software has to understand that that library has a patch cycle of it’s own.

ASSUMING the vendor understands the problem, they have to rebuild their software.  If the software is like gSoap, which has been downloaded over a million times, there is no easy way to get the word out, since there is no vendor selling it and no support contract with names and phone numbers.

To make it worse, lets say that Axis downloads the patched library and then figures out which models of their cameras use it and generates a new version of the firmware for that camera, how do they get the word out to their millions of customers that there is a new version of the firmware for some object that is hanging from the ceiling in a store, stadium or airport.  That is not an easy job.

From the customer’s standpoint, their vendor risk  management program needs to be asking questions about how their vendor is keeping up to date on their software supply chain and how they are notifying their customers about new software versions.

Now it is a simple matter of patching an IoT device hanging 30 feet or a hundred feet in the air in the middle of a store, school, stadium or airport.  Did I say SIMPLE?

All in all, a bit of a mess, but with some work it is possible to reduce the risk.  However, it will take work on the part of developers, manufacturers and end users.  THAT is not simple either.

Information for this post came from Senrio.



Yet Another Outsourcer Hacked

Aptos, an outsource point of sale vendor for many businesses, announced that they were breached.  Sort of announced, but not really.

The breach was active from February 2016 thru November 2016, but they didn’t notify their merchants until February of this year.  Now the vendors are slowly notifying their customers.  Potentially, customers are not going to be notified for a year after their card was compromised.  Aptos is not notifying the compromised customers at all – they are leaving that up to their customers.

If you are being proactive and watching the activity on your cards, you would have been aware of the fraud long before you found out about it from them.

When contacted, Aptos said that they were not going to say who was breached and leave it up to the vendors.  According to a blurb of a WSJ article, Aptos apparently told at least some of their merchants that they didn’t have to disclose the breach, but attorneys are disagreeing with that.  Some of the merchants affected are:

  • Abbott Store.com
  • Liberty Hardware.com
  • Mrs Prindables.com
  • Affy Tapple.com
  • Alpha Industries.com
  • Atlantic Cigar.com
  • Blue Mercury.com
  • Hue.com
  • Movie Mars.com
  • Nutrex-Hawaii.com
  • Pegasus Lighting.com
  • Plow and Hearth.com
  • Pudys.com
  • Runnings.com
  • Sport-Mart.com
  • Thiesens.com
  • Vapor Beauty.com
  • West Music.cm
  • Percussion Source.com
  • and a number of others

For an updated list of affected vendors, visit the Data Breaches link below.

Information taken includes name, address, email, phone number and credit card information.

Some of the merchants are offering credit monitoring.  Hopefully if you bought anything from these merchants, they have already reached out to you.

Besides the hassle if your card was compromised, this is yet another example of outsourcing things that are not core to your business to make your life easier and it winding up making your life harder and costing you money.

Most of these merchants are small, which means that they are less able to deal with the reputation hit.  Remember that cyber insurance will not pay for your damaged reputation – to deal with that, you would have to sue the outsource vendor.

Some thoughts –

  • Make sure that you do your due diligence before you sign up with an outsourcer to run your point of sale system.
  • Make sure that you have cyber risk insurance and it covers that kind of situation.
  • Make sure that your agreement with the outsource vendor specifies who is liable, exactly WHAT they are liable for and how you are going to get paid for the damage.
  • Make sure that the outsource vendor has cyber risk insurance as well.

So while you cant eliminate risk, at least you can work on reducing that risk.  The due diligence and insurance are critical.

Information for this post came from Data Breaches and The Register.

Partners and Too Much Data Equals Data Breach

The Australian Red Cross recently apologized for losing control of 1.74 gigabytes of donor data. Included in the breach are name, address, email, phone number, date of birth and other information from blood donors.

The data, 1.3 million records stored in 647 database tables is all the information the Australian Red Cross had on donors who accessed the online donor portal.  This represents Australia’s largest leak ever of personal data.

The Australian government is asking a lot of questions, but this is a great exercise for everyone to contemplate.

First of all, why are they sharing all this data with a vendor?  Does the vendor really need all of it or could they give the vendor a subset of the data?

How come the data was publicly accessible on the Internet?  It sounds like the researcher was just looking for IP addresses that responded to a directory command and then looked for stuff. He found a file with a .SQL extension which turns out to be a MYSQL server backup.  How are you checking to make sure that data that should not be made public is not made public?

Since, apparently, this data was stored at a vendor, this calls into question the Red Cross’s vendor risk management program.  How active and effective is your vendor risk management program?

It sounds like the Red Cross did as good a job as possible under the circumstances to deal with the breach after the fact, which is good, but that still doesn’t lessen the damage.  Would you be able to respond as effectively?

But probably the most important question the Red Cross asked itself after the breach is why are we keeping this data?

Most companies are reluctant to delete any data.  Ever.  After all, you never know when you might need it.  On the other hand, if you don’t have the data, the hackers can’t steal it.

Maybe you need the data for compliance reasons or legal reasons.  That still doesn’t mean that it has to be online on a public server.  Archive the data, delete it from the primary databases and only allow access to selected people and then only from inside your four walls.

It is certainly true that you may, possibly, delete a piece of data that, in five years from now, you may, possibly find a use for.

On the other hand, that same piece of data may be exposed tomorrow by a business partner with poor cyber security practices.

One final thought – Do you regulate what your vendors can do with the data that you share with them?  How long can they keep it?  How do they protect it?

Whether we are talking Target, The Home Depot, The US Office of Personnel Management, the Australian Red Cross or a host of other breaches, vendors are often the weak link.

Consider the risk.

Information for this post came from Troyhunt,  ZDNet and a second ZDNet article.


Outsource Payroll Processer Sage Breached – Lessons to Learn

Sage Group, an international cloud based accounting,  payroll, HR and CRM services company acknowledged a breach this week.  The breach affects around 300 companies based in the U.K. but the value of the breach is not in who got breached, but rather the lessons to be learned from it.

The company provides accounting and payroll services in 23 countries, is listed on the FTSE 100 list and has over 13,000 employees, so it is not a small company.

Sage has only said that the unauthorized access occurred through the use of an internal login.  They did not say whether that meant a rogue employee or a hacker inside the walls of their fortress.

Given that they are a payroll and accounting service, the data that they hold includes names, addresses, insurance information, dates of birth, banking information and other financial information.

The British Information Commissioners Office said that “the law requires organisations to have appropriate measures in place to keep people’s data secure.  When there’s a suggestion that hasn’t happened, the ICO can investigate and enforce if necessary.”

So what are some of the lessons to learn from this?

  1. Just because you outsource it does not mean that you are not responsible.  While Sage will take the brunt of the hit, those 280 or so companies who’s employee and financial information are at risk will both feel the heat and pay the bill.
  2. If you choose to outsource services such as payroll, understand where the financial liability lies.  In the contract, in writing, it should say who is responsible and exactly what they are responsible for.  Is Sage going to make these 280 companies whole?  How exactly are they going to do that?
  3. If the outsource provider is going to make you whole, do they have the financial ability to do that.  Some outsourcers have cyber liability insurance, but only a small amount.  Let’s say Sage has a $5 million policy (and I have no clue, they could have a $500 million policy, but I doubt it).  That $5 million might cover the cost for one customer.  And it might not, depending on the size of the customer.  But in this case, and many others, they have to make hundreds of customers whole.  If $5 million is the right number to make one company whole and there 280 companies involved, then $5 Mil x 280 =  $1.4 Billion is the magic number. The good news is that Sage generates over a billion dollars in revenue a year, so, in theory, they might be good for it – if, as it says in item 2, they are even liable for it.  Small companies – or companies that are not yet profitable – are not going to be able to write that check, so the best you will be able to do is drive them into bankruptcy and then you get to write that check.
  4. It sounds like this COULD be an inside job.  Alternatively, it could just be a hacker who snuck behind the walls of the fortress, compromised an ID and is making it look like an insider – which brings us to the next item.  If it is an inside job then it becomes a people conversation – what is the right balance for watching people.
  5. Audit, audit and then audit some more.  You have to know who did what when.  What they accessed. What they did with it.  This is likely 10 times more stuff than you audit today.
  6. Make sure that the audit logs cannot be accessed or erased by a rogue employee or a hacker.  The first thing a smart hacker will try to do is erase the logs.  If the logs are shipped offsite, in real time, to a server that is not part of your domain and for which, neither your users’ nor your administrator’s credentials will work on, then you have made the hacker’s job of erasing the logs very difficult.
  7. Make sure that you keep the audit logs for a long time.  Long means AT LEAST one year; preferably longer.  In one of the hacks that I wrote about yesterday (HEI Hotels), the hackers were inside for 15 months PLUS the time it takes to investigate.  If you want to find out how they got in and you only have six months of data, that is not going to help much.  If you only have six months of data and they were there for 15 months, you are not going to know what they took, so you, and the authorities, will have to assume the worst.
  8. If the British ICO is any example, don’t count on the authorities to do anything meaningful in any time that is important.  Maybe a couple of years from now Sage will be fined, but that won’t help you much now.

This is just some food for thought, but thinking now will allow you to figure out what happened when the ka-ka hits the rotational air movement device.

By the way, this has nothing to do with the Cloud.  A traditional outsource provider using internal systems provides the same risks.

If you do not have a vendor risk management program, today would be a good day to start one.

Information for this post came from Dark Reading and ZDNet,


[TAG:TIP]  , [TAG:Breach]

The Point of Sale (POS) Breaches Continue

So far this week (and it is only Monday), we have two POS breaches in the news.

HEI Hotels and Resorts, which manages almost 60 hotels for Starwood, Hilton, Marriott and other chains announced that 20 of their locations, covering all of their brands, had suffered breaches.

While they have not said how many cards may have been compromised, they have said that the data that was compromised included name, account number, expiration date and verification code.

HEI said that they thought that the data was accessed in real time because they do not store the data.  They also said that they were unable to contact people who’s cards were likely breached since they do not collect or maintain enough information to do this.  This raises some important points.

These statements would seem to indicate that they outsource the processing of payments.  If so, that points to the fact that even if you outsource credit card processing, you are still the one who has to face the music in case of a breach.

It also indicates that they are likely not using chip based credit card readers because if they were, the data would not exist in an unencrypted state except inside the card reader itself, which does not appear to be where the breach occurred.  One more time where a chip based solution might have stopped a breach in its tracks.

The breach lasted a long time – from March 2015 to June 2016 – about 15 months.  It is not clear why the malware was not detected for so long.

In the second breach of the week, Oracle acknowledged a breach affecting their Micros POS software.

Apparently, the breach is large enough that VISA issued an alert to merchants, which they usually don’t do.

Visa said that hackers broke in to hundreds of servers at Oracle and had “completely compromised” Oracle’s support portal.

Micros, according to Oracle, is installed at over 300,000 locations, including 200,000 food and beverage locations, 100,000 retail locations and 30,000 hotels.

With millions of cards used at these locations per week, this could be a major breach.

Oracle is being very tight lipped about this breach – whether that is because they do not understand the scope of the breach and don’t want to make incorrect statements or because Larry Ellison knows he is about to be hit with multiple lawsuits, is unclear.

Oracle told customers to change their passwords and to change any passwords used by Oracle staff to access their systems and not much else.  That would suggest that hackers, in hacking the Oracle servers, got credentials that would allow them to access their customers’ systems.

Some of Oracle’s customers are saying that by not sharing information, Oracle is making it harder for them to clean up Oracle’s mess – all fodder for the inevitable lawsuits.

Brian is also saying that it is possible that Oracle was breached by more than one Eastern European (read this as Russian) crime group or at least more than one is dividing the spoils.  If in fact, there are 300,000 plus locations hacked and people will eventually change passwords, the hackers have to work fast in order to install other back doors and extract data.

It appears that the customer network and Oracle’s internal network were on the same network segment, but that network was split.  Somehow, sources say, that facilitated the breach.  They do not say how.

And here is the killer.

In mid July, Oracle told employees in the hospitality division that they had to wipe their computers WITHOUT BACKING ANYTHING UP.  The computers were then reimaged with a clean operating system.

This means that employees lost implementation plans and schedules and software that was going to be deployed.  The source said that this has cost Oracle billions of dollars – however that seems like a lot of money.  Still, I am sure that did cost Oracle a bunch.

Oracle did not tell employees that the reason that they had to wipe their computers was because the company had been breached.

I am sure that more details will emerge, even if Oracle does not want them to.

What this does point out is that companies need to have an active and aggressive vendor risk management program.  In both of these cases, the problem stemmed from vendors.  The restaurants, bars, hotels and retail stores were counting on their vendors to protect them.  While it is possible that there are clauses in the customer’s contracts with Oracle in which Oracle agrees to indemnify and reimburse the stores and restaurants for all costs associated with the breach, but knowing Oracle, it probably says that they aren’t responsible for anything.  We shall see how this turns out in court – but that is years from now.

In both of these examples, these businesses are going to have very unhappy customers and not because they did something wrong, but rather because one of their vendors did something wrong.

Vendor risk management programs are effective at reducing risk associated with outsourcing.  If you don’t have a program, you should create one now.  If you do have one, you should review it for completeness.

Information on the HEI Hotels breach came from CSO Online.

Information on the Oracle breach came from Krebs on Security.

MBA Panel Discusses Third Party Risk Issues

According to HousingWire, a panel at the Mortgage Bankers Association mortgage servicing conference discussed cyber risks and one seems to have the attention of regulators is risk introduced by vendors.  All you have to do is think back to Target, Home Depot and the Office of Personnel Management (collectively around 200 million compromised records).  The entry point of attackers in all three cases was vendors.

The panel pointed to guidelines from The New York Department of Financial Services (NYDFS), which are voluntary now, but may not be voluntary for long.  NYDFS is working with many state and federal regulators to make their view of the universe the nation’s standard.

While NYDFS only regulates entities like banks, insurance companies and broker-dealers (among others), there is a food chain to consider.  If you sell to or provide services for one of these covered entities, then that entity is going to require that you measure up to their regulator’s rules.  Otherwise, the regulator will come after them.

The NYDFS wants their rules to be included in contracts that regulated entities use.  That way there is no question.  You don’t want to agree to these terms, then don’t do business with them.

Some of the rules include:

  • Requirement to use two factor (or multi factor) authentication.
  • Use of encryption at rest and in motion.
  • Notification in case of a breach (yes, believe it or not, some banks recently were found to not require vendors tell them if the vendor was breached).
  • Indemnification in case the entity that is contracting for services experiences a loss due to the vendor being breached.
  • A requirement that the entity be able to audit the third party vendor (you may recall some issues around Blue Cross and their refusal to let the feds audit them.  With this clause in the contract, no audit, no payments).
  • Finally, reps and warrants regarding the third party’s information security.

This is only a partial list of the requirements, but as you can see, the implications are serious.  If Target’s refrigeration vendor had to indemnify them, the vendor would be out of business.

AND, the NYDFS is working with other regulators to get them to adopt these same rules.

So, while this only affects New York regulated entities and any company that does business with them, expect this to grow.  Look for a future blog post on what California is doing in this area.

One option is to wait until the rules are mandatory and then scramble to react to them.  Alternatively, you could be proactive and create a vendor risk management program under your timeline.  The second way may be less stressful.  It will allow you to grow the program over time as you work out the kinks.


Information for this post came from HousingWire.