Building a Security-Minded Organization

Tips from the Trenches: Building a Security-Minded Organization

As a security software company, it’s essential that everyone at Code42 thoroughly understands the security industry. This is true for nearly every position. Our sales teams need to fully understand the needs of our customers—and human resources need to understand security as they recruit candidates in the security industry, where it’s highly competitive to find the requisite talent. 

Marketing clearly needs to understand not only the big-picture security needs of our customers, but also the daily life and day-to-day challenges of a security analyst. Furthermore, as security becomes an integral component in DevSecOps, developers need to better understand application security, which means that security folks also need to up their code writing skills.

Of course, not everyone requires the deep depth-of-knowledge one would expect to find with a professional security team, but everyone who works at a security software company should understand security basics. With that goal in mind, we have created the new Security Ninja program designed to teach security and enable employees to earn new belts as their mastery progresses. These belts start with a white belt and culminate with a black belt, which requires a security certification to earn. These Code42 security ninjas will become our security ambassadors within the company.  

This self-driven program, which begins when an employee registers to earn a belt, can be completed per an employee’s individual schedule. Credits are allocated by time spent learning and consist of a mix of free training that can be found online, including through YouTube videos, attending a security lunch, and learning and sharing their learnings on our company’s Slack channel. When an employee does share his or her lessons learned on our internal Slack channels, it makes me smile because we now have employees who are teaching each other what they know about information security. 

For security awareness teams, watching employees gain more security knowledge that exceeds what is required for compliance, is literally a dream come true. These trainings are no cakewalk, mind you: The belts require the applicant to not be late on any of his/her security or privacy trainings, and the applicants must not have clicked on a link in a test phishing email. If they do, they can apply to continue their training in the following quarter. Since we implemented the Ninja program last January, we’ve seen our training completions rise and fewer links in phishing tests clicked. This is a huge win.

To keep engagement high, we’ve built the program to be competitive and also fun and lighthearted. We regularly communicate about the program on our company-wide Slack channel. Some managers have set goals for their teams to gain their belts and initiate a bit of friendly competition in the process. Our sales teams are thrilled to expand their security expertise to better understand our customers and prospects and to speak their language.

Here’s how applicants earn their belts: First, they must provide evidence of completion on the learning activities they chose, even if it’s just a screenshot. Once they’ve gained the required amount of training credits, applicants can then take an online exam in our Learning Management System (LMS). At the end of the quarter, the LMS list of successful exam completions becomes my starting list to check off evidence submitted by each applicant. I check evidence “audit style” by randomly selecting people to audit; the truth is, however, that I’m so thrilled at the work they are all doing that I tend to review all evidence submitted, especially the “lessons learned.” There is no greater sense of satisfaction for a security awareness professional. 

Each quarter, we celebrate all of the new ninjas and award them their “belt,” i.e., a colored badge with an outline of a ninja. The ninjas can attach the belt to their badge holder or lanyard to proudly display their ninja level status. Of course, we have fun with this, too, by inviting everyone to our main meeting area and provide donuts for their accomplishments. We call it “Donuts in the Dojo,” and our CISO is there to congratulate everyone on their newfound security expertise.

This is not only a win for the security team, it’s also a win for the employees. They can more confidently navigate the world of security professionals and better understand our customers. All of this means it’s a huge win for Code42.

Using Slack to Enhance Security Blog post

Tips From the Trenches: Using Slack to Enhance Security

Slack, the popular collaboration tool, got more than its share of media attention last month. All this Slack buzz gives us an opportunity to share how we use Slack here at Code42. We’ve thoroughly vetted Slack, and rather than banning it as a security risk, we actually use the tool to enhance our security capabilities.

Why Code42 uses Slack

So, what about those security concerns? Any tool that facilitates the sharing of information brings some risk of user abuse or error , such as oversharing, mis-sharing, etc. That’s true for Slack, just as it’s true for Google Docs, Dropbox — and even, yes, Microsoft Teams. Just like our approach to data loss protection, our internal security strategy takes an honest look at risk mitigation that focuses on the biggest risks — without unnecessarily impeding productivity, collaboration and innovation. Like all our third-party vendors, we hold Slack to our rigorous vendor security standard, which includes an annual vendor security risk reassessment process. Moreover, we’ve put security controls in place that balance the need to mitigate the inherent risks of information-sharing with the productivity and innovation value of the tool itself.

How we use Slack

