What is CAN/CSA T200 and Why That Matters
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.
- 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
- 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
- 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
- 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