IoT

Last week, I was an invited as a guest presenter to the EFC’s IoT group meeting in Toronto, Canada. During this meeting, I presented our current view on state of standards and regulations that will impact many markets globally but with a focus for vendors who service the NA market for electrical and critical infrastructures.

With pending Bill C-26 and it’s current requirements it will have a potential negative impact to SMBs who are not servicing this sector. Our guidance is component and product vendors must start assessing both cybersecurity and privacy risks in their business not just a once but on-going basis and ensure they create auditable outcomes for these activities (full stop). Governments globally are clearly going this route and if you want to sell into many jurisdictions you will need to demonstrate how you meet these requirements.

By far the easiest way to do this is by implementing a governance framework (there are many, just chose one!). Likewise, you need a SDLC, again just implement one for your business if your a product vendor. Last but not lease, think about how you will demonstrate you meet these requirements. I would highly recommend you loot at the CSA Groups T-200 which has been adopted in both Canada and US as a means for certification.

Here are the links I have included in my presentation:

a. US Executive Order for Cyber Security

b. Report the US President on Improving the Nations Cybersecurity

c. Canada announcement on Secure by Design Approaches

d. Bill C-26

e. NASA Details of Detecting Fraud in Supply Chain

My Presentation:

ElectroFederation – IoT:OT Standards and Regulations

 

A short history

This project started from a request back in 2016 from national energy provider company wanting to ensure that the IoT based devices they were recommending to clients were safe for use and could not be weaponized. This came to be as their in-house legal team we getting nervous hearing about all the device compromises on a daily basis.

This organization was known to the CSA Group standards teams and the reach out happened in the Fall of 2016 in a former site of CSA in Seattle suburb near Redmond. This meeting focused on the current nature of standardization and the complete lack of certification that looked at both the companies and the products they created from a maturity perspective. Hence the concept of the T200 was born and I was fortunate to be part of that discussion and in the develop of the T200.

Now happens next is bit strange for standards developers, specifically when creating new standards you do that market scan, determine weaknesses, etc. In essense a study period to better understand the market. However, CSA with our help decided to build a cyber assessment program. Yep, that is what we did and tried it a few times to better understand the overall impact to the vendor (regardless of size) and their ability to meet a baseline. This was a challenge and was not easy, it resulted in a lot more grey hairs. However, after 18 months of developing a process and validating it with vendors on both sides of the border, we had something. Not a small something but a concept that was field tested and ready for prime time!

Now based on this and with support of the folks at our energy company and CSA, a NOI (Notice of Intent) was filed with Standards Council of Canada. It was met with some challenges by other SDOs that other “certifications” existed and this was not required. However, I was called up from pinch hit for the CSA on this as I wrote the seed document used for the NOI filing. My position on my argument was easy. There is no certification scheme that considers a company and the products they create from maturity model perspective. Needless to say, CSA was granted the project and we began our work in earnest to build our committee.

I will not get into all the trials in tribulations for a standards development process as it long, boring, and I don’t need to make this blog any longer than it needs to be ;). We assembled a mix of expert in both Canada and the US and developed the core content and 200+ controls that would be included in the initial version. This included adding a last minute supplement to meet the specific needs of the energy sector for both NERC and FERC compliance. It was tough and we got it done and published in May of 2022.

T200 Foundations

Here is what is contained in the standard, and why it is a game changer:

  • It starts with a vendor self -assessment, then initial Maturity Level is assigned.
  • Next up an audit verification of the self-assessment claims, then Maturity Level is updated to reflect any issues identified.
  • Finally a penetration test for the primary solution of the vendor including all components (device, cloud, apps). The final overall Maturity Level is assigned to the organization.

