How do you Identify? Business Email Compromise #1

Business Email Compromise

business email compromise

Recently, we posted the Business Email Compromise (BEC) checklist. We’ve gotten a lot of great feedback on the checklist…as well as a few questions. What if you’re new to security? What if your organization’s security program is newer, and still maturing? How can you leverage this list?

Since the checklist is based on the NIST model, there’s a lot of information here to help your security program mature, as well as to help you mature as a security practitioner. MSI’s engineers have discussed a few ways to leverage the checklist as a growth mechanism.

Continue reading

Inventory Control a Must for Effective System Security Maintenance & Config Control

Some security controls can’t reach maximum effectiveness unless other, related controls are also in place. This is the case with system security maintenance and configuration control. If you don’t tie these controls to well maintained and updated inventories of all network assets you are bound to see vulnerabilities cropping up on your systems.

Continue reading

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.