We just finished a series of SCADApedia entries on security in Rockwell Automation (RA) controllers and software applications.
- The ControlLogix PAC (powerful PLC) is a prime example of why we are fans of the simple, little IEEE P1686 standard effort. The Logix family only supports a single password that locks and unlocks the PAC through a CPU Lock utility, that quite frankly was not integrated with any management software at least through Version 15. P1686, which is for much simpler IED’s, requires support for ten UserID and Password combinations. Maybe P1686 is a low bar, but it would be a dramatic improvement in the security in most controllers including the RA family.
- If anyone can confirm the CPU Lock feature was integrated into RSLogix in Version 16 it would be appreciated. Screen shots and documentation hints at this. Also, how about RSLinx?
- In our informal survey of RA users, RA personnel and integrators, it was clear that even the limited security features in the Logix PAC’s (CPU Lock, Source Protection, Priority and CIP limits) were unknown and unused by most. One of the most common recommendations was to turn the physical key to Run and remove the key to prevent any remote changes. Great control, if practical in your environment. Of course, this is not possible or prohibitively expensive in many larger or geographically dispersed systems.
- Does previous point mean security awareness efforts are failing? Are Joe Weiss and others correct to continue to hammer the basics at PCSF and other events? Perhaps awareness has been achieved in a narrow percentage of the community – – the ones that attend events, contribute to standards, read SCADA security blogs, etc. The challenge is building security awareness amongst those who are not part of the control system security community, which would be the majority of control system users.
- I’m uncertain what to recommend for limiting CIP connections. The ControlLogix supports up to 128, and has a feature that can set a lower maximum. So if an asset owner knows their should only be ten valid CIP connections at most, a maximum could be set. However would this make it more or less susceptible to denial of service attacks? If forced to choose, I would recommend setting the limit because it would be so easy for an attacker to exceed the 128 maximum if denial of service was the goal. Setting the limit may identify an attacker who is trying to go low and slow.
- RA should be commended for making huge amounts of documentation available. In fact, I cannot think of any other control vendor where we can read huge manuals on all of the products and options. Often this level of detail is not even written let alone available. RA does need to retire superseded documents or mark them obsolete because they conflict with current information. For example, we read that CPU Lock was not supported on the Ethernet interface in multiple documents when in fact that was old news.
Part II will cover opinions on security in the Rockwall Software management applications. We have some very strong and important pro and con opinions on this.
Note: This series of RA blogs and SCADApedia entries was the original impetus for the SCADApedia. We were frustrated on how difficult to get accurate basic security guidance. Once we had the information, we had a lot of opinions in addition to the facts. We didn’t to mix the two, and we didn’t want the facts in the blog entry to age off and be of little use after all this work. Hopefully this helps our current and future readers.
We added two SCADApedia entries on the security features of Rockwell Software Management: FactoryTalk Security (formerly RSAsset Security) and FactoryTalk AssetCentre (formerly RSMACC). The naming is still confusing with much of the documentation, website content, and RA customer and employee base still using the old names.
The Good
There is a lot to like about the security controls in these controller management solutions. In fact, there is little we don’t like “inside” these applications except perhaps the complexity, especially with AssetCentre, which may not be worth the time for organizations without large numbers of PAC’s. Some of our favorite features:
- FactoryTalk Security is a central repository of authentication and authorization controls. Users are entered and managed in one location rather than trying to enforce the same controls on each PC with the RSLogix application.
- The authorization is quite granular and can be based on 50+ actions individually settable for each PAC. The application supports groups for role based access control which makes life easier. Just because you can create an extremely complex authorization environment does not mean you should. Complexity makes periodic review and changes difficult and prone to errors with a security impact.
- FactoryTalk Security allows users to be entered locally in the application or it will proxy authentication to a Windows domain controller. If you have deployed a separate domain (in its own tree/forest unrelated to the enterprise), you can leverage that existing infrastructure. However, you are not forced to deploy a domain controller or, even worse, use the enterprise domain controllers and subject the control system to all the related risks. While Windows Active Directory supports numerous two-factor authentication solutions, we have not yet verified if these can be used with FactoryTalk Security.
- The change management system in AssetCentre is a huge benefit, especially if you have found your separate change management process to be ineffective or cumbersome. Achiving each change and knowing who made each change is great for forensics. Rolling back for recovery is simple. AssetCentre leverages FactoryTalk security authentication and authorization to limit who can do what.
- A periodic backup of each controller can be automated and scheduled.
- The Verification Compare action will verify that the master record in the AssetCentre matches what is running in the field. It will identify when someone has circumvented AssetCentre and made a change locally or by some other means (see below).
- AssetCentre supports an integrated RSLinx Gateway so all communication can be sent from the AssetCentre server to the controllers. This simplifies access control lists and firewall rules.
The Bad and Ugly
and it does get ugly . . .
The authentication and authorization features stop at management software.
Consider a top of the line FactoryTalk Security and AssetCentre example. A user with an AssetCentre client will login and be authorized at AssetCentre, make changes, and send those changes to one or more Logix controllers. The communication between AssetCentre and the Logix controller requires no authentication and has no security.
In fact, many of the great automated and scheduled features such as Verification Compare and Backup require the controllers to remain “unlocked”, not password protected.
Of course, many of you have leaped to the really big problem, why would an attacker bother going through the AssetCentre? An attacker would get a copy of RSLinx or RSLogix and go directly at the unprotected controllers as shown in the figure below.
The figure above shows the recommend compensating control, limiting access via a router ACL or firewall. This is recommended anyway for defense-in-depth, but let’s be honest, it will be a long time, if ever, until most of the community gets to this point. It is a lot faster and cheaper to provide some rudimentary access control features on the controllers.
Another compensating control is to use the AssetCentre Verification Compare feature to identify unauthorized changes, but the time between Verification Compares will be a time window when one or more controllers may be easily compromised and undetected.
Perception
What makes this even uglier is almost everyone we talked to assumed AssetCentre/RSMACC to controller communication was authenticated. The documentation is silent on this, not giving false information, but all the benefits listed in AssetCentre and FactoryTalk imply the authorization and authentication restricts who can manage/exploit the controllers.
To prove the perception point further, we talked to asset owners who purchased RSMACC and who assumed the authentication was required prior to controller access. We talked to RA systems engineers and third party integrators who assumed this was true, but never could explain how it could work when a CPU lock password was not ever entered by the user or in AssetCentre. After a few weeks we finally found someone at RA who knew the details.
Suggestions for RA
These were the unsolicited suggestions we made to RA last year. We do not know if any have been implemented (anyone in the know please let us know so we can update this and the SCADApedia) or are planned for a future release. To the best of our knowledge there are no announced plans to secure the AssetCentre to contoller communications.
1. Immediate Action
There is a relatively simple solution that is far from perfect but would be a dramatic security improvement. Integrate CPU Lock in AssetCentre. When AssetCentre is communicating with a controller it would unlock the controller, perform all actions, relock the controller.
This would not require any changes to the controller code. The CPU Lock password could be entered only in the AssetCentre, and users would be authenticated to AssetCentre with unique username and passwords via FactoryTalk. User and attackers could no longer circumvent AssetCentre.
Of course the controller would be vulnerable for other attackers during the time AssetCentre had it unlocked and the CPU Lock messaging is not secure. So it is not a long term solution.
2. Better Solution
Update the CPU lock function in the controller and AssetCentre to a secure authentication protocol and restrict unlocked access to the session that sent the valid unlock message.
This would still only support one account and have limited logging, but asset owners that require this could get those controls by deploying AssetCentre.
3. Best Solution
The standards bodies are working on this. It would include support for multiple user accounts on the controller, strong authentication, better error message logging, etc.
Of course, the other immediate solution from an asset owner perspective is to continue to use RSLogix with the CPU Lock utility and avoid the FactoryTalk solutions until this security issue is addressed.