Fixing a Hole

In July, I had an email exchange with a well-known CIP auditor – who has contributed very heavily to this blog since I started it more than three and a half years ago – that covered several important topics. I was just rereading that exchange and was struck by the following passage from him:

“Stop limiting protections to just Interactive Remote Access and the Intermediate System.  The firewall cannot distinguish between interactive and machine-to-machine traffic.  If I have an authorized connection from a Cyber Asset outside the protected network boundary to a Cyber Asset inside that boundary, strongly protect that outside system by managing it the same way you manage the Intermediate System (patched, anti-malware, logged and monitored, and multi-factor authentication at a minimum).  Let's extend the protection zone to the first "hop" outside the protected network boundary.  If you always play the game from your 3 yard line, you are going to lose.”

Since understanding what this means requires some unpacking, let me translate for you:

1. The auditor is referring to the fact that the NERC definition of Interactive Remote Access contains the sentence “Interactive remote access does not include system-to-system process communications”.  Of course, CIP-005-5 R2 requires that all IRA sessions must pass through an Intermediate System. Thus, system-to-system communications (i.e. no human at a keyboard) do not have to pass through an Intermediate System, even though the system outside of the ESP isn’t controlled in any way by the CIP requirements.
2. Of course, many people will point out that all communications into the ESP must come through an Electronic Access Point like a firewall. Firewalls can restrict certain types of access as well as certain IP addresses, but if a machine is already permitted access into the ESP, and it has been taken over by a malicious attacker, the game is over: the attacker has access to the ESP.
3. The auditor is saying that, to prevent this from happening, remote machines that are allowed to directly access an ESP need to have the same protections that an Intermediate System does. The point of the Intermediate System is to make it impossible for a remote human user – who could be anyone, anywhere on the planet – to directly access systems within the ESP. But trusted remote machines are allowed such access. What happens if one of those is compromised? It seems that some protections should be required for those machines, if they are going to be allowed to bypass the Intermediate System to access the ESP.
4. There are two main types of remote machines that can have direct access to the ESP. Some are used by vendors, who require ESP access for diagnostic purposes. Since vendors are not NERC entities, they are not subject to the CIP standards. However, vendor remote access will be addressed in some way in the new supply chain standard that FERC has ordered NERC to develop.
5. The other category of remote machines is machines that are on the IT network of the entity that owns or operates the ESP. This category can include backup servers, historians, FTP servers, etc. They are not in scope for CIP versions 5 and 6, even though they may actually meet the definition of BCA/BCS. Why aren’t these in scope? Because CIP-002-5.1 R1 says that only BES Cyber Systems located at one of the six asset types listed in R1 are in scope. By definition, these remote machines aren’t at one of those asset types

But should these machines on the IT network, that are under the control of a NERC entity and have direct access into the ESP, be in scope for CIP? I would say they should be in some way. If they can’t be forced to go through an Intermediate System, some protections need to be required of them.

However, before I’m accused of recklessly expanding the scope of CIP and placing another burden on the already-overburdened entities that have the misfortune of having High or Medium impact assets under CIP, I need to come back to an argument I’ve used before: I don’t think the scope of CIP should be expanded to cover IT assets until the CIP standards are made non-prescriptive and threat-based. Unlike the current standards, these future (hopefully) standards will require the entity to take a look at all of the threats to its control systems, including those threats that originate in the IT network.[i] All serious threats will need to be mitigated in some way, but the exact mitigations applied will be up to the entity; the auditors will determine whether they are sufficient, given the threat they address. It is only in this “new CIP” that I support putting controls on machines owned by the entity but outside of the ESP, that are currently granted direct ESP access.[ii]

The views and opinions expressed here are my own and don’t necessarily represent the views or opinions of Deloitte Advisory.

---

[i] Exhibit A for a threat coming through the IT network is the Ukraine attacks, as discussed in the post just linked.

[ii] I have realized more recently that a new approach to CIP doesn’t require rewriting all of the standards from scratch. Requirements can be made non-prescriptive one-by-one. I provide a real-life example of that in this post.

“Asset Boundary”

I attended the CIP v7 Standards Drafting Team meeting in southern California last week, and was quite glad I did. One of the highlights was observing the drafting team’s webinar on the new LERC definition (which they presented in a separate room from the one where I and the other observers were). A lot of questions were submitted during the webinar, and not all of them were fully answered. I will take it upon myself to provide what I think are the correct answers to a few of these, in separate posts on each question.

