The Magic of Hash

Hi, all –

Time for a bedtime story? A little light reading? Something to listen to on the treadmill?

Come listen to our CEO, Brent Huston, riff on blockchain, trust models, and ancillary bits.

The audio is HERE. And the accompanying slides are HERE.

Until next time, stay safe out there…take care of earth, it’s the only planet with chocolate!

If you would like to know more about MicroSolved or its services please send an e-mail to info@microsolved.com or visit microsolved.com.

Positive Train Control: Skating away on the thin ice of a new day?

Positive Train Control: Skating away on the thin ice of a new day?

From the movie “The Polar Express


That line: “Skating away on the thin ice of a new day” is from a Jethro Tull song by the same name. (Yes – I am that old 😉 ).

It came to me as I was reflecting on the reading I’ve been doing on the topic of Positive Train Control (PTC).

PTC is an idea rather than any specific technology or architecture.  Continue reading

Encrypt That Drive

Promise me you’ll return to this blog piece, but go ahead and open a new tab and search for “stolen laptop.” Filter the search results for a specific year. Or refine the search within an industry, eg. healthcare or financial. Too many results. Too many incidents. The U.S. Department of Health and Human Services, Office for Civil Rights, has a breach portal – https://ocrportal.hhs.gov/ocr/breach/breach_report.jsf – only incidents involving more than 500 PHI records are in the database. Search for theft of laptop.

Continue reading

Micro Podcast – Amazon AWS

In this episode of the MSI podcast, we discuss recent issues involving AWS misconfigurations that led to incidents, common problems, the importance of proper configurations to avoid these issues and how we can help you identify them in your environment.

Listen here

If you would like to know more about MicroSolved or its services please send an e-mail to info@microsolved.com or visit microsolved.com.

IoT Smart Devices: The Honeymoon is Over!

What isn’t an Internet of Things device these days?! Companies are literally flooding the consumer market with smart chip-equipped devices you can control with your iPhone or Android (which themselves are equipped with smart chips – sigh!). Smart bike locks, smart egg trays, smart water bottles, smart dental floss dispensers, smart baby-changing pads!! These are all real devices.

Continue reading

Do You Have Production Data in your Test Environment?

We’ve talked about development servers, and the perils of internet facing development environments.  Now, let’s talk about what is IN your development environment.

Another issue we run into fairly often with dev environments,…they are set up to use production data, and sometimes this data is piped in directly at night with no modification. This introduces a risk of not only exposing this data through vulnerabilities within the development environment but could allow a contractor or unauthorized employee to view sensitive information.

Continue reading

It’s Dev, not Diva – Don’t set the “stage” for failure

Development: the act, process, or result of developing, the development of new ideas. This is one of the Merriam-Webster definitions of development.

It doesn’t really matter what you call it…dev, development, stage, test. Software applications tend to be in flux, and the developers, programmers, testers, and ancillary staff need a place to work on them.

Should that place be out on the internet? Let’s think about that for a minute. By their very nature, dev environments aren’t complete. Do you want a work in progress, with unknown holes, to be externally facing? This doesn’t strike me as the best idea.

But, security peeps, we HAVE to have it facing the internet – because REASONS! (Development types…tell me what your valid reasons are?)

And it will be fine – no one will find it, we won’t give it a domain name!

Security through obscurity will not be your friend here…with the advent of Shodan, Censys.io, and other venues…they WILL find it. Ideally, you should only allow access via VPN or other secure connection.

What could possibly go wrong? Well, here’s a short list of SOME of the things that MSI has found or used to compromise a system, from an internet facing development server:

  • A test.txt file with sensitive information about the application, configuration, and credentials.
  • Log files with similar sensitive information.
  • .git directories that exposed keys, passwords, and other key development information.
  • A development application that had weak credentials was compromised – the compromise allowed inspection of the application, and revealed an access control issue. This issue was also present in the production application, and allowed the team to compromise the production environment.
  • An unprotected directory that contained a number of files including a network config file. The plain text credentials in the file allowed the team to compromise the internet facing network devices.

And the list keeps going.

But, security peeps – our developers are better than that. This won’t happen to us!

The HealthCare.Gov breach https://www.csoonline.com/article/2602964/data-protection/configuration-errors-lead-to-healthcare-gov-breach.html in 2014 was the result of a development server that was improperly connected to the internet. “Exact details on how the breach occurred were not shared with the public, but sources close to the investigation said that the development server was poorly configured and used default credentials.”

Another notable breach occurred in 2016 – an outsourcing company named Capgemini https://motherboard.vice.com/en_us/article/vv7qp8/open-database-exposes-millions-of-job-seekers-personal-information exposed the personal information of millions of job seekers when their IT provider connected a development server to the internet.

