News

TDi and its ConsoleWorks product, which manages privileged-user access and permissions, participated in the National Cybersecurity Center of Excellence (NCCoE) practice guide. The practice guide is available here along with the project fact sheet here.

The NCCoE, a part of the National Institute of Standards and Technology (NIST), has developed cybersecurity guidance that explores how information exchanges between commercial- and utility-scale distributed energy resources (DERs) and the electric distribution grid can be monitored, trusted, and protected.

“Securing DER  communications and data will be vital to protecting the distribution grid,” NCCoE senior security engineer Jim McCarthy said. “This guide shows how several cybersecurity capabilities can be applied to enhance data integrity, protect distributed end points, and reduce the IIoT attack surface for DERs.”

As a collaborator, TDi worked with NIST’s NCCoE in their Securing Distributed Energy Resources project to develop practical, interoperable cybersecurity approaches that address real-world needs of distributed energy resource environments.

“NCCoE is the tip of the spear for this research. We want to learn from these experts and learn how our technology can be a part of that solution,” CEO of TDi Technologies Bill Johnson said. “Our goal is to support research activities in these industries and create efficiencies, while validating and learning additional challenges that take our product in directions resulting in more value to our customers.”

This practice guide aims to help organizations:

• Remotely monitor and control utility-owned and customer-managed DER assets
• Protect and trust data and communications traffic of grid-edge devices and networks
• Capture an immutable record of control actions across DERs
• Support secure edge-to-cloud data flows, visualization, and continuous intelligence

Challenges for Distributed Energy Resources Infrastructures

Small-scale DERs are growing rapidly and transforming the power grid. The distribution grid is becoming a multisource grid of interconnected devices and systems driven by two-way data communication and power flows.

These data and power flows often rely on IIoT technologies that are connected to wired and wireless networks, given a level of digital intelligence that allows them to be monitored and tracked, and share data on their status and communicate with other devices.

A distribution utility may need to remotely communicate with thousands of DERs—some of which may not even be owned or configured by the utility—to control the operating points and monitor the status of these devices. Many companies are not equipped to provide secure access to DERs and monitor and trust the rapidly growing amount of data coming from them or flowing into them.

Securing DER communications will be critical to maintain the reliability of the distribution grid. Any attack that can deny, disrupt, or tamper with DER communications could prevent a utility from performing necessary control commands and could diminish grid resiliency.

ConsoleWorks’ Continued collaboration with NIST’s NCCoE

This is TDi’s 10th collaboration with the NCCoE, having collaborated with the agency and other vendors frequently in the past to develop practice guides that aim to help organizations understand and tackle cybersecurity challenges with effective solutions.

TDi’s previous participation in September was for the NIST Special Publication 1800-10, Protecting Information and System Integrity in Industrial Control System Environments.

This year has seen the rise of Zero Trust, as calls for its implementation came down even from the White House. In the wake of significant increases in ransomware attacks, and the major shifts to remote work, today we are looking at the stages of the secure remote access maturity model.

Secure remote access (SRA) is a key component in the Zero Trust architecture. It enables you to enforce the least privileged access to your endpoints for a user performing their role. Managing the connections between partners, contractors and employees can be a challenge, but reaching a mature level of privileged access management is critical for the safety of your network.

Do you know where you stand in the secure remote access maturity model and does your current level meet the requirements to enable Zero Trust?

What is a Secure Remote Access Maturity Model

A mature secure remote access implementation would have prevented some of the attacks we’ve seen in the news before they even started. As we’ll review in the secure remote access maturity model below, there are 5 distinct levels.

Each maturity level builds on the last and layers in additional security and least-privileged access of users connecting to your endpoints. Some of these levels also look at the structure of your architecture, helping you to enforce other security standards as well.

Though we are looking at secure remote access, it’s important to remember that a fully mature cybersecurity architecture will go beyond simply enforcing least privileged access and even Zero Trust. Zero Trust should be your goal “foundational” security level. From this foundation, you build more sophisticated and layered defenses on top, taking you beyond Zero Trust and increasing your defense against even the most sophisticated of attacks.

Secure Remote Access Maturity Model Stages

SRA Maturity Level 0
No secure remote access exists. At this level of privileged access management maturity, there is essentially no plan in place to control a users’ access to endpoints. Here a truck is simply rolled to a site and access is granted based on knowledge of the password to the endpoint. Anyone with this password can access the endpoint and no one will know who accessed it when or what they did.