It is clear that one of the big concerns entities have is the term the SDT introduced in the new LERC definition: asset boundary. More than one questioner asked why they didn’t define this term. I will explain why I think the SDT didn’t define it, and also why I’m not sure they need to. But I will also make one point about LERC that should be made, either in a definition or in the Guidance and Technical Basis for CIP-003-7.

This post won’t make a whole lot of sense unless you have already read my previous post discussing the new LERC definition (and the revised section 3.2 of Attachment 1 to CIP-003, which goes with the new definition). Please do that now….All done? Great, here’s a short quiz to make sure you really read it. You will need to answer all of these questions correctly in order to become a Certified LERC Expert.

1. What two-word French phrase did I use in the post? What does it mean?
2. How many of my previous posts did I link to in this post and in its footnotes? Why do I link to previous posts so often? Is it because I get paid by the hit?
3. Is the post brilliant or merely very insightful?

I see enough of you passed the quiz so that I should continue with this post. So why did the SDT not define “asset boundary”, since the phrase plays such a big role in the new LERC definition? At first glance, it would seem to be a pretty simple question, but as with almost every other question about the new CIP standards, it is actually much larger.

The big problem here is that to define an asset boundary, there has to be a definition of “asset”. And believe it or not (considering how important the concept is in the CIP standards), that word isn’t defined in the NERC Glossary[i]. Why is this the case? I don’t know for sure, but I believe the reason “asset” isn’t defined is because there is a fundamental contradiction at the heart of CIP-002-5.1 R1 and Attachment 1. The contradiction is that in theory CIP v5 doesn’t apply to assets (“big iron”), but only to cyber systems (“little iron”). This is why the High and Medium impact criteria in Attachment 1 strictly speaking don’t apply to assets (or Facilities, for that matter) but to BES Cyber Systems. And it is why the definition of Low asset is “an asset containing Low impact BES Cyber Systems”. Yet I think it would be close to impossible to find a single NERC entity or auditor that didn’t first classify its assets as High, Medium or Low impact, then identify the BES Cyber Systems at the Highs and Mediums. No other approach makes sense.[ii]

However, I’m not sure that “asset boundary” needs to be defined, even if it could be. There is no specific compliance obligation associated with this phrase, as there is with the phrase Electronic Security Perimeter (which is defined, of course). So if the entity and the auditor disagree about what the asset boundary is, there is no way this would be likely to lead to a Potential Violation, and certainly – in my opinion - not to an actual violation.

But there is one consideration that was brought up in the SDT meetings, which I don’t see in the LERC definition or the Guidance: The asset boundary needs to encompass all of the BES Cyber Systems located at the Low impact asset; if it doesn’t do that, then it is conceivable some BES Cyber Systems which actually have LERC will end up not being protected.

For example, an auditor pointed out to me that he knew of at least one Low impact generating station that draws its cooling water from deep wells located as far as five miles from the fence line; the pumps for these wells are controlled by systems that most likely meet the BCA/BCS definition. If that entity decided the fence line were the asset boundary and had an external routable connection that ended at the pumps (I realize this scenario isn’t very likely), they might be tempted to declare that the asset didn’t have LERC (since they would consider the pumps outside of the asset boundary). Assuming they also had BCS within the fence line, they then wouldn’t be obligated to protect them as required in Section 3.2 of Attachment 1 of CIP-003-7 (i.e. in the new version of CIP-003 discussed in the post I linked at the beginning of this post).

However, I think this point should be made in the Guidance, not with a definition. This is because a definition would read something like “A physical border that encompasses all BES Cyber Systems at the asset.” How would an entity demonstrate that their asset boundary did include all BCS? Of course, they would have to have a list. And the need to have such a list is ruled out repeatedly in the CIP v5 and v6 standards.[iii]

So I think this point should at least be made in the Guidance.[iv]

   

The views and opinions expressed here are my own and don’t necessarily represent the views or opinions of Deloitte Advisory.

---

[i] It is “defined” in CIP-002-5.1 R1, in the list of six asset types that are considered in scope for CIP versions 5 and 6. So for purposes of CIP versions 5 and 6, “asset” is well defined. Of course, there are a lot of other problems in CIP-002 R1 and Attachment 1 that aren’t so neatly dealt with.