The State of Vermont also saw their health care exchange – Vermont Connected – compromised in 2014 https://www.databreachtoday.asia/hackers-are-targeting-health-data-a-7024 when a development server was accessed. The state indicates this was not a breach, because the development server didn’t contain any production data.

So, the case is pretty strongly on the side of – internet facing development servers is a bad idea.

Questions? Comments? What’s your take from the development side? I’d love to hear from you – lwallace@microsolved.com, or @TheTokenFemale on Twitter!

If you would like to know more about MicroSolved or its services please send an e-mail to info@microsolved.com or visit microsolved.com.

 

 

 

 

 

 

 

 

 

Stopping the Flow of Business: EDI as a Natural Gas Pipeline Attack Vector

In the not too-distant past I was involved in helping secure the information infrastructure of a major EDI “VAN”.

How’s that  for gibberish?   Some definitions are in order:

EDI = “Electronic Data Interchange”.  Effectively, a collection of standards for the encoding of documents such as invoices, purchase orders, bills of lading, medical information, and – it seems – information pertaining to the business of buying, selling and moving natural gas.

EDI dates from the 1970’s. It took advantage of pre-Internet communication mechanisms but quickly was adapted to the Internet and likely will be to blockchain.

EDI “trading partners” can communicate directly, but often they rely on  third-party EDI specialists to handle communication with their various trading partners.  These are the EDI “Value Added Networks” (VAN).

EDI is the unsung hero of modern commerce.

Everything we buy or sell has a secret life as an EDI document. Usually a number of them.

Not surprisingly, natural gas pipeline companies use EDI in the running of their business, communicating information about availability and pricing to their customers and government.  A few months ago,  the business of some natural gas pipeline companies was disrupted by the sudden unavailability of those EDI services.

The attack, in March 2018, was directed against a central provider of EDI services to several major natural gas pipeline operators. Although it did not affect actual in-field operations, it did stop all normal business traffic for several days, causing confusion and a fall-back to alternate communication mechanisms.

Of greater concern was the loss of potentially sensitive information about internal business structure, all of which can be inferred from the ebb and flow of EDI data.  Such information can be invaluable to an attacker and in this case can be an aid in eventually attacking actual pipeline operations.

The point here is that it is easy to view such operations as strictly an ICS security concern, and that with proper segmentation of business from ICS infrastructure all will be well.

I’ve had some experience in that ICS world over the last few years and know that segmentation is often incomplete at best. Even when segmentation is present, your business can still be vulnerable to attacks on exposed business systems that have process flow links to ICS.

What to do?

  • Know how you use EDI and what your supporting infrastructure is.
  • Know who your EDI providers are and what security measures they employ
  • Do a business impact analysis of your EDI environment. What happens if it goes away?
  • Ensure you really do have segmentation of your business and ICS worlds. Make sure the places they touch are known, secured, and monitored.

 


See:

EDI defined: 

https://www.edibasics.com/what-is-edi 

https://en.wikipedia.org/wiki/Electronic_data_interchange

https://www.edibasics.com/edi-resources/document-standards

Natural Gas Industry Usage of EDI:

http://latitudestatus.com/

https://www.naesb.org/pdf4/update031413w4.docx

Quote: “The NAESB wholesale natural gas cybersecurity standards facilitate an infrastructure of secure electronic communications under which the electronic transmission of data via EDI or browser based transactions is protected. There are more than fifty separate transactions identified for nominations, confirmations, scheduling of natural gas; flowing gas transactions including measurement, allocations, and imbalances; invoicing related transactions including invoices, remittances, statement of account; and capacity release transactions.”

https://www.edigas.org/faq/

http://www.rrc.texas.gov/oil-gas/applications-and-permits/oil-gas-edi-filing-deadlines/

The Attack:

https://www.eenews.net/stories/1060078327

http://securityaffairs.co/wordpress/71040/hacking/gas-pipeline-operators-hack.html

https://www.bloomberg.com/news/articles/2018-04-03/day-after-cyber-attack-a-third-gas-pipeline-data-system-shuts

EDI Security:

https://www.acsac.org/secshelf/book001/18.pdf

Quote:  “EDI security appears at several interrelated stages:

  • The user/application interface,
  • EDI applications and value added services,
  • The processing (both batch and interactive) and storage of EDI messages,
  • The communication of these messages in an open systems environment”

If you would like to know more about MicroSolved or its services please send an e-mail to info@microsolved.com or visit microsolved.com.

They Price It Right! Come on down…

