Security-must-enable-people-Code42-Blog

Security Must Enable People, Not Restrain Them

Do you ever think about why we secure things? Sure, we secure our software and data so that attackers can’t steal what’s valuable to us — but we also secure our environments so that we have the safety to do what we need to do in our lives without interference. For example, law enforcement tries to keep the streets safe so that civilians are free to travel and conduct their daily business relatively free of worry.

Now consider how everyday police work keeps streets safe. It starts with the assumption that most drivers aren’t criminals. Officers don’t stop and interrogate every pedestrian or driver about why they are out in public. That type of policing — with so much effort spent questioning law-abiding citizens — would not only miss spotting a lot of actual criminal behavior, it would certainly damage the culture of such a society.

There’s a lot we can learn about how to approach data security from that analogy. Much of cybersecurity today focuses on trying to control the end user in the name of protecting the end user. There are painful restrictions placed on how employees can use technology, what files they are able to access and how they can access them. Fundamentally, we’ve built environments that are very restrictive for staff and other users, and sometimes outright stifling to their work and creativity.

This is why we need to think about security in terms of enablement, and not just restraint.

“ Security should be about enabling people to get their work done with a reasonable amount of protection — not forcing them to act in ways preordained by security technologies. ”

Prevention by itself doesn’t work

What does that mean in practicality? Consider legacy data loss prevention (DLP) software as an example. With traditional DLP, organizations are forced to create policies to restrict how their staff and other users can use available technology and how they can share information and collaborate. When users step slightly “out of line,” they are interrogated or blocked. This happens often and is mostly unnecessary.

This prevention bias is, unfortunately, a situation largely created by the nature of traditional DLP products. These tools ship with little more than a scripting language for administrators to craft policies — lots and lots of policies, related to data access and how data is permitted to flow through the environment. And if organizations don’t have a crystal-clear understanding of how everyone in the organization uses applications and data (which they very rarely do), big problems arise. People are prevented from doing what they need to do to succeed at their jobs. Security should be about enabling people to get their work done with a reasonable amount of protection — not forcing them to act in ways preordained by security technologies.

This is especially not acceptable today, with so much data being stored, accessed and shared in cloud environments. Cloud services pose serious challenges for traditional DLP solutions because of their focus on prevention. Since so many legacy DLP products are not cloud native, they lose visibility into what is happening on cloud systems. Too often, the result is that people are blocked from accessing the cloud services they need. Once again, users are treated like potential criminals — and culture and productivity both suffer.

This is also a poor approach to security, in general. As security professionals who have been around a while know, end-user behavior should never be overridden by technology, because users will find ways to work around overbearing policies. It’s just the law of governing dynamics and it will rear its head when the needs of security technologies are placed above the needs of users.

Where’s the value for users?

There is one last area I’d like to go over where traditional DLP falls short when it comes to providing user enablement, and it’s an important one. Traditional DLP doesn’t provide any tangible value back to staff and others when they are working in an environment protected with legacy DLP. All they typically get are warning boxes and delays in getting their work done.

In sum, traditional DLP — and security technology in general — doesn’t just prevent bad things from happening, it also too often prevents users from doing what they need to do. They feel restrained like criminals for simply trying to do their jobs. In actuality, a very small percentage of users will ever turn malicious. So why should we make everyone else feel like they are doing something wrong? We shouldn’t.

Code42 Next-Gen DLP

At Code42 we believe it’s essential to assume the best intentions of staff and other users. That’s why Code42 Next-Gen Data Loss Prevention focuses on identifying malicious activity, rather than assuming malicious intent from everyone. It’s why the product is built cloud-native: organizations aren’t blind when it comes to protecting popular cloud services, and users aren’t blocked from working the way they want to work. It also doesn’t require policies that need to be created and forever managed that pigeonhole users to work certain ways.

Finally, we believe in providing value to the end user. It’s why we provide backup and restore capability in Code42 Next-Gen DLP. This fundamentally gives users the freedom to make mistakes and recover from them, and it gives them the knowledge that that their data is also protected and safe.

Because it doesn’t block or interrogate users every step of the way, we believe Code42 Next-Gen DLP helps users to be more secure and productive, and enhances organization culture. It also provides the security team the opportunity to be an enabler for their end users, not an obstacle.

