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.
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.
Business Email Compromise (BEC) Checklist
MSI has recently received requests from a variety of sources for guidance around the configuration and management of business e-mail, in particular the preponderance of business email compromise (BEC). Phishing attacks increased almost 500% in the previous year, as reported by Proofpoint.
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.
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.
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.
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:
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.”
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
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.