Healthcare from United States, come on down! Welcome to “They Price It Right!” There goes the industry, high-fiving all the other industries in the studio as it rushes towards Drew Carrey and the stage. And pays the ransom.

In 2017, healthcare organizations accounted for 15% of all security incidents and data breaches, second only to financial institutions (from Verizon’s 2017 DBIR). 66% of malware was installed through either email links or attachments. The healthcare industry has also been hard hit with ransomware in recent years.

* The above images captured from Verizon’s 2017 Data Breach Investigations Report

The last several years have seen a dramatic increase in ransomware within healthcare. To quote the CEO of an organization that DID pay out the ransom demand, “These folks have an interesting business model. They make it just easy enough. They price it right.” Symantec’s ISTR on Ransomware 2017 reports the average ransom demand “appears to have stabilized at US$544 indicating attackers may have found their sweet spot.” Ahhh…can just picture the blackmailer getting a notification that their target had succumbed and paid up…that hit the sweet spot.

However, a reminder; a $500 ransom may not seem much to an organization with millions or billions in revenue, but that’s per infection (sorry, pun not intended as we’re discussing the healthcare industry). Dozens or hundreds of infection can easily tally up the ransom to total in the tens or hundreds of thousands.

Furthermore, paying the sweet spot ransom does not guarantee even a bittersweet outcome. SentinelOne’s 2018 Ransomware Study shows 42% of ransom payments did not result in data recovery. 58% demanded a second payment.

* The above image captured from SentinelOne’s Global Ransomware Study 2018

Most ransomware is delivered through email. Phishing. Spearphishing. Targeted targets. Email addresses for an organization can easily be harvested using readily available open source tools. 15 minutes to create a phishing campaign with the newly found targets with a link or malicious attachment. The context of the email can be social media related, user needs to reset their password, they have a package that was undelivered, the CEO has attached a memo addressed to all staff. The recent Russian indictments – regardless of the reader’s political leanings – are proof that PHISHING WORKS! (Also blogged here in stateofsecurity.com)

Technology has come a long way – email filters, domain verification, Sender Policy Framework, malware and link scanners – plus many more help in filtering out the 50-70% of the email traffic that is spam. But they still get through. I know for one my Inbox is not spam-free or devoid of any phishing messages.

Since technology is not at the point where it’s able to stop all phishing email, it is up to the user to NOT click on that link or attachment. Sure, there are technologies that prevent bad things from happening if a user DOES click on a phishing link or malicious attachment. But then again, technology is not at the point where they are 100% effective.

Businesses with big budgets buy all kinds of hardware and software solutions to try to counter phishing. But they ignore a big piece of the phishing attack model, and that is the end user. And here, education and training is imperative.

Repeating phishing exercises should be conducted on all or selected groups of employees. These campaigns should be at not-too-regular intervals, so as not to evoke an anticipation from the employees – alright, here come some vaguely suspicious email on the first day of each quarter; I’ll just delete them. Then the rest of the year, they blatantly open, view and click on any and all email links. The simulated campaigns should be randomized and as unexpected as possible.

These campaigns should also be followed up with some education, either some static web pages, training video or live in person session. Phishers are always coming up with new tricks and methods. As a result, end users should be brought up to speed with their new tricks. A couple academic research papers on the efficacy of phishing training demonstrate that EDUCATION WORKS! (links under Resources below)

Then there needs to be a culture of non-retribution. Phishing exercises should be conducted with learning as the objective. Employees should come away with a heightened awareness of phishing and the social engineering tricks used by phishers that make you just want to click that link/attachment.

Employees should be encouraged to report any suspicious email so that word gets around. Homeland Security’s “See something, say something” campaign applies here too; someone is perhaps targeting your firm, alert your fellow colleagues.

Resources:

https://www.verizonenterprise.com/resources/reports/2017_dbir_en_xg.pdf

https://go.sentinelone.com/rs/327-MNM-087/images/Ransomware%20Research%20Data%20Summary%202018.pdf

https://www.healthcaredive.com/news/must-know-healthcare-cybersecurity-statistics/435983/

https://www.symantec.com/content/dam/symantec/docs/security-center/white-papers/istr-ransomware-2017-en.pdf

https://blog.barkly.com/phishing-statistics-2016

http://www.cs.cmu.edu/~jasonh/publications/apwg-ecrime2007-johnny.pdf

https://www.usenix.org/system/files/conference/soups2017/soups2017-lastdrager.pdf

https://www.dhs.gov/see-something-say-something/about-campaign

If you would like to know more about MicroSolved or its services please send an e-mail to info@microsolved.com or visit microsolved.com.