Secure By Design

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

 

 

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!

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.

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.

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

 

It is hard to believe that we are days away from the 10 year anniversary of our humble beginnings. We have come so far from the company that I started in my basement. Back then it was just a dream of starting something small as an independent consultant but wanting to share my expertise in cyber to help clients. Now we have grown to a team of 7 and have offices in a great part of town in Ottawa, Canada and global clients. We are bursting at the seams and have already expanded our office footprint. With next year poised for more growth we will be expanding again and adding more R&D capacity in the process.

I have learned lots during my tenure as both a business owner and executive, and have made some good and bad decisions along the way. I never shy away from admitting my mistakes especially some questionable partners and sub-contractors – but life and business are about learning and I am grateful for the lessons.  I am humbled and blessed by our staff, clients, and partners we currently have as without you none of this would exist.

We will be refining our services as we shift the company from consulting to formal testing and evaluation and secure product development.Our capabilities will be expanding in the next year including our Hut6 platform to offer more services. With our growth in education, healthcare, and industrial our next 10 years looks very promising and with our current team in place we are definitely going to make this happen.

For all of you who believed in me and my dream thank-you! Lets make the next 10 years better than the first as we enter the teenager years of the company.

//Faud

At the recent IEC SC 41 Working Group and Plenary Meetings in Chongquin, CN. Our CEO and Convenor of AG 15 and AG 22 within SC41 presented at the Industry Workshop. It was well attended by government dignitaries, industry, local media and students.

Our presentation was focused on the testing and evaluation considerations for IoT products/solutions. This is based on the work we are doing with companies such as CSA Group for formal testing and evaluation and the development of a bi-national standard, T200, that reflects this need for product companies to have both a secure organization and products.

The goal is to have a cyber label on products for organizations who can demonstrate a security maturity. More details are contained in the presentation SC41 – TwelveDot_v1.

 

Today our CEO presented at IoT613 an Ottawa based conference focused on all things IoT. There was also a developer day before the conference as well. The conference had really good attendance including several vendors or other organizations working in this area. If you are interested in this topic plan to attend the conference next year, speakers provide a range of views and experiences.

Our presentation focused on how to evaluate IoT products and solutions for both security and privacy. The lack of education in this area is of concern as many product companies are amping up their marketing to “assure” of product safety but yet many products have never undergone formal testing and certification nor do many even have secure by design or privacy by design approaches. Security for most IoT vendors is an after thought. When purchasing one of these products assume that security and privacy testing has not been conducted.

If you did not make it out to the presentation please find it attached, we hope that it helps to be better understand the issues.

IoT613 – TwelveDot – May 9 2019