Quick Use Case for HoneyPoint Wasp

Several organizations have begun to deploy HoneyPoint Wasp as a support tool for malware “cleanup” and as a component of monitoring specific workstations and servers for suspicious activity. In many cases, where the help desk prefers “cleanup” to turn and burn/re-image approaches, this may help reduce risk and overall threat exposures by reducing the impact of compromised machines flowing back into normal use.

Here is a quick diagram that explains how the process is being used. (Click here for the PDF.)

If you would like to discuss this approach in more detail, feel free to give us a call to arrange a one on one session with an engineer. There are many ways that organizations are leveraging HoneyPoint technology as a platform for nuance detection. Most of them increase the effectiveness of the information security program and even reduce the resources needed to manage infosec across the enterprise!

Snort and SCADA Protocol Checks

Recently, ISC Diary posted this story about Snort 2.9.2 now supporting SCADA protocol checks. Why is this good news for SCADA?

Because it is a lower cost source of visibility for SCADA operators. Snort is free and a very competitive solution. There are more expensive commercial products out there, but they are more difficult to manage and have less of a public knowledge base and tools/options than Snort. Many security folks are already familiar with Snort, which should lower both the purchase and operational cost of this level of monitoring.

Those who know how to use Snort can now contribute directly to more effective SCADA monitoring. Basically, people with Snort skills are more prevalent, so it becomes less expensive to support the product, customize it to their specific solution and manage it over time. There are also a wide variety of open source add-ons, and tools that can be leveraged around Snort, making it a very reasonable cost, yet powerful approach to visibility. Having people in the industry who know how the systems work and who know how Snort works allows for better development of signatures for various nefarious issues.

It is likely to be a good detection point for SCADA focused malware and manual probes. The way these new signatures are written allows them to look for common attacks that have already been publicly documented. The tool should be capable of identifying them and can do so with ease. In terms of trending malware, (not currently) these attack patterns have been known for some time. 

The specifics of the probes are quite technical and we would refer readers to the actual Snort signatures for analysis if they desire.

By learning the signatures of various threats to the industry, people in the field can translate that into Snort scripts which can detect those signatures on the network and make the proper parties aware in a timely manner. Snort has the flexibility (in the hands of someone who knows how to use it) to be molded to fit the needs of nearly any network.

It makes an excellent companion tool to a deployment of HoneyPoint deep inside SCADA and ICS networks. In this case, Snort is usually deployed on the internal network segment of the ICS/SCADA firewall, plugged into the network switch. HPSS is as shown.  

 

 

 

 

 

 

 

 

If you’re looking for a low-cost solution and plenty of functionality for your SCADA, this recent development is a welcome one!

What the Heck Is FeeLCoMz?

FeeLCoMz is a string I often get a lot of questions about. Basically, people see it and other strings in their logs, or if they are unlucky, they run into it like this, in a file in their web directories:
 
 Basically, if this is in the file system, then the system has been compromised, usually by a PHP RFI vulnerability. Other strings to check for, if you feel you want to run some basic grep checks against web files, include: 
 
“FaTaLz”,”KinCay”,”CreWz”,”TeaM”,”CoMMunity”,”AnoNyMous”,”Music”,
“ProGraMMeR”,”CyBeRz” and “mIRC”
 
If you find those strings, they usually indicate other PHP scanners, worms or attack tools have compromised the system. Now, if you don’t find those, it does NOT mean the system is safe, the list of all of those relevant strings would be too large and dynamic to manage. 
 