This level has no “roles” to speak of. You are at your most vulnerable to attack here. This is made worse by your lack of insight into how an attack may have occurred or even what happened during it.

SRA Maturity Level 1
Sites are added to a network containing strict firewalls with normal connectivity (SSH, Dial Up). In this level of the privileged access maturity model, many of your vulnerabilities remain from level 0. Access is granted manually by an administrator who decides if certain actors are allowed. However, nothing is done to verify an actor after initial access is granted.

Visibility into identities and the risks associated with access is limited. If another user has the password, then they have the keys into your network without any way for you to know who they are or what they are doing.

SRA Maturity Level 2
A Jump Host is added to the network. User access is tightened and more defined. You start to identify users at this level for access into the network and its endpoints. Certain verifications are added, like checks on the location a user is trying to access the network from and what role that user may have.

SRA Maturity Level 3
At this level in the secure remote access maturity model, you reach a mature realization of firewalls with an added DMZ. Access is further controlled, with durations for access assigned to certain roles. Identities are associated with specific access-level capabilities for these roles as well, further limiting what a user can do or see on the network.

SRA Maturity Level 4
More user authentications are layered in at this level, with things like two-factor authentication/multi-factor authentication. We are approaching a very mature realization of privileged access management. Here we see robust network access control, with combinations of authentication, enforcement of security policies and strong endpoint security.

We are also near the true realization of Zero Trust secure remote access at this level. Trust at this level is highly diminished in the network. Identity access policies now gate access to applications and endpoints within the network and we begin to see analytics implemented to improve situational awareness on the network.

At this level, just knowing a password is no longer the same threat that it was at the lower levels, as other authentications are required, and access given to any user is substantially controlled by permissions.

SRA Maturity Level 5
You have reached the highest level in the secure remote access maturity model. Level 5 is the full realization of Zero Trust secure remote access. User activity is logged, providing critical information on who connected to what, what they did and when. Granular control of user connections inside each security zone also means users are only permitted to see the applications or endpoints necessary for them to perform their role.

Users are monitored in real time and their risk is assessed continuously; they may only be able to perform certain commands. If their behavior is viewed as suspect, their connection is terminated, and the incident escalated. Every action is auditable.

Access is only permitted when it is needed, to whom needs it and only for the duration they need it. For example, if a contractor arrives on a certain day, their access is only granted for the date and time of their arrival, along with their duration needed to perform the work.

A protocol break now stands between the user and the endpoints in the network. With this, they never directly connect to any endpoint within the network, instead ConsoleWorks brokers the connections between user and endpoint, protecting you from viruses, malware or ransomware.

The Path to Achieving SRA Maturity

Many organizations struggle to reach the higher levels of privileged access management maturity. It is imperative that these levels be attained as passwords alone will not protect you from an attack, nor will simply assigning roles to users who access your network.

The best security attained is by permitting least-privileged access, only when it is needed and only for as long as it is needed, while treating every connection as untrusted. This means continual monitoring and auditing of connections on your network to ensure an attack is not taking place and that a bad actor has not gained access.

ConsoleWorks is built with SRA maturity in mind and takes you to level 5 with ease, significantly heightening your security and even taking you beyond the Zero Trust baseline. Talk to us about your secure remote access needs here to achieve the highest maturity level possible today.

Securing critical infrastructure is a key talking point this year. Recently, hackers have become more ambitious with their targets, shutting down crucial pipelines, hospitals and other critical infrastructure across the world.

Because of this, governments are stressing the importance of securing networks and reducing the opportunity that you become a victim of the next attack. President Biden issued an executive order around this issue and even made it a talking point at his summit with Putin.

It’s important for IT/OT to be ready to shield against these ambitious hackers and not be caught by surprise. The International Society of Automation Global Cybersecurity Alliance (ISAGCA) announced the release of its position detailing the cybersecurity public policy views of the organization and its members.

As a member of the ISAGCA, we were happy to see this announcement. With the increased risks of an attack, securing critical infrastructure is of top importance and is what we do for our customers every day.

ISA/IEC 62443 Cybersecurity Standards Position

The position paper encouraged the adoption of the ISA/IEC 62443 cybersecurity standards. These standards were initially introduced in 2002, after ISA’s ANSI-accredited standards department stood up a committee to develop the ISA/IEC 62443 series of standards for automation and control systems.

With over 1,000 experts contributing, their collective expertise developed a series of coherent standards for securing critical infrastructure.

