Category Archives: Breach

Come On Folks – Another Amazon S3 Breach

AgentRun is a startup that helps independent insurance agents and brokers manage customer relationships (CRM) and they are the latest company to do the perp walk for leaving an Amazon storage bucket unprotected.

Compromised were thousands of client’s sensitive data files like insurance policy documents, health data, medical data, social security and medicare cards, blank checks for payment info and financial data.

Andrew Lech admitted to the faux-pas and quickly fixed it.

But not to worry;  their web site says that the service is secure and uses the latest encryption technology.  Unfortunately, it doesn’t, in this case, require passwords.  Of course, that statement is mostly meaningless, although it MAY be possible to use it in court.  Probably not sufficient to gain a win, however.

Information for this post came from ZDNet.

How do you protect yourself?

First thing – who do you think is liable for the breach?  If you said AgentRun, you are very likely wrong.  the terms of services says:

h.  … Your use of the Service is at your own risk.
i. Among other things, the Service Provider does not warrant or represent to the client that:
  • defects or bugs within the Service will be eliminated or fixed
  • the client’s use of the service will meet the client’s qualifications
  • the Service will be error free, secure or undisrupted to the client
  • any information, regarding the clients use of the Service, will be accurate, current or credible
j. Warranties do not apply to the Service except to the degree they are expressed in the Agreement.
  • The Service provider is not responsible or liable for any direct, indirect or consequential damage to client which may be incurred in relation with the service, including:
  • damage associated with corruption of, deletion of or failure to store any Client’s Content
  • damage associated with any changes or alterations which the Service Provider may make to the Service
  • damage associated with the Client’s inability to provide the Service Provider with credible and accurate account information
  • damage associated with the Client’s inability to protect and secure the Client’s account details (such as a username and password)
  • damage associated with any temporary or permanent interruption in the provision of the Service
And, to add insult to injury, it also says:
n. The client must indemnify the Service Providers, its employees, employers, affiliates, etc. for any and all claims, losses, damage, costs and liabilities resulting from the breach of the Agreement and from the use of the Clients Account.

Source for the terms of service: https://agentrun.com/legal.html

If you are a large enough company, make the vendor give you preferred terms of service if they want your business.

You need to make sure that you have GOOD cyber risk insurance and that it covers breaches at third party providers and breaches of third party (as in your client’s) data.

You should have a vendor cyber risk management program.  My guess is that AgentRun’s cyber security program may be lacking.  Don’t know for sure, but, look at the evidence.  This problem happens weekly.  

Amazon has created a whole bucket of tools for you to use to help protect yourself from self inflicted mortal wounds like this. Check out Jeff Barr’s post from last year.  Jeff is AWS’s chief evangelist.  The post can be found at https://aws.amazon.com/blogs/aws/new-amazon-s3-encryption-security-features/

Some of Amazon’s features include default encryption, automatic permission checks, detailed inventory reports and other security features.

Finally, as an executive in your company, you need to be asking your IT guys embarrassing security questions.  After all, your head will be on the chopping block if your third party provider – or you – suffer a breach.  Since sometimes it is hard to be a prophet in your own land, contract with us to be your virtual Chief Information Security Officer (vCISO).  We don’t mind asking those embarrassing questions.

 

Facebooktwitterredditlinkedinmailby feather

Better, but not Good Enough

There is a term in the cyber security world called dwell time.  Dwell time is the amount of time between the time an attacker breaks in and the good guys figure that out.

In 2011 the average dwell time was over 400 days.  According to a just released Mandiant report, that number is now only 100 days.

Over half of the attacks are discovered by the the company that was hacked, but more than a third of the attacks are still discovered by outsiders like the police.

Compare that 100 days to this.  Verizon says that the time from the first attacker action to compromise is measured in seconds.  Or, maybe, in minutes.  That gives the attacks 99 days and change to laugh.

Information for this post came from Dark Reading.

Given this insane difference between the time to compromise and the time to be discovered, what should you be doing.

First, the amount of auditing or logging that companies do needs to increase dramatically.  If you are not auditing the right events then you cannot detect attacks.

