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 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.

Code42-Tips-from-the-Trenches-Searching-Files-in-the-Cloud

Tips From the Trenches: Searching Files in the Cloud

In a few of my previous blogs, I shared some examples of ways the Code42 security team uses Code42 Forensic File Search to find interesting files — macro-enabled Microsoft Office files, known malicious MD5 hashes and so on. Now that the search capabilities of our newest product have been extended beyond endpoints to include cloud services, such as Google Drive and Microsoft OneDrive, I’d like to look at how we’re using this broadened visibility in our investigations.

“ Because we can now use Code42 Forensic File Search to search for files and file activity across both endpoints and Google Drive, we can be more certain of the locations of sensitive files when we are doing file movement investigations. ”

Finding files – and tracking file movement – in the cloud

Code42 uses Google Drive as a cloud collaboration platform. Because we can now use Code42 Forensic File Search to search for files and file activity across both endpoints and Google Drive, we can be more certain of the locations of sensitive files when we are doing file movement investigations. We combine Code42 Forensic File Search with the Code42 File Exfiltration Detection solution to execute an advanced search — using a given MD5 hash — to find files that have been moved to a USB drive. This allows us to quickly build a complete picture of where a file exists in our environment — and how it may have moved from someone’s laptop to the cloud and back.

What files are shared externally?

Using the latest version of Code42 Forensic File Search, we can also search files based on their sharing status. For example, in a matter of a few seconds, we can search for all Google Drive documents that are shared with non-Code42 users. This shows us all documents that have been intentionally or inadvertently shared outside of the company. A deeper look at this list helps us identify any information that has been shared inappropriately. As with all searches within Code42 Forensic File Search, these investigations take only a few seconds to complete.

Here’s a hypothetical example: Let’s say the organization was pursuing an M&A opportunity and we wanted to make sure that confidential evaluation documents weren’t being shared improperly. We could use Code42 Forensic File Search to pull up a list of all documents shared externally. Should that list contain one of the confidential M&A evaluation documents, we could look more closely to determine if any inappropriate sharing occurred.

Continually finding new use cases

Code42’s ffs-tools repository on GitHub now includes several new searches that take advantage of our new cloud capabilities. You can find them all here.

Like most organizations, we use many cloud services to perform our day-to-day work. That’s why in the near future, we plan to expand the search capabilities of Code42 Forensic File Search across even more cloud services — giving you even greater visibility into the ideas and data your organization creates, no matter where they live and move.

Happy threat hunting!

7 Steps to Real-Time File Exfiltration Detection (Video)

This year’s Verizon Data Breach Investigations Report (DBIR) came out a few weeks ago, and — surprise, surprise — insider threat remains one of the biggest problems for enterprise data security. Looking at the DBIR, there are all the usual data exfiltration suspects: Most are so-called “inadvertent insiders” and a few are malicious insiders or malicious outsiders using stolen credentials. All of these attackers are acting with complete authorization, so their activities tend to fly under the radar — not tripping any of the traditional data security alarms — until it’s far too late. In fact, Verizon found that the vast majority (68 percent) of insider data loss events take a month or more for the organization to discover.

See file exfiltration in real-time

With Code42 deployed in your environment, you have a powerful tool for recognizing suspicious file exfiltration activity by authorized users. Code42’s File Exfiltration Detection solution enables you to set a threshold to alert you if users move more than a typical amount of files to an external location — whether copying them to a removable storage device or uploading them to a cloud service.

Code42’s File Exfiltration Detection solution in action

Here’s how File Exfiltration Detection could help you detect and respond to a disgruntled employee’s malicious attempt to steal your IP:

  1. Set the threshold. From the Code42 web console, set the File Exfiltration Detection threshold at 10 files or 50 MB.
  2. Alert! An email notification tells you that a user recently moved more than 200 MB of data to a third-party cloud service account, such as Microsoft OneDrive or Google Drive.
  3. Confirm. Clicking the email link brings you back to the Code42 web console, where you can see the details of the user’s suspicious activity. For example, you can view a historical perspective of the user’s cloud service activity to see that, yes, this is a highly unusual event.
  4. Investigate. Dig deeper by exporting a CSV file that shows detailed information on all the files included in this mass exfiltration. The CSV includes each file’s name and MD5 hash as well as details on where the files were moved and when.
  5. Unzip the zip. Let’s say the malicious insider attempted to hide photos and videos of proprietary manufacturing processes in a large, innocent-sounding zip file: “cat videos.zip.” You can use the Code42 Backup + Restore solution to download that zip file and reveal its true contents.
  6. Track the source. What if the malicious actor tried to hide his tracks by renaming and/or modifying the original files? Because File Exfiltration Detection provides the MD5 hash of all the exfiltrated files, you can use Code42 Forensic File Search to search your entire environment for the MD5 hashes. This lets you track the modified or renamed file back to its source.
  7. Take action — faster. Between the real-time alert from File Exfiltration Detection, the complete data visibility from Code42 Backup + Restore and the instant file search capabilities of Code42 Forensic File Search, this entire investigation took less than an hour. You know the event happened. You know who did it. And you have a huge head start on stopping the malicious actor before more sensitive data gets out of your control.