At Code42, nearly every employee uses Slack every day for real-time direct messaging, increasing productivity and helping us deliver on one of our core company values: Get it Done, Do it Right. The Code42 security team, in particular, leverages Slack in unique and powerful ways.  Here are a couple ways we have integrated Slack functionality to improve our internal security program:

  1. Security alert notifications: Slack’s Incoming WebHooks allow you to connect applications and services to your Enterprise Slack. We use this capability to implement security notifications tied to activities in our security applications, which are then posted in a corresponding Slack channel. This provides our security analysts and partners across the business with real-time alerts right in the application where they are already communicating and collaborating throughout the day, helping them take appropriate and timely action.

    For instance, we have created private channels to alert on critical events within different environments, such as alerts from Capital One’s Cloud Custodian. The alerts are based on policy violations that we define in YAML policy files. Cloud Custodian then alerts our team — and takes action when needed. For example, if Cloud Custodian sees an S3 bucket configured as public, it will make it private by changing permissions in the access control lists (ACLs) and bucket policies — and then notify our teams of the change via Slack as depicted below.



    Screenshot of Slack’s Incoming WebHooks tool:


  2. Security news and updates: Our security team also created a public channel (open to everyone at Code42) as a collaborative workspace for all users. The public channel enables staff to crowdsource and share security knowledge, and to have discussions around the latest security news. Anyone can post security articles, whitepapers, podcasts, blogs or news — highlighting interesting ideas — and weighing in on each other’s responses. This channel acts as a security news feed, delivering just-in-time security-related information to employees to keep them aware of the latest security threats and trends. Code42 employees also often post what they are seeing in their own news feeds as they become more security savvy.

Walking the Talk

At Code42, we talk a lot about the fundamental paradox of enterprise information security: Information-sharing is both the key to success — and the biggest risk — in organizations. The smart approach focuses on controlling the risk, so you can unlock that value. We’ve vetted Slack and put security controls in place, so we can leverage its capabilities to fuel collaboration, enhance productivity and improve our internal security capabilities. Slack integrates with our security tools for real-time alerting and allows us to quickly disseminate security knowledge throughout the organization. Our internal use of Slack demonstrates how we walk the talk in our own approach to information security.

The Five Big Themes I’ll Be Looking for Next Week at Black Hat

If there was one annual event that encapsulates cybersecurity, it’s Black Hat. For more than 20 years, thousands have gathered to learn security during the Black Hat training sessions and see cutting-edge research on display at the Black Hat Briefings. Black Hat has been doing this every year in Las Vegas since 1997. That’s right about the time enterprise data security started maturing into widespread practice. Over the years, the crowds have grown, and so has the importance of data security. 

Every year at Black Hat, I try to keep an eye out for different trends. These are themes that I believe will be important and drive a lot of the conversation at the conference, not to mention the months that follow. Here’s what I’m looking at this year:

“ What piques my interest about insider threat isn’t just the number of attacks perpetrated by insiders; it’s about how damaging insiders can be to an organization. After all, insiders know where the data is and what data is valuable. ”

The insider threat

There have been several recent news stories that highlight insider threat and it’s no fluke that they dominate the news cycle. Insider threats are up 50 percent in the past four years alone. Recently, we learned about the McAfee employees who quit and were sued for allegedly taking intellectual property to a competitor. Then there was the SunPower exec who emailed himself highly sensitive trade secrets. And the Desjardin employee who accessed the data of nearly three million bank customers. Earlier this year, the Verizon Insider Threat Report found that 20 percent of cybersecurity incidents originated from trusted insiders and often went unnoticed for weeks, months, and even years. 

What piques my interest about insider threat isn’t just the number of attacks perpetrated by insiders; it’s about how damaging insiders can be to an organization. After all, insiders know where the data is and what data is valuable. I’ll be looking for lots of conversations in this area, and new insights into ways to better detect and respond to insider threats before IP is gone and the damage is done.

The increased importance of DevSecOps

The popularity of DevOps keeps growing. According to Allied Market Research, the global market for DevOps tools was nearly $3 billion in 2016 and is expected to reach over $9 billion by 2023 — growing at a healthy 19% annual clip. Yet, enterprises have a challenge when it comes to incorporating security into the DevOps application development and management processes. That’s what DevSecOps is all about. I think we’re going to hear some great advice and ways to maximize the incorporation of strong security practices into DevOps.

Insight into the emerging threat landscape

We always look toward finding a fresh perspective on the threat landscape at Black Hat. The conference presenters are always examining new attack methods in detail. This year will be no different, and I’m expecting to see interesting approaches to attacks via social media and insider threat exploits.

Latest trends in Zero Trust security

Zero Trust has moved from buzzword to reality, but we’re just beginning to see organizations move beyond superficial Zero Trust implementations. I expect the conversations around Zero Trust, a concept of security centered on the belief that companies shouldn’t trust anyone or anything inside or outside their perimeters, and instead must verify and monitor anything and everything trying to access company data, to become more meaningful and results-based. This will continue to be an interesting and compelling topic in the months following Black Hat.

A deep look inside a few interesting security vulnerabilities

At Black Hat, if you don’t make it to a few sessions where they dive deep into a security flaw or exploit, you’re really missing out. These sessions are eye-opening, heart-stopping, and mind-jarring to see. It opens your eyes to the ways in which people make new inroads to devices, hack into large enterprises, and leverage vulnerable software to do it silently.

