Some Thoughts on Dragos and Imposter Syndrome

After attending my first DISC conference at Dragos yesterday, I realize how easy it is to experience feelings of imposter syndrome. Imposter syndrome is that feeling like everyone else around you knows so much more than you and you don’t have much to contribute. A good description of it can be found in WebBreacher’s blog and video from BSidesDC 2017 at https://webbreacher.com/2017/02/17/imposter-feelings-resources/.

The DISC conference is a yearly internal Dragos conference. DISC allows Dragos personnel to talk about some of their research and present some levels of information that aren’t always appropriate for public release at normal security conferences. There may be semi-private releases about activity groups, internal research projects, discussions about lessons learned from customer engagements, and other really powerful content. DISC 2019 was no different. The lineup of speakers and the topics at this year’s conference were outstanding and the presenters themselves were very engaging on stage in front of over 300 people, split about half staff and half customers and visitors. Listening to the amazing content, my feelings of imposter syndrome really kicked in.

I come from an engineering background, not a cyber security, computer science, or networking background. About 5 years after I started working, I was given the opportunity to move into an ICS networking project. I was the only one working on this project for a number of years, so I didn’t really have anyone to teach me networking, writing test tools, and the specifics of ICS implementations. I had to teach myself for the most part. I stuck my foot in my mouth multiple times while learning and got shutdown by multiple people who were “superstars.” Even after being in the ICS cyber security world for almost 20 years, I regularly feel like I don’t always belong.

I joined Dragos in August 2019, which means I’ve been here a little over 2 months at this point. I’m no longer the “new guy,” but I’m still not part of the old guard at Dragos. I’m still learning the way Dragos does things and getting used to the flow of startup culture. I’m getting there, and I realize I still have a long way to go.

That said, I work with some amazing, smart, talented people. Not only that, they are all welcoming and willing to talk and teach the things they are working on. I’ve been told multiple times that people are excited to work with me and feel that they could learn a lot from me. My normal imposter syndrome kicks in often during these conversations. My internal voice is always like, “What I’m doing isn’t really that impressive. I’m not as smart as all these other people. Anyone could do what I’ve done if they just thought about it a little.”

What I need to remind myself to fight the imposter syndrome is that Dragos doesn’t hire mediocre people. We are all amazing in our own ways. I wouldn’t be here if they didn’t see value in my experience, knowledge, and desire to learn. I’m also not a full-of-myself “superstar” that’s a walking policy #1 violation, like some people in the industry. I may not know what some of the other really smart people in the company know, but I’ve got my own set of knowledge that can help move Dragos forward. I belong here. I feel like I’m part of the Dragos family. While my imposter syndrome will probably never go away, I feel like I belong here more than any other place I’ve been before.

Some History of Security Levels in ISA/IEC 62443

One of the comments/complaints I’ve heard often about the ISA/IEC 62443 series is that the definition of Security Levels (SLs) is too vague and can’t be used. Many of these comments come from people that are either safety engineers or have worked around inside and/or safety systems for long periods of time. Now that 62443-4-2 has been published and 62443-3-3 is being revised, I felt it would be a good idea to give some history behind the decisions made surrounding the SL language.

SL Definitions

The ISA/IEC 62443 series define SLs in terms of four different levels (1, 2, 3 and 4), each with an increasing level of security.  (SL 0 is implicitly defined as no specific requirements or security protection necessary.)  The model for defining SLs depends on protecting against an increasingly more complex threat and differs slightly depending on what type of SL it is applied.

  • SL 1 – Protection against casual or coincidental violation
  • SL 2 – Protection against intentional violation using simple means with low resources, generic skills and low motivation
  • SL 3 – Protection against intentional violation using sophisticated means with moderate resources, IACS specific skills and moderate motivation
  • SL 4 – Protection against intentional violation using sophisticated means with extended resources, IACS specific skills and high motivation

These definitions were intentionally written vague in order to be used in various instances without the need to change the overall format. There are a few main points to consider with these definitions.

Risk Reduction Factors (RRFs) & Safety Integrity Levels (SILs)

NOTE: I’m not a safety engineer, so my explanation is strictly from what I’ve learned from working alongside safety engineers and Google searches.  There are probably some mistakes and oversimplifications in this section.  I include this information to help justify why we went the direction we did when developing 62443-3-3.

When you look up “risk reduction”, many different topics come up, including, financial, medical, disaster, and safety. For industrial control systems (ICS), most professionals look to disaster recovery and safety when thinking about risk reduction.  For safety systems, the level of risk reduction that a system needs to bring it to within a desired range is called the risk reduction factor and is measured by Safety Integrity Levels (SILs).

