Category Archives: SCADA/ICS

IT/OT/Business Integration Insights from ComEd

Posted on by
Reply

Background:

For several years now I have been working with utility companies, and other critical infrastructure organizations particularly focused on Industrial Control Systems (ICS) and Operations Technology (OT) solutions such as SCADA. During that time, one of the most common issues that our customers and the folks who attend our Security Summit every Fall discuss with us revolves around a lack of communication, engagement and ultimately cooperation between ICS engineers, along with Operations staff and the more traditional enterprise focused IT teams. In many cases, this is often expressed as the number one issue that the organization faces.

 

A few years ago, I began asking around the community who might have a solution to this problem. Several people pointed me in the direction of Commonwealth Edison Co. (ComEd), the electric utility in Illinois, which led me eventually to a gentleman named Mark Browning. Through a mutual business partner, I asked to be introduced to Mark, and during that introduction, asked  if he would agree to discuss this problem and the methods ComEd has used to tackle it. Thankfully, Mark and his team agreed. What follows is a summary of the information I gathered from several email interviews and time spent with Mark on the phone.

 

A Bit About Mark:

The first thing you should know is that Mark is a seasoned veteran of the ICS and OT world. He has spent an entire career working in IT, Operations Support and other functions in the ComEd utility. He is, by his own admission, an “old school SCADA” guy. Over the years he has moved from designing and implementing ICS and OT systems through the ranks of  OT application support and eventually into a leadership position where he oversees both traditional IT and the OT teams. It is this experience, along with the commitment, passion and wisdom of the entire ComEd team that make them successful at tackling what seems to be such an industry wide problem.

 

A Bit About ComEd and Exelon:

ComEd is an energy delivery company providing electric transmission and distribution services in the northern 3rd of Illinois, including the Chicago metropolitan area. Exelon Corporation is the parent company of ComEd. As part of Information Technology, Mark and his team work for a corporate shared services group, Exelon Business Services Company.  Mark’s Utility Solutions team  is responsible for the successful implementation and management of IT and OT architectures across and throughout the utility lines of business of ComEd. Embedded in the ComEd business to be close to their counterparts, Mark and his team are directly focused on the success of the business and on providing support to each of those business lines of his customers. This client focused business model is one of the things that Mark credits with keeping his team actively engaged with his business partners and not just supporting requests – thus truly empowering each of the lines of business.

 

This organizational design creates a system of centralized leadership for IT and OT technologies. Acting as a centralized technology group, Utility Solutions is responsible for service levels across all business functions. By design, this creates a direct chain of responsibility to each of the lines of business, and makes technology success fully dependent on the success of each line of business. Mark says this level of integration fully supports solving the lack of engagement problem.

 

How Does It Work at ComEd?:

Mark and his team shared that the strength of engagement between the IT and Business teams stems from a program created more than 10 years ago. They call it the “client engagement model”. Basically, it is a process of fully embedding IT alongside the lines of business. While IT and the Business perform their respective roles, they also collaborate heavily to achieve common objectives. This has created an atmosphere of respect and trust between groups who are comfortable with the shared vision of business goals and an open architecture roadmap to support those goals both short and long-term.

 

In order to cement and maintain that trust between the lines of business and the technology teams, all projects require co-sponsorship and co-leadership. Representatives work directly with their embedded team members in order to create, lead, implement and manage the projects required to build each line of business. Mark’s team members emphatically shared, via a variety of emails, how much easier it makes the job of doing IT well using this approach. They raved about their relationships with the lines of business, with their business focused teammates and with the upper management and leadership of their organization. In particular, many of them commented on how refreshing it was to get to see the technology products that they created actually in use in the business and serving the needs of the end users.

 

It should be noted that such trust between technology teams and lines of business would be nearly impossible to build were it not for a laser-like focus on business problems. Team members with strong technical skills must interface directly with business team members who have strong organizational and communication skills. The problems of the business must be clearly and concisely expressed between the teams and there must be full integration between technology teams and the lines of business. Mark credits much of the success of this program with the embedded nature, that is putting IT and OT people directly in everyday contact with their business partners focused on each line of business.

 