I’m also going to keep a lookout for new buzzwords and emerging attack trends. For instance, we already see the rapid rise of deepfake movies. And let’s face it, these videos are getting incredibly good, thanks to sophisticated algorithms that create unprecedented reality. Soon, we’ll have issues trusting our own eyes and ears and their ability to discern what is real. This will be fun to see take shape this year.  

Finally, we all know that the IT industry is increasingly turning to artificial intelligence (AI) and machine learning to help secure our increasingly complex environments. But when it comes to new security technologies, it’s a bit of a double-edged sword. What can be used for our defense can also be used to attack us. AI is no different, and in the near future, we’re going to see AI used more commonly to attack enterprises. AI-based attacks are on their way. You can count on it.

Mitigating Departing Employee Data Loss Threats Code42 Blog

Mitigating Departing Employee Data Loss Threats


The first thing most IT security pros think when they read, “DLP is a program or a process — not a product,” is, “A program sounds a lot more complicated and expensive than a product.” But that doesn’t have to be the case. In my last blog, I outlined 10 key steps to building a simplified insider threat program that’s based around three key workflows: departing employees, organizational change and high-risk employees. We believe these three scenarios account for 80% of insider threat. 

Today, we’re diving into the first workflow: departing employees.

“ Most organizations don’t have a specific and consistent workflow to account for the unique data exposure risks surrounding a departing employee. ”

It’s a big problem, and it’s only getting bigger

Even the very best places to work are feeling the pain of this growing challenge. People are changing jobs more frequently than ever, a trend that started shortly after the recession and has continued accelerating: Employee “quits” (voluntary departures) have risen every year since 2010, according to the U.S. Bureau of Labor Statistics. A recent survey suggests more than half of U.S. workers will look for a new job in 2019 — and half of those new-job-seekers haven’t even been at their current gig for a full year. One big reason: employees increasingly don’t have the same feelings of loyalty toward their employers — in fact, they fully expect to switch jobs frequently in order to stay fresh and grow. With the job market remaining strong (especially for in-demand knowledge workers), their confidence in finding a new job is as high as ever.

And when they leave, they’re taking valuable and/or sensitive data with them. The Code42 2018 Data Exposure Report showed that roughly half of employees admit to taking IP with them when they leave. Even more concerning: The higher you go in the company, the more likely data is walking out the door with over 70% of execs admitting to taking IP from one employer to the next. 

It’s not black and white

The risk posed by departing employees tends to be viewed in absolute terms. Most organizations assume that 99.9% of employees would NEVER take anything or do anything risky. “They’re good people; they know better,” is something we hear all too often. On the flip side, most assume that any employee that does take data is doing so maliciously. The reality is that there’s a tremendous gray area. Most people aren’t outright stealing. They’re doing things like:

  • Pulling together their best work to help them land a new job
  • Taking the work they’re most proud of with them
  • Taking things like templates to use in their new gig
  • Taking “their” client info
  • Deleting files to “help” clean up their devices for the next user
  • Even just sharing work with colleagues, or pulling important working files onto thumb drive to give to a current colleague to ensure the project keeps moving forward after they leave

Most have good (if self-centered) intentions. But they’re still taking actions that put the company at risk.

Offboarding is just as important as onboarding

While most organizations dedicate significant time and resources to their employee onboarding program, offboarding gets far less attention. In fact, most organizations don’t have a specific and consistent workflow to account for the unique data exposure risks surrounding a departing employee much less involve the security team if they actually do have a process. 

Building a departing employee workflow

With employee departures accelerating across the workforce — you need to have a dedicated program to account for these risks. So, what should that program look like? Here are a handful of best practices that simplify the task:

  • Have a corporate policy. You may think your idea of data theft is universal. It’s not. Every organization needs an explicit, written policy around employee data exfiltration: what they can and can’t take; where they can and can’t move data; and how they should go about getting permission to take files or data upon their departure.
  • Publicize the policy. Bad habits are hard to break. Make data protection best practices part of employee onboarding. But also make sure data exfiltration review is part of the offboarding process. A simple reminder can go a long way toward preventing well-intentioned employees from doing something they shouldn’t.
  • Create a departing employee trigger — and execute the workflow every time. Most organizations have a new employee trigger, owned by HR, that automatically sets in motion an onboarding process that includes everything from training to IT and security teams giving the new employee the access privileges they’ll need. HR should also have a departing employee trigger that automatically sets in motion an offboarding process that includes a security analysis of the employee’s data activity to account for potential risks. Just like onboarding, this departing employee workflow should be followed for every departing employee — not just those you consider high-risk. 
  • Go back in time. A common mistake is to think employees start taking data after they give notice or right before they leave. Moreover, most employee monitoring tools only start monitoring an employee once notice is given. The reality is that the risky activity most often occurs much, much earlier — as they’re looking for a new job; after they’ve accepted another position, but before they’ve given notice; etc. To account for this reality, best practice is to analyze departing employee activity going back months from the day they give notice.
  • Build a “red flag” list with LOB. By focusing on just departing employees, you’ve already dramatically narrowed the scope of the security analysis from the traditional, “classify ALL your data” approach of legacy DLP. But you can hone in further by engaging LOB leaders to build a specific list of your organization’s most valuable files and file types: source code for tech companies, CAD drawings at an engineering firm, Salesforce files and customer lists, spreadsheets with financial info, codenames for R&D projects, etc. Make sure your monitoring tools allow you search and filter activity by file type, file name, etc., so you can quickly look for these red-flag activities.
  • Search for common signs of suspicious activity. In addition to looking at specific file categories, your monitoring tools should also allow you to easily see when file activity deviates from normal patterns (a spike, e.g.), to search specifically for after-hours or weekend activity (when suspicious activity often occurs), and to uncover suspicious file mismatches (i.e., a customer list file is renamed “photo of my daughter” and the MIME type doesn’t match the extension).