Are are some of the details on this approach.

  1. Maturity Levels:
    • Level One – Global baseline controls for a device
    • Level Two – Low security maturity for cyber risk and safety related solutions
    • Level Three – Midrange security level for cyber risk and safety related solutions
    • Level Four – Highest security maturity level for cyber risk and safety related solutions
  2. Six Domains of Coverage
    • Governance – Practices that organize, manage, and measure software security initatives within an organization
    • Intelligence – Practices that result in corporate knowledge used in carrying out software security activities
    • Software Development Lifecycle – Practices associated with analysis and assurance of particular software development artifacts and processes
    • Deployment – Practices that work together with traditional network security and software maintenance organizations
    • General – Practices related to an organizations approach to cyber security and data protection
    • IoT Solution – Practices considered during the development of IoT products/solutions
  3. Eighteen Practice Areas (these align to the Domains)
    • Governance – Strategies and Metrics, Compliance and Policy, and Training
    • Intelligence – Attack Models, Security Features and Design, Standards and Requirements
    • Software Development Lifecycle – Architecture Analysis, Code Review, and Security Testing
    • Deployment – Penetration Testing, Software Environment, Configuration Management and Vulnerability Management
    • General – Asset Management, Trustworthiness, and Security Operations
    • IoT Solution – Security by Design, Data Protection, and Security Feature Set
  4. The Entire Process for T200 Certification (this will depend on the lab conducting the evaluation)
    • Complete a NDA or similar
    • Complete a self-assessment questionnaire
    • Submit the self-assessment questionnaire for evaluation and grading
    • Audit of vendor
    • Audit Findings report
    • Testing and evaluation (product/service)
    • Testing and evaluation report
    • Attestation label filed for product/solution

This process makes it easy for vendors to undergo the evaluation but at the same time it allows any organization to chose the target Maturity Level for a vendor to target.

What has been identified is the ability to meet requirements for supply chain and third party providers for any sector and it aligns to the ISO/IEC standards for IoT Baseline and Security/Privacy, the NIST IoT baseline, ETSI 303 645, and UK regulatory requirements. Harmonization was a key aspect of this project and ensuring we were tracking too and preventing fragmentation was key to our success. Security is not a one and done process but an ongoing lifecycle. You either buy into this approach or you don’t. It is only way to ensure the changing landscape of cyber risks are being identified and mitigated.

Here is a link to the standard: CAN/CSA T200

 

 

Well folks, we just completed 12 years at TwelveDot and it has been quite the ride for both the company and myself. We have had  a lot of changes over the years with both the company and how we operate. This was due to a changing focus with our customers and how we had approached offering our services. I would have never thought that I would get to meet so many new contacts, work in new sectors such as aviation, healthcare, and education, and get to travel the world over doing so. To all of our current and former clients thank-you for believing in us. To those we still have to meet, we look forward to the day we can satisfy your cyber needs.

Starting this month and going forward, I will be posting updates as we look to change some of the operational aspects of the business. These are not significant just changing with the times to again meet the demand of the market and need for specialized services.

I will also beginning a series on the CSA/ANSI T200 standard that was published last year. We were pivotal in both developing and writing this standard and we are hoping that it will really become a baseline for all IoT devices to be evaluated using a maturity model approach. This standard already is aligned to the ISO standard on a IoT baseline (ISO/IEC 27402) and the ETSI baseline (303 645) for Europe. We made harmonization a key aspect of this standard to allow vendors to get assessed under one program that would have global recognition. More on this later including the many organizations who are already recognizing this standard for testing and evaluation of IoT products.

I will also be announcing a book I am working on later this year as well. It represents the 10 plus years of work we have done for IoT both as research and as product evaluators.

With the post-COVID generation upon us, we look forward to contributing to more International standards work and projects that help to build on our recognized achievements to date. To our staff, this would not have happened without you and I am grateful for all our staff both current and previous.

//Faud

Note: This blog was written by Marc C. a recent co-op student with us this summer. We were very fortunate to have such a great student and future cyber security profession on our team. His “report” below just shows the potential we have in our youth for cyber today. It was great having you on our team Marc. We wish you great success in your future studies and cyber education (which will be life long).

As a 16-year-old high school student from Immaculata High School, this summer I had the opportunity to do an internship with a cybersecurity company called TwelveDot. This amazing opportunity has been a great learning experience for me. I was able to explore a professional environment while engaging in technical projects at the company.

The project that I worked on consisted of making a proof of concept that could be used to demonstrate common vulnerabilities in embedded devices and ways deployed IoT devices can be exploited. Using a microcontroller and a Lego Mindstorms wind turbine, I built a network with the microcontroller using the MQTT architecture. The microcontroller would then be used to control the wind turbine over the network, just like how a real-life deployment would be.