[ii] I have discussed this contradiction a number of times – coming from different angles – since April of 2013. Two posts that tried to address it more head on are this one and this one. Of course, I estimate that very close to 100% of NERC entities and auditors think in terms of the big iron / little iron model (which after all is how CIP v1-4 worked: Critical Assets and Critical Cyber Assets). In other words, just about everybody thinks in terms of “High impact Control Center”, “Medium impact substation”, etc., even though strictly speaking those terms don’t refer to reality any more than the terms “unicorn” and “griffin” do. In fact, during the SDT meeting the group was considering requirement language that referred to “High and Medium impact assets”. I had to be the bad guy and point out that the correct terms were “assets containing High impact BCS” and “assets containing Medium impact BCS”. Nobody disagreed with me on that.

[iii] Someone might object that, by the SDT’s simply stating in the Guidance that all BCS had to be within the asset boundary, the entity would probably still be obligated to have a list. But an issue almost identical to this one has already been addressed and resolved by – I believe – all of the NERC regions, in discussions of the current definition of LERC (i.e. the one that came into effect with v6, not the one that was just drafted and will almost certainly come into effect in 2017). Of course, in the current definition of LERC and the current “requirement” 3.2 of CIP-003-6, a LEAP is required to protect all BCS with LERC. However, the regions all seem to agree that it is possible to show that your LEAP is protecting all of your BCS without having to enumerate all of them; for example, an entity can provide a network diagram showing that all BCS are on a network protected by the LEAP – but the diagram doesn’t have to show each BCS. In the same fashion, using the new LERC definition, the entity could demonstrate to the auditor that all of its BCS were within the asset boundary by providing a physical map of the facility that includes locations where BCS are found – but which does not need to enumerate the BCS themselves.

[iv] There is a small problem with saying this, since technically there is no Guidance provided for definitions, just for requirements (as was brought up in another context at the SDT meeting). But understanding the LERC definition (including “asset boundary”) is required for compliance with Section 3.1 of CIP-003 Attachment 1; it shouldn’t require an act of Congress to allow the SDT to insert this helpful advice about the meaning of asset boundary in the Guidance for that section.

Webinar: Do Virtualization and NERC CIP Play Nicely Together?

One of the most important developments in IT in the past ten years has been the rapid growth of virtualization – compute, network and storage. Use of virtualization has led to huge cost savings, as well as large efficiency gains, in IT environments – especially data centers. Even more importantly, virtualization greatly expands IT's repertoire of services they can call upon to enable new business initiatives. However, electric utilities subject to NERC CIP requirements are still struggling to take advantage of virtualization in their OT environment, even though they realize they would receive huge benefits – especially in control centers. This is because the CIP standards are totally silent on this topic – and this silence continues in CIP versions 5 and 6. Many utilities are too worried about inadvertently falling afoul of some CIP requirement to try virtualization in OT. At the same time as utilities implement compliance with CIP versions 5 and 6, NERC and the Regions have made it clear they want utilities to feel comfortable introducing virtualization. However, they have not provided any definitive guidance on how to do this in a CIP-compliant manner. NERC has ordered the new "CIP v7" Standards Drafting Team to develop revised requirements or guidance, so that CIP will finally address this topic. But it will be close to three years before the new version comes into effect. Where does this leave the utilities? This webinar will try to answer that question. Tom Alrich and Joe Andrews of Deloitte will discuss how virtualization can work under CIP versions 5 and 6, and how v7 may finally settle this issue. John Reno of Cisco will discuss the many advantages that electric utilities and IPPs can realize through implementing virtualization on their OT networks. This includes server, switch, and storage virtualization Steve Sumichrast of Northern Indiana Public Service Company will discuss some of the lessons learned from NIPSCO's successful implementation of virtualization in their control centers in 2011.

