Update on the ProtoPredator Family of Products

Today, I just wanted to provide a quick update on the ProtoPredator family of products. As you may recall, we have released ProtoPredator for Smart Meters (PP4SM) as a commercial product. It became available over one year ago and continues to be a strongly performing tool for validating the optical security of smart meters.

I have gotten several questions from clients and the community about the ProtoPredator family and what was next. I am pleased to say that we are continuing to develop and enhance ProtoPredator for Raw Serial (PP4RS). This is currently a private, in lab tool for our testing. But, we do plan to release it eventually as a commercial tool. The tool is designed to discover serial communications, explore them, adaptively identify protocols and patterns and introduce the ability to fuzz those protocols on demand. The tool has been a long time coming and we are continuing to develop its capabilities. We want to make sure we have it fully functional prior to release.

Additionally, we are working on ProtoPredator tools for ModBus, DNP3 and other ICS protocols. Those versions are behind PP4RS in development and testing, simply due to the “scratch your own itch” workload we are using for testing. Though, DNP3 is quickly rising to the front burner.

If you have any questions about ProtoPredator, or any of the products we are working on, please let us know. We are always happy to discuss our work under NDA with folks in the ICS security field. As always, rest assured that just like PP4SM, while the products are commercially available with support and upgrades, WE DO NOT RELEASE THEM TO UNVETTED PARTIES. We think smart meter testing belongs in the hands of the professionals, as does testing other ICS protocols, so we don’t release our tools to folks not involved with utilities, manufacturing of the devices or other testing groups. If you are such a stakeholder and have an interest in the tools, please get in touch.

Thanks for reading and as always, stay safe out there! 

What Do You Want from InfoSec Next Year?

Given that so many firms will spend the end of the year issuing their opinions and predictions for next year, we thought we’d go against the grain, so to speak, and instead ASK YOU what you want the next year to bring?

What do you hope the information security community accomplishes or changes in a major way next year?

What new services or changes to service offerings would you most like to see?

If you could wake up on the first morning of the new year and have a brand new security product on your door step, what would it do for you? How would you like it to operate? What do you most fantasize about accomplishing?

What projects would you like to see grow in 2014? What terms, techniques or technologies would you like to see left behind in 2013?