In this sense, Code42 Next-Gen DLP is a lot like good police work. It gives its users the freedom they need to move about the world without every motion being questioned for potential malicious intent. This is a very powerful shift in the workplace paradigm; users should be empowered to behave and collaborate as they want without fear or worry regarding the security technology in place.

Gene Kim on DevOps, Part 3: DevSecOps and Why It’s More Important Than Ever (Video)

We at Code42 were fortunate to have our good friend Gene Kim, author of The Phoenix Project and the leading expert on DevOps, stop by our office for a conversation about DevOps and its implications for security. One of the best parts of the visit for me was talking with Gene about our DevSecOps experiences here at Code42 and how we have brought security into the DevOps model.

Here at Code42, we are on a mission to secure our customers’ ideas. That’s why our DevOps journey included bringing security into the DevOps model. I’m proud to say that we’ve been profoundly successful bringing those security risk controls into our process and making it part of our engineering process.

Security is often viewed—especially by engineering— as the department of “No.” Yet, in the DevOps model, you’re trying to embody self-service and autonomy, which can be difficult to square with accountability.

As our DevSecOps model has come together, our security team has been taking the time to establish the expectations for the engineering side of the house, and we’ve been able to implement those controls. One of the most gratifying outcomes for me is, instead of an after-the-fact security scan, we’re now proactively dealing with security as we design and build our software.

Now, engineering has the freedom to do what they need to do, because they’re able to talk more openly and collegially with the security team. A lot of the answers that were “No” before, when explained in the right context, become “Yes,” because the security team can enable the engineers to move forward.

During our interview, Gene echoed the advantages of bringing security to the DevOps table. “It’s been really gratifying to see organizations … call it not DevOps but DevSecOps,” said Gene. “Truly integrating all the information security objectives into everyone’s daily work.”

Hear what else Gene had to say about DevOps and its implications for security.

If you haven’t already, be sure to check out the previous two installments in our three-part blog and video series with Gene where he talks about what it takes to become a DevOps organization and the role of culture.

Gene Kim on DevOps, Part 1: How Do You Become a DevOps Organization?

Gene Kim on DevOps, Part 2: The Cultural Impact of becoming a DevOps Org

Gene Kim on DevOps, Part 2: The Cultural Impact of becoming a DevOps Org (Video)

Gene Kim, author of The Phoenix Project and one of the most vocal thought leaders for DevOps, spent a day at Code42 headquarters in Minneapolis. During his visit, Gene talked about the optimal cultural conditions that must be in place for companies that embark on a DevOps journey and the advantages of bringing security to the table. This is the second installment in our three-part blog and video series, capturing our conversations with Gene.

As we’ve embarked on our own DevOps journey at Code42, we’ve experienced firsthand that the transformation must be embraced from a cultural perspective in order to make it happen. The core principals of DevOps require systematic thinking, coming together, gaining feedback and then at the same time, constant experimentation. For DevOps to work, it’s critical to have cultural norms that allow people to provide honest feedback without repercussions.

DevOps is not just for the engineering team. There’s something in DevOps that affects everybody from the systems architects to the operations teams to the very way in which QA is administered. In fact, the focus right now on privacy and security make the cultural perspective of DevOps more important than ever because it brings the security and engineering teams together in a very real way. That’s one of the things we at Code42 really appreciate about DevOps: that the cultural norms start to propagate around the organization, so you find groups collaborating across the company.

During my conversation with Gene, he reinforced the importance of team work. He said “Without a doubt, there has to be a sense of collegiality between information security and the engineering teams — that we are fellow team members working toward a common objective.  It’s so counter-intuitive how much more effective this is than the traditional high-ceremony and adversarial nature between infosec and everyone else!”

Listen to part two of my interview with Gene to hear what else he had to say about cultural norms, the absence of fear and empowering security.

“ Without a doubt, there has to be a sense of collegiality between information security and the engineering teams — that we are fellow team members working toward a common objective. ”

Check out the first part of our blog and video series with Gene for insights on how to become a DevOps org and part three — why DevSecOps is more important than ever.





Gene Kim on DevOps, Part 1: How Do You Become a DevOps Organization? (Video)

