Monday, July 28, 2014

Corrections to Yesterday's Post

Correction No. 1: In my post on the question of the "top-down" vs. "bottom-up" approaches to BES Cyber System identification, I stated "I actually know of only two auditor presentations that have squarely addressed the BCS identification issue.  Kevin Perry of SPP, in his webinar on CIP v5 last February, only talked about the top-down approach.  On the other hand, Joe Baugh of WECC, in his presentation linked above (starting on slide 40), only discusses what I call the bottom-up approach, and never even mentions the BROS."

Kevin informed me by email this morning that I didn't read his webinar narrative closely enough, since he does state in there that  he is open to the entity's using either approach; in fact, he suggests they use both, as I also suggest.

I further went on to say "Does this mean that SPP entities should use top-down, WECC entities should use bottom-up, and all other entities are simply SOL?  At the moment, I’d say yes..." Obviously, I was wrong to suggest SPP entities need to use top-down.  But I was also wrong to suggest WECC entities need to use bottom-up.  Just because Joe Baugh didn't mention top-down in his presentation that I referenced, this doesn't mean WECC won't allow either approach - or a blended one like I and SPP suggested.

However, my statement about other entities being SOL stands, and should be generalized. All NERC entities are SOL until there is some sort of comprehensive interpretation of CIP-002-5 R1 published; and I really think NERC should do it, not the individual regions.

Correction No. 2: This isn't a correction per se, but an enhancement suggested by the generation CIP compliance person that I mentioned in the first post.  He says:

The fix to SPP's concern about missing systems such as environmental is to apply criteria for misuse, misoperation, or failure to operate from the BCA definition to evaluation/classification of the BES Asset's systems.

So if the system's misuse, misoperation, or failure to operate adversely affects performance of a BROS within the 15 minute window and it has cyber assets, it is a BCS.

This should be written into the required Process and applied before identifying and classifying cyber assets.



The upshot of this is that, once an entity has done the top-down approach and come up with a list of BES Cyber Systems, it should then consider all of the other systems at the facility - i.e. the remainder of systems that weren't considered so far because they don't fulfill a reliability purpose. The entity should consider whether misuse, etc. of each of these systems can affect a BROS within 15 minutes. If so, the system should also be considered a BCS.  This provides a rule that would capture the environmental system discussed in the original post, which wouldn't be identified by the top-down approach since it doesn't fulfill a BROS.   If someone were to fool the environmental system into thinking there had been an environmental excursion, the plant would shut down in ten minutes in this hypothetical scenario.

I should also point out that this works both ways.  I recommend that, once an entity has developed their list of BCS using the top-down approach, they should consider whether each BCS so identified can have a 15-minute impact on reliability if misused, etc. (as required by the definition of BES Cyber Asset).  If the answer to that question is no, then it shouldn't be listed as a BES Cyber System.  The top-down analysis by itself won't catch this, since it doesn't build up from BES Cyber Assets as the bottom-up approach does.

Of course, if you actually use both the top-down and bottom-up approaches, then you don't have to add these two qualifications just discussed; they are both part of the bottom-up approach.  In most cases, I don't think it's a huge burden to use both approaches.  The big exception is large generating stations, where there are often literally thousands of cyber assets, and where - as I discussed in the first post - there can be many Low impact BCS, which shouldn't have to be inventoried.


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

Sunday, July 27, 2014

Top-Down vs. Bottom-Up


This is a post I’ve wanted to write for a while.  I have been talking about the “top-down” and “bottom-up” approaches to BES Cyber System identification since last fall, but – as with everything else I write – my views have evolved since that time.  So this post is hopefully my definitive take on this topic, and I can get on to others I want to write[i].

Before I start, I want to point out that there is another use of the words “top-down” and “bottom-up” in regards to CIP version 5.  This is exemplified by Dr. Joe Baugh of WECC, who has used (in the CIP-002 presentation found at this link, slide 20) the words to mean how one approaches CIP-002-5 R1 in the first place: either by evaluating an inventory of BES assets (substations, etc) against the criteria in Attachment 1 (“top-down”), or by evaluating an inventory of BES cyber assets against those same criteria (“bottom-up”). 