Date: Thu, Sep 15, 2016 Time: 2:00 PM EDT Duration: 1 hour Host: Bob Lockhart   Presenters: Tom Alrich, Deloitte & Touche LLP Tom Alrich is a Manager in Cyber Risk Services with Deloitte Advisory, part of Deloitte & Touche LLP. He has worked in cyber security for 16 years, and with NERC CIP since CIP version 1 was approved in 2008. He has worked with over 30 NERC entities to understand and implement CIP versions 1 through 6. He writes a popular blog on developments in CIP.   Joe Andrews, Deloitte & Touche LLP Joe Andrews is a Manager in Cyber Risk Services with Deloitte Advisory, part of Deloitte & Touche LLP. He spent five years as a CIP auditor with the Western Electricity Coordinating Council (WECC). Previously, he worked in cyber security for the US Department of Defense, based in the US, Europe and Japan. He holds many certifications, including CISSP, CISA and PSP.  John Reno, Cisco John Reno manages product and solutions marketing for Cisco IoT. Previously, John directed the product marketing group at Silver Spring Networks, drawing on over fifteen years of experience in software applications, infrastructure management and system design. For the past ten years John has launched and led go to market initiatives for network and data security companies such as Securify (acquired by Intel/McAfee) and EMC/RSA Steve Sumichrast, NIPSCO Steve Sumichrast is the Lead System Engineer for NIPSCO's Operations Technology department, and has worked in the department since 2010.  He is responsible for implementation and adherence to NERC CIP standards for all server, workstation, storage and virtualization infrastructure used by real-time systems.  He holds numerous industry certifications, including certification from Cisco, NetApp and VMware.

To register, go here

The views and opinions expressed here are my own and don’t necessarily represent the views or opinions of Deloitte Advisory.

Deloitte Advisory is Expanding!

Deloitte Advisory’s Cyber Risk market offering for Power and Utilities is pleased to announce two important new additions to its team.

Joe Andrews is Manager of Cyber Risk Services with Deloitte Advisory, part of Deloitte & Touche LLP. He joins Deloitte Advisory after five years as Senior Compliance Auditor – Cyber Security with the Western Electricity Coordinating Council (WECC). While at WECC, he annually served as Audit Team Lead for over 120 on-site and off-site CIP audits. His other duties included providing cyber security SME support to the WECC Enforcement department, speaking at WECC and NERC technical and training conferences, establishing WECC’s audit approach for the CIP v3 to v5 transition, being an SME liaison with WECC Registered Entities on CIP issues, and analyzing and reverse engineering malware to stay current with new and emerging threats.

Before joining WECC, Joe spent 21 years working in cyber security for the US military, based in Europe, the US and Asia. His many responsibilities included implementing and training on the military’s Enterprise Security Framework (ESF), conducting audits and self-assessments of compliance with the ESF, and supervising and training the Incident Response Team. Joe has a BS in IT/Information Security from Colorado Tech University and an MS in Information Security and Assurance from Norwich University. He holds many certifications, including CISSP, Certified Information Systems Auditor (CISA), GIAC Reverse Engineering Malware (GREM), Certified Reverse Engineering Analyst (CREA), and Certified Ethical Hacker (CEH).

David Gulosh is also Manager of Cyber Risk Services with Deloitte Advisory, part of Deloitte & Touche LLP. After a successful career in law enforcement, he has held executive positions in Corporate Security at two large corporations, as well as in the consulting field. Most recently, he was Manager of Corporate Security at a major Independent Power Producer. He has overseen all aspects of corporate security, including Security Operations Centers, security policies and procedures, security assessments and remediation, penetration testing, incident response and business continuity planning, and procurement and implementation of physical and cyber security systems. He has extensive regulatory compliance experience with NERC CIP, CFATS (Chemical Facilities Anti-Terrorism Standards), Maritime Transport Security Act (MTSA), TSA and other regulations. David is a Certified CSO (CCSO) and a DHS Authorized CFATS user.

Deloitte Advisory’s cyber risk services help complex organizations more confidently leverage advanced technologies to achieve their strategic growth, innovation and performance objectives through proactive management of the associated cyber risks. With deep experience across a broad range of industries, Deloitte Advisory’s more than 3,000 cyber risk services practitioners provide advisory and implementation services, spanning executive and technical functions, to help transform legacy IT security programs into proactive, secure, vigilant and resilient cyber risk programs. The Power and Utilities Market Offering performs many types of cyber security services for electric utilities and Independent Power Producers. In particular, we have many consultants with experience providing NERC CIP-related services. For more information, please email me at talrich@deloitte.com.

The views and opinions expressed here are my own and don’t necessarily represent the views or opinions of Deloitte Advisory.

A Breach in the Wall?