What Can You Do?:

I asked Mark what lessons could be learned from the ComEd approach. In order to help other folks who might not have 10 years of  inertia behind them, I asked Mark what are the key things he would do to apply a similar program to a new organization just beginning to tackle this problem. Mark shared with me the following four key undertakings:

  • Immediately and fully embed and co-locate the IT staff with the business staff members . Ensure that all projects begin to be co-led by a member of the IT team and the business team. Make both of the teams directly responsible for the success of projects.
  • Increase cross training and shared knowledge between the two groups who are now embedded together. Make sure that you are hiring great leaders, and where possible, hire from within the lines of business. Consider functional swaps, where traditional IT staff members temporarily swap positions with business team members. This system of functional swaps often leads to rapid cross communication and knowledge sharing between teams on both a functional and personal level.
  • Hammer home the idea of customer facing trust and co-working communications. Active engagement must occur at all levels for maximum success.  From VP to individual contributor, the IT and business teams must challenge their counterparts by being both advocates and challengers.  Include a shared mission message along the lines of “we must work together because our customers expect us to do so”. Make this mantra a part of everyday life for all team members.
  • Greatly increase the amount of coaching and management level engagement across the now embedded teams. Especially engage in ongoing training for technical team members to see, feel and engage in business operations. Encourage opportunities for the business to directly demonstrate how technology products support both the business and the customer. Clearly demonstrate the benefits to both teams of working together to provide value to the customer.

 

The Payoff:

Lastly, I asked Mark about the payoff for organizations who successfully increase the cooperation and engagement of their IT and business teams. Mark and I both agreed that as the convergence between information technologies and utility delivery mechanisms increase, so too does the importance of integrating these teams.  Essentially, Mark believes that IT has quite a bit to bring to the table.  “IT will become the engine of the utility.”, says Mark. While we both  agree that security remains a risk that we are carrying, convergence and automation will create a unique opportunity to work together to protect and support both the goals of the business,  the desires of the customer and the public at large. With technologies like smart grid on the horizon, those organizations that can effectively conquer the problem of IT and business engagement will be the leaders for the utility markets of the future.

 

Thanks:

I would like to thank Mark and the teams at both ComEd and Exelon for their willingness to discuss their program and to help others with one of the biggest problems many organizations face today. I hope you enjoyed learning from their experiences, and both Mark and I hope that it helps your organization. As always, thanks for reading and until next time, stay safe out there!

3 Tough Questions with Chris Jager

Posted on by
Reply

Recently, I got to spend some time interviewing Chris Jager via email on industrial control systems security. He didn’t pull any punches and neither did I. Here, are 3 Tough Questions between myself (@lbhuston) and Chris.


A Short Biography of Chris Jager (@chrisjager): I have over 15 years of experience in Information Technology and have focused on the practical application of security principles throughout my career. Most recently, I was director of the NESCO Tactical Analysis Center at EnergySec; a non-profit organization formed to facilitate information sharing, situational awareness, and education outreach to the energy sector. I am active in a number of information security workgroups and have provided operational, architectural, and regulatory compliance guidance to large and small organizations in both the public and private sectors, focusing on the energy sector exclusively since 2006.


Brent: You have spent a lot of time working on Industrial Control Systems (ICS) in your career. During that time, you have been witness to the explosion of interest in IT security as a profession. Why should some of the younger folks thinking about information security as a career consider a focus on ICS and SCADA? Why should they care?

Mr. Jager: This is a fantastic question and, if I frame my response correctly, the answer will hopefully be self-evident to your readers.

ICS and SCADA are terms that are seldom understood and often misused by information security (infosec) publications. SCADA systems typically manage geographically disperse areas and often consist of numerous functionally disparate processes.