Second, there needs to be an effective alerting process.  Effective means not too much.  Not too little.  Like Goldilocks, just right – but if you have to err, unfortunately, err on the side of too much.

Once those alerts are created, there needs to be an effective response plan.  There are plenty of situations were alerts are generated and then ignored or even unseen.

It is not a simple problem, but it is possible.  If we have cut the dwell time from 400 days to 100 days, can we cut it from 100 to 25?  Or less.  Improvement is incremental.

Facebooktwitterredditlinkedinmailby feather

Email Breach at Oxygen Equipment Maker Affects 30,000

Oxygen equipment maker Inogen announced that information on 30,000 customers was hacked as an attacker compromised the credentials of an employee.

In the grand scheme of breaches, this one barely registers.  Yes, HIPAA protected information was taken (and Health and Human Services may come after them in say 2021, but it is another example of totally preventable self inflicted wounds.

OK, now that I have sufficiently beaten them up, lets look at what they did wrong.

The company is publicly traded so they need to be SOX compliant.  They should have a Board advising them on issues like cybersecurity, but likely not.  Totally silent on the issue.

The breach went from January 2 to March 14 – certainly not the longest breach, but certainly not the shortest.  I know of an incident recently where a company received indicators of a breach at 6:30 AM one day and had contained and mitigated the breach before 9:00 AM the same day and they are looking to shorten that window.  What kind of monitoring and alerting did Inogen have?  Over two months for the hacker to do the dastardly deed?  Obviously, not good enough.

The stolen emails contained name, address, phone number, email address, date of birth, date of death, Medicare ID number, insurance information and type of equipment.  What is that doing in email?  That belongs inside a secure application or web portal.  Not only is this a HIPAA violation before the breach, it is a privacy breach after the event.  The company is based in California, so the Attorney General may be rattling their cage as well.

The worker’s credentials were compromised and then the attacker logged in. From another country.  Two factor authentication would have neutered the attack and, failing that, conditional access geo-fencing would have stopped the attacker cold.  Where was their CISO?  Do they even have one?

One thing they did right – they disclosed the breach in their latest SEC filings. In light of the SEC’s new cybersecurity transparency rules, that is probably a very smart move (to disclose).  One less party out to sue them.

In the SEC filing the company said they hired a forensics firm and made users change their passwords.  Definitely impressive (not).

They have also turned on two factor authentication.  A little late, but better late than never.

Oh, yeah, they have started training.  Nice.  Would have been nicer years ago.

One challenge is the founders are a few young kids who did not, until this, have many battle scars.

I am guessing they are getting those scars now.

Finally, they say in the SEC filing that they have insurance but it may not cover the costs.  Cyber insurance is good, but you better have enough and the right options.  Depending on what lawsuits happen and what regulators (such as Cali and HHS) go after them, this could cost them a couple of million or more.  Depending on what coverage they have, they could be writing all or part of that check themselves.

As a side note, Airway Oxygen, likely a competitor, told HHS last June that they had a breach affecting 500,000 customers.

Cardionet paid a fine to HHS last year of $2.5 million.  That is just the fine and doesn’t cover any other costs.  With a fine like that, Inogen’s total costs could be in the $3-$5 million range.  If they have a $1 million cyber policy, they will be writing a large check.

Other companies could learn from their lessons.  The learning part is free.  OR, they can wait until their story is in the news.  That can be a tad more expensive!

Information for this post came from Careers Info Security.

Facebooktwitterredditlinkedinmailby feather

Friday News

Delta Airlines Terms of Service “Concern”

Users that tag pictures with Delta Skymiles hashtags (#Skymileslife and #Deltamedalionlife) agree to some interesting terms and conditions according to a recently modified Delta Skymiles program terms.  First, they give Delta a perpetual license to use the tagged content (photos) and (b) they warrant they are the sole owner of the content and have the authority to post the content.  Note that you are not posting this on Delta’s web site.  The next term is the one that is mind blowing.  (C) you agree, under your Skymiles program agreement that if you post something, say on Twitter, with those hashtags, that you will indemnify Delta and pay any legal fees, among other terms.  Pretty amazing.  (Source: BoardingArea.com).

Ransomware May Kill You – Literally

Researchers at Vanderbilt studied the mortality rate in hospitals and correlated that data to hacking attacks.  They found that the mortality rate increased by about one-third to one-half percent after an attack.  They also say that the size of the breach doesn’t seem to affect the mortality rate.  (Source: Dark Reading).

Alabama is the last state in the union to enact a data breach notification law

Almost 15 years after California’s landmark privacy law, SB 1386, became effective, Alabama passed a data breach notification law and the governor signed it.  Like many other states, it refers to “implement and maintain reasonable security” and “conduct a good faith and prompt investigation” in case of a breach.  What is a bit less customary is that they give some detailed specifics as to what is reasonable.  Yeah for Alabama.  (Source: Ballard Spahr)

Homeland Security Says Rogue Stingrays Operating in DC

Stingrays, one brand name for cell phone call interceptors were found by Homeland Security to be operating in DC last year according to a memo between DHS and Sen. Ron Wyden (D-OR).  DHS said that they did not have the equipment or funding to monitor for rogue devices.  It makes sense that foreign intelligence services would be very interested in intercepting cell phone calls made by government officials in DC and likely many other cities where there are large defense and intelligence communities.  Wyden said that leaving cell phone security to the phone companies has been disastrous, which is certainly true, but he didn’t mention efforts by the NSA to weaken crypto over the last 20 years or efforts by the FBI to intentionally build in back doors to all encrypted communications, so, maybe, what goes around, comes around  (Source: Associated Press).

Why Vendor Cyber Risk Assessments Are So Important

Bangalore based Business Process Outsourcer [24]7.ai admitted that they suffered a breach between September 26th and October 12th 2017.  Being an outsource vendor, their breach likely affected many customers.  Among those that have fessed up, so far, are Delta Airlines, Sears and yesterday, Best Buy.

[24]7.ai said that they thought that only a million of their customers credit cards were affected by the breach

You can outsource the work, but you can’t outsource the liability.  Even though Sears, Delta and Best Buy are trying to throw [24]7.ai under the cyber liability bus, who their customers will blame is them (Source: Economic Times of India).

Facebooktwitterredditlinkedinmailby feather

Saks, Lord and Taylor Demonstrate How Not to Respond to Being Hacked

The New York Times is reporting that The Hudson’s Bay Company that owns Saks Fifth Avenue and Lord & Taylor confirmed that some number of stores run under these names and also Saks Off 5th were hacked and 5 million credit cards are available to be sold on the black market.

The breach is one of the larger retail credit card breaches – Target and Home Depot were each about ten times the size.  The Times says this is an indication of how difficult it is to secure credit card transaction systems.  While there is some truth to the statement, the more likely reality is that companies do not want to spend the money to fix horrible, decades old, security designs.  If you are unwilling to make changes then you should not be surprised at what you get.

Information for this post came from the New York Times.

So what can you do?

First, if you are a merchant, you need to secure your credit card system.  Hudson’s Bay said this only affected in store systems, not online shopping.

If you only allow those systems to connect to your inventory system, your loyalty card system and the credit card processor’s systems – by specific IP addresses, you have made the game geometrically harder for the hacker.  What you cannot see is difficult to hack.  For every exception you make to this rule, you make the hacker’s job easier.

You should be monitoring web traffic for unusual addresses.  While they have not given us any details, my guess it there were unusual traffic patterns.  Of course, you have to be watching for those patterns.

As a consumer, you should be watching your credit card transactions in real time.  I have had cards stolen numerous times.  The hackers get one transaction from me.  Recently, it happened to me and by the time the hackers were trying to use the card a second time, I was on the phone with the bank, they were watching the traffic stream and they killed the transaction in real time.  If hackers can’t use stolen cards, they won’t steal them.  It is no fun at that point.

How the public found out about the attack was from a security firm, Gemini Advisors, not from Hudson’s Bay.  How did they let that happen?  Did Hudson’s Bay think they could keep the breach secret?

Given the size of Hudson’s Bay, they should have had a crisis communications plan in place to be ready to deal with this.  If they did, it didn’t work.

Gemini (not Hudson’s Bay) said the hackers were in the system since last May.  They were active in the system for almost a year and they didn’t know it?  That doesn’t inspire confidence.

Hudson’s Bay said that they wanted to assure their customers that they weren’t liable for fraudulent transactions.  Note that they didn’t say that under federal law credit card companies are responsible for all fraudulent charges after the  first $50 or debit card charges after the first $500, subject to certain rules.  This is not Hudson’s being nice, this is federal law.  If you are going to hire spin doctors, do a better job of spinning.

Regarding Social Security numbers, driver’s license numbers and PINs – bottom line, they don’t think they were compromised.  That data should be tokenized so that there is no question that it can’t be compromised.  Bad system design.

If you need help with solving problems like this, give us a call.

Facebooktwitterredditlinkedinmailby feather

Orbitz Data Breach Affects Almost 900,000 Consumers

Orbitz announced today that hackers accessed customer data including credit cards submitted to one of their websites between January 2016 and June 2016 and data on an Orbitz partner web site between January 2016 and December 2017 – two years worth of data.  They estimate it to be around 880,000 cards, but they, apparently, don’t really know.

They also say that they don’t think that Social Security numbers, passports and itinerary info was accessed.  At least they don’t think so at this point.

Information that was accessed includes names, credit cards, birth dates, phone numbers, emails, physical and billing addresses and gender info.

But they don’t really know.

It seems like they don’t know much of anything.

Other than “Ensuring the safety and security of the personal data of our customers and our partners’ customers is very important to us”.

Orbitz, a division of Expedia, say that they enhanced their security right away after they discovered the breach.  Nice, but their timing is a bit off.

Okay, so now that I beat them up, what should you do?

First, that answer depends on whether you are a web site operator or a consumer.

For the consumer, it is easier – almost all credit, debit and bank account providers can text you if your card or account is used.  You will receive the text within seconds.  SET THIS UP.  It is free.

If your bank or credit card company is one of the very few that don’t offer this, move.  Seriously.  It is that much of a game changer.

If you can detect credit card fraud in seconds, you have completely neutered a hacker’s desire to steal or your your credit card.  They are toast.

Most people don’t do this because, they figure, it is the bank’s problem or the credit card company’s problem.  That is true, BUT ONLY FOR CONSUMERS.  THIS IS NOT TRUE FOR BUSINESSES.  But, the fraud raises the price on everything you buy by several percent.  Get rid of the fraud and things could be less expensive.  More importantly, it is a huge hassle to deal with the fraud.  Avoiding it improves your sanity. 

For web site operators, AKA business owners, there are many things you can do.

For credit cards, why are you storing credit card numbers at all.  There is zero reason to do this other than laziness.  Tokenizing the card numbers reduces the fraud risk to zero, reduces your liability and you can advertise that you don’t store customers credit card info.  You can still do recurring credit card charges.  If you don’t know how to do this, contact us for help.

Next, Expedia should be embarrassed beyond belief that they don’t know what was accessed and what was stolen.  Logging of data access has become much simpler over the past few years.  Step up the logging and keep the logs.  And, figure out how to do the reporting on that data as well.

Next, figure out what data you really need to preserve.  If you can delete it without affecting your business, delete it.  What you don’t have cannot be stolen.

Detect the breach faster.  While it appears that Expedia detected the breach after it was operating for only several months, could you detect it in one month?  One week? One day?   Yes, yes and yes, if your systems are designed right.

Finally, make sure that you have an incident response program tuned up and ready to go.  Document it.  Train people.  Give them parachutes so they can parajump into the fray when needed.  Social media will crucify you within a few hours of the public announcement of the breach.  You better be ready to counteract that.

If you need help with this, please contact us. 

Information for this post came from Engadget.

Facebooktwitterredditlinkedinmailby feather