“ To get to the bottom of suspicious activity and act with confidence, you need the ability to restore and review any version of any file — so you can see if it’s really a problem. ”

A departing employee workflow example

Here’s a rough look at how a departing employee workflow…works:

1) TRIGGER
Employee gives notice, triggering activity review by IT security.

2) ANALYSIS
Security looks back at the past 90 days of employee data activity, searching for suspicious or risky actions.

3) ACTIVITY FLAGGED
Security flags suspicious activity: a product pricing spreadsheet that was emailed to an external address.

4) HR/LOB REVIEW
Security restores the spreadsheet and brings it to HR. HR brings it to the LOB manager. LOB manager confirms that emailing pricing document was not authorized.

5) ESCALATION TO LEGAL
Depending on the activity and severity of the risk, the issue may be escalated to legal.

It all depends on visibility

The departing employee workflow — like your entire insider threat program — depends on visibility. To be able to look back at the last 90 days of a departing employee’s activity, you can’t be working with a DLP or monitoring solution that only kicks on after the employee gives notice. You need to be continuously monitoring all data activity, so you’re instantly ready to execute a 90-day security analysis of any employee, as soon as they give notice. This visibility can’t be limited to file names. To get to the bottom of suspicious activity and act with confidence, you need the ability to restore and review any version of any file — so you can see if it’s really a problem. With this kind of always-on monitoring, you can enable the kinds of targeted triggers that focus your attention where it matters most — and act quickly to mitigate risk and potential damage from the many things departing employees take with them when they leave.

Happy Anniversary! GDPR One Year Later

Happy Anniversary! GDPR One Year Later

It’s been a year since we — and many of you — went live with enhancements to our privacy and security programs tied to GDPR, and two years since we started the GDPR journey. That’s why it’s a great time to look back at the impact GDPR has had on the way we do business.

This post is purely for general information purposes and is not intended as legal advice. This blog gives a glimpse into Code42’s early GDPR implementation. We, along with GDPR as well as other national and international privacy rules, will continue to evolve and mature.

“ The GDPR journey shouldn’t be a one-department initiative or the sole responsibility of Legal or Security. It must be a business-driven initiative with Legal and Security providing recommendations and guidance. ”

What we did to get ready for May 2018

We started preparing for GDPR around May 2017. The GDPR journey shouldn’t be a one-department initiative or the sole responsibility of Legal or Security. It must be a business-driven initiative with Legal and Security providing recommendations and guidance. At Code42, we established a cross-functional group comprised of Legal, Security, IT and system subject matter experts. The key activities of this group were to:

  1. Create an inventory of applications in scope for GDPR. We have European employees and customers so we had to look at applications that were both internal and customer-impacting. When outlining in-scope applications for GDPR, we kept in mind that more restrictive data privacy laws seem imminent in the U.S. We also conducted a cost-benefit analysis to determine whether we should keep non-EU PI in scope now or revisit it at a later date.  
  2. Define retention periods for all of the applications in scope. Prior to our GDPR journey, we had a retention program in place, but it was largely focused on data we knew we had legal, regulatory or other compliance obligations around, including financial records, personnel files, customer archives and security logs. GDPR just gave us the nudge we needed to mature what we were already committed to and have better conversations around what other data we were storing and why.
  3. Figure out how to purge personal data from applications. This may be challenging for SaaS organizations. When applications are managed on premise, it’s much easier to delete the data when you no longer need it. But translating that to all your SaaS applications is another story. There are a few areas where SaaS applications are still maturing compared to their on-prem counterparts, and data deletion appears to be one of them. Delete (or anonymize) data, where you can. Otherwise, either add the applications to a risk register, requesting that the application owner do a risk accept and submit a feature request to the vendor, or look for a new vendor who can meet your retention requirements.
  4. Create an audit program to validate compliance with our security program. We are fortunate to have an awesome internal audit program that monitors effectiveness of our security program, among other IT and technology-related audit tasks. So it was logical to test our in-scope applications against our newly defined retention requirements. We review applications periodically.
  5. And lastly, but just as important, define a process for data subjects to request that their information be deleted outside of a standard retention schedule (aka “right to be forgotten”). It is important to remember that this is not an absolute. While we want to honor a data subject’s request as much as possible, there may be legitimate business cases where you may need to maintain some data. The key for us was defining what those legitimate business cases were so we could be as transparent as possible if and when we received a request.