Code42 Forensic File Search: from Endpoints to the Cloud

Code42 Forensic File Search: from Endpoints to the Cloud

Think of your favorite bank heist movie. Ocean’s Eleven, The Italian Job, Die Hard — they all revolve around elaborate schemes to evade and overcome security: guards, metal detectors, badge and lock systems, and the imposing physical safe itself. It happens in real life, too. Thousands of bank robberies are reported to the FBI every year.

Now imagine you’re a bank manager and someone breaks into your safe. What’s one of the first things you’ll do? Look at your security camera footage. These recordings are the fastest and most reliable way to see what happened, who did it and what they took — so you don’t waste another precious minute while the thieves are making their getaway.

“ Now, we’re expanding the powerful investigation capabilities of Code42 Forensic File Search to follow your files into the cloud — starting with Microsoft OneDrive and Google Drive. ”

Code42 Forensic File Search: your cyber security camera

Today, organizations have a wide array of sophisticated cyber security tools designed to prevent and mitigate data loss. But any security pro who is being honest knows it’s a question of when a data breach will happen, not if. When a data loss event occurs, Code42 Forensic File Search is like a security camera for your entire digital environment. With Code42 Forensic File Search, you can “go to the tapes” to see exactly what happened, who was involved, what was taken and where it went. Code42 Forensic File Search is simply the quickest, most effective way to jumpstart your investigation efforts — so you can get your valuable assets back sooner.

Code42 Forensic File Search expands from endpoints to the cloud

We’re constantly looking for new ways to give businesses and security teams greater visibility to their data. We’ve pioneered capabilities that have brought unprecedented visibility to users’ endpoint devices. Now, we’re expanding the powerful investigation capabilities of Code42 Forensic File Search to follow your files into the cloud — starting with Microsoft OneDrive and Google Drive, and adding other leading cloud services platforms, like Box and Slack, in the near future.

Find any file, no matter where it lives — in seconds

As more and more enterprise workflows touch the cloud, there is a growing technology disconnect for security teams. There are tools that give them visibility to data that lives on-premises and on endpoint devices; and there are separate CASB tools that provide visibility to data that lives in cloud accounts. Code42 has bridged that gap by extending Code42 Forensic File Search to cover cloud services. That means you’ll now be able to use the product to easily and instantly search across your entire environment: your users’ endpoint devices and enterprise cloud accounts — whether users are online or offline.

You no longer need to spend weeks sifting through piles of data from multiple tools. Now you have a simple search bar that allows you to “go to the tapes” to find any file, no matter where it lives and moves — in seconds.

Tips from the Trenches: Multi-Tier Logging

Tips From the Trenches: Multi-Tier Logging

Here’s a stat to make your head spin: Gartner says that a medium-sized enterprise creates 20,000 messages of operational data in activity logs every second. That adds up to 500 million messages — more than 150 GB of data — every day. In other words, as security professionals, we all have logs. A lot of logs. So, how do we know if our log collection strategy is effectively meeting our logging requirements? Unfortunately, a one-size-fits-all logging solution doesn’t exist, so many leading security teams have adopted a multi-tier logging approach. There are three steps to implementing a multi-tier logging strategy:

“ A one-size-fits-all logging solution doesn’t exist, so many leading security teams have adopted a multi-tier logging approach. ”

1. Analyze your logging requirements

A multi-tier logging strategy starts with analyzing your logging requirements. Here’s a simple checklist that I’ve used for this:

Who requires access to the organization’s logs?

  • Which teams require access?
  • Is there unnecessary duplication of logs?
  • Can we consolidate logs and logging budgets across departments?

What logging solutions do we currently have in place?

  • What is the current health of our logging systems?
  • Are we receiving all required logs?
  • Have we included all required log source types?
    • Do we need public cloud, private cloud, hybrid cloud and/or SaaS logs?
  • How many events per second (EPS) are we receiving?
  • How much log storage (in gigabytes) are we using now?
  • What are our logs of interest?
    • Create alerts and/or reports to monitor for each.