The standards focus on the principle of shared responsibility among stakeholders, from end users, product suppliers, integrators and service suppliers.

The basic architecture revolves around breaking assets into security zones. Each security zone is determined by its security level, which is assessed after performing risk analyses for the associated assets. The zones are then separated from each other by security boundaries. This practice adds a layering or redundancy to the architecture, should one security measure fail.

Securing critical infrastructure is imperative because of the consequences and impacts of a cyberattack. These systems extend past the digital form, making the endangerment of the public or employees a real possibility.

Beyond this, damage to the environment or equipment, in addition to reputation or financial harm are likely outcomes of a successful attack. Because of their key role in the lives of citizens, a breach on an industrial control system can become a threat to national security. Adopting a set of agreed upon, well-informed standards is important for standing up a defense against external threats.

Advocating for the adoption of the ISA/IEC 62443 standards brings a universal definition of security capabilities and provides a shared language among all stakeholders, as well as a common set of requirements for designing and assessing cybersecurity. Importantly, these standards translate across industries.

As we work to secure these ICS environments every day for our customers, we think it is important to also highlight much of what we have been discussing since the increases in these attacks started.

Key Practices for Securing Critical Infrastructure

A key item highlighted in President Biden’s executive order was the need to implement Zero Trust security principals. Our overview of Zero Trust security covered the traits of the architecture, including its defining principle of assuming a breach in your network is inevitable or that it has already occurred.

As remote work has increased – perhaps permanently – in a post-COVID world, combined with intricate supply chains and other change factors, it is necessary for this to be implemented as a baseline for securing critical infrastructure.

We’ve also stressed the importance of moving beyond Zero Trust for securing your critical infrastructure. Zero Trust should be your foundation, which you build the rest of your security on top of.

With the complexity of supply chains and potential for a breach in one part of the chain to cascade into a breach of thousands of other businesses, it’s more important than ever that you are critically evaluating your partners.

It’s why we completed the SOC for Supply Chain evaluation and penetration test our product and our company to ensure we are a responsible partner and secure link in your supply chain.

Beyond giving least privileged access and reinforcing the supply chain, you need to have a protocol break and sophisticated critical configuration monitoring and change controls, alongside the capability for thorough audits and logging in the event a bad actor passes through your other defenses. Now you have created a layered defense and gained an understanding of what is happening. This allows you to see attack patterns from an external threat who has gained access.

ConsoleWorks Secures Critical Infrastructure

ConsoleWorks functions across industries, like oil and gas, water and wastewater, finance, healthcare, manufacturing, energy and more. We enforce the NIST cybersecurity framework requirements and we built ConsoleWorks around the 62443 requirements for operations and maintenance of critical infrastructure.

As the threat of cybersecurity attacks remains high, we know it can be tough to be certain you are securing your critical infrastructure properly against looming attacks. ConsoleWorks is a single cybersecurity operations platform that hardens your environment. Schedule a demo to see how it works or start a conversation with us to make sure you’re secure.

Our Intern Spotlight series highlights the experiences of interns at TDi. If you want to read previous entries in our Intern Spotlight series, you can see our other posts below:

Intern Spotlight with Hector, our UI and UX Intern
Intern Spotlight with Jonathan, our Development Intern
Intern Spotlight with Carter, our DevOps Intern
Intern Spotlight with Julia, our Graphic Design Intern
Intern Spotlight with Franklin, our Product Engineering Intern
Intern Spotlight with Jacob, our Software Engineering Intern

Meet Matthew, our DevOps Software Engineering Intern

Matthew got into computer programming in high school after taking a few classes on the subject. From there, he and his friends got into robotics and even set up his school’s robotics team. He enjoyed being in an environment that allowed him to learn programming, to build things and to enter competitions.

In 10th grade he took an internship documenting patch notes. Here he realized this was an area he liked as a potential career path. Between this experience and taking more programming classes, he made his final decision to switch from a mechanical engineering degree to computer programming in college, where he is starting his senior year. Below we talk to Matthew about his experiences.

What is your focus in college?

In college I went in with the idea of going into mechanical engineering. I eventually changed my mind and went into computer programming. The classes are pretty fun. I’ve taken a course in graphic design and app design, and those are probably some of the most interesting classes I’ve had. They were really fun and I thoroughly enjoyed them. This year I started my internship here too.

What projects have you been working on in the DevOps software engineering internship?