What we’ve learned in the last year

So what have we learned about GDPR one year and two internal audits later? A lot. 

What’s going well

1. A vendor playing nice

We had a really great success story early on with one vendor. When we dug into it, we found that our users were previously set up with the ability to use any email address (not just a Code42 email). We also learned our instance was configured to save PII that wasn’t a necessary business record. Based on that conversation, we were able to make a few configuration changes and actually take that application out of scope for GDPR! 

2. A more robust application lifecycle program and greater insight into the actual cost of a tool

As a technology company that is continually innovating, we want to empower our users to use tools and technologies that excite them and increase productivity. At the same time, we want to ensure we are addressing security, privacy and general business requirements. Users often find tools that are “so cheap” in terms of the cost of user licenses. Our new Application Lifecycle Management (ALM) process, however, gives us a better sense of the actual cost of a new tool when we factor in:

  • Onboarding requirements: Think Legal, Security, IT, Finance. Are there compliance requirements? Do we already have similar tools in place?
  • Audit requirements: Will this be part of the GDPR data retention audit, user access audit or other application audit?
  • Stand-up/stand-down requirements: Will it integrate with single sign-on solution? How does it integrate with other tools? How is data returned or destroyed?
  • Support requirements: Who are users going to contact when they inevitably need help using the tool?

When the person making the request can see all of the added costs going into this “inexpensive” tool, it makes for easier discussions. Sometimes we’ve moved forward with new tooling. Other times we’ve gone back to existing tools to see if there are features we can take advantage of because the true “cost” of a new solution isn’t worth it.

3. A great start toward the next evolution of privacy laws

On the heels of GDPR, there has been a lot of chatter about the introduction of more robust state privacy laws and potentially a federal privacy law. While future regulations will certainly have their own nuances, position yourselves to comply with them in a way that will require just small tweaks versus major lifts like the GDPR effort.

What’s not working

1. What exactly IS personal data?

We have had a lot of conversations about what data was in scope… and I mean A LOT. According to the GDPR, personal data is defined as any information related to an identified or identifiable natural person. That puts just about every piece of data in scope. And while it may seem like an all-or-nothing approach may be easier, consider risks that could affect things like availability, productivity, retention, etc. when implementing controls, then scope programs appropriately to address those risks in a meaningful way. 

2. “Yes, we are GDPR compliant!”

One thing we realized very quickly was that it wasn’t enough to simply ask our vendors if they were “GDPR compliant.” We ended up with a lot of “Yes!” answers that upon further investigation were definite “No’s.” Some lessons learned: 

  • Understand the specific requirements you have for vendors: Can they delete or anonymize data? Can they delete users? 
  • Whenever possible, schedule a call with your vendors to talk through your needs instead of filing tickets or emailing. We found it was much easier to get answers to our questions when we could talk with a technical representative.
  • Ask for a demo so they can show you how they’ll delete or anonymize data and/or users. 
  • Don’t rely on a contractual statement that data will be deleted at the end of a contract term. Many tools still aren’t able to actually do this. It’s important that you know what risks you are carrying with each vendor.
  • Audit your vendors to ensure they are doing what they said they would. 

Would we do it all over again?

Actually, yes. While our GDPR project caused some grumbling and frustration at the beginning, it has now become an integrated part of how we operate. There is no panic and no annoyance. Instead, there are lots of great proactive conversations about data. At the end of the day, we have matured our tool management, and our privacy and security; and our data owners feel a stronger sense of data ownership.

Wanna see a sample of our Application Lifecycle Management (ALM) vetting checklist? 

Legacy_DLP_does_not_work_Code42_Blog

Legacy DLP Doesn’t Work: McAfee Sues Former Employees for Stealing Company Data

If you think your company is immune to departing employees walking out the door with sensitive data, think again.

Case in point: A world leader in data loss security, McAfee, just filed a lawsuit against three former employees for conspiracy and stealing trade secrets before they went to work for Tanium, a market rival. To carry out the alleged heist, the employees did not use the type of sophisticated technology that you might expect. Instead, according to the lawsuit, confidential company information was moved to unauthorized USB devices, private email addresses and cloud-based drives.

“ If a legacy DLP vendor can’t keep a simple breach from occurring in its own company, why would anyone trust legacy DLP software to keep their data safe? Short answer: they shouldn’t. ”

The kicker? A “leader” in data loss prevention didn’t realize that critical data was leaving until months after the damage was already done. And even then, they couldn’t definitively determine what had been taken or how much. 

Thank you, McAfee, for demonstrating what many of your customers must already know — legacy Data Loss Prevention (DLP) doesn’t work. If a legacy DLP vendor can’t keep a simple breach from occurring in its own company (a breach of data that McAfee claims is worth millions of dollars!) why would anyone trust legacy DLP software to keep their data safe? Short answer: they shouldn’t.