To kickstart the project, I started by learning about the different hardware pieces required, and how the microcontroller can be used. In particular, I looked at the Onion Omega Pro 2, which is a microcontroller with the capacity to be connected over a network and is used for many purposes, including IoT deployment. With the help of Bryan, a technical security analyst, I found a way to control the Lego with the microcontroller using logical signals. During development, we decided this project needs to be as realistic to real-world deployments as possible, so not only this meant considering the network piece and how it’d translate to code, but it also meant understanding realistic configuration parameters and incorporating those into the model. Since this meant a lot of testing, much debugging also took place. While testing, we identified many bugs, so Bryan and I had to change certain parts of our code.

 

Figure 1: Marc and his project (love the t-shirt, it just says it all)

Once the testing was done, we did a demo to showcase the architecture and the different vulnerabilities the model is subjected to. This includes different types of attacks such as information disclosure, man-in-the-middle, or a DoS attack.

Overall, this project was exciting but challenging. Throughout my co-op journey, I ran through many obstacles which made me quite uncomfortable due to my lack of experience. Fortunately, at TwelveDot I had support from Faud, my supervisor, and my colleague Bryan.  At first, I had trouble connecting the Lego piece to the microcontroller board to allow the Lego piece to be controlled logically. With the help of my team, Faud and Bryan, we discovered we needed additional hardware components like the h-bridge circuit driver and a voltage set-up. This experience made me realized how useful the internet is in helping us troubleshoot technical issues.

 

 

Figure 2: Marc and Bryan after the final demo

Debugging and testing the various aspects of the project was the most demanding for me, but it was also the most important for me since testing is often necessary for the unexpected. For example, I had some troubles since I was not used to some of the technologies used, but my colleague Bryan walked me through the debugging and testing needed to troubleshoot the network and hardware pieces. After this experience, I understood a lot more in the field of hardware engineering and cybersecurity. During testing or debugging, we can sometimes run into bugs that can make us change the model or the blueprint of the project. For example, we had to refactor the code to object-oriented to accompany new features. One other valuable lesson for me was the need to consider the safety of the end-product, as it relates to electric power, and incorporating that into the testing phases as well as the codebase.

Overall, working on this project was an amazing experience. It gave me exposure to coding, working with electronics, and exploring how vulnerabilities can turn into exploits. This has allowed me to be more familiar with Python, Linux, JSON, MQTT, Hardware Engineering, SSH, and Computer Networking. I learned that sometimes it can get frustrating when you get stuck on a problem, but it also made me realizes the tools, resources, and the people who could help me get work towards the end goal. A huge thank you to the TwelveDot team for this valuable learning experience!

At the recent ETSI annual conference, several cybersecurity domains were discussed. In this article, we’ll look at the latest development in IoT.

With the increasing adoption of 5G technology, the European Commission had requested ENISA to develop a candidate European Cybersecurity Certification scheme for 5G network. The EU 5G will be an extension of the EU toolbox for 5G security as it seeks to address certain risks, as part of a broader risk mitigation strategy. While ENISA is still processing both ECUU and ECUS schemes, we can expect the finalized version of ECUS in Q4 2021.

As the European Commission and Cybersecurity Group under the CSA start the discussion on a candidate for a cybersecurity certification scheme for connected devices, we can expect such scheme will be aligned to EU legislative frameworks and other European Cybersecurity Certification Schemes. In the EU, it’d be consistent with EU Cybersecurity Certification Schemes such as the European Common Criteria Scheme and the European Cloud Services Cybersecurity Certification Scheme. We believe combining multiple schemes may provide a holistic approach to certification. For example, using the IoT scheme for products and the EUCS scheme for supporting services may complement the standalone IoT scheme approach. As of now, we are expecting the URWP for European Cybersecurity Certification to be published in Q3 2021 where we can then understand how the European Commission would issue the request to the EU Cybersecurity Agency. Right now, we know the scope for such scheme will capture IoT devices in residential, industrial, and any other settings. The assurance levels will be the same three levels provided under the CSA. As the European Commission emphasizes the need for standardization, standards development in EU member states and internationally will need to be integrated into the EU Cybersecurity Certification Scheme for IoT.