Joe says either approach is acceptable, but entities will find the latter to be much more burdensome, since they will have to first evaluate all of their cyber assets as BES Cyber Assets.  This means they’ll have to have a complete inventory of High, Medium and Low cyber assets (since at this point they don’t know how they’re classified).  As a result, just about all entities are using what he calls the “top-down” approach.

This is not how I’m using the terms.  I have been using them – since last October – in a much narrower sense: they are two different approaches to identifying BES Cyber Systems at a Medium or High-impact asset/Facility.  In the bottom-up approach as I define it, the entity starts by applying the definition of BES Cyber Asset to each of its cyber assets.  The next step is to combine those cyber assets into BES Cyber Systems, with no hard-and-fast rule about how to do so – other than the rule that every BCA needs to be part of at least one BCS.

What I call the top-down approach is to start with the BES Reliability Operating Services (BROS), discussed in the Guidance and Technical Basis section of CIP-002-5.  The entity needs to determine which BROS apply to the asset being evaluated (e.g. in a generating station, it is likely that the “Controlling Frequency” BROS will apply, while the “Controlling Voltage” BROS may not).  Then it needs to identify the systems that support one or more BROS at the asset (e.g. the DCS in the generating station).  These will then be the BES Cyber Systems (they need to be further broken down into their component BES Cyber Assets for completeness’ sake, but the unit of compliance is BCS, not BCA).

When I first realized that both of these approaches were viable, I thought it was an either/or question: which one was required by CIP-002-5 R1?  And the answer to that was clear: the bottom-up approach is actually built into the requirement, whereas the top-down approach only comes from reading the Guidance, which is of course not part of the standard for compliance purposes. 

When I say the bottom-up approach is built in, I mean it is implicitly built in.  One of the many endearing features of CIP-002-5 R1 is that it never explicitly orders the entity to identify their BES Cyber Systems in the first place; it starts right out by telling you to classify your BCS[ii].  But obviously you can’t classify what you haven’t identified, so first you have to figure out how to identify BCS.  And since the BCS definition refers to BCAs, you logically have to start with BCAs – then group them into BCS.  So the bottom-up approach is the only one that you can derive from simply reading the requirement.

However, the BROS are discussed at length in the Guidance section, and I know that many auditors consider the top-down approach to be the approach for BCS identification.  I actually know of only two auditor presentations that have squarely addressed the BCS identification issue.  Kevin Perry of SPP, in his webinar on CIP v5 last February, only talked about the top-down approach.  On the other hand, Joe Baugh of WECC, in his presentation linked above (starting on slide 40), only discusses what I call the bottom-up approach, and never even mentions the BROS. 

Does this mean that SPP entities should use top-down, WECC entities should use bottom-up, and all other entities are simply SOL[iii]?  At the moment, I’d say yes, but as I’ve said many times, I’m hoping there will be a comprehensive re-interpretation of CIP-002-5, almost certainly by NERC.  I would think that re-interpretation would address this issue, along with the many other issues I’ve been writing about for more than a year.  And if this doesn’t happen?  Well, we can all take comfort in the fact that McDonald’s is still hiring.

And what do I believe is the right approach?  I have been saying for a while (e.g. in this article in the June issue of Power magazine) that it is best to use both approaches, one as a check on the other.  Practically, I’ve been saying the entity needs to start with the top-down approach, which of course yields a list of BES Cyber Systems.  However, the entity needs to then run the bottom-up approach, going at least as far as the step of identifying BES Cyber Assets.  Then the entity needs to confirm that each BCA is contained in one or more BCS.

I was fairly happy with that idea until I had lunch recently with the CIP manager on the generation side of a large IOU.  He pointed out to me that, in large generating plants (those over 1500MW and subject to criterion 2.1), this will place a big burden on the entity.  It does this because the bottom-up approach requires a complete inventory of cyber assets, and large plants can literally have thousands of cyber assets – “programmable electronic devices”.

You may say at this point (especially if you’re on the Transmission side of the house), “Well that’s too bad, but CIP-002-5 R1 clearly requires the entity to consider every cyber asset at a Medium plant against the definition of BES Cyber Asset; this can only be done if there is a complete inventory.”  However, this misses one important point (and I can say that I missed it until my friend reminded me): not all BES Cyber Assets at a criterion 2.1 plant will be Medium BCAs.  Those that don’t affect 1500MWwill be Lows[iv], and CIP-002-5 says in two places that an inventory of Low cyber assets isn’t required[v].