The insider threat problem is growing

The insider threat problem is getting worse. Simply put: when people leave jobs, they take lots of data with them. According to McKinsey, 50 percent of breaches involved insiders between 2012 and 2017. It’s no longer a matter of whether data leaves, but when it leaves – and it’s leaving every day.

Part of the problem is that data has never been more portable — so taking it has never been easier. Sales lists, product specs, pricing information, payroll data and even contact lists are just a few examples of small but critically important files that are simple to take. Employees can store hundreds of gigabytes on their mobile devices, put 1TB or more of data on removable media, or quickly transfer data to personal cloud storage services like Dropbox.

Not only is data moving around more, but so are employees. The median tenure of U.S. workers ages 25 to 34 is just 2.8 years. And as they move from company to company, they take data with them. But that’s not all. While they may change companies, many opt to stay within the same industry, making the data that goes with them even more valuable.

“ We are offering all McAfee customers six months of free service when they buy a year of Code42 Next-Gen Data Loss Protection. ”

This is a solvable problem

At Code42 we’ve been working to help our customers face these challenges. Our insider threat solution identifies what data employees are taking as they depart your organization. In fact, we look back for 90 days because we have found the smart employees take important data long before they actually quit. Unlike McAfee and other traditional DLP players, we don’t require policies or classification of data, which means our solutions roll out in days not months. Oh, and unlike traditional DLP, we track all data exfiltration. Our products are designed to tell you before the damage is done so you don’t have to file lawsuits like McAfee’s.

To put our conviction on display, we are offering all McAfee customers six months of free service when they buy a year of Code42 Next-Gen Data Loss Protection*. And yes, that offer even extends to McAfee. After all, their data is valuable too, and they clearly need a better solution. 

*Offer details: If you are a current McAfee DLP customer, Code42 will offer six free months of service to switch to Code42. You must be a new Code42 customer and you must buy a minimum of 12 months of service to qualify for the six free months. This offer is valid through December 31, 2019. Contact Code42 sales at (877) 464-1061, or email mark.blaseck@code42.com.

Gartner’s CARTA Enable a Shift in Data Security

CARTA: What Role will it Play in the Hippy Era of Data Love?

The Gartner Security & Risk Management Summit 2019 is upon us and this year’s theme is all about how you can shift organizational culture to improve cybersecurity, data privacy and business resilience.

When it comes to building a viable data security strategy, organizational culture has easily been one of the more overlooked elements. But that is changing! Today, end users play a key role in shaping security. The ultimate conundrum organizations face is how to embrace cultural shifts that drive  productivity without jeopardizing data protection.

“ CARTA offers a strategic approach to information security that assumes that everyone inside a security perimeter is a threat and all data interactions are a security event. ”

To that end, I’m very interested to learn more about Gartner’s Continuous Adaptive Risk and Trust Assessment (CARTA) framework. A logical companion to Forrester’s Zero Trust model, CARTA offers a strategic approach to information security that assumes that everyone inside a security  perimeter is a threat and all data interactions are a security event. The approach makes sense. In times where insider threat scenarios are clearly on the rise, a data focused approach to detecting and responding to risk becomes paramount. In my opinion, the best part of the CARTA framework is its approach of continuously adapting to change and learning from each data interaction.

I’ve often joked with security analysts that they have the unenviable task of protecting data in the hippy era of data love. In this new data paradigm, users call the shots. They use their device of choice, work from their location of choice and sometimes select their corporate IP storage destination of choice! Today’s users have rejected the mores of mainstream security. Countering this wave may actually have adverse effects on the business.

One of the key questions for me to answer at this year’s summit will be, “How well can CARTA enable this cultural shift?”

If you are attending the Gartner Security & Risk Management Summit, stop by booth #448. Learn how the Code42 Next-Gen Data Loss Protection solution makes it quicker and easier to detect and respond to data exfiltration and insider threats.

Code42 Blog

Breach Fatigue – And How to Take Action

Since 2005, a staggering 9,033 data breaches have been made public — that averages about 1.77 breaches a day. In the wake of this stream of breaches, a sense of apathy has taken hold, causing both employees and organizations to become numb to their own security risks.

In her latest byline for TechBeacon, Code42 Chief Information Security Officer Jadee Hanson shares the dangers of employees and leadership experiencing breach fatigue and how it leaves an organization open to insider threats, ineffective security strategies and other security vulnerabilities.

Securing Your Software Supply Chain Code42 Blog

Securing Your Software Supply Chain

Software supply chain attacks have hit the news in a big way. In March, hardware maker ASUSTeK Computer, or ASUS, found its auto-update process hijacked to deliver malware and more than a million users may have downloaded a backdoored version of the company’s update software. 

Concerns about these types of attacks are growing. In recent years, we’ve witnessed attackers increasingly leveraging software supply chain attacks to do things, such as corrupt PC utility software and collaborative development tools. 

