Cybersecurity Insights

Today is the first day of National Cybersecurity Awareness Month, an appropriate occasion to review some of the most important lessons that industry organizations should have learned as they strive to maintain a holistic cyber-risk mitigation program that their leadership can trust. Based on more than two decades of shaping the landscape of cybersecurity solutions, here are a few of the consensus insights we have gleaned.

Cybersecurity requires more than a nod of approval from the C-suite.

A bottom-up approach to cybersecurity, often originating in the IT security shop, is common. But securing C-suite buy-in after the fact can be a struggle. In today’s environment where a robust cybersecurity risk management program is essential to the ongoing viability of an organization, the drivers must be at the top. Moreover, cybersecurity must be a consensus priority for all elements of leadership, starting with the CEO but vitally including the CIO, CISO, CTO, CFO and the top legal and risk-management leaders in the organization. And because a holistic approach involves people and process as well (see below for more on that), HR must be on board. Since a cyber attack can impact the organization’s systems, finances, people, facilities and even reputation, it really is a matter of all C-suite hands on deck.

Cyber-hygiene is not enough.

Most cybersecurity efforts have focused on cyber ‘hygiene’ through compliance with a set of recommended but unenforceable standards. Rather than checking boxes, however, what’s really needed is a holistic risk framework that is much more analytically sound and scientifically grounded — in other words, a solid commitment to risk-based assessments and responses — in order to accurately understand and prevent the most serious cybersecurity threats. Security teams should ask important questions like “which threats are most likely to occur?” and “what are our greatest vulnerabilities?” Translating these into business terms is key, and measuring them so that risks and countermeasures can be prioritized is essential.

Network data is not enough. 

Many organizations are still trying to detect their biggest external and internal threats based mainly on network logging and aggregation. But the fact is that the earliest indicators of such threats lie in human actions and attitudes. Thus, security teams that are proactive and focused on data-driven cybersecurity need to find ways of bringing in more unstructured data from unconventional sources that will reveal behaviors well in advance of an actual event. After all, you can’t discipline or fire an end-point.

Technology alone is not the solution.

To hear many security vendors tell it, they’ve already developed the perfect all-encompassing cybersecurity solution. The reality, however, is that a truly holistic cyber-risk management program requires a well-thought-out and coordinated set of protocols and routines that encompass people, process and technology. No tool on its own will protect an organization if the server room door is left unlocked, or if the staff isn’t vigilant to avoid clicking on a suspicious email. Continuous training and education, along with easily understood policies implemented from the top down with no exceptions, are just as critical as the best firewall or SIEM tool.

Enterprise security teams responsible for preventing insider threats have mixed feelings about acquiring and analyzing internal data. Sure, that data contains a wealth of knowledge about the potential for risk from trusted employees, contractors, vendors and customers. But it also comes with a mountain of legal and organizational headaches, can be contradictory and often generates more questions than answers. No wonder most security programs prefer to rely on monitoring network logs.

But there’s a more methodical way for organizations to approach data acquisition and analysis: before diving into the arduous task of trying to work with the data theyhave, it’s better to first ask what problems they want to solve — and let the answers guide them down the path of obtaining the data they need.

One effective mechanism for carrying out this sequence is to build a model of the problem domain and then go find relevant data to apply to it. At Haystax, we collaborate with diverse subject-matter experts to build probabilistic models known as Bayesian inference networks, which excel at assessing probabilities in complex problem domains where the data is incomplete or even contradictory.

Our user behavior analytics (UBA) model, for example, was developed to detect individuals who show an inclination to commit or abet a variety of malicious insider acts, including: leaving a firm or agency with stolen files or selling the information illegally; committing fraud; sabotaging an organization’s reputation, IT systems or facilities; and committing acts of workplace violence or self-harm. It also can identify indicators of willful negligence (rule flouting, careless attitudes to security, etc.) and unwitting or accidental behavior (human error, fatigue, substance abuse, etc.) that could jeopardize an organization’s security.

The UBA model starts with a top-level hypothesis that an individual is trustworthy, followed by high-level concepts relating to personal trustworthiness such as reliability, stability, credibility and conscientiousness. It then breaks these concepts down into smaller and smaller sub-concepts until they become causal indicators that are measurable in data. Finally, it captures not only the relationships between each concept, but also the relative strength of each relationship.

Sitting at the core of Haystax’s Constellation Analytics Platform, this UBA model provides the structure our customers need to: 1) pinpoint which of their data sets can be most usefully applied to the model; 2) identify any critical data gaps they may have; and 3) ignore data that’s unlikely to be useful. Most importantly, it enables security teams to assess workplace risk in a holistic and predictive way as the individual’s adverse behaviors are starting to manifest themselves — rather than after a major adverse event has taken place.

Data relevant to insider threat mitigation can be categorized as financial, professional, legal and personal. Within these categories are two main data types: static and dynamic:

