Cyber Security

**Full Disclosure — I have been working in both software and system development for over 25 years and have been lucky to bring solutions to both enterprise and carrier markets. I am currently the CTO of EdTech company that builds solutions using a secure-by-design approach. My background includes research where I was awarded 5 patent grants for technology in carrier networks. This includes over 20 years of ISO/IEC standards experience as an expert , editor, and HoD for Canada. **

I have been working on this project for more years than I care to remember and want to share my insiders view of this project and some real dangers this standard poses to innocent buyers of the vendors who “claim” conformance to this standard. Given that there is a full project review underway the time is right for making this standard for the masses. This includes helping vendors to find affordable methods for developing and maintaining secure software.

The Bases for this Standard

This project started from the Ph. D of the lead editor. At the time of writing, 2008, the security landscape was very different than it is now and applications meant different things in different sectors of the development and engineering sectors including the technologies used to develop them. With a lead editor that only sees this through the lens of his Ph D and not the industry need, it is very difficult to develop something that is not complex and that can provide a means for any organization to develop secure software. If you know ISO rules, you will quickly realize that this clashes completely with ISO rules for consensus based approach.

BTW, the editor has a great “intro” course he will provide any willing participant who wants to spend 3 hours of their life and 400 Powerpoint slides to educate you to the base concepts of this standard. I am not kidding you when I say many ISO delegates need to drink during these sessions. Keep in mind, this slide deck is 400 slides with lots of detail. You need to understand these concepts to implement this standard. Which gives you a little sense to level of complexity and serious skills need to do this work.

The Standard

As this project was focused on securing web applications and that was the premise of the Ph. D these concepts got embedded into the standard.

I will not breakdown each part of standard in detail but only provide that there is Overview and Concepts and many supporting documents. In total there are 8 parts which will set you back about 1200 Euros ($1750 CDN) to buy the entire collection. It details a framework for securing applications however development details are not provided. This part is 80 pages which gives you a sense to the level of complexity. Several parts are just XML so don’t purchase those unless you really need them. If you have bought those in error, I apologize for this. Basically, the following are some key aspects that are not considered.

ISO/IEC 27034 is not intended to be used for the following:
– Development standard for software applications
– Application project management standard or similar
– A Software Development Lifecycle (SDLC) standard

ISO/IEC 27034 does not provide any guidance on the following:
– Guidelines for technologies such as cloud, AI, physical, or network security
– Controls for measurement (metrics) nor considerations
– Secure coding strategies for any programming language
– Mandatory requirements in any form

I highlight these due to fact that industry has adopted this series was explicitly for the reasons above. This includes that many multi-national corporations hold “certifications” for it! Did I mention that there are no requirements in this standard as it is a framework only. It is anyone’s guess what they are claiming or what specific requirements they actually meet. SAP provides lots of documentation on their implementation of their SDLC using this standard. However, with no requirements and the fact that it does not cover an SDLC makes one a little puzzled to what exactly are they claiming to do. If someone can figure this out please share, I would love to know.

The base concept of an Application Security Control (ASC) is defined as a control to mitigate the risk. This can in essence be anything the only requirement is the format. The vendor unilaterally gets to decide this control including how it is measured. For example, they can create a ASC that states that failed logins are allowed with no further action or mitigation. This is a valid ASC and the buyer would be tasked with understanding what this means for a risk scenario.

The author will tell you that these are driven by the buyer but how many companies buying software will write these for the software they purchase when they don’t even know the technology or have the necessary capabilities of cyber for software development? Again, as stated above the vendor generates these with no requirements or minimums.

Other concepts build on how you then take these and put them into a governance model however this does not currently align to ISO/IEC 27002 which has defined requirements for software development. The editor will argue it does even as Part one is over 12 years old and 27002 was just published last year.

The Challenge and Risks

As you can tell this blog is born out of frustration with this project and how we have created a model of security by obscurity. A standard that pertains to do one thing but does not really move the needle on developing secure code or software. With the need to show that you’re secure, ISO has become a go to for organizations who want to demonstrate a gold standard and this is where the risk of exposure exists.

For any company that is looking to use a vendor that makes these claims you need to do your homework and determine what have they really implemented and does it align to other standards such as ISO/IEC/IEEE 12207:2017 Systems and software engineering Software life cycle processes for secure software development. You may also want to reference and research the following standards:

Governments movement to Secure-by-Design
European Union Cyber Resilience Act (CRA)
NIST Secure Software Development Framework

This is but a small sample to provide detailed guidance on creating secure software driven by industry and regulators. Software can be secure but it takes structure and due diligence on the part of the vendor. This needs a governance infrastructure which requires process, procedure, and a risk management framework. It is not a “one and done” but embedded and part of a companies culture.