Initially I was working on setting up the checks for baseline processors in ConsoleWorks. I did that for a couple of systems, mostly Windows operation systems. After that, I went into all these security standards. I was working on CIS controls and other standards, so HIPAA, NIST CSF, CMMC, NIST SP 800. I was working on creating spreadsheets for all the controls for those and mapping them to CIS controls to see which ones are related. It was fun trying to figure out Excel and in general speed up the process, making it look nicer and then importing it into the system. That was the second thing that I worked on.

Now I’m working on a log cloud, which takes in log files and shows it in a word cloud. The more occurrences there are for a word in the log, the larger it is and the closer it is to the center. The less occurrences, the farther away it is from the center and the smaller it is. I’ve been working on making it in general look better, trying to get the animations set up, the settings for it set up, and also trying to get it to work with the logs.

Do you think working on these projects has helped solidify that you picked the right major over mechanical engineering?

Yea, for sure. I feel like I’m enjoying programming a lot more than I would have enjoyed mechanical engineering.

How is it working with the team here in your DevOps software engineering internship?

They’re all really nice. Any time I have a question I reach out and they respond back quickly. It’s nice being able to ask questions and work with them on the best approach to take. It’s definitely really beneficial to all the stuff that I’ve been learning.

What has been really challenging for you?

The most challenging thing I’ve had to do so far was integrating the script that I have into ConsoleWorks. Trying to learn how ConsoleWorks does it and integrating what I have into that has been a bit of a challenge. There have been a couple of methods that I haven’t had available to me. It’s been a bit of a challenge to find work arounds, although it’s also been pretty fun to find those workarounds. Integrating that has been a challenge.

You’re going into your senior year, it’s the home stretch for you. Are you wanting to stay in cybersecurity?

I am looking to stay in cybersecurity and stay in programming. In my senior year I’m looking to get a couple of certifications for cybersecurity and get further into it.

What’s your favorite part about the DevOps software engineering internship?

I really like being able to work on the projects. It’s been fun being given work on this task and just going through and trying to finish it and make it look good. I’ve been really liking the problem-solving approach for it all.

What would you tell a student interested in a cybersecurity internship at TDi?

Just have fun and learn while they’re here. I’ve learned quite a bit while I’ve been interning here. It’s definitely good to take away the experience from this and just to have it available. It’s been really fun. The internship has been one of my better job experiences.

Keep Watch for More Internship Spotlights

Our Intern Spotlight is a series of posts throughout the summer highlighting the experiences of TDi’s cybersecurity interns as they develop their skills to be the next defenders of IT and OT operations. To learn more about TDi’s internship program, you can read our cybersecurity internship overview here.

Stay tuned to our updates page for the latest IT/OT cybersecurity posts and more Intern Spotlights.

Our Intern Spotlight series highlights the experiences of interns at TDi. If you want to read previous entries in our Intern Spotlight series, you can see our other posts below:

Intern Spotlight with Hector, our UI and UX Intern
Intern Spotlight with Jonathan, our Development Intern
Intern Spotlight with Carter, our DevOps Intern
Intern Spotlight with Julia, our Graphic Design Intern
Intern Spotlight with Franklin, our Product Engineering Intern

Meet Jacob, our Software Engineering Intern

Jacob is a sophomore Computer Science major. Growing up, he was involved in Boy Scouts. In high school he got involved in coding and doing cybersecurity competitions in the Cyber Patriot program. It was here that he first learned about TDi, as Jacob’s team was sponsored by the company.

Once he entered college, he was ready to start getting more experience and entered his internship in May 2020. Below we talk about his experiences in cybersecurity and at TDi.

What led you to concentrate on your field of study?

In middle school I learned some HTML coding and JavaScript and made a few websites. I thought it was really cool to go from the lines of code to a fully visual thing. There’s just so much that you can do with that. That’s what first got me into computer science.

What got me into cybersecurity specifically, is I started participating in the Cyber Patriot competition in Freshmen year of high school. That competition was really interesting to me because it’s different every time and you’re finding different vulnerabilities in the operating systems. You only have a specific amount of time and you get instant feedback. I really enjoyed that.

Did anything surprise you once you started doing your software engineering internship? Was it different from what you thought it would be?

The biggest difference is that in a lot of the Cyber Patriots stuff, you would write scripts to help automate things, but a lot of that on the Windows end was very visual. ConsoleWorks has a lot of visual elements, but most of what I end up doing is not. So, it’s not that I wasn’t expecting that, but it’s just a little different.