When the safety of a system is evaluated, a native risk factor is determined by using a Process Hazards Analysis (PHA).  These techniques often use the results of a Hazards and Operability (HAZOP) study and/or a Failure Modes and Effects Analysis (FMEA) to determine the overall hazards associated with the process and its equipment.  A HAZOP looks at the process itself and looks for ways in which the process can cause undesirable consequences and impacts.  This allows designers focus on the areas of the process that may be riskier and helps to prioritize the mitigation efforts.  A FMEA looks at the ways in which a system can fail and determine the potential consequences and impacts of that failure.  They look at it from a feed forward point-of-view, meaning they look at initiating events and then look at the potential consequences and impacts of those specific initiating events.

From the PHA, an organization can determine the processes and systems that may have a native risk that is outside a level that the organization has deemed tolerable.  If that is the case, the organization needs to apply risk reduction measures to bring it within a tolerable level.  The risk reduction factor (RRF) needed for the system is determined and a target SIL is assigned based on whether the system runs continuously or only at select times.  SIL ratings are assigned a number from 1 to 4 with 1 being the lowest RRF and 4 being the highest.

Risk Reduction Based vs. Attacker Based

One major thing to note about this discussion of safety systems and all of the analysis and mitigation techniques revolve around accidental and unintentional failures of a system.  They usually don’t consider the intentional circumvention of safety systems or sabotage.  In those cases, all of the SIFs applied to a system may be useless to prevent a critical situation that results in potential disastrous consequences and impacts.

This is where the application of risk reduction has a major difference between safety and security.  Security, especially that for ICS, is mostly about preventing a condition from arising that results from the accidental or intentional circumvention of policies, procedures, practices, and technology.

Risk reduction, therefore, cannot be calculated completely quantitatively for security.  The mindset of an attacker cannot be broken down into any mathematical formula that can then be used to determine a strict order of magnitude type measurement of RRF.  Antivirus companies, like Symantec, McAfee, and TrendMicro, that operate in the information technology (IT) and business environment have enough statistical sampling from their installed clients that they can produce some level of approximation, however, it is highly biased by their sample set.  They give some indication of trends in the overall IT/business attacker mindset and techniques, but they cannot be used as direct input for risk calculations.  When it comes to attackers in the ICS environment, there is not enough statistical data for designers and defenders to make any logical conclusions about motivation or specific techniques.

Writing the 62443-3-3 Standard

While writing the 62443-3-3 standard, we found that we wanted some logical separation between different sets of requirements and also wanted to be able to provide some justification as to why particular requirements were placed in those different sets.  We knew that we would never reach complete agreement on which requirements belonged into which buckets, however we could at least show that some thought went into the choices.

The four main groups that we chose were as follows:

  • (Unintentional) Personnel violating policies, procedures, and techniques inadvertently while trying to do their daily jobs.
  • (Intentional) Generic business-style attackers, script kiddies, bleadover from the business network, etc.
  • (Intentional) Industrial aware attacker or insider, but not someone with elevated privileges or detailed knowledge of the systems.
  • (Intentional) Industrial aware attacker or insider with elevated privileges and detailed knowledge of the systems.

When we looked at the first level (SL 1), we generally thought about well-meaning personnel that were trying to do their job in a way that made sense to them.  They may have violated policies, procedures, or techniques, but it was not intentional.  These may be cases like personnel posting the password for the engineering workstation on the monitor or side stepping a policy in order to get something done in a time critical situation.  They may go against basic security principles, but it is done with the intention of getting their normal job done.

The second level (SL 2) is the first where we thought about intentional attacks.  These would generally not be directed ICS attacks, but would be the typical bleedover from the business network.  They would be generic types of malware or Internet-based attackers that don’t have an understanding of ICS and ICS-specific attacks.  For the most part, these types of attackers would be interested in using the ICS system for some sort of financial gain, such as ransomware, botnet, industrial espionage, etc.

The third level (SL 3) is where ICS-specific attacks first appear.  This type of attacker might be someone that’s worked in the ICS environment or it might be an insider in an organization that has access to some systems but not everything.  The attacker in this case might be a disgruntled employee or a competing organization that is trying to infiltrate the systems.  These would generally be normal operations staff, not those with detailed knowledge of the systems and defenses.

