We’ve just released a white paper on the topic of leveraging MachineTruth™, our proprietary network and device analytics platform, to segment or separate network environments.
Why Network Segmentation?
The paper covers the reasons to consider network segmentation, including the various drivers across clients and industries that we’ve worked with to date. It also includes a sample work flow to guide you through the process of performing segmentation with an analytics and modeling-focused solution, as opposed to the traditional plug and pray method, many organizations are using today.
Lastly, the paper covers how MachineTruthTM is different than traditional approaches and what you can expect from such a work plan.
To find out more:
If you’re considering network segmentation, analysis, inventory or mapping, then MachineTruthTM is likely a good fit for your organization. Download the white paper today and learn more about how to make segmentation easier, safer, faster and more affordable than ever before!
If you haven’t heard about our MachineTruth™ offering yet, check it out here. It is a fantastic way for organizations to perform offline asset discovery, network mapping and architecture reviews. We also are using it heavily in our work with ICS/SCADA organizations to segment/enclave their networks.
Recently, one of our clients approached us with some ideas about using MachineTruth to PROVE that they had segmented their network. They wanted to reduce the impacts of several pieces of compliance regulation (CIP/PCI/etc.) and be able to prove that they had successfully implemented segmentation to their auditors.
The project is moving forward and we have discussed this use case with several other organizations to date. If you would like to talk with us about it, and learn more about MachineTruth and our new bleeding edge capabilities, give us a call at 614-351-1237 or drop us a line via info <at> microsolved <dot> com.
Windows Server 2003 has officially reached it’s end-of-life date. Does this mean that all of your Windows Server 2003 servers will be hacked on July 16th? Probably not. However, it is worthwhile to ensure that your organization has a plan in place to migrate all of your applications and services off of this legacy operating system. This is especially true if you have any Windows Server 2003 systems that are exposed to the internet. It is only a matter of time until a new vulnerability is discovered that affects this operating system.
As a former Windows Systems Administrator, I understand how difficult it can be to convince an application owner to invest the time and resources into migrating a system or service to a new operating system. Despite the fact that these systems have a heightened risk of being compromised, it’s very possible that your organization doesn’t have the financial resources to migrate your applications and services to a new operating system. You’re not alone. I found over 1.3 million servers running IIS 6.0 in Shodan. Over 688,000 of these servers are in the United States. However, there are still ways to reduce the risk of hosting these legacy operating systems until a migration plan is put into place.
A few ways to reduce the risk of hosting an application on a legacy operating system are:
Discover and document – You can’t protect a system if you don’t know it exists. Take some time to identify and document all of the legacy and unsupported operating systems in your network.
Learn about the application – Take some time to learn some details about the application. Is it still even being accessed? Who uses it? Why is it still hosted on an unsupported operating system? Are there other options available?
Educate the business users – If financial resources are an issue, take some time to explain the risks of hosting this application to the business users. Once they gain an understanding of the risk associated with hosting their application on a legacy OS, they can help secure funding to ensure that the application is upgraded.
Isolate – Segmenting the legacy system can reduce the risk that it is accessed by an attacker. It also can decrease the likelihood that a compromise of the legacy system will spread to other servers.
Update and secure – Install all available patches and updates. Not only for the operating system, but the hosted applications as well.
Perform thorough log analysis – Implement some sort of centralized logging platform to ensure you have the ability to detect any anomalies that occur within these systems.
Plan for the worst – Be prepared. Have a plan in place for responding to an incident involving these systems.
My Dad called me earlier this week to ask if I heard about the FBI’s investigation of the St. Louis Cardinals. My initial reaction was that the investigation must be related to some sort of steroid scandal or gambling allegations. I was wrong. The Cardinals are being investigated for allegedly hacking into the network of a rival team to steal confidential information. Could the same team that my Grandparents took me to see play as a kid really be responsible for this crime?
After I had time to read a few articles about the alleged hack, I called my Dad back. He immediately asked me if the Astros could have prevented it. From what I have read, this issue could have been prevented (or at least detected) by implementing a few basic information security controls around the Astros’ proprietary application. Unfortunately, it appears the attack was not discovered until confidential information was leaked onto a pastebin site.
The aforementioned controls include but are not limited to:
Change passwords on a regular basis – It has been alleged that Astros system was accessed by using the same password that was used when a similar system was deployed within the St. Louis Cardinals’ network. Passwords should be changed on a regular basis.
Do not share passwords between individuals – Despite the fact that creating separate usernames and passwords for each individual with access to a system can be inconvenient, it reduces a lot of risk associated with deploying an application. For example, if each member of the Astros front office was required to have a separate password to their proprietary application, the Cardinals staff would not have been able to successfully use the legacy password from when the application was deployed in St. Louis. The Astros would also have gained the ability to log and track each individual user’s actions within the application.
Review logs for anomalies on a regular basis – Most likely, the Astros were not reviewing any kind of security logs surrounding this application. If they were, they might have noticed failed login attempts into the application prior to the Cardinals’ alleged successful attempt. They also might have noticed that the application was accessed by an unknown or suspicious IP address.
Leverage the use of honeypot technology – By implementing HoneyPot technology, the Astros could have deployed a fake version of this application. This could have allowed them to detect suspicious activity from within their network prior to the attackers gaining access to their confidential information. This strategy could have included leveraging MSI’s HoneyPoint Security Server to stand up a fake version of their proprietary application along with deploying a variety of fake documents within the Astros’ network. If an attacker accessed the fake application or document, the Astros would have been provided with actionable intelligence which could have allowed them to prevent the breach of one of their critical systems.
Do not expose unnecessary applications or services to the internet – At this point, I do not know whether or not the Astros deployed this system within their internal network or exposed it to the internet. Either way, it’s always important to consider whether or not it is necessary to expose a system or service to the internet. Something as simple as requiring a VPN to access an application can go a long way to securing the confidential data.
Leverage the use of network segmentation or IP address filtering – If the application was deployed from within the Astros internal network, was it necessary that all internal systems had access to the application? It’s always worthwhile to limit network access to a particular system or network segment as much as possible.
Honestly, I hope these allegations aren’t true. I have fond memories of watching the Cardinals win the World Series in 2006 and 2011. I would really hate to see those victories tarnished by the actions of a few individuals. However, it’s important that we all learn a lesson from this..whether it’s your email or favorite team’s playbook…don’t overlook the basic steps when attempting to secure confidential information.
Another clever use for HoneyPoint™ Agent, running on a Linux system without SMB components, is to have the system listen on the Windows SMB ports (135-139 & 445). The HoneyPoint will then inventory the Windows machines and other SMB speaking tools that attempt to contact it. Since this traffic is pretty routine, it will serve as an inventory mechanism for these types of systems on the local collision domain, or other “same-as-on-the-LAN” segments.
Running HoneyPoint in this fashion has been very useful to several of our ICS customers and has allowed them a quick, and most importantly, passive way to identify hosts on the same segment. No probes or scans needed!
Give us a call today at (614) 351-1237 or email us at email@example.com if you want to discuss how HoneyPoint might be used in your environment. We look forward to talking with you, and as always, thanks for reading!
We are proud to announce the immediate availability of an entirely new service offering in our security tool kit, made possible by TigerTrax™.
This service offering leverages the power of MSI’s proprietary TigerTrax analytics platform to parse, correlate and visualize the configurations (and packet logs (if desired)) from the routers, switches and firewalls of your network “en masse”.
Our security and analytics teams then create detailed maps of the network as seen from the eyes of the machines, document the various network segments and their relationships, build a hierarchy of powerful machines and segments, identify hardening techniques that could help your organization better secure your network and provide insights into the gap between your organization’s “common wisdom” versus the real environment.
We can even teach “Close The Gap” sessions to help re-align your team’s “common wisdom” with “machine truth” and to help socialize the new knowledge to other groups.
How it works:
The client delivers the configuration and log files as needed for the service. MSI can assist with this step, if needed, at an additional hourly consulting fee.
The offering uses TigerTrax to perform automated analysis of the configuration and log files as needed – holistically, systemically and “en masse”.
Various data points are delivered to the analysts and security team who then create the documentation, maps and reports. Visualized data is also generated using the TigerTrax platform where appropriate.
Any professional services, such as interviews/questionnaires, gap analysis and training are provided by MSI team members using our proprietary delivery methodologies.
Completely passive, offline analysis is perfect for critical networks.
Three different levels of service are available, as is single – one time engagements (perfect for M&A activities, and new IT management) or ongoing subscriptions that allow organizations to track changes and maintain knowledge over time. The highest level of service also includes 30 days worth of packet analytics to identify overtly compromised hosts and to determine “normal operating conditions”, which is often quite useful for incident response activities in the future.
Give is a call today at (614) 351-1237 or email us at firstname.lastname@example.org to start a conversation about how we can help you know the truth about your network!