Does this mean that, at least in a criterion 2.1 plant, the bottom-up approach really isn’t feasible?  In general, I’d say yes.  The entity first needs to do the top-down approach to produce the list of BCS.  It then needs to determine which if any of these BCS affect[vi] 1500MW.  Finally, the entity needs to identify the component BES Cyber Assets of each BCS - as well as those cyber assets that are networked with one or more BCAs, since they will be Protected Cyber Assets.  Any cyber assets that aren’t identified as BCA or PCA by these steps will be Low impact and don’t need to be inventoried.

However, I can think of an example where the top-down approach clearly isn’t enough in a 1500MW+ plant.  At SPP’s BES Cyber System identification exercise I attended in Dallas in February, they of course advocated the top-down approach.  But they also pointed out the case of an environmental system in a large plant that is designed to trip the plant if there is an environmental excursion of more than ten minutes.  Since environmental protection isn’t one of the BROS, this system wouldn’t be identified by the top-down approach; yet it clearly would be identified in the bottom-up approach, since it has an effect in under 15 minutes.  SPP clearly expects such systems to be included in the entity’s list of Medium impact BES Cyber Systems.

Therefore, my modified rule for the criterion 2.1 generating stations is: a) Use the top-down approach to get your list of BCS; and b) Augment that list with any other systems that may not fulfill a BROS but clearly can have a fifteen-minute impact.  In any case, you shouldn’t have to inventory all of your cyber assets at the plant, as long as you can show that cyber assets not inventoried are all on separate networks from those that contain Medium BCS. 

So at least in a criterion 2.1 generating station, the top-down approach (with the slight modification just described) is the only feasible one.  Does that mean it’s the only feasible approach across the board – for substations, control centers, etc?

I say the answer to this is no, for two reasons.  The first reason – the weightier from a “legal” point of view – is that IMHO criterion 2.1 is the only one that can lead to both Medium and Low BCA/BCS at a single asset/Facility.[vii]  If there can be only one classification of BCS, then every cyber asset at a Medium asset/Facility will need to be considered as a BCA, meaning it will need to be inventoried.  The second reason is that control centers and substations (and smaller generating stations) have much more manageable numbers of cyber assets; at them, I don’t believe it’s a great burden to do a complete inventory.

So here is my final “ruling” on the question of the top-down vs bottom-up approaches to BES Cyber System identification:

  1. At criterion 2.1 plants, use the modified top-down approach I outlined above.
  2. At all other High or Medium impact assets/Facilities, combine the two approaches so one checks the other.

Of course, as with everything else having to do with CIP v5, your friendly local Regional Entity auditor will have to decide this question for you (and hopefully he/she will get some guidance from NERC, as I think I’ve already said ten times in this post).

July 28, 2014: Please note I just posted a correction to this post. 

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



[i] What I’m hoping will come soon is a new post in which I “rewrite” CIP-002-5, the way I think it should have been written in the first place.  Of course, this is for heuristic value only, since there is no longer any chance that CIP-002-5 can actually be changed (unlike the last time I rewrote CIP-002-5 - in my comments to FERC last June - when I really did hope that FERC would direct NERC to rewrite the standard.  Of course, that didn’t happen).  But since I still think that somebody – almost certainly NERC – needs to take an extraordinary action and come out with a comprehensive re-interpretation of CIP-002-5, by rewriting the standard now I’ll at least provide my view on what that re-interpretation should look like.

[ii] You may find this statement confusing, since CIP-002-5 R1.1 and R1.2 clearly order the entity to “Identify” BCS, not classify them.  But since this is only done in the context of classifying BCS (i.e. R1.1 is about “identifying” High BCS and R1.2 is about “identifying” Medium BCS), this is a misuse of the term ‘identify’.  There should first be a separate requirement saying you should identify your BCS (using the top-down or bottom-up approaches) at High and Medium assets/Facilities, followed by a requirement something like the current R1 (but much more clearly written), in which you determine which of those BCS you’ve identified are in fact either High or Medium ones (I’m skating over a whole bunch of other issues here.  I’m hoping I can address them all when I “rewrite” CIP-002-5 in a future post).