Implementation will be very sector specific as many sectors might have a regulatory requirements they must meet. If you are unaware of market requirements get to know them fast, and as always in the software world it is a case of buyer beware. Standards such as ISO 27001 and NIST Cyber Framework provide lots of details on how to implement such a framework.

If you are looking to buy software from a vendor who claims implementation or a certification to ISO 27034, you must require the full disclosure of the ASCs including the testing results. If they claim this is not an easy task or if they don’t provide them you would have grounds to question what they are really doing and do they really have secure software.

Based on the current state of cyber insecurity, we know that current vulnerabilities and compromises can be fully traced back to the approaches used and considered at development time. There are ways to secure software but many organizations are just not equipped to implement them from either a governance or skill set perspective. For example, ISO 27002 has a requirement for ensuring staff skills but this concept does not exist in 27034 nor is any guidance for implementing a ASC for this control provided. We also know based on the quickly changing landscape for technology this is a moving target so keeping your developers and engineers current to cyber risks is critical. And no, using a cloud provider is not going to fix this as they are dealing with these same issues of resources and talent. You cannot transfer risk, you must be willing to accept it or mitigate it.

The most risk here is this model is being proposed for other projects in both the ISO/IEC. The problem is that the approach has not changed only the names to append new concepts such as “IoT”, “Cloud”, and “AI”. It does not consider any specifics of these technologies the editor again insists these concepts apply to anything and everything. Which if your engineer you would probably disagree with. The potential exposure is increased significantly when not considering the development and implementation risks for any of these new technologies.

The Future

This project is currently under review and is the perfect opportunity for you to be heard on this topic. If you have an opinion on this standard please reach out to me. Does it work, does it not work. Especially, if you have worked in software development in startup or similar. Would like to understand your approach to development and what you consider the options for securing your products.

Today many new and great ideas come from problems and siting around with friends, colleagues, or just shampooing your hair one day when it hits you! Bang, society needs this app or widget now, how do we make this? Typically, it will start with some early stage designs, components, and platform for hosting. This will quickly result in a UI design and possibly early web interface to get a feel of this concept. Your idea will be shared with friends, family, and other colleagues and your first users will be registered before you known it. However, did you stop to think about how secure it might be?

When these ideas are born, which is really exciting and overwhelming time in some cases, the time to stop and think about security and privacy is not the go to. It never has, nor do I believe we will change this any time soon from a mindset for developers. However, we much accept then it will have dramatic impacts to security and privacy aspects of the data being collected, processed, and stored for this application. From an engineering perspective, we know that bolting on features will have a negative impact to our application wither those are usability or security features.

Basically, we have gotten into this situation where the rush to market, appeasing investors, or getting customers means we do not think about the future for growth or operating as a business. The goal of the MVP is to get clients on the platform and generate the mighty MRR (Monthly Recurring Revenue). This MVP is good for this purpose but had many limitations that are not discussed and the down stream implications are dramatic for these apps which are now companies and have larger clients asking about the security posture of their app and company. The company at this point hits the proverbial “cyber wall” and scrambles to scale it fast.

The Cyber Wall, is being experienced by more and more companies as the race to market drives all activities but typically security and privacy are not invited to this dance. Unfortunately, many companies have being made to believe that SSO and SSL are security. Security (while not exciting) needs to be risked based not just a follow the crowd approach that works with many investment firms and end users. The mindset has become one of “once we sell this” it will be someone else’s problem and that is usually the end users data being exploited. I have seen this more times that I care or that we need to experience.

How do we turn the corner on this and get started right on the right path? Here are some of the aspects that need to considered or the questions you need to ask your self or your team at the early stages of development. This is based on the countless companies we have had the fortune to work with and help over the years. It represents the basic pattern of thinking and approaches used by many early stage companies.

1. What data will be collected, processed, and stored?
2. What regulatory requirements are required for this sector for the application and for the data we identified as being collected?
3. Will you be using 3rd party software components? If so, where do they come from and how can we validate they have not been tampered or modified?
4. How do we ensure our code base is tampered with?
5. How will we threat model our solution? And validate our assumptions?
6. How can we test our solution to ensure our threat model was validated by unit testing or other test approaches?
7. What base policies do we need to ensure that all the above have been addressed?

Yeah, that is lots but I want to discuss these in a series over the next few months. If you are not aware many governments globally are moving to a system of secure-by-design approach and this will have an impacts to all industry sectors creating software in some form. As usual, I will be using known standards that will help you in all of these. You do not have reinvent the wheel the know how is there you just need to learn how to leverage it.