What time zone strategy will you use for logging? 

  • How many locations are in different time zones across the organization?
  • Will you use a single time zone or multiple time zone logging strategy?

How much storage capacity will be needed for logging for the next 3-5 years?

Do we have a log baseline in place?

  • Where are our logs stored now?
  • Where should they be stored in the future?

Are we collecting logs for troubleshooting, security analysis and/or compliance?

  • What are our compliance requirements?
    • Do we have log storage redundancy requirements?
    • What are our log retention requirements?
    • Do we have log retention requirements defined in official policy?
  • What logs do we really need to keep?
    • Identify those that are useful.
    • Drop those that are not.

2. Digest log information

After all of this information is gathered, it’s time to digest it. It’s important to align your logging infrastructure to log type and retention needs — so you don’t end up inserting a large amount of unstructured data that you will need to be able to quickly search in an SQL database, for example. Most organizations have multiple clouds, many different devices that generate different log types and separate required analysis methods. In other words, one solution usually does not meet all logging needs.

3. Implement multi-tier logging

If, after analyzing your logging requirements, you find that one logging strategy does not meet all of your requirements, consider this tiered logging flow:

Code42 Tiered Logging Flow Example

In this example logging flow, there are three different logging flow types and five different log repositories. There are SIEM logs, application logs and system log flow types. The repositories are the SIEM database, ELK (elasticsearch, logstash and kibana) stack, two long-term syslog archival servers and cloud storage. The repositories each have a unique role:

  • The SIEM correlates logs with known threats.
  • The ELK stack retains approximately 30-60 days of logs for very fast searching capabilities.
  • The two syslog archival servers store the last three to seven years of syslog and application logs for historical and regulatory purposes. One syslog archival server is used for processing logs, the other is a limited-touch, master log repository.
  • Cloud storage also stores the last three to seven years of logs for historical and regulatory purposes.

Simplify your log activity

This is just one quick example of an innovative solution to simplifying log activity. Regardless of whether multi-tier logging is the right solution for your organization, the most critical step is making sure you have a clearly defined logging strategy and an accurate baseline of your current logging state. This basic analysis gives you the understanding and insights you need to simplify log activity — making it easier to accomplish the complex logging goals of your organization.

Using “Honey Files” to Stop Data Exfiltration (Video)

The honeypot is a simple security concept: something so sweet and enticing that the “bad guy” just can’t help but walk right into your trap. In the world of data security, honeypots are typically systems or resources that appear legitimate, but are actually isolated and monitored. Honeypots have been around for almost 30 years, but they’re enjoying a recent resurgence. As security teams increasingly realize that they can’t completely prevent malicious actions, the honeypot gives them a tool to identify who the malicious actors are, how they’re working and what they’re doing.

Creating a “honey file” to track malicious insiders

The honeypot concept is hardest to apply for data exfiltration, insider threat and other events where the malicious actor has authorized access to the network or resource. Fortunately, Code42 Forensic File Search enables a new type of lure: the honey file, a single, attractive (but not actually valuable) file that a security team can use to identify and track malicious insiders. Here’s how a honey file workflow would look:

  1. The security team places a honey file — in this case an Excel file named “employee salary data 2018.xlsx” — in a shared OneDrive account. The security team knows both the file name and MD5 hash.
  2. After a few days or weeks, the security team can log onto the Code42 web console and use Code42 Forensic File Search to execute a simple search for the file’s MD5 hash.
  3. The search results show any traces of the original honey file on any user or host in your environment.
  4. Digging into the search results, the security team can not only see who touched the honey file, but also what that person did with it. For example, if a user copies the honey file, renames it and then deletes the original in an attempt to cover his tracks, every step in this “coverup” is able to be seen through Code42 Forensic File Search.
  5. Using this insight, the security team can quickly take steps to investigate and remediate effectively.

“ Digging into the search results, the security team can not only see who touched the honey file, but also what that person did with it. ”

Watch the video above to see how to create a honey file and track data exfiltration with Code42 Forensic File Search.

The Synergy of SIEM and Code42

I’ve been a user of security information and event management (SIEM) software for over a decade now. I loved it back in 2006, and it’s been incredible to watch SIEM tools evolve into a data security tool category that brings together a powerful community of administrators and a rich ecosystem of vendors, integrators and enhancements that continue to redefine adaptive response.

When I joined Code42, I was pleased to see that the company was already partnering with SIEM providers. Together, we are providing our customers an even more expanded view into the data that is living on their devices.

Code42 + SIEM: We’re both in the business of business resiliency