However, because of the immense variety of different processes that can be managed by industrial control systems, ICS has become somewhat of a catchall term – including SCADA systems. For example, you’ll often find electric power generation processes such as turbine control, burner management, vibration monitoring and more lumped into the mix. Each of these processes has discrete or locally distributed control and instrumentation systems, any of which can cause catastrophic safety, reliability, and financial issues if misused.

For me, the challenge of protecting these kinds of systems is far more interesting than making sure that little Bobby can’t drop the student records table in a classroom database. Much of the actual management technology is the same as what is used in general IT, but the application is very different. Things get a little more exotic (and arcane) when you go further down the stack into digital–to-analog conversion, but it’s not overly difficult for most folks to understand once exposed to it. The negative impacts of misuse aren’t limited to convenience and financial loss. Risk to life and limb is a very real possibility in many processes that are managed by industrial control system automation that is being run out of specification.

Typically, industrial control systems are deployed in step with the physical equipment they are designed to manage. The physical equipment is often orders of magnitude more expensive than the ICS components that ship with it and may be designed for lifespans measured in decades. In short, upgrades seldom occur as they need to be engineered and tested for functionality, safety, and a myriad of other issues pertaining to the existing physical equipment.

This has led to a situation where the groups that understand control systems and processes are naturally (and often generationally) gapped from those groups who understand the current threat and vulnerability landscapes. Consequently, there are currently very few individuals that understand industrial control system security as it relates to the changing threat picture. If the challenge of doing something very few dare to try doesn’t sound good on its own, this is the sound of opportunity knocking. Answer the door!

I’d like to make one last point on this question. Take a look around your house or apartment and count the number of internet-enabled devices you have. Most people these days have far fewer traditional computers than embedded systems – devices that aren’t user-serviceable without breaking a warranty or two. And the hacking skills necessary to modify such devices to fit use cases unintended by the manufacturers seem to come naturally to the younger folk of today. Those skills are also relatively portable to the ICS/SCADA world where embedded systems are the norm. Sure, some of the protocols and hardware packages are somewhat different, but they are all relatively simple compared to what folks are tinkering with at their coffee tables. We can always use more QA/breakers – particularly at key points in the supply chain where issues can be spotted and fixed before they become permanently vulnerable installations. Again I say, “knock knock”!

 

Brent: You talk a lot about how challenging ICS/SCADA security is. Do you think protecting ICS/SCADA systems in a meaningful way is an attainable goal? Assuming yes, do you think it could be done during what’s left of our careers? Why or Why not?

Mr. Jager: If I didn’t think it was an attainable goal, I’d not be doing the kind of work I’ve done over the past number of years. There are much easier ways to make a buck than to have people who are entrenched in the old way of doing things actively work to prevent you from even introducing discussions about change – let alone actually implementing it!

There is momentum in this area, but much work still needs to be done. Devices still ship from manufacturers with easily discerned hardcoded administration credentials, firmware updates are accepted without challenge and more. Once deployed in the field, user passwords seldom change, vulnerabilities discovered post-installation go unmitigated, and so on.

Because we have all this noise around basic security failures and their associated issues, we don’t yet know what constitutes “meaningful” or “attainable” when we speak of complex industrial control systems. A prime example here is that the electric sector is still using the exact same set of controls and asset scoping for its regulated security standards as when I first started working in the sector in 2006. NERC CIP version 1 was in final draft form, and the current requirements catalog will remain largely unchanged until at least 2015 when and if version 5 becomes effective. There have been minor changes in the interim, but not one that comes remotely close to addressing change in the threat landscape.

Will we ever have a perfect system? No. We do, however, urgently need to stop being complacent about the subject and implement those security measures that we can.

 

Brent: If you had your own ICS system, let’s say you ran Chris’s power company, what would that look like? How would it be protected?

Mr. Jager: It would look very, very “dumb”. Until such time as ICS and other automation technologies are vetted by process engineers – and I’m talking about the entire ICS/automation stack, I would automate only where it was impossible to operate the business or process without it.