Supply chain attacks are different from other cyberattacks in a number of ways. In addition to being sophisticated, successful attacks have the ability to impact thousands to millions of users in ways few cyberattacks can. Then there’s the rising complexity of software. Software vendors today are making software self-updating and even self-healing. Because of all this, and the increasing amount of open source and third-party software in use, I expect the supply chain attack vector to become more common.

With this in mind, it’s important to understand the steps your software makers and providers are taking to protect the software and systems they provide you. 

“ One must take the best of precautions, such as conducting due diligence on hardware and software providers and ensuring that they do what they can to keep their systems and customers secure. ”

For instance, to help ensure the integrity of our software, we take a number of precautions here at Code42. We protect our systems with defense-in-depth, and we monitor the integrity of our files. We also encrypt our software certificates, and we make sure they are safe and well protected. We maintain strong file validation, to mitigate the risk that an attacker might inject something nasty and try to deploy software while posing as us to our customers.

Still, these types of attacks are very humbling for security professionals. They highlight the stark reality that no matter how many precautions one takes, everyone is still part of a chain of technology and reliant on third-parties. And if anyone in that chain of technology and services gets compromised, you are also now at significant risk of compromise. One must take the best of precautions, such as conducting due diligence on hardware and software providers and ensuring that they do what they can to keep their systems and customers secure.

While there’s certainly no guarantee of success, there are things one can do to approach the security of your software supply-chain.

First, I’d like to say, broadly, is that you should generally trust your software vendors. When a software provider publishes updates, there is a good reason. Good software development, especially one that includes software security, is a process — a process that certainly doesn’t end when software ships. In fact, the time to be concerned about trusting software vendors is if they’ve never reported a vulnerability. If not, there’s a good chance that they are not being transparent, or they are not looking closely enough. I don’t know which is worse. 

It’s also important to make sure that your software providers engage in secure software best practices. When issuing updates, are they signed? Are application bundles and libraries signed? Do they have a functioning vulnerability reporting process and publicly posted policy related to security patches? Make certain these things are in place.

Finally, don’t think it’s smart to block or skip updates. You could actually “denial-of-service” yourself by blocking updates because your software could stop properly functioning without new code. Some organizations think blocking updates helps improve their systems stability. It doesn’t. If your change controls are too rigid, they need to be updated so that software updates can be tested and then rolled out efficiently. Additionally, software compliance as well as government and industry regulations likely mandate that systems be kept up to date. 

When it comes to defending an organization against software supply chain attacks, it’s crucial that not only security best practices be closely followed, but one also needs to hold the seemingly contradictive assumption that nearly two-thirds of IT security professionals believe a successful cyberattack is imminent in 2019. This is why, in addition to the usual good user authentication practices, data backups, system and network segmentation, and anti-malware, it’s crucial to monitor for file integrity and mysterious traffic patterns. That means making certain that systems and data are persistently monitored for potentially malicious activity, such as unauthorized data exfiltration and other shenanigans. 

That’s certainly not a panacea. But the reality is there isn’t one. Still, every organization needs to be proactive and take the steps necessary to identify any anomalies underway in their environment. And they need to make sure their software providers are, for their own part, taking an aggressive stance themselves when it comes to software security and protecting themselves, and therefore their customers, from attack.

While security-savvy organizations have long thought about the nature of the security of the software they install, it’s time they also think more about the software update process from each of their vendors, and continue to do so for as long as it’s being used.

3 Key Workflows to Build an Insider Threat Program Code42 Blog

3 Key Workflows to Build an Insider Threat Program

We’ve never been shy about beating the insider threat drum at Code42, but the buzz on insider threat is reaching fever pitch. Small to medium-sized enterprise security and IT teams know they need to address this looming risk. But the biggest hurdle is answering the question, “Where do we start?”

For the past few years, the prevailing answer has been, “BUILD A COMPREHENSIVE INSIDER THREAT PROGRAM.” But let’s be honest: This is daunting. It’s time-consuming. It’s expensive. Moreover, these “best practices” often involved creating an entire team dedicated exclusively to insider threat detection and response. That sounds fantastic — but well beyond reality for most of us dealing with strained resources and limited budgets.

Most problematic: The root of this traditional approach is implementing traditional DLP. Just mentioning DLP might make you cringe as you imagine expensive technology and super complex rules that, at the end of the day, often do more harm than good — frustrating users with barriers to productivity and leading to workarounds and exceptions that compromise the whole program.

You need something simpler. We all do, because the insider threat problem is not going away. 

“ Start by focusing on the most common data exfiltration scenarios. These center on a few common use cases that impact nearly every organization — departing employees and high-risk workers, accidental leakage and organizational changes (re-organization, M&A, divestiture, etc.). ”