[iii] I believe this is a NERC Glossary term, but if not I’m sure it’s in Webster’s.

[iv] This is my interpretation.  Criterion 2.1 doesn’t explicitly say that any cyber asset that doesn’t affect 1500MW will be a Low.  This is one of the many areas in CIP-002-5 R1 and Attachment 1 where some sort of ruling needs to be provided by NERC.

[v] It actually says a list of Low BES Cyber Systems isn’t required, but you couldn’t have that list without having a list of Low BCAs.

[vi] I’m simplifying by saying “affect”; see criterion 2.1 for the full story.

[vii] I’m glossing over a whole bunch of considerations here, of course.  I’ve addressed them in previous posts, but when I do my rewrite of CIP-002-5 R1 I hope to address them all in a logical, consistent fashion.

Tuesday, July 15, 2014

The Timeline for CIP Version 5.5


When FERC said they were going to approve CIP version 5 in their April 2013 NOPR, I immediately drew the conclusion that CIP v5 wouldn’t be the next version that entities had to comply with; it would be a new version 6.  My reasoning, outlined in this post, was this:

  1. Given the tone of the NOPR, it was clear that FERC wasn’t going to approve v5 unchanged. 
  2. Since NERC’s Rules of Procedure don’t allow changes to be made to a standard after it has been approved by the Board of Trustees (and all of the v5 standards were so approved at the end of January 2013), the changes would have to be in a “compliance filing” ordered by FERC when they approved 2013.  The revised standards would have to have a new version number, which would almost certainly be v6.
  3. I also didn’t think it was likely that v5 would ever be allowed to come into effect before v6.  I felt the changes ordered by FERC (especially removal of the “Identify, Assess and Correct” language, which FERC strongly suggested they would order when they wrote the NOPR, and indeed they did mandate in Order 791) would make it almost impossible to have a smooth transition from v5 to v6.  I therefore thought that v6 would “sunset” v5, just as v5 would “sunset” v4 when it was approved, and the next compliance version would be v6.
I continued to hold this position when Order 791 came out last November.  In a post two days later, I argued that it was likely that the v6 standards would come into effect on the same dates as the v5 standards, so they would clearly supersede v5. 

However, after attending the first meeting of the “CIP Version 5 Revisions” drafting team in February, I changed my opinion.  As discussed in this post, I was convinced at the meeting, by the smooth-tongued Scott Mix, that there was really no problem with v5 coming into effect before v6; all NERC has to do is let it be known they won’t consider IAC in their auditing, and all will be well.

At that point, my official position became that v5 would be the next version, followed after some period of time by v6.[i]  That is, until I saw the official first drafts of the drafting team’s work (now being balloted by NERC).  Then I realized two things.  First, the drafting team hasn’t produced new versions of all the v5 standards.  Specifically, they have only revised CIP-003, -004, -006, -007, -009, -010, and -011.  They have left CIP-002, -005, and -008 exactly as they were.  You might wonder why this is unusual, since the latter three standards must not have needed changing.

But this hasn’t been the previous practice.  For example, in the CIP v2 to v3 transition, the only standard that was changed in v3 (I believe) was CIP-006; yet all of the standards were revised so that there was a “-3” at the end of them.  Similarly, when CIP v4 was developed, only CIP-002 was changed in substance, but all of the other standards were revved to v4.  The fact that this hasn’t been done this time means that the next compliance version of CIP won’t be v5 or v6; rather, it will be the mixture of v5 and v6 standards I’ve just described.

Is this a problem?  No, it isn’t in theory.  But it does mean that NERC entities need to be careful with the version of the standard they’re using.  With versions 1-3, you could tell simply by the “-1”, “-2” or “-3” which version you were dealing with.  Now, you need to have a little cheat sheet telling you that you should always be using the “-6” versions of CIP-003, -004, -006, -007, -009, and the “-5” versions of CIP-002, -005 and -008.  And how about CIP-010 and -011?  Those were “-1” in the original v5, but they have both been revved to “-2”.  So you need to use the latter.  And since the next CIP compliance version will be a mixture of 5 and 6, it may be better to just call it v5.5 (except I know everyone – including me – will continue to call it v5).