What I think is really cool, is my first thing with the CIS benchmarks. I wrote the benchmarks, got those so they would run. The next thing was getting it to upload, getting that working. My most recent project was developing reports for those baselines that I helped write. It’s fun to build on it.

Has anything you’ve done in college helped with the internship or do you think the internship will help you this year in college?

I think the biggest experience from the internship is finding the right way to think about things. I think the application of coding is so much more useful, at least to me, than a lot of the more theoretical stuff that I’ve heard in some of my classes.

I think using it and writing code and figuring out the process of debugging and finding fixes for weird errors and things you’re not able to do – I think that’s useful for me to help develop more skills. I think that will help me in future classes at school.

In school the biggest thing they emphasize is the mindset and way to think about the problems and I think that has helped, but I think the actual experience is more important.

What’s the most challenging part of your software engineering internship?

I think the biggest thing for me was just getting used to figuring things out and getting used to doing it. Solving the problems, making up for any knowledge I didn’t have already.

Did the team help you fill in those gaps?

Yea – when I started, I mostly worked with Carter, because he had already written a few of the baselines. He talked me through how to do that and I was able to use them as examples. Recently other team members have been incredibly helpful when I run into walls because there’s other stuff I’m doing now that’s completely unrelated to previous stuff. It’s helpful when I can’t make headway and need to take a step back and figure out what an issue might be.

Has your software engineering internship experience helped you achieve your career goals?

It’s definitely helping me to get important experience and it helps keep me remembering why I enjoy computer science. The classes can be really hard and a lot of work. Every once and a while the work kind of outweighs it, like “is this something I want to do?”

So the internship helps to keep me remembering why I enjoy it and why I started doing computer science in the first place.

Do you think you’ll go into cybersecurity?

Yea I would like to go into cybersecurity. Probably on the software development side. It’s more important now than ever. It will only grow in importance as people find newer and newer ways to break systems. It’s a field that allows for continual learning. You can’t stop. It’s important for people, but it’s also important for things as big as countries.

The only other thing I’ve done that’s completely unrelated is I wrote a book that was published last April. It’s about how certain musicians can really change music because they disregard what audiences think and try completely new things. That was a really fun thing for me – completely different than what I normally do with work and school.

It seems like you’ve got that analytical perspective and you carried it over into your writing too.

I’ve always really liked music. One of the things I like about music is the lyricism and what it means, what the artist is trying to say. I think that attention to detail carries into coding. And that type of analyses also carries back, looking at things line by line.

What’s your favorite part about the software engineering internship?

It goes back to how I like that I’ve been doing stuff that builds on each other and is going to be used. I like that the stuff I’m doing is important and will be used by people. I also have liked the people I’ve worked with. That’s been really nice. Everyone is so supportive here.

Thinking about how to solve very specific problems – an example is one of the things I had to write – we needed two values to be put into this thing that ran. There was no way to really pass the values directly, so I had to start using custom files. One would write to it, and one would pull from it. So it’s getting the values, but not really in a linear way.

Now we figured out how to directly pass through it, but I thought things like that, figuring out how to make things work, was really cool.

What would you tell a student interested in a cybersecurity internship at TDi?

I’d tell them it’s important to be curious and keep learning about computer science and cybersecurity. Not even just that, but just anything really. As we talked about earlier, things kind of loop back in. Make sure you’re taking classes that are beneficial and that you’re getting the knowledge you need to participate in cybersecurity.

Keep Watch for More Internship Spotlights

Our Intern Spotlight is a series of posts throughout the summer highlighting the experiences of TDi’s cybersecurity interns as they develop their skills to be the next defenders of IT and OT operations. To learn more about TDi’s internship program, you can read our cybersecurity internship overview here.

Stay tuned to our updates page for the latest IT/OT cybersecurity posts and more Intern Spotlights.

Our Intern Spotlight series highlights the experiences of interns at TDi. If you want to read previous entries in our Intern Spotlight series, you can see our other posts below:

Intern Spotlight with Hector, our UI and UX Intern
Intern Spotlight with Jonathan, our Development Intern
Intern Spotlight with Carter, our DevOps Intern
Intern Spotlight with Julia, our Graphic Design Intern

Meet Franklin, our Product Engineering Intern

Franklin just graduated from college, where he studied applied computer science and concentrated on front-end web development. Prior to college, he was already coding and doing animation, but it wasn’t until college that he saw how coding could be applied and how software was everywhere in his life.