Gene Kim, author of The Phoenix Project, stopped by our offices. Gene, who is regarded in the industry as one of —if not the — most vocal enthusiasts of DevOps, is a friend of Code42 and a personal mentor of mine. I was thrilled to sit down and interview him. As a result of our visit, we created a three-part blog and video series, where we explore his views on DevOps — particularly security’s growing role. Our first installment opens with his thoughts on what goes into becoming a DevOps company.

The books Gene has written and his perspective on DevOps have changed the way we at Code42 think about our process. After going through our own DevOps journey, we’ve been optimizing our teams to improve our speed of delivery, ensuring we get our customers the features they need faster.

We are not the only ones to find ourselves on this transformational path. Many of our customers are on DevOps journeys of their own — or thinking about starting one — so we wanted to share our experiences and Gene’s best practices on becoming a DevOps organization.

When I was talking to Gene, I asked him about what it means to be a DevOps company, particularly in this day and age when security is such a top concern for businesses and consumers. We hope this video will help companies understand some of the implications and real advantages of adopting a DevOps model.

“ One of the biggest surprises coming off The Phoenix Project is just to see how much DevOps can dramatically improve the lives of not only developers, but also QA, operations and security. ”

During our conversation, Gene said, One of the biggest surprises coming off The Phoenix Project is just to see how much DevOps can dramatically improve the lives of not only developers, but also QA, operations and security.”

Be sure to check out the next two installments in our three-part blog and video series with Gene, where he talks about the role of culture in becoming a DevOps org and why DevOpsSec is more important than ever.

Gene Kim on DevOps, Part 2: The Cultural Impact of becoming a DevOps Org

Gene Kim on DevOps, Part 3: DevSecOps and Why It’s More Important Than Ever (Video)

Security Panel: Filling Gaps in Your Security Stack (Video)

Keeping up with the constantly evolving cyber threatscape and plugging new security gaps is never-ending. We recently gathered several members of the Code42 security team for a panel discussion about how they manage threats and mitigate risks in today’s security environment. A recording of their conversation is now available on demand.

Below are a few highlights and sneak peeks from their conversation. You can check out the full panel discussion here.

Vendor risk management in the SaaS era

Maintaining visibility across a SaaS environment can be very challenging. One action our security team has taken to help address the situation is to put more focus on vendor risk management. Watch the short clip below to learn how they have defined a set of security controls for our vendor partners — and how the team holds vendors accountable to these standards.

Managing insider threats

Not all insider threats are malicious. People sometimes make mistakes and unexpected disruptions can put data at risk. In the next video clip, our security team talks about strategies to consider when implementing a comprehensive insider threat security plan that protects against both malicious and unintended threats.

Mitigating the risk of shadow IT with an application inventory

Gartner now predicts that by 2020, one-third of successful enterprise attacks will aim at unauthorized shadow IT applications. At Code42, we know that shadow IT is a big security risk. We also know it’s a risk that we’re not going to fully eliminate. Instead, our security team is focused on increasing our visibility to what applications — authorized or not — exist in our environment. In this next video clip, our panel shares how they search for instances of potentially compromised applications, so they can take quick and effective action.

How Code42 Forensic File Search fits in the security tech stack

With the wide range of security tools that already exist, where does Code42 Forensic File Search fit in a security stack? In the next video clip, our security team talks about how they use Code42 Forensic File Search in combination with other security tools and on its own to address unique use cases. The panel also talks about innovative ways that organizations can use Code42 Forensic File Search to fill existing security gaps, instantly expanding visibility and getting answers to questions like “Where is this file in our environment?”

This is just a sample of the insider knowledge shared during our panel discussion. Don’t miss your chance to hear the full conversation, on demand, right here: Code42 Security Panel: Choosing Tools to Fill Gaps in Your Security Stack

Code42 Next-Gen Data Loss Protection: What DLP Was Meant to Be

Malware and other external cyber threats get most of the headlines today. It’s not surprising, given the damage done to companies, industries and even countries by outside-in attacks on data. Despite that, insider threats — the risks of data being lost or stolen due to actions inside the company — are just as big a threat.

According to the 2018 Insider Threat Report by Cybersecurity Insiders, 90 percent of cybersecurity professionals feel vulnerable to insider threat. McKinsey’s Insider threat: The human element of cyberrisk reports that 50 percent of breaches involved insiders between 2012-2017.