Here at Code42, we’ve come up with a better approach to building an insider threat program — and it all centers on a simple starting point: the everyday triggers that create your biggest insider threat risks. These are common use cases that happen every day (or every hour) that account for the vast majority of insider threat incidents — departing employees, accidental leakage and organizational changes. Hone-in on these high-risk triggers, and make sure you have the right technologies in place to see the full picture — not just a trail of breadcrumbs after the fact.

With these everyday use case triggers as the foundation, here are 10 critical steps that make it faster, easier and more cost-effective for small to medium-sized enterprises:

Code42’s 10 steps to building an insider threat program

1. Get executive buy-in: Don’t fight this battle on your own. Getting definitive buy-in from leadership is the first and most critical step in defining your security and IT team (and your efforts) as value-adding business partners — instead of frustrating data police. 

2. Identify and engage your stakeholders: Continue the buy-in campaign from the top down. Think about which individuals or teams within your organization stand to lose the most from insider data theft or leakage. Identify and engage line-of-business leaders, HR, legal and other IT leaders as key stakeholders in your insider threat program.

3. Know what data is most valuable: Once you know who you’re protecting, engage those line-of-business stakeholders in conversations about what data is most valuable to them. All data has value, but these conversations are essential to understanding the different types of unstructured data to keep a close eye on — and which types of high-value unstructured data will require more creative means of tracking.

4. Think like an insider: With your valuable data in mind, put yourself in the shoes of an insider. Why would they want to move or take information — and what would they ultimately want to do with it? What tactics or blind spots might they exploit to do it? What workarounds could they use to get work done? We call these actions inside indicators of compromise.

Up to this point, the steps may look very similar to more traditional approaches. You’re figuring out what data you’re protecting — and the indicators or compromise that point to insider incidents. Now, here’s where things get simpler:

5. Define insider triggers: Instead of building a monster program with classification schemes and policies that attempt to monitor every potential scenario (and ultimately fail), start by focusing on the most common data exfiltration scenarios. These center on a few common use cases that impact nearly every organization — departing employees and high-risk workers, accidental leakage and organizational changes (re-organization, M&A, divestiture, etc.). These use cases make up the vast majority of insider threat incidents, and serve as the foundational triggers of your insider threat program.

6. Establish consistent workflows: Investigating suspected data exfiltration can be daunting in itself. Once again, start small by focusing on the key use cases. For example, when an employee departure is triggered, define which activities will be examined — and what activities will trigger in-depth investigation. Exceptions and workarounds are the Achilles heel of insider threat programs. Make sure you clearly define the workflow for each trigger — and consistently execute and improve the steps you establish.

7. Create rules of engagement: Once a workflow has been triggered and potential data exfiltration identified, it should be the key stakeholder’s responsibility to directly engage the employee/actor. For example, departing employee and accidental leakage incidents will likely trigger engagement from HR and the line-of-business manager. A M&A workflow might trigger engagement from internal legal staff — or even a CFO. It’s important that these rules of engagement separate security and IT from any enforcement responsibilities. This allows them to focus on monitoring, detection and remediation — and prevents security and IT from developing an adversarial “data police” relationship with staff.

8. Leverage existing security and IT teams — and train your stakeholders: It doesn’t make sense for most small and medium-sized enterprises to create a fully dedicated insider threat team. Because we’ve honed the insider threat program down to a few key workflows, your existing security and IT teams should be able to handle the monitoring and detection responsibilities. But security and IT teams — who are already wearing multiple hats and managing strained resources — don’t have to shoulder the full burden. It’s also critical that all stakeholders (the HR, legal, line-of-business managers, etc.) be trained so they understand the full scope of the insider threat program: what is being monitored, the specific use case triggers, the investigation workflows, the rules of engagement and the tools used to accomplish all of this. This training should also clearly define their roles and responsibilities, so they’re ready to jump in when an incident response workflow is triggered.

9. Be transparent in communication: Transparency is critical for building a healthy culture that values security. Employees should know — from day one — that your organization tracks file activity. They should understand that the program is applied universally and without privileges or exceptions — and they should understand how the program is designed to support their productivity while protecting the business.

10. Implement true monitoring, detection and response technology: Perhaps most important of all, your insider threat program must start long before a trigger. In other words, you can’t afford to only monitor an employee’s activity after he’s given his notice, or after rumors of organization change have begun rippling through the office. Too many insider threat monitoring solutions are limited to this post-trigger scope — and far too often, the actual exfiltration occurs much earlier. True monitoring, detection and response technology must be continuously running, providing historical context and complete visibility into all data activity. This enables your insider threat team to quickly and effectively see the full picture — and protect all data at all times.

At the end of the day, let’s stop talking about insider threat exclusively as “employees stealing stuff.” This market perception perpetuated by our industry has done more harm than good. In reality, insider threats are the actions (good, bad and indifferent) people take with data (any data) that puts customer, employee, partner or company well-being at risk. The smaller the enterprise, the greater the business risk. That’s the real promise of the workflow-based approach: It gives small and medium-sized organizations a simple starting point — just three or four use cases — that will effectively address 80% or more of your insider threat risks.