It seems to me that we have a major employment problem in this country and no clear path to resolution. Putting some of these people to work securing our industrial control systems is an area where the private sector can help get the country back to work without relying on government funded stimulus packages. An added bonus is that we’ll end up with a whole cadre of workers who have been exposed to the industry, a percentage of who will stay in the field and help to address the industry’s gray out problem. All it takes is one or two sizable impacts from automation failure or misuse for the cost savings seen through automation to be wiped out.

Where I had no choice but to automate, Chris’ Power Company would look very much like any power company out there today, unfortunately. There simply aren’t enough vendors and manufacturers out there presently that produce secure equipment. Even then, systems integrators often further weaken the environment by adding support accounts and other remotely accessible backdoors to these systems.

Be it in the energy sector or any other, process automation installations will inevitably mature to a state of persistent vulnerability due to their long lifespans. Vulnerability discovery and exploitation techniques advance over time, vulnerabilities are introduced through regression bugs elsewhere in the software or protocol stack, or the process itself may have changed to a point where a previously innocuous vulnerability now has the ability to introduce a large impact if exploited.

Eventually, pointing out that the emperor has no clothes becomes a career limiting move – particularly when said emperor is an exhibitionist! Instead, the focus should be on identifying the more sensitive individuals in the crowd and protecting them appropriately through sound risk identification principles. We can’t make the problems go away through risk management, but we can use the techniques to identify the things that matter most and, where we can’t mitigate the risk, implement monitoring and response controls. This sort of approach also helps prioritize future efforts and dollars.

The top security controls at Chris’ Power Company would center around monitoring and response as employees would be trained to assume the environment was in a persistent state of compromise. In the environment we live in today where threats are real and expressed, and vulnerabilities aren’t able to be universally mitigated, the only real chance at controlling risk you have is to manage the impact of a successful attack. You only get that chance if you are able to detect and respond before the attack balloons to the maximum impact value.

If you failed to give my company that chance, you wouldn’t be working at Chris’ Power Company!


Thanks to Chris Jager for his insights and passion about ICS security. We appreciate his willingness to spend time with us. Thanks, as always, to you the reader, for your attention. Until next time, stay safe out there!

HoneyPoint Security Server ICS/SCADA Deployment Example

Posted on by
Reply

Recently, there have been several questions about potential deployment scenarios for HoneyPoint Security Server in and around ICS and SCADA organizations. Here is a quick, high level view of what a sample deployment might look like in a utility or other ICS environment. Note that the sample environment has fully embraced enclaveing. The network is fully segmented based on function.

In organizations where segmentation or the use of enclaves has not been established, HPSS can still be used and would be deployed in much the same manner.

Please let us know if you have any questions about this diagram or about deploying HPSS in your environment. We would be happy to set up a free consultation with you to discuss how the tool could aid in your detection program and give you increased visibility throughout your enterprise.

PS – If the graphic is difficult to read, right click on it and select view in new tab. The theme for the site is having trouble with this particular graphic.

HighLevelEnclaves

Event Announcement: ICS/SCADA Security Briefing

Posted on by
Reply

MSI, along with the teams at NexDefense and Critical Intelligence, will be participating in an online webinar about ICS/SCADA Security. The date of the event is February, 6th and you can learn more about it here. 

The event is free to attend, though registration is required. You can earn a CPE for participating! 

We hope you will tune in and check us out!

Overview of the event: 

Learning Objectives

  • Significant trends in the threat and vulnerability environment
  • Relevant trends in ICS technology
  • What proactive steps you can take
  • How to leverage security intelligence

Agenda

  • Introductions
  • ICS Cyber Security Intelligence Briefing, Michael Assante
  • ICS Threat Update, Brent Huston
  • How to Leverage Security Intelligence, Bob Huber
  • Live Q&A