Below is our conversation with Franklin about his internship and building his professional experience.

Leading into college you were already coding?  

I had coded a little bit – basic animation, HTML, JavaScript, CSS. It was in college where I really saw how coding could be used. Everything is software. I think that’s just so cool. I get to work on something that has an outreach.

People don’t really understand software, but it’s everywhere.  You’re going to see it every hour of every day. It has such potential to benefit everyone. I think how the modern world works, it runs on software. It’s my way to contribute to society.

What led to you concentrate on front-end web development?

I noticed that the products that stood out to me looked really good. A product can work really well, but people’s first impressions will be of the front end. How the UI or the UX works for a person. I’m a very visual coder. You don’t really think about it, but the front end is art to me.

There are a lot of good coders in every department – data science, back end, but with front end, you need to have a bit of an artistic perception. I’ve always been interested in art and music my entire life. This is where it kind of unites.

In your product engineering internship you get to apply the things you’ve been learning – is it what you though it would be?

I think the big thing is that software engineering isn’t 24/7 coding. A lot of what my internship does is being in staff meetings and seeing how they work together and from then on seeing how I fit into that. They have treated me really well. It’s really cool to see how it works. It feels sort of like a homework assignment, because it’s structured that way, but the code that I do actually outputs to a real product that people in the industry can see.

Did anything surprise you once you started doing your internship?

I’ve worked on team projects before and everyone here is so nice. You can tell everyone is passionate about coding. They’re so nice to me about it. The overall positivity – you know in school, students get assignments and they’ll get it done because there’s a deadline and you have to do it, it’s part of being a student – but here, you can tell people really do care about the company.

It’s nice to have such a positive work environment. That’s something that I was not taught. You can’t really be taught about a work environment, how those atmospheres operate.

My school is very cooperative, I can reach out to any of my peers or teachers to ask for help. At the beginning of college, it was kind of daunting, you have to put yourself in that vulnerable position to ask for help. But then I was met with all this positivity, no questions asked, they helped me, and I didn’t feel like I overextended myself. And it’s like that here too. I don’t feel like I’m imposing. Everyone makes me feel like I’m worth the time.

It’s pretty flexible too. They’ll give me an assignment and I can work on it. I don’t feel like there’s too much pressure. I just don’t want to disappoint them because they’re so nice. I don’t feel really pressed for a deadline because I have to, but because I want to.

What projects have you been working on?

I’ve been working on ConsoleWorks scripts for different report types. It feels like one of my coding challenges. Each report has its own scripts and then you have to do certain things with them. I was just assigned to another one.

What’s the most challenging part of your product engineering internship?

I think onboarding and just figuring out ConsoleWorks. It’s a big program. Once I understood what the software did, then I could understand my part and what my code would do. Like all the tunnels, twists and turns in the software.

Has your internship experience helped you achieve your career goals?

An internship with a company like this would look good on a resume. As I do more, I can have specific things that would look good to recruiters and different companies.

I feel like whatever I do after this in tech, I’ll be able to compare those meetings and team dynamics to what I’ve done here in my internship. It won’t be unfamiliar anymore. It’s the big takeaway from the internship – real industry experience.

What’s your favorite part about the product engineering internship?

The guys at the meetings are kind of funny sometimes. They’ll do little jokes and those gems make you smile. There’s humanity in it. It’s very light. They have a lot to do each sprint and you can tell that there’s pressing deadlines, but they’re light, they keep it chill.

What would you tell a student interested in a cybersecurity internship at TDi?

I would say connect with your team. They don’t hold seniority in your face. You can ask for help or advice and they’ll give it to you.

Internships are supposed to be a taste of a full-time job and having one remote is probably like the most authentic taste you can get now. When I’m coding, I don’t think there’s much difference from what I’m doing to a normal full-time engineering job. It’s a really good comparison and you’re getting industry experience in the comfort of your own home.

I think that’s what a lot of tech jobs, if they haven’t moved already, will move to remote work. This internship, just being on teams and having this whole online atmosphere, is pretty cool.

Keep Watch for More Internship Spotlights

Our Intern Spotlight is a series of posts throughout the summer highlighting the experiences of TDi’s cybersecurity interns as they develop their skills to be the next defenders of IT and OT operations. To learn more about TDi’s internship program, you can read our cybersecurity internship overview here. Stay tuned to our updates page for the latest IT/OT cybersecurity posts and more Intern Spotlights.