In conjunction with one of my colleagues at Deloitte, I have been thinking about what will be required for the new supply chain security standard. One of the first questions that came up was what assets and cyber assets will be in scope for it.

Up until now, there has been an (almost) invisible wall guarding the NERC CIP standards: The standards just apply to devices and systems that contribute to the NERC entity’s control of Bulk Electric System assets (these are now commonly referred to as OT assets, although that term has only come into widespread use in the last couple of years). These devices were called Critical Cyber Assets in CIP v1-v4 and BES Cyber Systems in CIP v5 and v6.

On the other side of that wall are the IT assets, which are not at all in scope for CIP. These are all the systems – financial, personnel, etc. – whose purpose is simply running the business of the entity, not directly impacting the BES. Even IT systems that are used to remotely access OT systems – HMIs, etc. –are not directly subject to CIP requirements, since the remote access controls in CIP-005-5.1 R2 only apply to the Intermediate Systems that allow these IT systems (and others) to access OT devices. But the actual devices used for remote access are completely out of scope for CIP, whether located in the corporate offices next to the control center or in Uzbekistan.

Of course, all of the CIP v5 and v6 standards now in effect only apply to BES Cyber Systems (and related devices like Protected Cyber Assets, EACMS, etc). But what about the new supply chain security standard that FERC just ordered? Does that just apply to BCS as well?

Strictly speaking, there is no way the new standard could apply to BES Cyber Systems. A BCS is a device that is already purchased and in place; only then can it (more correctly, its components) meet the definition of BES Cyber Asset. By definition, the supply chain refers to what happens to devices before they even reach the NERC entity; so strictly speaking, the standard can’t apply to BCS. However, I don’t think this is a huge issue. Maybe the drafting team for the new standard can invent a term like “Intended BCS” for devices that are still in the supply chain, but are intended to be implemented as BCS.

The bigger question is, will the standard have to apply to more than just “Intended BCS”? In particular, is it possible that the new cyber security standard will in some way have to apply to IT, as well as OT, systems? I ask this mainly because the Ukraine attack was primarily facilitated through the IT network. It began with a phishing attack that compromised certain IT systems, and spread until the entire IT network was compromised. Once the HMIs that the engineers used to monitor and control the relays in the substations were compromised, it was an easy step to use those to attack the relays themselves. So – with no reference to the current Presidential campaign – just building a “wall” between IT and OT will ultimately fail to keep out a group that is determined to get through it.

Now, I am certainly not recommending that the supply chain standard should apply equally to IT and OT! However, whether it does or doesn’t isn’t my call, but FERC’s. So what did FERC say in Order 829 that can shed light on what they’re looking for? Do they want the scope of the new standard to be limited to BCS and “Intended BCS”, or do they want it expanded to at least some IT assets?

I reread the Order with this question in mind. When I reached paragraph 24 (page 16), I saw “With regard to concerns that the NOPR’s use of the term ‘industrial control system’ signals the Commission’s intent to address issues beyond the CIP Reliability Standards or cybersecurity controls, we clarify that our directive is only intended to address the protection of hardware, software, and computing and networking services associated with bulk electric system operations from supply chain-related cybersecurity threats and vulnerabilities.” This seems to be fairly clear: only systems associated with BES operations are in scope. These will be BES Cyber Systems and other systems already in scope for CIP.

I continued through the document and came to the meat of FERC’s argument, where they discuss the four objectives they want the new standard to meet. In the discussions of three of the objectives, BES Cyber Systems are explicitly mentioned; clearly FERC had OT in mind for these objectives. But when I came to the title of the third section (paragraph 56, page 40), I noticed something different. The title reads “Information Systems Planning and Procurement”. In this section, the focus is on “Information Systems”. In fact, there is no mention of BCS at all in this section.

Was FERC just sloppy in their language? Did they really mean BCS when they said Information Systems? I don’t think so. BCS, and OT assets in general, are control systems, not information systems. Control systems may contain information, but if so that is incidental to their real purpose. I am especially convinced that FERC meant what they said by the fact that they illustrated their point (paragraph 57) by pointing to Black Energy, the malware that enabled the attackers in the Ukraine to take control of the IT network. Black Energy did all of its damage on the IT network. As far as I know, it was never spread to the OT networks. Of course, it enabled the attack by allowing the remote attackers to take complete control of an HMI that had direct access into the OT network. But Black Energy didn’t actually spread to the substations, as far as I know.