If your not thinking secure-by-design start doing that today. I hope that this series will be a helpful start for think in this way and also for planning your new cool app and company before it launches.

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

As a security consultancy firm, our job is to provide guidance on security best practices to facilitate the protection of privacy and data for all the clients we serve. We believe strong encryption should be a global effort for national security, personal security and privacy, and free expression. In particular, the use of end-to-end encryption is currently what keeps our information assets secure across the web. For those who are not familiar with end-to-end encryption and why it is important in all aspects of security, here’s a great video resource https://www.youtube.com/watch?v=ADg7x2Buw0s

To extend our effort in advocating strong encryption adoption, we would like to vocalize our membership in the Global Encryption Coalition community. As stated by Global Encryption Coalition, “several governments and law enforcement agencies are trying to ban or weaken encryption for everyone”. The premise is that “They (the governments) want to require companies using encryption to create backdoors to catch criminals or wrongdoers”. We believe in a global movement to strengthen and preserve the use of strong encryption. As part of a global coalition, the movement calls on governments and the private sector to reject efforts to undermine encryption and to pursue policies with the adoption of strong encryption.

While members of the Global Encryption Coalition recognize crime prevention as a universal priority, undermining encryption efforts would also mean greater threats in the global economy and at the expense of users’ security privacy.

As Edward Snowden once said, “If you weaken encryption, people will die. This year alone, after the fall of the government of Afghanistan, we saw how crucial encryption is in keeping ordinary people safe. … Encryption makes us all safer. From families protecting photographs of their kids, to personal healthcare information, encryption keeps our private information private”.

The current trend of technical measures proposed to “break” end-to-end encryption all have one thing in common: each of them involves creating a form of “backdoor access” to “moderate” the data sent. The opportunities for misuse of such “backdoors” can be disastrous.

What this means for Canadians

The ruling by the Supreme Court of Canada stated that speech, including controversial or repugnant speech, has social value and should be protected from unjustified state monitoring. We did see attempts, despite criticism, from the government to enact “online harm laws” to restrict yet-to-be-defined “hurtful” online content, with the targeted categories in terrorist content, content that incites violence, hate speech, intimate images shared non-consensually, and child sexual exploitation content. What Canadians need to know is that such law will require internet giants and platforms utilizing end-to-end encryption to inspect all online content traversing. This also means communication between anyone, including privileged communications between physicians and their clients, will need to be examined by “breaking” encryption and thus undermining personal security and privacy. Canadians and businesses need to be aware of how ongoing privacy and security laws relate to the security of their personal data and any client data housed.

While cyber security is a broad discipline and requires collaboration between all stakeholders, we would like to highlight the importance of strong encryption usage in all sectors of business and the user data housed. We recommend reading this article published by the Global Encryption Coalition, where it highlights the security impact of “breaking” end-to-end encryption. You can find the article at this link – https://www.globalencryption.org/2020/11/breaking-encryption-myths/

It was a great privilege to part of this group and lead the discussion. While our discussion was only the beginning, organizations have to wake up to the fact that they are under attack for IP they have or have access to. While they might not be able to see this impact everyday it does exist and the attack surface can be devices or relationship based. As a business executive, educate yourself on how your organization might be targeted and what mitigations you can put in place to minimize the attack surface. Training and awareness for your staff, will be at the core of any program you develop. If you were unable to make the recent Internet Society – Canada Chapter Webinar here are some further details that might be of interest.

Here is the list  our distinguished panelist:

Gentry Lane – CEO and Founder, ANOVA Intelligence
Tyson Macaulay – Chief Security Officer and VP of Field Engineering @ Rockport Networks
Jeremy Depow – Director, Policy and Stakeholder Relations CyberNB
Mary Anne – Intelligence Officer, Canadian Security Intelligence Agency (CSIS)

Here is the link the video:

Protecting Innovative Canadian Sectors from Foreign Threats

I have also included links to resources provided by Gentry Lane, CEO & Founder, Anova Intelligence.

https://admin.govexec.com/media/diux_chinatechnologytransferstudy_jan_2018_(1).pdf

https://www.hsdl.org/?view&did=812268

China’s National Cybersecurity Center

For anyone who is part of a startup or even considering one, this book is a must read:

https://startupsecure.io/

Continuing on from our observations from Day 1, we noted several key points at the ETSI annual conference relating to cybersecurity policies.

Some future plans for standards and certifications under CSA include future candidate schemes in areas of IoT and IACS (industrial automation control system). As ENISA develops a candidate scheme for 5G network, several items need to be considered. One is the 5G context. This concerns what subset of 5G architecture, for the certification to be applied. Another is identifying scheme elements that support 5G evaluation and certification. Currently, we can expect a draft version of the NIS Directive v2 soon. Interestingly, the new directive introduces responsibilities for ENISA to be more involved in standardization. In response, ENISA developed its strategic objectives to maintain an inventory of standardization organizations and their activities and products. The goal is to then act as a cybersecurity reference point for the EU and participate in relevant standardization actives.