Drop us a line via Twitter (@microsolved or @lbhuston) or via our Facebook page (http://facebook.com/microsolved) and let us know what you dream about. We’ll work hard to see if we can make your holiday season wishes come true! 

Using HoneyPoint to Inventory Windows Boxes on a Segment

For quite some time now, we have been using HoneyPoint Agent and Console to do some passive inventory and mapping exercises for clients, particularly those involved in ICS and SCADA deployments where active scanning to get inventories is often strongly discouraged. We had particular success with a specific client in this space a couple of weeks ago, and I wanted to discuss it here, since it has proven itself to be a useful tool and is on the top of my mind at the moment.

To get an inventory of the Windows systems on a collision domain, you simply install the Agent on a Linux box (or I suggest using the virtual appliance we already have built for your ease) and implement it and the Console. Once HoneyPoint is operational, you configure a UDP listener on port 138. From there, all of the NETBios speaking Windows systems will begin to send traffic to the host, as per the usual behavior of those systems. In this case, however, HoneyPoint will capture each source IP and log it to the Console. It will also capture the UDP datagrams from that conversation and place them as event data in the logs. By reviewing the source IPs, you can quickly and easily take stock of the Windows systems on the collision domain without sending any traffic at all to the systems. As a bonus, if you dig into the datagram data, you will also see the names of the hosts and other information.

Most of the time, this technique captures only Windows boxes, but if you have other devices out there running NETBios, they will likely get detected as well. This can include embedded systems, Unix systems running SAMBA, printers and copiers, Windows CE systems (often seen in many field equipment deployments), etc. You might be surprised what you can find.

Try this with a laptop, and move the laptop around your environment. You can pretty quickly and easily get an inventory by collision domain. You can also try dialing other NETBios ports and see if you get traffic that is routed across your switching fabric. Depending on your configuration, you might be able to gather a great deal of inventory data from a single location (especially if your network is flat and switches are poorly configured).

Give this a shot or get in touch if you would like us to come onsite and perform the inventory for you. We think it is a pretty useful technique and one that many folks are enjoying the benefits of. Let us know what you think when you give it a run in your network!

As always, thanks for reading, and until next time, stay safe out there!

PS – You can also do this with HoneyPoint Personal Edition on a Linux system, which makes it very easy and cheap to do if you don’t want to invest in a full blown HoneyPoint Security Server implementation. (You should invest though, it is a FANTASTIC detection tool!)

**(The link above is for HPPE on Windows, but if you purchase a license and contact us, we will send you the Linux build right away. You can’t easily capture port 138/UDP traffic in Windows HPPE because Windows has those ports in use…)

Datacenter Attack Surfaces

Hello!  I’m Jim Klun – a comparatively recent addition to the team here at Microsolved. 

I have worked over the years to protect large datacenter environments from compromise.  I want to take moment to share a way to look at the external security risks facing such an environment .  I’ve used it effectively to explain (usually to senior management)  the reality of risks that often go unplanned for.

 Essentially, I have come to view a typical datacenter environment as presenting three major “doorways” that external attackers will attempt to break through.  These are often described as “attack surfaces” in the literature and are illustrated below:

Let’s take a look at each side of this “attack surface” triangle

Internet

An organization’s Internet presence – the Internet-facing services offered to the public over the Internet – is usually well understood as an attack surface.  Organizations with at least some security awareness will ensure that servers with publicly exposed services are protected by a firewall, offer only a limited number of secured services to the Internet and tightly monitor those services for signs of potential abuse or compromise.  Best practice also dictates that they be in a separate network segment (e.g. a “DMZ”) with limited access into the rest of the datacenter.  Segmentation makes it more difficult for an attacker who has gained access to an Internet server to extend their control inward without being detected.

But – note the other attack surfaces shown in the diagram. These are the ones often ignored by organizations.  The reason is invariably a misplaced sense of “trust”. 

Private Connections

These are the various “private” pathways into your datacenter provided to vendors, business partners or customers.  Communication may be over dedicated non-Internet communication channels or possibly via site-to-site VPN over the Internet.  Portions of some other organization’s internal infrastructure is connected to yours via such paths.  Your organization becomes dependent on their internal security.

Regardless of the private communication mechanism, the special nature of the relationship invariably instills a sense of trust in the security of the connection.  The assumption is the folks at the other end are “doing the right thing” and pose a limited risk.   But of course you have no way of really knowing that.  A compromise of a vendor site that has a direct connection into your datacenter so that the vendor can perform maintenance work on your servers is a  real and serious risk to you.  As an attacker, I would delight after compromising a support vendor to find such maintenance connections.
Hopefully one would not be to your datacenter.

Unless you have complete, assured control of the infrastructure at such sites, you must assume they are potentially hostile.  Firewalls, logging, segmentation, and intrusion detection are as much a requirement here as they are for the Internet.

Employee/Contractors

“We trust our employees!”   Of course you do.  But trust here goes beyond trust of the individual human being.  The trust is of a combined entity – your employee AND that company laptop they take home every night.  Few people are capable of using a Windows-based laptop in such a way as to avoid compromise over the long term.  You may have a full array of anti-malware solutions running on company laptops, but the simple fact of modern digital life is a subset of them will be compromised and you will not detect it.

The trick is to limit the damage that any one such compromised laptop can do to the security of your datacenter.  If you have no firewalls between your internal employee space and your datacenter and you have no controls on outbound traffic from your employee space to the Internet (porn filters are not enough), then an attacker who has remote control of that laptop can simply use it as an internal attack platform against your datacenter.   This has become a major vector for data-center compromise.

Employee desktop/laptop/smartphone IP-space should be entirely different from that used internally within your datacenter.  Firewalls should lie between those spaces. Strict limits must be imposed on what your non-technical users “see” of your datacenter.  If they can see everything, then an attacker who has taken control of their machine can see it all as well. Ideally all access to datacenter servers by technical administrators is by way of “jump hosts” that sit at the boundary between the datacenter and employee space. Two factor authentication for access to such administrative jump-hosts is  a requirement.  System admins are just as likely as any other user to have traditional credentials stolen.

By limiting what your internal users can see of your datacenter and logging all access attempts, you have some chance of limiting the opportunities for attack from a compromised laptop and at least some chance of detecting it if it does occur.

Don’t think it happens?   http://spectrum.ieee.org/riskfactor/computing/it/south-korean-banks-weeklong-system-failure-affecting-30-million-an-inside-job

_______________________________________________________

For my next post,  I’d like take a look at a topic closely related to the above: Egress Filtering.  Don’t do it?   You need to.  See: http://en.wikipedia.org/wiki/Egress_filtering

 

 

CMHSecLunch for December is the 9th

Just a reminder that the CMHSecLunch for December will be on the 9th at North Market. As always, admission is free and everyone is welcome. Come on out and see your friends.

As usual, to RSVP and let others know you are attending, or to view more information about the event, you can visit the eventbrite site here.

See you there! Or, on Twitter with the hashtag #CMHSecLunch if you can’t make it or are out of the Columbus area. The more the merrier!

Touchdown Task for November- Network Segmentation Review

Whether it is budget preparation or annual project planning, the end of the year always leads us to think of the “big picture”. The touchdown task for this month is to review your network architecture maps and diagrams. First of all, make sure they are up-to-date. But secondly, look for indications that your network might be too flat. That is, do you have proper network segmentation between all of your information resources? Are your firewalls placed properly throughout your environment? 

 

A “flat” network architecture allows attackers who have gained a foothold on the internal (and sometimes even the external — you do have a layered DMZ, right?) network full visibility to internal systems and to move freely through workstation and server space. 

 

If you see some re-architecting that should be done, make note of it now. Depending on the complexity of the work, either schedule the re-architecture for a slow period at the end of this year or create a work plan for 2014. 


As always, thanks for reading and keep your eyes on the goal!

Code of Conduct Research

We have begun working on another project around helping organizations better protect their information assets and the reputations of both their employees and their firms at large. As part of that project, we would like to solicit some feedback from the readership of the blog. 

Does your organization have a code of conduct for employees? Does is have a written code of conduct for management, board members and/or public relations campaigns? 

Is it a living code of conduct or is it a stagnant piece of policy? How often is it updated? Does it cover social media presence, community engagement and/or public perception of the firm or individual?

Who audits the code of conduct and how is it monitored for violations? 

Please feel free to give us your thoughts on the code of conduct and which industry you are in. We are taking responses via email (info <at> microsolved <dot> com) or via Twitter (@lbhuston). 

Thanks for responding. Responses will be entered into a random drawing for a Starbucks gift card, so respond for a chance to win some java goodness. 🙂

Brent Huston to Lead ICS/SCADA Honeypot Webinar with SANS

Our Founder and CEO, Brent Huston (@lbhuston) will be leading a SANS webinar on ICS/SCADA honeypots. The webinar is scheduled for November, 25th, 2013 and you can find more information and register by visiting this page.

The webinar will cover when honeypots are and are not useful, basic deployment strategies and insights into using them for detection in field deployments and control environments. 

Check it out, tune in and give Brent a shout out on Twitter. Thanks for reading and we hope you enjoy the webinar.

Thanks for Making the 3rd Mid-West ICS/SCADA Security Symposium a Success

Thanks to the attendees and speakers who participated yesterday in the 3rd Annual ICS/SCADA Security Symposium. It was another great event and once again, the center of the value was in the interactions of the audience with the speakers and each other. It’s great to hear asset owners discuss what is working, what is challenging and what is critical in their minds.

Thanks again to those who attended and contributed to making this event such a wonderful thing again this year. We appreciate it and we can’t wait until next year to do it all again.

Thank YOU!