We are also seeing exciting updates to EN303 645. EN provides a common baseline across the European and global markets for all consumer IoT. Currently, the focus for Q2 2021 is on developing assessment specifications (TS 103 701) to test against provisions of EN303 645. As this standard matures, we can expect alignment to standards and legislation under development for IoT.

General cybersecurity assessment frameworks often serve as a horizontal solution; however, to cover the general assurance requirements (such as assurance levels defined by the CSA) and to the specific field of application such as IoT, some guidance is provided on how to integrate EN17640 into a certification scheme. EN 17640 as a general evaluation methodology that when integrated into a certification scheme to fit the scheme assurance requirements, it raises some interesting questions. One is the extent of assessments required for each level. Currently, dEN 17640 editors and CEN/CLC JTC 13/WG 3 are working to publish this standard in September of 2021. Interesting to note is the future outlook of possible application in the Radio Equipment Directive Certification scheme.

The GCF also had some interesting updates on its Consumer IoT Security Accreditation programme based on EN303 645. Currently, its phase 1 provides self-accreditation for non-constrained devices. This involves the manufactures submitting a security compliance declaration covering the first 3 IoT Security Provisions defined by ETSI Cyber (EN 303 645). We are expecting development work for phase 2 to focus on extending assessment coverage to include constrained IoT and using TS 103 701 Test Specification as a baseline for conformity assessment to EN 303 645. For now, product manufactures should make sure no universal default passwords are used, implement a way to manage reports of vulnerabilities, and keep software updated for phase 1.

Another aspect of EN303 645 adoption is from the Cybersecurity Labelling Scheme from CSA Singapore. This scheme consists of 4 tiers. Although participation is voluntary, security-critical devices such as Wi-Fi routers will obtain at least tier 1 in Singapore. As more nations launch their schemes, we have to more mindful of fragmentations. For this particular scheme, it is done by leveraging EN303 645 and TS103701 for tier 4 testing.

Our observation was the importance of the collaborative effort in developing mutually recognized standards. For product manufactures in the global market, this provides value in that manufacturers do not have to choose which standard to be compliant for to operate in many jurisdictions.

This project started back in the Fall of 2016 in a boardroom in Seattle, Washington. The goal was to help a national utility company ensure that IoT based products were not weaponized while deployed. Their challenge to the team: How could a product assessment team help them given that there was national standards for things like a building code and electrical products.

Over the course of 18 months, a framework was created and validated using a pilot program with vendors who were considered SMBs in the IoT space. Several of these companies were only a few years old with very little in the way of process and procedure but were building a name for their products.

The program has three main phases:

    1. A self assessment;
    2. An audit based on claims made in the self-assessment, and;
    3. Formal testing (blackbox, white box, and grey box).

We were able to identify that most companies could complete the first phase in about 4 hours, the audit was typically completed in a day and testing was taking about one month. As the approach was not a “one-and-done” approach but a method to show maturity having a company enter the program would allow for the mapping of next target controls that need to be required.

This was how we started when we wrote the Expression version of T200, now fast forward 12 months and we have now added the following:

  • Add a baseline that maps to all international baselines for IoT based product companies;
  • Scope of testing is the solution not just the device;
  • Does not invalidate other programs or certifications already received for cyber but compliments them;
  • Created a supplement to deal with OT systems;
  • Defined the audit details that will be significant for both the auditor and organization being audited, and;
  • Providing a roadmap for young product companies to quickly map their current controls to those based on international standards and best practices to build maturity.

We believe that this standard will help SMBs who make products and services as it focuses not only on a product but how the company operates securely. This standard has been registered in both Canada (under Standards Council of Canada) and the United States (ANSI) so it will have applicability to many sectors including healthcare, OT, and automotive.

More information will be provided once the final version is published, which we anticipate in Spring of 2021. If you have any questions in the meantime please contact us.

With the dramatic growth of IoT globally in all sectors, medical was not going to be bypassed but instead there was going to be significant growth in new products/services for medical.

With some of these new solutions come more capabilities and freedoms for patients who can now still be fully monitored without patient care. With an aging population and global pandemic, the timing cannot be better for the uptake of these technologies.

Now the part that makes everyone uncomfortable is how to protect the privacy of the patient and ensure that there is no inherit cyber risks of using the product. i.e. can it be weaponized.