• Static data is typically used for identifying major life events, and can establish a baseline for what ‘normal’ behavior looks like for that individual. This type of data isn’t updated frequently, so there may be longer periods of time with no new information.
• Dynamic data is updated on the order of hours or days and is the source of detection for smaller, less obvious life and behavioral changes in an individual. For example, there may be a record of marriage (large life event; static data) and a recent vacation for two (smaller life event; dynamic data) indicating a healthy and stable home life.

Ideally, organizations have some of each data type to establish baselines and then maintain day-to-day situational awareness.

Another important part of the data identification and acquisition process is accessibility. There are three levels of data accessibility to consider: public, organizational or protected/private:

• Public data is readily available from open external sources.
• Organizational data is managed internally by a company or government agency and can be obtained if a compelling case is made.
• Protected/private data is mostly controlled by individuals or third-party entities and is difficult to access without their consent.

The table below contains a detailed list of data sources broken down by category and accessibility level, and by whether it’s static or dynamic.

UBA industry analysts at Gartner have observed that incorporating unstructured information like performance appraisals, travel records and social media posts “can be extremely useful in helping discover and score risky user behavior,” because it provides far better context than structured data from networks and the like. (And with more and more network data being encrypted, pulling threat signals from network logs is in any case becoming increasingly challenging.)

There are dozens of behavioral indicators for which supporting data is available or obtainable, and which can be readily ingested, augmented, applied and analyzed within the Constellation UBA solution. Take the case of a senior-level insider who intends to steal a large volume of his company’s intellectual property (IP). An early risk indicator is that he comes into the office at an odd time (badge records), accesses a file directory he is normally not privy to (network data) and prints out a large document (printer logs). This activity alone would not trigger an alert in Constellation, as it could be that he was assigned a new project with a tight deadline by a different department.

But then data is obtained which reveals that he is experiencing financial or personal stress (public bankruptcy/divorce records), leading to degraded work performance (poor supervisor reviews) and several tense confrontations with colleagues (staff complaints), all of which will elevate him in Constellation to a moderate risk. Finally, he is caught posting a derisive rant about the company on social media (public data) and either contacting a competitor (email/phone logs) or booking a one-way ticket to another country (travel records). This activity elevates him to high-risk status in Constellation and he is put on a watch list, so that when rumors spread of pending departmental layoffs (HR plans) and the company detects him downloading large files to a thumb drive (DLP alert), the company’s security team is ready to act.

October is National Cybersecurity Awareness Month in the US. In the months leading up to it, technology and security experts have increasingly come to the consensus view that while insider threats constitute one of the fastest-growing risks to the IT and physical security environments, organizations don’t have the analytical tools — or the data —to pinpoint their biggest threats in a timely way.

The reality is that most organizations today still try to detect their insider threats by analyzing log aggregation files, and not much else. Because they invariably end up with an excessive number of false positives and redundant alerts, their analysts often feel overwhelmed trying to triage their cases and waste precious time chasing down contextual information to verify what’s real and what is not.

By contrast, Haystax’s approach with its Constellation UBA solution is to apply a much larger volume and variety of data to a probabilistic behavioral risk model, which then continuously updates its ‘belief’ that each employee is trustworthy (or not). With Constellation — and a broader array of data sources — a security team can perform true cyber-risk management, avoiding alert overload and focusing instead on quickly and proactively identifying those individuals who are poised to do the most harm to the enterprise.

Hannah Hein is Insider Threat Project Manager at Haystax Technology.

If you’ve ever questioned whether your SOC team is missing things or your MSSP is keeping up, you’re not alone. That’s why SOAR (Security Orchestration Automation and Response) is gaining popularity fast.

It’s an easy way to do more with less.

“Our experts deliver a force multiplier for your overworked analyst teams,” says Fishtech CISO Eric Foster.

The question of controlling access to an organization’s data and systems comes up often in our conversations with customers. Recently we had another customer ask how to ensure that devices being used to access their cloud environment met their security requirements.

While there are several ways to address that issue, one of the technical solutions we did some digging on was Microsoft’s Conditional Access solution that is part of Azure AD and Intune.

What follows below are some of the key findings we uncovered in configuring Microsoft Conditional Access via Intune.

Licensing Model(s)

While there are several ways to gain access to Conditional Access functionality within the Microsoft cloud platform, we decided to go down the Intune route.

This is because we wanted to be able to apply access policies based on different aspects of the device which in the Microsoft world means Intune is needed.

In addition, Intune provides ways to manage other aspects of both mobile and laptop/desktop devices which is a bonus.

So in order to get the functionality of Intune and Conditional Access you will need to look at Microsoft’s Enterprise Mobility + Security (EMS) offerings. The licensing models break down like this:

• EMS E3
  • Intune
  • Azure AD Premium P1
  • Azure Information Protection P1
  • Advanced Threat Analytics
• EMS E5
  • Intune
  • Azure AD Premium P2
  • Azure Information Protection P2
  • Advanced Threat Analytics
  • Cloud App Security
  • Azure Advanced Threat Protection