“ By rethinking traditional DLP, you can know exactly where all your data is, how it is moving throughout your organization and when and how it leaves your organization — without complex policy management, lengthy deployments or blocks to your users’ productivity. ”

“The rise of insider threats is a significant threat to every business and one that is often overlooked,” said Jadee Hanson, Code42’s CISO. “While we all would like to think that employees’ intentions are good, we prepare for malicious actions taken by those from within our organizations. As external protection increases, we all should be concerned as to the influence external actors may have on those working for us and with us every day.”

Insider threats are a big deal, and traditional data loss prevention (DLP) solutions were developed to protect companies and their data from these internal events.

DLP hasn’t delivered

While traditional DLP solutions sound good in concept, most companies are only using a fraction of their capabilities. Security teams describe using these solutions as “painful.” Legacy DLP deployments take months or years, because proper setup requires an extensive data classification process, and refining DLP policies to fit unique users is complex and iterative. And after all that time, traditional DLP still blocks employees from getting their work done with rigid data restrictions that interfere with user productivity and collaboration. They also require on-site servers — counter to the growing business priority of moving solutions to the cloud.

Most importantly, legacy DLP solutions are focused on prevention. Business and security leaders now recognize that prevention alone is no longer enough. Mistakes happen, and data threats sometimes succeed. Being able to recover quickly from data loss incidents is just as important as trying to prevent them.

Rethink DLP

At Code42, we protect over 50,000 companies from internal threats to their data. This focus on protection has enabled us to see things differently, and develop an alternative to data loss prevention: data loss protection. We are excited to announce the new Code42 Next-Gen Data Loss Protection (Code42 Next-Gen DLP) solution that rethinks legacy DLP and protects data from loss without slowing down the business.

Code42 Next-Gen DLP is cloud-native and protects your cloud data as well as all of your endpoint data. It deploys in days instead of months, and provides a single, centralized view with five key capabilities:

  • Collection: Automatically collects and stores every version of every file across all endpoints, and indexes all file activity across endpoints and cloud. 
  • Monitoring: Helps identify file exfiltration, providing visibility into files being moved by users to external hard drives, or shared via cloud services, including Microsoft OneDrive and Google Drive.
  • Investigation: Helps quickly triage and prioritize data threats by searching file activity across all endpoints and cloud services in seconds, even when endpoints are offline; and rapidly retrieves actual files — one file, multiple files or all files on a device — to determine the sensitivity of data at risk.
  • Preservation: Allows configuration to retain files for any number of employees, for as long as the files are needed to satisfy data retention requirements related to compliance or litigation.
  • Recovery: Enables rapid retrieval of one file, multiple files or all files on a device even when the device is offline, or in the event files are deleted, corrupted or ransomed.

By rethinking traditional DLP, you can know exactly where all your data is, how it is moving throughout your organization and when and how it leaves your organization — without complex policy management, lengthy deployments or blocks to your users’ productivity. DLP can finally deliver on what it was originally created to do.

Architecting-IAM-for-AWS-with-Okta-Code42_Blog

Tips From the Trenches: Architecting IAM for AWS with Okta

In the last year, Code42 made the decision to more fully embrace a cloud-based strategy for our operations. We found that working with a cloud services provider opens up a world of possibilities that we could leverage to grow and enhance our product offerings. This is the story of how we implemented identity and access management (IAM) in our Amazon Web Services (AWS) environment.

IAM guiding principles

Once the decision was made to move forward with AWS, our developers were hungry to start testing the newly available services. Before they could start, we needed two things: an AWS account and a mechanism for them to log in. Standing up an account was easy. Implementing an IAM solution that met all of our security needs was more challenging. We were given the directive to architect and implement a solution that met the requirements of our developers, operations team and security team.

We started by agreeing on three guiding principles as we thought through our options:

1.) Production cloud access/administration credentials need to be separate from day-to-day user credentials. This was a requirement from our security team that aligns with existing production access patterns. Leveraging a separate user account (including two-factor authentication) for production access decreases the likelihood of the account being phished or hijacked. This secondary user account wouldn’t be used to access websites, email or for any other day-to-day activity. This wouldn’t make credential harvesting impossible, but it would reduce the likelihood of an attacker easily gaining production access by targeting a user. The attacker would need to adopt advanced compromise and recon methods, which would provide our security analysts extra time to detect the attack.