The fourth level (SL 4) is the highest level of defense.  This is the level where “Trust No One” is the general rule of thumb.  The attacker in this case would have deep insider knowledge of the systems and processes being utilized.  These would generally be engineering staff, system administrators, database administrators, or other personnel with elevated privileges or extensive access.

While some may classify SL 4 as “nation state” defense or being able to defend against “Stuxnet 2.0”, this would not really be the case.  In most cases, if a “nation state” actually came after an organization, it is doubtful that the any level of defense could completely eliminate the possibility of being penetrated.  At best, your organization would hope that they are able to detect the attacker’s presence and initiate some sort of remediation effort prior to the attacker reaching their final objective, whether that is collecting information or causing damage.

These four categories of attacker allowed us, as the writers of the 62443-3-3 standard, to look through our set of requirements and decide that one requirement was really trying to defend against a known insider versus a general business virus.  The levels were never intended to have quantifiable, distinct, easily identifiable separations.  They were not intended to be used as absolute, set in stone values or to be used by themselves to define the security applied to the system.  They were only intended to allow us, as the authors, to convey to the reader of the standard some level of justification for why certain requirements ended up in the levels they did.

BSidesDC QR Registration System

By all accounts, this year’s BSidesDC (http://www.bsidesdc.org) registration system was a vast improvement over previous years. We’ve had a variety of problems that have all caused on-site check-in for registered attendees, sponsors, speakers, and trainees to be extremely slow. The 2015 BSidesDC conference was particularly bad, resulting in a nearly complete failure of the automated system. We actually resorted to a paper printout of the database in order to get everyone checked in.

In the after action review, we decided that a new system was needed. I took it upon myself to figure out a better way, either by finding something out there that we could use or by designing and building a new system.

The first thing I did was to investigate commercial solutions. Companies like Eventbrite make systems specifically designed to register people for events and then check them in. Many other BSides conferences use them, and it was a logical place for me to start looking. It turns out that these companies don’t charge a service fee for free events, so events that are free can use the software without any difficulty. If you collect money for an event, then they charge a pretty high service fee. It’s not a knock against those types of companies. They make a good product, and they deserve to get paid for it. The problem is that it would require us to build in that service fee into the price of our tickets. It would have increased our prices significantly.

So, it looked like I was going to have to investigate building something. The engineer in me said, “Awesome! A project!”

I first looked at commercial barcode scanners to get a price comparison. 2D code scanners are not cheap. New ones start at around $100 and go up from there depending on the features you want. That was just for the reader itself. That didn’t include the computer that it would plug into or any other systems needed. I figured that there must be a cheaper solution.

img_20160911_152000Like most engineers and tinkers, I have a couple Raspberry Pi at home. Also, like most engineers and tinkers, I haven’t really come up with much to do with them. I played around with them when I first got them, but I haven’t really put them to good use. I decided I would look into building a QR reader system that used them.

The system I finally came up with uses a series of two or more Raspberry Pi units, one server and one or more readers. I used a Raspberry Pi v3, the Pi camera unit, some python programming, and some electronic components to build a system that worked well enough to check-in over 1000 in the span of a weekend without any major failures or screwups. Was it perfect, no. Are there things that could be done better, absolutely.

I have already started a list of improvements that I’m planning for next year. If you have any suggestions, please feel free to send them to me. BSidesDC wants this to be a community effort, so we welcome input.

I am currently working to document the hardware that I built. The software is already up on GitHub if you are interested in looking at it, https://GitHub.Com/jimgilsinn/PiConReg.

I will be posting a few different articles about this system in the near future. Keep an eye open for more to come.

Obligatory First Post

This is my obligatory first post. This is my first real attempt at blogging. I have written quite a bit over the years, and had discussions with many of my friends. I’ve never really gotten into writing my thoughts down for others to see. There have been a lot of times where I’ve just wanted to say something about all sorts of issues, but I’ve never really had a vehicle for putting it out there. I’ve written some longer posts and notes on Facebook, but those are limited to my friends. I’ve written a little bit on Twitter, but that is limited by the number of characters per tweet. So, I felt that creating a blog was really the only way I could really go forward.

I have all sorts of things that bounce around in my head on all sorts of topics. This blog will probably be a mix of technology, information/cyber security, ICS/SCADA, family and friends, politics, rants and raves, and other random thoughts. I don’t have any real desire to limit the topics yet. I will probably be pretty sporadic in my posts. At times, there will be a bunch. At others, there won’t be anything from me for a long time. Since this is a personal blog, I will be writing when I get time or get the energy.

I hope you like it.