For the purposes of this article the minimum level needed is EMS E3 which adds Conditional Access functionality. Not to be confusing (yeah right), but in order to get ‘Risk-based Conditional Access’ the top level EMS E5 subscription is needed.

The primary difference between Conditional Access and Risk-based Conditional Access is that Conditional Access allows policies to be built based on User/Location, Device, and Application criteria while Risk-based Conditional Access adds Microsoft’s Intelligent Security Graph and machine learning to create a more dynamic risk profile to control access.

A final point about licensing. It is complex. Get your Microsoft contact involved to help figure out the licensing details for specific situations because there are many paths to the same destination.

Setting up Conditional Access

In order to configure a Conditional Access policy, there are a few pre-requisites that need to be configured. The specifics of configuring those pre-requisites is beyond the scope of this article, but the broad strokes are that you have properly set up and configured your azure account, Azure AD, and Intune.

This includes ensuring you have some Azure AD users and groups defined that policies can be applied to. Again, this is an oversimplification so my apologies if I left major pieces out.

Now we move into actually creating a Conditional Access policy. Fair warning, I will not cover every possible scenario. Instead, I will try to convey the major concepts and features of a Conditional Access policy as well as any gotchas I came across.

Open up your Azure portal and navigate to Intune>Conditional Access

Note: You can also find Conditional Access by navigating to Azure Active Directory>Conditional Access. In fact, this may be the better route to go because this path exposes additional options that you won’t find by navigating there via Intune.

For example, in the Azure AD Conditional Access portal you can create custom controls using JSON. You can also define named locations, VPN connectivity, terms of service.

In the right-hand pane, click + New Policy and a new policy window will open.

The two main sections of a Conditional Access policy are ‘Assignments’ and ‘Access Controls’

Assignments:

• Users and Groups
  • Select the users and/or groups the policy will be applied to.
• Cloud Apps
  • Select the Cloud Apps to be covered by the policy. O386 apps are available by default. Others can be added as needed (beyond the scope of this article)
• Conditions
  • The conditions under which the policy will apply.
  • The four condition areas are
    • sign-in risk (Requires the EMS E5 plan I believe)
    • Device platforms (ios, windows, android, etc.)
    • Locations (requires configuring locations in Azure Portal)
    • Client Apps (browser or client app)

Access Controls

• Grant (block or grant access based on additional criteria)
  • Require multi-factor authentication
  • Require device to be marked as compliant (more on this below)
  • Require domain joined
  • Require approved client app
• Session
  • App enforced (in preview release)
  • Proxy enforced (in preview release)

Once these sections have been completed the policy just needs to be enabled to take effect.

A word about Device Compliance

In order to select the ‘Require device to be marked as compliant’ option in the Grant section of an Access Control policy, you will need to create a Device compliance policy (or several depending on your needs). Device Compliance policies are pretty much what they sound like.

A set rules that indicate whether a managed device complies with your organization’s requirements. Depending on whether the device in question does or does not meet the compliance policy, it will be marked as either ‘Compliant’ or ‘Not Compliant’.

For a device compliance policy to work on a given device, it must be managed by Intune. It is beyond the scope of this article to get into the details of how devices are enrolled and managed in Intune, but at a high-level Intune can manage both personally owned and corporate owned devices.

To create a Device Compliance policy open up your Azure portal and navigate to Intune>Device Compliance >Policies and click “+ Create Policy”.

After entering a Name and selecting a platform to apply the policy to, click on Settings>Configure.

The policy settings have three categories of configuration. Note: The number of options under each category will change based on the OS platform that was selected.

• Device Health (settings vary based on OS. Examples for Win10 include Require BitLocker and Require code integrity)
• Device Properties (settings vary based on OS. Examples for Win10 include Minimum OS version and Maximum OS version)
• System Security (settings vary based on OS. Examples for Win10 include Require a password to unlock device and block simple passwords)

Once the policy is created, it must be assigned. Click on ‘Assignments’ and choose either a group or ‘All Users’. Warning, it is not recommended to apply policies to all users as there could be unintended consequences. The main point is to know who you are applying policies to so as to minimize surprises.

Now that a compliance policy has been applied it will require a check-in by the targeted user’s device(s) so that the device can run the compliance scan and return a compliant/not compliant result. This compliance assessment can then be used in a Conditional Access policy as described in the previous section.

Final thoughts

In wrapping all of this up there are a few things to keep in mind. First, the licensing aspect of Intune/Conditional Access is unclear from a non-employee standpoint. So for anyone looking to use Microsoft’s Conditional Access to address non-employee scenarios, further digging will be required.

Second, while it may seem mind-numbingly obvious, organizations that are already invested in Azure AD and O365 should take a serious look at Microsoft’s Conditional Access. With the proliferation of security tools in the market, it is sadly true that many organizations continue purchasing more tools when they may already have an adequate solution in hand.

In addition, Microsoft is taking cloud security very seriously and from what I can tell will continue to invest in improving their security solutions.

Related Links:

• Intune/EMS Subscription Levels
• Microsoft Conditional Access 
• Integrating Threat Defense to Intune for compliance policies