2.) There will be no local AWS users besides the enforced root user, who will have two-factor authentication; all users will come through Okta. Local AWS users have some significant limitations and become unwieldy as a company grows beyond a few small accounts. We were expecting to have dozens, if not hundreds, of unique accounts.  This could lead to our developers having a unique user in each of the AWS environments. These user accounts would each have their own password and two-factor authentication. In addition to a poor end-user experience, identity lifecycle management would become a daunting and manual task. Imagine logging into more than 100 AWS environments to check if a departing team member has an account. Even if we automated the process, it would still be a major headache.

Our other option was to provide developers with one local AWS user with permissions to assume role in the different accounts. This would be difficult to manage in its own way as we tried to map which users could connect to which accounts and with which permissions. Instead of being a lifecycle challenge for the IAM team, it would become a permissioning and access challenge.

Fortunately for us, Code42 has fully embraced Okta as our cloud identity broker. Employees are comfortable using the Okta portal and all users are required to enroll in two-factor authentication. We leverage Active Directory (AD) as a source of truth for Okta, which helps simplify user and permission management. By connecting Okta to each of our AWS accounts, users can leverage the same AD credentials across all AWS accounts — and we don’t need to make any changes to the existing IAM lifecycle process. Permissioning is still a challenge, but it can be managed centrally with our existing IAM systems. I will describe in greater detail exactly how we achieved this later in the post.

3.) Developers will have the flexibility to create their own service roles, but will be required to apply a “deny” policy, which limits access to key resources (CloudTrail, IAM, security, etc.).  As we were creating these principles, it became clear that the IAM team would not have the bandwidth to be the gatekeepers of all roles and policies (how access is granted in AWS). Developers would need to be empowered to create their own service roles, while we maintained control over the user access roles via Okta. Letting go of this oversight was very difficult. If not properly managed, it could have opened us up to the risk of malicious, over-permissioned or accidental modification of key security services.

Our initial solution to this problem was to create a “deny” policy that would prevent services and users from interacting with some key security services. For example, there should never be a need within an application or microservice to create a new IAM user or a new SAML provider. We notified all users that this deny policy must be attached to all roles created and we used an external system to report any roles that didn’t have this deny policy attached.

Recently, AWS released a new IAM feature called permission boundaries. The intent of permission boundaries is similar to that of our deny policy.  By using permission boundaries we can control the maximum permissions users can grant to the IAM roles that they create.  We are planning to roll this out in lieu of the deny policy in the very near future.

Example of a role found without the deny policy attached

Implementing Okta and AWS

When thinking through connecting Okta and AWS, we were presented with two very different architectural designs: hub and spoke and direct connect. The hub and spokedesign leverages an AWS landing account that is connected to Okta. Once logged in to this account, users can switch roles into other AWS accounts that are authorized. The direct connect design we implemented creates a new Okta application icon for each AWS account. Users access their accounts by visiting their Okta homepage and selecting the account they want to use.

Power users tend to prefer the hub and spoke model, as this allows them to quickly jump from account to account without re-logging in or grabbing a new API token. The more casual users prefer to have all accounts presented on one page. They aren’t swapping among accounts, and it isn’t fair to ask them to memorize account numbers (or even exact short names) so they can execute an assume role command. In addition to user experience, we considered how easy it was to automate management once a new account has been created. The two approaches each have merit, so we decided to implement both.

When a new account is created, it is bootstrapped to leverage the hub and spoke landing account. Automation can immediately start working with the account, and certain power users get the access they need without any IAM intervention. The IAM team can revisit the account when convenient and stand up the direct connection to Okta. New Okta features, currently in beta, will improve this direct connect process.

One final thing I would like to touch on is how we leverage the Okta launcher to get API tokens in AWS. One of the benefits of having local users in AWS is that each user is given their own API key. While this is a benefit to end users, these keys are very rarely rotated and could present a significant security risk (such as an accidental public GitHub upload). To address this, Okta has created a java applet that generates a temporary AWS API key. The repo can be found here. Like many other companies, we have created wrappers for this script to make things as easy as possible for our end users. After cloning the repo, a user can type the command “okta -e $ENV_NAME” and the script will reach out to Okta and generate an API key for that specific AWS account.  The users do need to know the exact environment name for this script to work, but most power users that need API access will have this information.