Who Should View?

  • Senior Information Security Leaders, CISOs and CTOs
  • Security and Risk Analysts
  • Control system security engineers
  • Security operation leads for ICS reliant organizations

SANS SCADA Security Conference & a DISCOUNT

Posted on by
Reply

SANS has allowed us to offer a 10% discount to our readers who attend their SCADA Security Summit. The event is being held in Orlando this year, February 12-13, with optional training courses wrapped around on both sides. We think this is a great event and we are proud to be able to help SANS promote it.

You can get your discount using the discount code: MicroSolvedSCADA

More information about the event follows below (Overview provided by SANS): 

More than 1,200 security analysts and process control engineers, from government and industry, have attended the SCADA Security Summits. That’s because Summits are the one place where the people shaping the future of control systems security come together to share the lessons they have learned and because the Summits give attendees unique, early access to important new information. This year’s program will be no different. If you have any responsibility for security of control systems – policy, engineering, governance or operations you won’t want to miss the 2013 Summit in Orlando, Florida.

 At the Summit you will:

  • Learn why control systems are so difficult to protect and arm yourself with clear case studies showing what’s been done and what can be done to protect SCADA and other control systems.
  • Learn the language of control systems so you can be of more help to the engineers who plan and deploy such systems.
  • Understand the requirements and constraints faced by owners and operators of automation systems. Determine the state of the art in control system security as a benchmark for your own future planning.
  • How to build an ICS security program and develop your team.
  • Better understand what government can and can’t do by learning the requirements, constraints and current capabilities available to secure critical control systems.

 For more information and to register click here  http://www.sans.org/event/north-american-scada-2013

Threat Data Sharing in ICS/SCADA Needs Improvement

Posted on by
Reply

I had an interesting discussion on Twitter with a good friend earlier this week. The discussion was centered around information sharing in ICS/SCADA environments – particularly around the sharing of threat/attack pattern/vulnerability data. 

It seems to us that this sharing of information – some might call it “intelligence”, needs to improve. My friend argues that regulation from the feds and local governments have effectively made utilities and asset owners so focused on compliance, that they can’t spare the resources to share security information. Further, my friend claims that sharing information is seen as dangerous to the utility, as if the regulators ever found out that information was shared that wasn’t properly reported “up the chain”, that it could be used against the utility to indicate “negligence” or the like. I can see some of this, and I remember back to my DOE days when I heard some folks talk along the same lines back when we showed up to audit their environments, help them with incidents or otherwise contribute to their information security improvement.

When I asked on open Twitter with the #ICS/#SCADA hashtags about what hampered utilities from sharing information, the kind Twitter folks who replied talked about primarily three big issues: the lack of a common language for expressing security information (we have some common languages for this (mitre’s work, VERIS, etc.)), legal/regulatory concerns (as above) and the perceived lack of mitigations available (I wonder if this is apathy, despair or a combination of both?). 

I would like to get some wider feedback on these issues. If you don’t mind, please let me know either in comments, via private email or via Twitter (@lbhuston) what you believe the roadblocks are to information sharing in the ICS/SCADA community.

Personally, I see this as an area where a growth of “community” itself can help. Maybe if we can build stronger social ties amongst utilities, encourage friendship and sharing at a social level, empower ourselves with new mechanisms to openly share data (perhaps anonymously) and create an air of trust and equity, we can solve this problem ourselves. I know the government and industry has funded ISACs and other organizations, but it seems to me that we need something else – something more easily participatory, more social. It has to be easier and safer to share information between us than it is today. Maybe, if we made such a thing, we could all share more openly. That’s just my initial 2 cents. Please, share yours.

Thanks for reading, and until next time, stay safe out there!  

What is this HoneyPoint Thing Anyway?

Posted on by
6