In discussing Black Energy, FERC points (in paragraph 57) to four steps that utilities should take to reduce the risk of propagation of the malware.[i] They don’t say anything about those steps only needing to be taken on the OT network. Obviously, had these steps been followed just on the OT network by the utilities attacked in the Ukraine, it wouldn’t have prevented the attack; they also needed to be followed on the IT network. In fact, since all four of the recommendations are already mandated for the OT network by the existing CIP standards, there would be no reason to repeat that mandate in the new supply chain standard. Therefore, FERC must have had the IT network in mind when they made those recommendations.

I am not going to say definitely that FERC wants the new supply chain standard (or at least the requirements that implement the third objective) to apply to IT systems as well as OT. But I do say that the SDT will have to figure out FERC’s intentions on this.

The Bigger Question

The bigger question is whether the CIP standards in general should address IT as well as OT assets. Would you like my opinion on this question? I didn’t think so, but I’ll give it to you anyway:

1. I think it is a delusion to believe that operational assets can be secured solely by protecting OT networks. As I have just pointed out, the IT networks of the utilities in the Ukraine that were hacked were compromised long before the full attack. In fact, it seems the attackers had full run of those networks for many months. That is why they were able to find and compromise the HMIs that had access to the substation relays. It is true that the specific attack last December could have been prevented with two-factor authentication (and probably a jump host) for remote access to the relays. But with the IT networks so thoroughly compromised, it would have been only a matter of time before the attackers figured out another way to get to the relays (here’s one: Certain engineers receive a well-crafted email from their bosses’ accounts, saying that at such a time on this day, certain circuit breakers should be opened).
2. However, I definitely do not advocate that the current prescriptive CIP framework should be extended to IT assets! Rather, I am now advocating that the CIP standards be written in what I call a threat-based approach (which others call risk-based). Essentially, that approach starts with the premise that no entity has an unlimited amount of funds to spend on cyber security. They need to assess all of the threats they face, and develop a plan that prioritizes action on the most important threats. These threats may be to OT assets or to IT assets; the question is simply how much of a danger each threat poses to the reliable operation of the BES.[ii] In other words, the risk of malware propagating to OT systems (through say improper use of USB sticks) will be compared with the risk of IT network users clicking on phishing emails (which, of course, is how the Ukraine attacks started). If these are both considered important threats, the entity will be required to address them both.  If one or the other is considered less important, it will be pushed down the list and may or may not get addressed (at least not as thoroughly as a threat that is near the top of the list).
3. I think it is close to certain that the new supply chain standard will not be a prescriptive one. It would be a nightmare if a utility had to take specific measures (and document them, of course!) for each of its suppliers and systems purchased, which could obviously number in the hundreds or thousands. FERC makes it quite clear in the Order that they don’t want this.
4. But does this mean I advocate including IT assets in the new standard? If there were time to think of a proper framework for doing that, I would. But this is a big task. If IT assets are now in scope, the BES Cyber System concept will need to be modified or thrown out. If NERC had a couple years to develop this standard (as they asked for in their comments to the NOPR last year), I would say it would be good to do this (the expanded asset identification framework could then form the basis for all of the CIP standards, when they are rewritten as non-prescriptive ones). But as I pointed out in my post after the Order (referenced at the beginning of this post), FERC is effectively giving NERC only 4-6 months to develop the new standards; having to invent a new, more inclusive, framework for asset identification might itself take that much time. So I don’t advocate that the new SDT take on this particular task; and for that reason, I don’t advocate that the new standard include IT assets.

However, my preferences don’t matter. FERC may be saying that at least some IT assets need to be included in the scope of the new supply chain standard. It will be up to the new SDT to decide whether this is actually what FERC is asking for. They they’ll have to figure out how to do it.

The views and opinions expressed here are my own and don’t necessarily represent the views or opinions of Deloitte Advisory.

---

[i] These recommendations were from the ICS-CERT.

[ii] So threats to the normal functions of “purely IT” systems like HR or customer service will not be considered; while they might have a significant impact on the utility financially, they will not impact the BES. However, if a machine in say HR could be compromised with malware like Black Energy, which could then easily spread to machines that do have an operational impact, that would be considered a threat to the BES.