Code42 has always been a natural complement to SIEM solutions — and vice versa. In fact, to a large extent, Code42 and SIEM software share the same goals:

  • Securing your digital environment and protecting your data.
  • Monitoring activities in your environment and detecting threats —whether it’s an external attack or an insider threat.
  • Ensuring resiliency through rapid incident response and guaranteed recovery.
  • Enabling advanced investigation and forensics.

Or, to put it simply: We both help you prevent bad things from happening to your data and your ideas — and if something bad does happen, we help you see it quickly and recover faster.

“ By integrating directly into your ecosystem and your SIEM, the same data auditing functions you use today can be applied to your Code42 solution. ”

A powerful integration for visualization

As SIEM technology has evolved, Code42’s ability to integrate into SIEM ecosystems has also grown, allowing you to take the comprehensive data collection and data visibility you get from Code42 and feed it into your analytics-driven SIEM tool.

What’s that really mean for you? Code42-specific dashboards within SIEM applications, so you can easily visualize some of the things that matter most, such as:

In other words, you get real-time feedback on how we’re protecting your information and any risks that exist. And by integrating directly into your ecosystem and your SIEM, the same data auditing functions you use today can be applied to your Code42 solution. Your existing alerting and workflow pipeline can drive the Code42 alerts. That means we’ve made it easier for you to get up and running, easier for you to stay secure and faster for you to respond to events.

  • Prioritizing alerts: Leverage your SIEM’s smart monitoring capabilities for an at-a-glance look at your most critical alerts — failed backups, server issues, data exfiltration, etc. — so you can prioritize action.
  • Validating backups: Get a real-time look at how many users, how many devices and how much data are covered by Code42.
  • Monitoring endpoint data storage: See exactly how much data is being stored in each device — so you can see if that number changes drastically or unexpectedly.
  • Classifying endpoint data: Know what kinds of files you’re backing up —how much of your storage is made up of Word docs, emails, Excel files, coding files, etc.

Synergistic visibility

Like any good partnership, this one’s all about synergy. In this case, it’s synergistic visibility (say that five times fast!). Code42 brings deeper visibility to SIEM applications, so the powerful tools can see all the data living on all your devices. And SIEM tools give you an intuitive visualization of Code42 —both how Code42 is protecting your data, and what your users are doing with your data. All that adds up to identifying risks sooner and enabling faster remediation, so you can keep risks from becoming irreparable damage. Together, we’re helping you make smarter, better decisions in less time.

Finding Malware that Prevention Tools Miss (Video)

Hunting for known malware

All security teams have their go-to industry intel sources for brand-new indicators of compromise (IOCs), and like you, we’re continually on the lookout for new threat intel tools to look for the footprints of malicious activity. But once you’ve identified a suspicious file or confirmed a malicious MD5 hash, the challenge for your security team is finding all the hosts in the organization that have the affected files. This kind of visibility is critical for mitigating any potential malware impacts, but it’s also critical to avoid wasting time cleaning uninfected hosts. Without this visibility, organizations are forced to take a “better safe than sorry” approach — and that leads to the frustrating situation where endpoint re-images or remediations are performed without knowing whether devices were actually infected.

A simple search bar changes everything

Security teams deal with questions — big and small — all day long. The simple search bar of Code42 Forensic File Search is a powerful tool for answering some of the most important questions, including, “Does known malware have a foothold in my environment?” But the usefulness of Code42 Forensic File Search isn’t limited to just finding malware. In the Code42 security team, we use Code42 Forensic File Search for malware investigations and monitoring. When our antivirus and EDR tools identify malware threats, we use Code42 Forensic File Search to validate those findings across the environment and dig deeper. After malware has been located on a device and remediated, we continue to monitor files on that device with Code42 Forensic File Search to ensure there are no further signs of infection.

With the ability to instantly search for known malicious MD5 hashes across every host in your environment, you can shave days off investigating and remediating malware events. More importantly, this complete, instant visibility gives you the assurance that you’ve identified and addressed the threat to the full extent.

Happy threat hunting!

Code42 13 Tips for Situational Awareness

Tips From the Trenches: 13 Situational Awareness Questions

A key aspect of responding to security events is situational awareness: knowing what is happening in your environment and why. Standard data security tools like firewalls, proxies, email filters, anti-virus reports and SIEM alerts are all common sources of data for situational awareness. However, it’s also important to have visibility into business operations. Only with a holistic view of your entire organization can you have true situational awareness.