Launched in 2006, initially as a distributed honey pot product, HoneyPoint Security Server (HPSS) has grown well beyond the initial concept. Today HPSS is a platform of components woven into a tightly integrated, fully capable, extremely flexible threat detection product. Organizations around the world are using it as a means of early detection of internal and external attackers, malware outbreaks and signs of users poking around where they shouldn’t be. Mature organizations have leveraged the product as a means of deterring attacks through automated black holing of scanning hosts on their perimeter, embedded detective controls inside their web applications to cut off users violating their terms of service and gather real world threat metrics to feed back into their mature risk management initiatives.

 

In the world of ICS/SCADA, HoneyPoint has found a quickly growing set of fans. HPSS can be deployed in a completely passive way that has no chance of interfering with critical operations, yet still brings incredible detection capability and vision into even the most sensitive of networks. ICS/SCADA environments have traditionally embraced the honeypot ideal, coining the term “canary” for these tools, but never before have they had such an easy to use, distributable, centrally monitored honeypot capability like HoneyPoint brings to the table.

 

Over the next few months, we will be deep diving into each of the HPSS components, but for now, as a high-level overview, here is a quick and dirty explanation of each of them:

 

  • HPSS Console – This is the central “brain” of the product. Designed as an easy to use GUI application, it receives the alerts detected by the sensor components and presents them to the user for analysis. It includes the “plugin” capability which allows for additional reporting and security automation based on the event data detected. The Console provides for “point and click” easy integration with SEIM products for clients who have deeper back-end data aggregation systems in place.
  • HoneyPoint Agent – This is the original HoneyPoint detection capability. Agent creates “fake services” on the network that have no real use other than detection. Since the services aren’t real, any interaction with them is “suspicious at best and malicious at worst”. Agent is capable of emulating a great variety of services and is completely user configurable. Agent runs on Windows, Linux and OS X. 
  • Wasp – Wasp is HoneyPoint’s hybrid client for Windows systems. It offers many of the port dilation features of Agent, but layers on top of that a whitelisting detection mechanism, file change detection for key files and some simple heuristics to identify the most common signs of intrusion. Tiny footprint, immense flexibility, self tuning whitelisting and no interference with operations make it an excellent choice for critical infrastructure use.
  • HoneyPoint Web – This is a completely emulated web environment with a mock up of applications that the organization uses. The entire environment is “fake” and studded with detection mechanisms that capture and measure attacker behavior, intent and capability. It might seem to be a new version of a banking application “accidentally” exposed to the Internet, or a replica of an HMI or maybe a login portal for Sharepoint/VPN or some other mechanism. What it really is is a detection mechanism for the good guys. Completely customized, able to detect the difference between a human attacker and most malware, it offers organizations a deeper, sneakier way to detect illicit behavior and measure the attacker attention various attack surfaces receive.
  • HoneyElements – Embeddable HTML and Javascript objects that can be added to new or existing real web applications, these HoneyPoints extend detection into the layers of the application itself. Integrates well with automated response and attacker black holing defenses to stop attackers and those engaging in undesired behaviors in real time.
  • HoneyBees – These work with Agent to simulate users authenticating to emulated services with plain text credentials. Organizations use this combination of tools to detect sniffing attacks and other attempts to harvest credentials off the wire or from network monitoring systems. 
  • HoneyPoint Trojans – Trojans are “fake” documents, applications or archives that appear to be real, but are actually detection mechanisms. For example, they might appear to be a PDF of some acquisition plans, while in reality they are armed with code to alert the security team when they have been opened or tampered with. Trojans use many of the same tactics as attackers, but instead of infection as a goal, they provide for detection and alerting.
  • HoneyPoint Handler – The Handler is a mechanism for getting external events into the HoneyPoint data ecosystem. Organizations often use the handler to receive events generated by custom nuance detection scripts. For example, a script might routinely check for new files in a directory or new files that contain the call base64decode(). When the script identifies a new file, the script can send an alert to the Handler, which will create a standard HoneyPoint alert from the script’s data and send it to the Console for easy and standardized security event management.
  • HoneyPoint Decoy Appliances – This is a set of hardened Linux powered devices that serve as an appliance for other components, usually Agent and Web. The appliances are available in three physical form factors (a rack mountable server, a mini-desktop, and a field deployable power substation solid state system) and/or a set of virtual appliances for most common virtualization platforms.
  • HoneyPoint Proxy – Lastly, this component is designed to act as an alerting data aggregator to simplify firewall ACLs that might be deployed between DMZ segments, enclaves or other network segments. The proxy can receive events from HoneyPoints and send them on to the Console without the need to expose the Console to each individual HoneyPoint. This makes managing global and highly distributed deployments significantly easier.

 