No matter where your company is on the path to leveraging a cloud service provider, IAM is a foundational component that needs to be in place for a successful and secure journey. If possible, try to leverage your existing technologies to help improve user experience and adoption. I hope the principles we shared here help you think through your own requirements.

MacDonald-Miller Boosts Mobile Workforce Productivity with Code42 (Video)

Ineffective data security strategies are expensive. Whether it’s an IT team trying to save corrupted files or perform manual data storage tasks, an employee having to redo work because a file was irretrievably deleted, or lost sales due to stolen IP, the cost in time, productivity and revenue can add up fast.

Recent research by the Ponemon Institute found that the global average cost of a data breach is $3.86 million, and the average cost for each lost or stolen record containing sensitive information is $148. However, much of that lost productivity can be mitigated with a comprehensive data security strategy that includes effective backup, restore, user self-service and legal hold tools.

Case in point: MacDonald-Miller, a full-service, design-build mechanical contractor in the Pacific Northwest, has developed and implemented a multi-faceted data security strategy that uses Code42 to save time and safeguard valuable company IP. With more than 1,000 employees — many of them mobile workers moving around to different job sites — and 10 locations, it’s critical for MacDonald-Miller’s IT team to have the right tools in place to keep its diverse workforce at maximum productivity. They turned to Code42 to help.

Mitigating employee downtime

With a highly mobile workforce of contractors, foremen, electricians, plumbers and other workers at different job sites, maintaining productivity is critical. If blueprints or plans are lost throughout the day, that can result in expensive idle time.

“All of a sudden, they can’t work,” says Eddie Anderson, help desk support agent for MacDonald-Miller facility solutions. “That’s an expensive workforce to have on hand.”

Previously, restoring lost files was a highly manual, labor intensive process with a low success rate. Workers had to drive to the company’s central location in Seattle to have the IT team work on the problem.

“We’d have to dig through recycle bins, looking for previous versions,” says Chad Tracy, network administrator for MacDonald-Miller facility solutions. “If it really came down to it, we’d have to scan the hard drive to search for missing sectors of files.”

Now, with Code42 Backup + Restore, MacDonald-Miller is saving time on lost file incidents like this, freeing up IT to take on more strategic work.

“We’re saving an hour if not more per restore,” says Tracy. “We’re utilizing that time to really revamp a lot of our knowledge base articles, help users understand self-service, get into that culture mindset and give us creative freedom. We can now jump into things like augmented and virtual reality, which is helping us as a very powerful sales tool.”

Leveraging employee self-service

Because user sophistication varies across MacDonald-Miller’s 1,000-plus employee base, developing self-service tools for IT tasks can be a challenge.

“Our engineering team is very tech-savvy. Then we have electricians and plumbers who, quite frankly, would not like to use a computer ever,” says Anderson. “When we look at a solution for self-service, it needs to be able to hit all those different aspects of our company.”

Previously, when users needed to restore a file, the process was very hands-on and manual. They would call the IT service desk and the IT personnel would have to figure out whether they would need to drive in to the central location for hands-on support.

Now, with Code42, users are able to perform their own restores. This boosts workforce productivity for both the employee needing the restore and the IT department. One sales team member accidentally deleted a bid proposal right before a presentation. She was able to use Code42 to restore a previous version of the file on her own.

“One of the best parts was, IT didn’t even know about it until she came and told us,” says Anderson.

Protecting valuable IP

MacDonald-Miller’s unique value proposition includes designing and blueprinting buildings, and then sending in a full team of plumbers, electricians and sheet metal workers to work on the build. With all that valuable design IP to protect, having an effective legal hold process is critical.

“Prior to Code42, our legal hold process was very vague,” says Tracy. “HR or IT had to find the user’s computer and manually try to search through documents, pictures and Excel files to see what may or may not have been on the user’s computer at the time of termination.”

Now, with Code42, MacDonald-Miller can use a portal to set up a legal hold for users and then monitor whether they’re copying documents on their personal drives.

“We had a pretty high-profile gentleman leaving the company,” says Anderson. “Through that portal, we were able to monitor his file history and found out 90 gigs of sales opportunities and other critical data had left to the network onto his external drive. Before Code42, there was no way of ever knowing that was happening.”

