mobile-logo
 

Pen Testing

Apr
12
2023
Audit and Assessment Cyber Security Governance Industrial Control IoT Pen Testing Secure By Design T200

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

 

 

0
Sep
01
2021
Education IoT Pen Testing Secure By Design

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!

0