To learn more about these components and how they can be leveraged to give your organization new, flexible and deep detection capabilities, give us a call. Our engineers would be glad to discuss the technical capabilities and an account executive would be happy to work with you to create a HoneyPoint deployment that meets your needs AND your budget. At MicroSolved, we are passionate about information security and HoneyPoint Security Server is just another that way it shows!

ProtoPredator to Become Family of Products

Posted on by
1

On Nov 16, we announced the availability of ProtoPredator for Smart Meters (PP4SM). That tool, aimed at security and operational testing of optical interfaces, has been causing quite a stir. Lots of vendors and utilities have been in touch to hear more about the product and the capabilities it brings to bear.

We are pleased with the interest in the PP4SM release and happy to discuss some of our further plans for future ProtoPredator products. The idea is for the ProtoPredator line to expand into a family of products aimed at giving developers, device designers and owners/operators a tool set for doing operational and security testing. We hope to extend the product family across a range of ICS protocols. We are currently working on a suite of ProtoPredator tools in our testing lab, even as we “scratch our own itch” and design them to answer the needs we have in performing testing of SmartGrid and other ICS component security assessments and penetration tests.

Thanks to the community for their interest in ProtoPredator. We have a lot more to come and we greatly appreciate your support, engagement and feedback.

ProtoPredator for Smart Meters Released

Posted on by
1

Today, MicroSolved, Inc. is proud to announce the availability of their newest software product – ProtoPredator™ for Smart Meters (PP4SM). This tool is designed for smart meter manufacturers, owners and operators to be able to easily perform security and operational testing of the optical interfaces on their devices.

PP4SM is a professional grade testing tool for smart meter devices. Its features include:

  • Easy to use Windows GUI
  • Easy to monitor, manage and demonstrate testing to management teams
  • Packet replay capability empowers testers to easily perform testing, verification and demonstrations
  • Manual packet builder 
  • Packet builder includes a standards compliant automated checksum generator for each packet
  • Automated packet session engine 
  • Full interaction logging
  • Graphical interface display with real time testing results, progress meters and visual estimations
  • Flexibility in the testing environment or meter conditions

The tool can be used for fuzzing smart meter interactions, testing protocol rule enforcement, regression testing, fix verification and even as a mechanism to demonstrate identified issues to management and other stakeholders. 

ProtoPredator for Smart Meters is available commercially through a vetted licensing process. Licenses are available to verified utilitiy companies, asset owners, asset operators and manufacturers of metering devices. For more information about obtaining PP4SM or to learn more about the product, please contact an MSI account representative. 

More information is available via:

Twitter: @lbhuston

Phone: (614) 351-1237 ext 206

Email: info /at/ microsolved /dot/ com (please forgive the spam obfuscation…) 🙂

Thanks for Another Great ICS/SCADA Security Symposium

Posted on by
Reply

 

J0289528

Thanks to all who helped make the ICS/SCADA Security Symposium fantastic again this year. Great conversations, excellent content and such friendly discussions among peers and concerned parties. 

Next year, we plan to open the event to attendees from throughout the midwest and hope to get even more participation from manufacturing and those who support critical infrastructures. 

Thanks again for all of the hard work that Connie, Chris and the rest of the organizers did to make the event possible. Most of all, thank you for attending, participating and trusting us (and each other) to create such an amazing process of open dialogue. You are all heroes in my book!