For example, as a software company, writing and deploying software is a significant and complex part of our business operations. Naturally, this work is supported by development, test and staging environments, which are used by our engineers to create and test product features. Security teams need to be aware of all non-production environments in their organizations. Open non-production environments (or environments that re-use credentials between production and non-production systems) can be a vulnerability that attackers can exploit.

“ No matter what business your organization is in, you should know where your important data can be found as well as what activities are normal and what is not normal. ”

Asking questions is the key to knowledge. Here are 13 questions I have used to help paint a full view of internal operations at Code42. They are divided into four separate categories based on major categories of concern for most organizations. I hope they will help you improve your situational awareness and overall data security.

Development Environments:

  1. Where are your development environments?
  2. Do you have the appropriate level of logging in those environments?
  3. How is access handled and are there controls that prevent the reuse of credentials across environments?
  4. Are there forgotten dev environments that need to be cleaned up?

Build Process:

  1. Where is your code built?
  2. Where is your code stored?
  3. If somebody maliciously inserted code into your environment, would you be able to detect who, when and what?
  4. Where are your build/CICD servers?

Deployments:

  1. Do you know what your typical deploy schedule is?
  2. Are you involved in the change management process and other governance bodies so you know when major changes are occurring in your environment?

Decommissioning:

  1. What systems and environments are going away?
  2. Is there a plan to keep information such as logs from those environments after the environment itself goes away, in accordance with your data retention policies?
  3. Will any infrastructure be reused, and if so, has it been processed properly?

While these questions are specific to software development and deployment, the data security issues they raise are relevant to businesses of all types. No matter what business your organization is in, you should know where your important data can be found as well as what activities are normal and what is not normal. Ensuring that tools are in place to answer these questions is vital.

Here’s one tool I use to answer these questions in our environment: Code42 Forensic File Search. It provides the visibility I need into all activity in our organization. With it, we can quickly and accurately take stock of data movement, data security risks and countless other activities. It makes it easier and faster to know what is happening in our environment and why. It provides the situational awareness that is critical for any modern organization.

Until next time, happy threat hunting!

Finding Rogue Software in Your Organization (Video)

There are many reasons you may want to locate particular software in your organization. Sometimes it’s because you are trying to catch someone doing something malicious, but sometimes it’s because employees are trying to work around processes to get work done. For example, many employees install software that isn’t yet approved by their company’s IT and security teams.

A true story: MacOS version control

Here’s a true story from Code42’s own IT team about MacOS version control. Code42 blocks the installation of the latest version of MacOS on employees’ laptops until it has been fully tested. While we don’t expect to see any security risks in the newest release, we also don’t want employees running unsupported or untested software. Once upgraded, MacOS can’t be reverted back to the older version—so untested installations are hard to correct.

The Code42 IT team knows when an employee figures out a way to circumvent their endpoint management system’s security controls to download the new version of MacOS. They know this because they’re able to locate the installer on employee endpoints with Code42 Forensic File Search.

A simple search, clear results

Many endpoint management systems block file installation based simply on filename. When the installer file is renamed, the program in question can be downloaded and the endpoint management system won’t catch it. However, Code42 Forensic File Search gives you the ability to search by MD5 hash. If you suspect that employees in your organization are downloading a particular program, you can search for the MD5 hash of the program to find everywhere it exists in your organization, even if it has been renamed. Code42 Forensic File Search locates all instances of the file across all endpoints, even on endpoints that are offline.

“ If you suspect that employees in your organization are downloading a particular program, you can search for the MD5 hash of the program to find everywhere it exists in your organization, even if it has been renamed. ”

Human behavior affects everyone

We upgrade all of our Mac users to the latest version of MacOS as quickly as we can. If employees break policy and install MacOS early, we recognize that it’s not out of malice—they just want to have access to the best and most current tools. This is likely the case at your organization as well. As the 2018 Data Exposure Report explains, employees want to work in ways that make them more productive even if that means violating IT policy.

This could be true of anyone in your organization, from the most junior employee to the CEO. In fact, according to the report, 59 percent of CEOs admit to downloading software without knowing whether it is approved by corporate security. Seventy-seven percent of business leaders believe their IT department would view this behavior as a security risk, but they do it anyway. No wonder that the Data Exposure Report also found that 75 percent of CISOs and 74 percent of CEOs believe their security strategies need to change from prevention-only to prevention-and recovery-driven security.

With Code42 Forensic File Search, you have visibility into what’s happening in your organization that your prevention tools don’t see. You’ll never be able to convince 100 percent of your users to follow your IT and security policies, but you can quickly and accurately locate the rogue software they bring into your organization.

Facebook Twitter Google LinkedIn YouTube