Over the past couple of years, we have been working with many health products companies globally to help with securing these solutions. This includes a 3-years research project on IoT for Medical Devices. This has led to a methodology that allows us to formally assess a solution. Now this is not just what some would call penetration testing but a lot more than that. We create a testing environment that includes power supplies, SDRs, packet generators for various protocols, wireless sniffers and countless other tools. We also have a playbook that is used to test all classes of products.

Based on this, if you are looking to test and evaluate health devices here is some guidance, we would like to share with you.

  1. Determine the market you looking to sell the product into, this will determine the minimum testing and evaluation that will have to be provided. In Canada that would be Health Canada and in the US that is the FDA. Both have very specific requirements for products under this classification so make sure you understand the documentation you will require.
  2. Determine the standards to be used for evaluation, this may include one or more of the following:
    • UL2900-1-1 or UL2900-2-1
    • CSA T200
    • ISO 14971
    • IEC 80001-1
  3. These standards will determine the test cases on how each aspect is to be assessed and verified. Keep in mind, these tests and tools must be repeatable, and all outputs of testing need to be collected for validation and auditing. When creating each test case ensure you are using a scientific methodology approach. You will have to provide to reviewers how and why of each test case. You can even take screen recordings and captures to record impacts to devices under test.
  4. Some of these testings will not be easy, especially if you do not know aspects of system design, hardware testing, and tools such as logic analysers. It will also take longer than you anticipated as well. Plan your project scope accordingly.
  5. Packet capture everything and spend enough time to analyze these. Many times, we found some intel on the devices by them being “chatty” on the wire. This includes sending nuggets of information in headers and data fields unencrypted which can be used against a device. You have got to love metadata!

As you work towards medical certification keep in mind you can do these tasks both in-house and using a 3rd party. If you are using a 3rd party, make sure they are accredited. Using a consultant for pen testing might save you some money but will not potentially pass a regulatory review.

TwelveDot currently provides a complete solution which includes testing hardware, firmware, network communication, mobile and web application and the cloud platform that exceeds current FDA and UL2900 requirements for testing and evaluation. We are working with global medical equipment companies to evaluate and secure their solutions. Please contact us to learn more.

 

To everyone that attending the IoT Ottawa Virtual Meetup thank-you for taking the time to attend this session and for participating. It was a good discussion and I hope it was helpful for those of you that attended. It is good to see that events like these can still be held despite the current conditions.

For those of you that were not able to make it to the Meetup here is the abstract of the presentation:

One of the biggest barriers for the adoption of the IoT products is the potential security and privacy risks. To help overcome this reluctance vendors need to ensure that they are clearly demonstrating to the market they have implemented security and privacy in their solution. This workshop will provide an understanding how to secure an IoT solution leveraging a risk based approach using standards. We are going to present how IoT projects should be approached to ensure both security and privacy requirements are included at design time and be validated during the development lifecycle. This is based on countless projects where we have worked on evaluating IoT products in multiple sectors to identify design and process issues including formal testing to T200 and UL2900.

We will share the best practices for the following:

  1. Design considerations
  2. Setting up a governance function
  3. How to operate a Secure Development Lifecycle (SDLC)
  4. Operational Considerations
  5. Testing and Verification

Other topics of discussion include:

  1. Latest developments in the global market for security and privacy requirements
  2. Strategy considerations

This session will be provided as a workshop to help SME’s hopefully address their security and privacy issues. Please bring your questions and concerns.

As mentioned, I am providing the presentation, the IoT attack surface poster and worksheet for the presentation. I am also hoping to provide the video of the session available at a later date as well.

Note: I will be posting the worksheet a bit later but wanted to share the presentation and poster right away.

Please reach out for any clarifications or questions you may have and most of all be safe everyone!

IoT Threat Poster

IoT Ottawa – Blueprint for IoT Security

 

The last few months have been hectic as many of the standards groups are pushing to get security and privacy aspects of IoT under control. As we get ready to whine down the year lets look at where we are:

a. ISO/IEC 27030 IoT Security and Privacy – This standard has now moved to Committee Draft (CD) and as the editor I am really proud of my editing team and global experts to get us her rather quickly. I believe this international standard will set the bar for IoT products globally and is highly anticipated by many groups and organizations globally.