Another good grep check to parse files for in web directories, especially PHP and text files, if the nearly ubiquitous, “base64_decode(“, which is an absolute favorite of PHP bot, shell and malware authors. Any files you find using that call should be carefully inspected.
 
If you want to find more information on how PHP RFI attacks and other such issues occur, check out these links 
 
 
Basically, if you find files with the FeeLCoMz tag in it in the web directories, you have some incident response and investigation work to do. Let us know if we can assist, and stay safe out there. 
 
PS – It’s a good idea to have all PHP applications, even common ones like WordPress and the like, assessed prior to deployment. It might just save you some time, hassle and money! 

Quick Use Case for HoneyPoint in ICS/SCADA Locations

 

 

 

 

 

 

 

This quick diagram shows a couple of ways that many organizations use HoneyPoint as a nuance detection platform inside ICS/SCADA deployments today.

Basically, they use HoneyPoint Agent/Decoy to pick up scans and probes, configuring it to emulate an endpoint or PLC. This is particularly useful for picking up wider area scans, probes and malware propagations.

Additionally, many organizations are finding value in HoneyPoint Wasp, using its white list detection capabilities to identify new code running on HMIs, Historian or other Windows telemetry data systems. In many cases, Wasp can quickly and easily identify malware, worms or even unauthorized updates to the ICS/SCADA components.

The Smart Grid Raises the Bar for Disaster Recovery

As we present at multiple smart grid and utility organizations, many folks seem to be focusing on the confidentiality, integrity, privacy and fraud components of smart grid systems.

Our lab is busily working with a variety of providers, component vendors and other folks doing security assessments, code review and penetration testing against a wide range of systems from the customer premise to the utility back office and everything in between. However, we consistently see many organizations under estimating the costs and impacts of disaster recovery, business continuity and other efforts involved in responding to issues when the smart grid is in play.

For example, when asked about smart meter components recently, one of our water concerns had completely ignored the susceptibility of these computer devices to water damage in a flood or high rain area. Seems simple, but even though the devices are used inside in-ground holes in neighborhoods, the idea of what happens when they are exposed to water had never been discussed. The vendor made a claim that the devices were “water resistant”, but that is much different than “water proof”. Filling a tub with water and submerging a device quickly demonstrated that the casing allowed a large volume of water into the device and that when power was applied, the device simply shorted in what we can only describe as “an interesting display”.

The problem with this is simple. Sometimes areas where this technology is eventually intended to be deployed will experience floods. When that happens, the smart meter and other computational devices may have to be replaced en masse. If that happens, there is a large cost to be considered, there are issues with labor force availability/safety/training and there are certainly potential issues with vendor supply capabilities in the event of something large scale (like Hurricane Katrina in New Orleans).

Many of the organizations we have talked to simply have not begun the process of adjusting their risk assessments, disaster plans and the like for these types of operational requirements, even as smart grid devices begin to proliferate across the US and global infrastructures.

There are a number of other examples ranging from petty theft (computer components have after market value & large scale theft of components is probable in many cases) to outright century events like hurricanes, floods, earthquakes and tornados. The bottom line is this – smart grid components introduce a whole new layer of complexity to utilities and the infrastructure. Now is the time for organizations considering or already using them to get their heads and business processes wrapped around them in today’s deployments and those likely to emerge in the tomorrows to come.

MSI Strategy & Tactics Talk Ep. 20: Denial of Service Attacks

We haven’t seen anywhere near the thresholds that could happen with massive scale bot-nets. I think it’s clear that bot-nets are the future weapon of DoS and we’ll continue to see that until somebody takes away the capability. In addition, mobile devices are going to experience an increase in DoS attacks. – Brent Huston, MSI CEO and Security Evangelist

Denial of Service attacks were alive and well in 2011 as seen with WordPress and MasterCard. What have we learned from these types of attacks?  In this episode of MSI Strategy & Tactics, the techs discuss what DoS attacks and how organizations can respond. Take a listen! Discussion questions include:

  • Organizations have been dealing with denial of service attacks for a while now, what lessons should they have learned?
  • What about this new hashdos attack against web sites?
  • How should they create and test dos detection and response plans?
  • What is the future of denial of service attacks?
Panelists:
Brent Huston, CEO, Founder, and Security Evangelist
Adam Hostetler, Network Engineer and Security Analyst
Phil Grimes, Security Analyst
John Davis, Risk Management Engineer
Mary Rose Maguire, Marketing Communication Specialist and moderator

Click the embedded player to listen. Or click this link to access downloads. Stay safe!

Interview with Brent Huston: Meet “Paul,” An Attacker — Up Close and Personal

Many organizations we talk to still vastly underestimate the capability of the threat. They still think of the attackers and the hackers as folks who are trying to use canned exploits or use the latest version of metasploits to pop a bunch of boxes — that’s just frankly not true. “Paul” is proficient in eight different coding languages. [He’s skilled and learning.] That needs to become the mindset of the defender. – Brent Huston, CEO and Security Evangelist, MicroSolved, Inc.

What would you do if you met an attacker online? Give him a piece of your mind? Or dig a little deeper to find out what motivates him and how he operates? In this special interview, Brent Huston discusses a recent incident where he had such an opportunity.  In this fascinating conversation, Brent described how he met Paul and his attitude toward meeting another “up and coming” hacker. Take a listen! Discussion questions include:

  • How Brent tracked Paul down
  • What was Paul’s attitude toward Brent and his questions
  • A little about Paul and his skills
  • What does Paul use his compromised systems for?
  • What lessons can organizations draw from this encounter?

Interview Participants:
Brent Huston, CEO, Founder, and Security Evangelist
Mary Rose Maguire, Marketing Communication Specialist and moderator

Click the embedded player to listen. Or click this link to access downloads. Stay safe!

How to Choose a Security Vendor: Beware of “Free InfoSec”

In your search for security vendors, be aware of those who offer assessments on the “we find holes or it’s free” basis.  Below are a few points to consider when evaluating your choices.

  1. Security testing choices should not be based on price. They should be based on riskThe goal is to reduce the risk that any given operation (application, network, system, process, etc.) presents to the organization to a level that is manageable.

    Trust me, I have been in the security business for 20 years and all vendor processes are NOT created equal. Many variations exist in depth, skill level, scope, reporting capability, experience, etc. As such, selecting security testing vendors based upon price is a really bad idea. Matching vendors specific experience, reporting styles and technical capabilities to your environment and needs is a far better solution for too many reasons to expound upon here.
     

  2. The “find vulnerabilities or it’s free” mentality can backfire.It’s hard enough for developers and technical teams to take their lumps from a security test when holes emerge, but to also tie that to price makes it doubly difficult — “Great, I pay now because Tom made some silly mistake!” is just one possibility. How do you think management may handle that? What about Tom?

    Believe me, there can be long term side effects for Tom’s career, especially if he is also blamed for breaking the team’s budget in addition to causing them to fail an audit.
     

  3. It actually encourages the security assessment team to make mountains out of mole hills.Since they are rewarded only when they find vulnerabilities and the customer expectations of value are automatically built on severity (it’s human nature), then it certainly behooves the security team to note even small issues as serious security holes.

    In our experience, this can drastically impact the perceived risk of identified security issues in both technicians and management and has even been known to cause knee-jerk reactions and unneeded panic when reports arrive that show things like simple information leakage as “critical vulnerabilities”. Clearly, if the vendor is not extremely careful and mindful of ethical behavior among their teams, you can get seriously skewed views between perceived risk and real-world risk, again primarily motivated by the need to find issues to make the engagement profitable.

In my opinion, let’s stick to plain old value. We can help you find and manage your risk. We focus on specific technical vulnerabilities in networks, systems, applications and operations that attackers could exploit to cause you damage. The damages we prevent from occurring saves your company money. Look for a service vendor that provides this type of value and realize in the long run, you’ll be coming out ahead.