At this point, you may ask (and if not, I’ll ask for you) “Why don’t we just simplify things and bring CIP-002, -005 and -008 to v6?  Then there will be a complete set of v6 standards, and we’ll just comply with those.”  I have to say, that’s an excellent question.  The answer is simple: After the debacle with CIP Version 4 – then v5 – then v4 – and finally v5, I think most people at NERC are convinced that if they introduce a new improved CIP version, they’ll all be strung up from the nearest lamppost by an angry crowd of NERC entities. 

And there is reason for that fear, since the CIP v4 debacle did result in real costs to a number of entities.  On the other hand, it simply isn’t the case that v6 is being foisted on the industry as part of some nefarious plan to generate more paperwork (and perhaps justify more jobs at NERC?).  V6 has only come about because FERC required changes in v5, and these can’t be included in the current version.  V6 is nothing more or less than what FERC ordered (I actually wish it were more than what FERC ordered.  For example, I would like to see CIP-002-5 R1 and Attachment 1 completely rewritten.  I believe I’ve mentioned this once or twice before – like in over 20 posts.  However, it ain’t happening, meaning we have to go to plan B.  Or C.  Or D….But something needs to be done).

So I can guarantee you won’t hear a NERC employee refer to CIP version 6, even though most of the standards currently being balloted have a “-6” suffix.  Instead, it’s “CIP Version 5 Revisions”.  Whatever…

The second thing I noticed is that, unlike what I expected, the compliance dates for the new standards are almost all exactly the same as they were for the “classic” version 5 standards – that is, High and Medium impact facilities need to comply on April 1, 2016, while Lows need to comply on April 1, 2017.  This may be hard to see from the wording of the new Implementation Plan, but hear me out.  For most of the standards, the plan reads like this:

Reliability Standard CIP-003-6 shall become effective on the later of April 1, 2016 or the first day of the first calendar quarter that is three months after the date that the standard is approved by an applicable governmental authority.

So CIP-003-6 will become effective on April 1, 2016 (the same day as CIP-003-5, of course), unless FERC doesn’t approve it until January 1, 2016 or later.  And what is the chance that the latter will happen?  Very small.  Since the new standards will all be presented to FERC by the beginning of February of next year, and since FERC is likely to be happy with them (after all, these new standards are simply what FERC ordered, and FERC staff members have been riding herd on the SDT to make sure they produced something the Commissioners would like, although I’m sure they were always careful to say they didn’t know what the Commissioners would like), it is very unlikely that FERC won’t approve them fairly quickly, and certainly before January 1, 2016.

In other words, there will be no v5 standards that will come into effect, only to be superseded by v6 standards.  The three v5 standards that don’t have v6 versions will remain in effect, and in fact the compliance dates for v5.5 are for the most part unchanged from those of v5.

Of course, this being NERC, there are exceptions to the statement that the compliance dates are the same for the v6 standards as for their v6 predecessors.  Here are the exceptions:

  1. This really isn’t an exception, but compliance with CIP-003-6 R2 – the only requirement that applies to Low impact assets – is due on April 1, 2017 (the same date as CIP-003-5 R2) or nine months after the effective date of CIP-003-6 itself.  This means that, if FERC doesn’t approve CIP-003-6 until April 1, 2016 or later, the compliance date for CIP-003-6 R2 will be later than April 1, 2017.[ii]  But there is almost no chance that will happen.[iii]
  2. CIP-004-6 is the only v6 standard that requires FERC approval six months before April 1, 2016, in order for it to be effective on that date.  Since FERC will get the v6 standards from NERC in early February, 2015, this means they would have to approve them before October 1, 2015; if they approve them in the fourth quarter, then CIP-004-6 will become effective July 1, 2016 (while the other v6 standards will still come into effect April 1).  I won’t say this is impossible, although I still think it is less likely than that FERC will approve all of the v6 standards before October 1.
  3. There is an exception regarding CIP-006-6 R1.10[iv]:
For new high or medium impact BES Cyber Systems at Control Centers identified by CIP-002-5.1 which were not identified as Critical Cyber Assets in CIP Version 3, Registered Entities shall not be required to comply with Reliability Standard CIP-006-6, Requirement R1, Part 1.10 until nine calendar months after the effective date of Reliability Standard CIP-006-6.