b. ISO/IEC 27042 IoT Basline – This standard is currently a New Work Item Proposal (NWIP) and will be going to voting in the next few months. This is the result of a Adhoc Group that studied this and determined that we need a baseline for vendors who are entering the IoT product field. The goal is that this would be just a starting point and not the finish line for securing the product and organization but would provide regulators the guidance they need for products.

c. IoT Platform is group that has developed as result of work completed by the Internet Society in Canada. As a result of this work, a platform of regulators has formed and continues to expand how to ensure that IoT products are secure both now and in the future. As a result of this many nations will be making formal announcements to aspects that products should have. In Canada this has posted by Office of Consumer Affairs (OCA) and details are located here. I believe that this is good starting point but an hope that vendors will realized these aspects alone do not make a secure product that only happens when security and privacy become an embedded part of the organization and is driven into the development processes. I also hope that our regulators hold vendors to a higher sense of responsibility for security and products going forward.

d. CSA T200 has been released as an Express Standard and over the next 24 months we hope to develop the final version that will be used as the baseline for products and organizations in Canada and the US for meeting or exceeding regulatory requirements for IoT products. In the future we are looking for the implementation of a cyber label on products for security. More to come on this in the future.

e. IEC 30149 IoT Trustworthiness is still very much a work in progress as many experts are still trying to determine what consitutes trust. While one faction believes it is result of SDLC, I am very much of the opinion that this is not the case but view of the organization that includes the development processes. The approach must be based on an approach such as ISO 42010 that will allow any organization to determine the specific attributes to trust for their company and products being developed.

Here is the content for the IoT Checklist:

1. Ask how the device is collecting, using, and sharing your data

  • Is the device collecting my data? How is the device collecting my data?
  • Is the device using my data? How is the device using my data?
  • Is the device sharing my data? How is the device sharing my data?
  • With whom is the device sharing my data?
  • Is the device collecting data I do not want shared, such as my location?
  • Is there an option for me to opt out of the device collecting, sharing or using my data?
  • Will I be able to opt out of additional or future features that collect data, without opting out of security updates?

2. Ask about the device’s lifecycle, if it can function offline, and if there is product support available

  • How long can I expect the device to work?
  • How long are security patches and upgrades expected to be available for this product?
  • What kind of support is available should I experience problems with the device or suspect the device has been compromised?
  • Will the device work without an Internet connection? Can I use the product if the Internet is down? What features work offline?
  • Will the device work if the manufacturer ceases to exist?

3. Ask if the device you are buying is from a reputable manufacturer

  • Does the company have a good track record when it comes to protecting its customers’ privacy and security?
  • Check for media coverage online about whether or not this company has experienced a security breach in the past. If so, what was the impact on its consumers? What measures did the company take to prevent future security breaches?
  • Are there independent user reviews of the product I can consult?

For more tips on how to approach a business or manufacturer about your privacy and security concerns, check out this tip sheet.

Lots of progress this past year and lots more to come. I do see a shift that regulators globally are moving towards requirements for IoT companies. I hope it is a wake up call for vendors that due to the lack of security controls and the growing attack surface that IoT vendors will see a day where their products will undergo formal testing and evaluation to enter certain markets globally.

 

Yesterday, we officially launched CSA P125 Technical Committee on  Operational Technology Functional Safety and Security. This group is compromised of experts who represent organizations in multiple sectors and from both Canada and the United States. Our mandate is primary ensure that both international and regional standards of interest are adopted in both countries.

As our standards will be published under Standards Council of Canada (SCC) and American National Standards Institute (ANSI) they will recognized in both of these markets. As we look forward to providing both vendors and organizations options for selecting and implementing standards and certification options that will reflect a commitment to secure products and solutions by these vendors.

As the co-Chair to this group, I am very fortunate to be in such great company and expertise. As the editor of T200, I am humbled by the expertise we will have available to make our standard reflective of industry needs and requirements. I am looking forward to building relationships with the new members in the years ahead.

As with all new journeys, this one is even more special due to many of the critical aspects of the technologies we are dealing with. Getting to discuss so many new use cases and sectors it the best part of the job. There are so many cool projects and technologies that the layman just never sees but ensuring that many aspects of society continue to operate normally. This group is going to be there to set the bar for security in OT technology.

//Faud