In the context of EU5G, the Network Equipment Security Assurance Scheme was submitted to ENISA for EU adoption. NESAS seeks to provide a security baseline for network equipment in the scope of mobile infrastructure. In particular, NESAS looks at if the equipment is developed to meet secure by design guidelines and does satisfy defined security requirements. Although NESAS is not a certification scheme, GSMA is currently looking at how certification components can be added.

We are also seeing some trends of transitioning from current schemes to CSA schemes. ANSSI is looking to provide EU-wide recognition for certified products and services. One example is ANSSI seeking to provide equivalent services of EUCS to the market. This may be achieved by leveraging consistency such as CSA levels, resistance tests, and applicable EU legislation.

A framework for European cybersecurity assessment (conformity) was proposed. The goal is to increase involvement and transparency to every member state, even those not offering certification or heavily involved in conformity assessment. The agreed new approach would then push for a horizontal regulation on cybersecurity (i.e. – it will capture all cybersecurity needs during vertical regulations to avoid fragmented conformant assessment across industries.

For SMEs, the SBS SME Compatibility Test for Standards was piloted. It provides an overall perception of SME compatibility of a given standard. As SMEs are essential parts of the supply chain, this may be a necessary starting point for improving standards.

Some updates on RED (Radio Equipment Directive) are the proposed applicable requirements. One interesting update is the essential requirements in article 3(3). Currently, Q3 2021 is the expected Commission adoption of a delegated act under Article 3(3)(d/e/f) of RED. This came from the Commission’s consideration of mandatory requirements to be proposed for market access of certain wireless products. For manufactures, this means they will need to demonstrate features to ensure protection of networks, privacy and data protection, and/or protection from frauds as conditions for market access.

The RED Article 3(3)(i) is the proposed next step after RED 3(3)(d/e/f). It concerns the software for the radio equipment. Currently, ETSI had developed a solution proposal on how to test for the new requirements and communicated it to the Commission.

The topic of cybersecurity policy presented challenges in standardizations. In which, we’d like to highlight that all schemes and legislation must provide some improvements to baseline security. Parallel schemes do not necessarily de-value, rather it is important that any parallel schemes will then allow manufactures to submit evidence transferred from 1 of the overlapping schemes to prove compliance.

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.

The encryption debate is in full swing as we once again face the real challenge that governments need access to all of our data, on all devices in real-time including the ability to monitor all communications for signs of a threat to citizens and the nation.

From a policy perspective, we as consumers and citizens need to better understand the risks and exposures we might face. First of all, we are not talking about lawful access where a warrant is used to monitor the activities of a specific user or target of interest. We are talking about the open blatant use of techniques that will allow for wholesale capture and recording of all of your data transmissions.

Governments are asking that tech companies add a capability that will allow them to gain unfettered access to these servers to capture data at will and share or process this data with unknown sources including not having to provide notification to the end user. Psst some companies have already been doing this for years and just not telling you. This started in the 70s using an obscure ruling as precedent to now have all companies collect data as the “owner” of the data. It is buried in the EULA in pure legal speak that you clicked on to get access to their service.

Think about that for a second, would you like the government to monitor all of your banking transactions? What about the sexting with your spouse or significant other, or your company files stored on personal cloud storage services. Could this be used against you? Could you be charged or arrested? These are the big unknowns of such a broad data collection and history has proven that data collection schemes were used for nefarious reasons when needed by governments of questionable intentions.

We need to ask for openness on the intention of the data capture, who is impacted, what does this mean for service providers, and who it is the data being shared with. A policy framework should require that all proposed encryption schemes being recommended be peer evaluated to ensure that the design does not lead itself to backdoors, data collection, or meta data deciphering.

I would advise all citizens and business owners to learn more about this topic and get engaged in the discussion. These laws will change your life regardless if you realized it or not.

We need to have voice our concern before it is too late, in some jurisdictions it already might be. I also want to lying to stop and agencies to just come open on the topic. Just be truthful to Canadians of the data collection and when and where it is happening so we can make informed decisions to use the technology or not.

Here are some links worth checking out:

  1. Government recommendations for security and privacy – What is government of CA really asking for?
  2. Keys under door mats – What top crypto experts think of the issues at hand and potential risks
  3. “I have nothing to hide” – Good insight to personal privacy in the digital age

Please reach out to your MP or MPP and ask them what their stance is on the topic and what they are prepared to do to protect your privacy.