This states that control centers that weren’t Critical Assets under v3 have an additional nine months to comply with this one requirement part – so their date is January 1, 2017.

  1. The next exception may seem small but is probably huge: 
Registered Entities shall not be required to comply with the elements of Reliability Standard CIP-007-6, Requirement R1, Part 1.2 that apply to PCAs and nonprogrammable communication components located inside a PSP and inside an ESP and associated with High and Medium Impact BES Cyber Systems until six calendar months after the effective date of Reliability Standard CIP-007-6.

This states that, for the purposes of compliance with CIP-007-6 R1.2, Protected Cyber Assets and “nonprogrammable communication components” inside an ESP have an additional six months to comply, for an effective date of October 1, 2016.

  1. Here is the last exception:

Registered Entities shall not be required to comply with Reliability Standard CIP-010-2, Requirement R4 until nine calendar months after the effective date of Reliability Standard CIP-010-2.

CIP-010-2 R4 is the new requirement for Transient Cyber Assets and Removable Media.  This says that the effective date for this requirement – for all entities with High and Medium assets (the only ones subject to the requirement) – is January 1, 2017.  This is of course a big exception, but probably reflects the SDT’s estimate of the effort that will be required to comply with this requirement.

So there you have it – the timeline for CIP version 5.5.  If somebody creative wants to put this into an actual visual timeline, I’ll publish it.  Otherwise, this is left as an exercise for the reader.


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





[i] There is a precedent for a smooth transition like the above.  When FERC approved CIP version 2 in the fall of 2009, they ordered a single change – a requirement for providing escorted physical access to non-authorized visitors to a Critical Asset.  NERC developed this requirement, added it to CIP-006-2, and changed the version number of all the v2 standards to v3.  CIP version 2 came into effect on April 1, 2010, while v3 came into effect on October 1, 2010.  This transition was possible because there was nothing changed or removed from v2; just the one requirement was added.  In the case of the v5-v6 transition, that was certainly not the case, so I didn’t see that it would be possible to have a similar transition happen as had with v2-v3.

[ii] Here’s why I say this: As has just been said, the compliance date for CIP-003-6 will be April 1, 2016 or three months after FERC approval.  If FERC waits until April 1, 2016 or later to approve the standard, then the effective date for the standard will be July 1, 2016 or later.  Since that date is nine months before April 1, 2017, in this case CIP-003-6 R2 would have an effective date later than April 1, 2017.  However, there is just about zero chance that FERC will dawdle this long in approving CIP-003-6.

[iii] And this is a pretty significant point.  I had really expected that the new requirement for Lows would have a compliance date 9 months or even longer after April 1, 2017.  Given the number of Low impact assets that most NERC entities have, it really behooves them to start planning for the Low compliance effort now.  I have had a couple large entities tell me that, regardless of problems they see with the High and Medium impact assets, it’s the Lows that scare them – simply because of their number.

[iv] This requirement is for protection of cabling that connects devices in an ESP, which itself exits the PSP.  It was one of the four items mandated by FERC in Order 791.

Tuesday, July 1, 2014

More Utility Bashing

In this recent post, I discussed three particularly egregious instances of people reflexively dumping on electric utilities for poor cyber security, without bothering to back up what they said with any evidence.  The first example was an article on the Smart Grid News website, which had attacked the new NERC physical security standard without bothering to understand how and why the standard was developed.

I regret to say that SGN is at it again.  In this recent article – whose overall premise I basically agree with – Jesse Berst takes a pot shot (so to speak) at Pacific Gas and Electric, owner of the Metcalf substation, by saying “Metcalf is the California substation that was attacked last year (though the incident was not revealed until the following spring).” 

I found this quite interesting, since I remember reading about the incident when it happened in April 2013.  Sure enough, a quick Google search found several contemporaneous articles, including this one published the same day as the attack.

It is true that the publicity became much more widespread this year, when the former FERC chairman began raising the issue repeatedly, and some US Senators and Congressmen wrote FERC to do something about this (even though they had been doing a lot) – this led to the new physical security standard, CIP-014-1.   

But to say that this was never disclosed last year is just another example of the reflexive utility bashing that seems to be one of the biggest sports in the media nowadays.  I’m certainly not saying the utilities can’t be criticized for poor cyber security practices.  But make your case, guys – based on facts.

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