Schneider Electric Saves Time and Productivity with Code42 (Video)

Code42 customer Schneider Electric is a global specialist in energy management and automation. The company helps its customers manage energy and processes in homes, commercial buildings, data centers and industries. With such a wide variety of projects in the organization, the company’s IT desk also faces a broad range of requests from employees. Fortunately, Schneider Electric is a Code42 customer, and the self-service features of the Code42 platform help keep minor tasks like device migrations and file restores from getting in the way of more pressing IT projects.

Schneider Electric Infrastructure Architect Brian Junker and Endpoint Solutions Senior Engineer Austin Joe recently spoke to us about how Code42 helps them preserve the productivity of both the IT team and end users.

In this video, they discuss how Code42’s self-service restore features remove the burden of file restores from IT:

In the second video, Brian and Austin discuss how those same self-service restore features are saving time in device migration and tech refresh projects — a task that traditionally eats up a lot of hours for both IT and the end user.

Code42 Experience Week: Connecting, Learning and Values

Recently, a cohort of about 30 talented new Code42 hires spent a week with our leadership team, taking in their advice and wisdom. It was Experience Week, our quarterly cultural deep-dive that all new employees participate in within the first 90 to 180 days of their time with the company. Experience Week is a cross-functional, educational, and rewarding experience, and it’s always delivered by senior leaders at Code42.

“ New hires find their place to belong and are charged to make an impact at Code42. It is a powerful and unique experience that motivates and supports our employees. ”

During the week, executives share their experiences, talk about Code42’s values and give a bird’s eye view of the work their teams are doing to move our business forward. In addition, they share anecdotes about family life, hobbies and passions outside of work. Here are some of the snippets shared at our most recent Experience Week:

  • “Greatness is a choice. It’s being able to see things the way they could be,” said Mike Robbins, senior vice president of worldwide sales. “It’s not a function of circumstances. That’s not how greatness works. We need to choose it.”
  • “Working at Code42 doesn’t come with an instruction manual, it’s a chance to make an impact,” said Leslie Pendergrast, senior vice president of people. “It’s not a calm carousel ride, but instead a thrilling and exciting roller coaster.”
  • “As Mark Zuckerberg says, ‘If you’re not breaking stuff, you’re not moving fast enough,’” said senior vice president of research, development and operations Rob Juncker, as he charged the new hires to move fast and innovate.

Feedback from new hires that have gone through Experience Week affirm the personal value they place on the experience. “Every company should invest in their people like this,” said one attendee.

Code42 Experience Week 2018

Here are some more thoughts from Experience Week attendees:

  • “Thank you for taking the time to invest in this for all new hires. I can’t tell you how far it goes to really indoctrinate us into the culture and heartbeat of the company. As a remote employee, it was even more invaluable.”
  • “I learned a ton about what it will take to succeed at Code42 and emerged really energized to break out of my comfort zone.”
  • “I was inspired to bring passion and commitment every day and be in charge of my own development.”

Education and connection

As much as Experience Week is about equipping new hires with the context they need to be successful at Code42, it’s equally about connection — connection to our culture and values, and most importantly, our people. By the end of Experience Week, our cohorts of new hires have close connections to 30 to 40 employees from all across the company.

These connections are formed in part by the entertaining evening activities that are part of Experience Week. In the past, these activities have included Iron Chef style cooking competitions, Amazing Race inspired scavenger hunts, Segway tours, escape rooms, Minnesota Twins baseball games and happy hours with executives.

Capstone experience: a personal manifesto

The action-packed week ends with every member of the new hire cohort sharing their personal manifesto. It’s their chance to present themselves to the company in a personal and creative way. The entire company is invited to watch the presentations and learn about who our new employees are, what drives them personally, and how they plan to make an impact on the organization going forward.

We are only as good as our people. Experience Week is an investment in our team members. New hires find their place to belong and are charged to make an impact at Code42. It is a powerful and unique experience that motivates and supports our employees with the context and connections they need to pursue peak performance, individually and collectively.

Are you a difference-maker? Join our team and maybe we’ll see you at our next Experience Week. code42.com/careers 

Facebook Twitter Google LinkedIn YouTube