Security at Your Service

Part 2 of a series

By 2021, experts predict we’ll see 3.5 million open cybersecurity positions worldwide, with at least 500,000 of those unfilled jobs in the U.S. alone. That’s more than triple the shortfall that existed just two years ago. Meanwhile cyber-attacks are growing in scale and impact.

What’s an industry to do? Clearly, fixing the cybersecurity pipeline is an imperative, and it won’t be a simple fix.

Today’s talent shortage is similar to the run-up to 2000 with the dot-com bubble, says Eric Foster, COO of CYDERES, the Security-as-a-Service division of Fishtech Group. Then, most colleges couldn’t keep up with workforce demand for programmers, and many IT degrees didn’t have the right technologies or skills.

Today, while schools such as Carnegie Mellon and Stanford offer exceptional cybersecurity programs, programs more broadly are missing the mark, he said.

“IT, and especially cybersecurity, tend to move fast, and you can’t set a curriculum on specific technologies and have that be good for four, five, let alone 10 years,” he said. “We are finding a lot of times what [graduates] are learning in those cybersecurity programs may or may not be relevant to the current, real world cybersecurity.”

To bridge the gap and cultivate the next generation of IT talent, Fishtech and others are exploring an old school idea: formalized apprenticeships.

Read the complete article here.

Eric Ullmann, Director of Enterprise Architecture

At some point, most organizations realize that they are not in the business of IT. In order to return focus to their core business, be it airplanes or higher education or healthcare, the efficiencies and benefits of the public cloud make a ton of sense. But that doesn’t mean the C-suite always knows where to start. Here are a couple of questions to ask when moving to the cloud, or upgrading your AWS/Azure/GCP program.

Migration: How will you use the cloud?

In the cloud, everything becomes infrastructure as code. This can become challenging for organizations and requires a mindset change. Many organizations will take a lift and shift approach but this does not allow the organization to take full advantage of efficiencies that can be realized from the public cloud. In addition, security is now implied in everything we do. In order to remain secure in a cloud operating model, security teams must inject security controls into the CI/CD pipeline. Traditional approaches are no longer effective and applications need to be de-coupled to work effectively in a cloud model.

What does that mean? It means fully taking advantage of a cloud that offers elasticity and scalability for every use-case. Applications should be redesigned dynamically to be able to function differently, work differently, and react differently to everything that happens, and present it differently to the end user.

The problem with this whole scenario is every org sees the value-add of going to a public cloud or a hybrid (which is really a mixture of your private environment and your public cloud), but often don’t understand the available resources that, at best, are limiting their potential and, at worse, become a huge security liability. Every org sees the advantage of the cost savings, the faster go-to-market strategies, etc, but need to be careful how they formulate and execute their cloud strategy. (Example: GCP’s cloud technology itself is not new, it’s everything that Google used to build Search a decade ago, but now they’ve open-sourced it and given it to the community. Taking advantage of that intel offers huge potential!)

All of these tools are available, but how do we use them? And then how does security come into play?

Fishtech’s cloud enablement services might mean strategizing a full-blown migration — moving an org’s primary data center to a cloud approach. And using an advisory approach, we ask questions like:

1. How are we going to get there? We have to get an understanding of what it’s going to look like from a security perspective.
2. What controls need to be put in place?
3. What does the migration strategy look like from an operational standpoint? While we don’t normally have our hands on the keyboard for this, we can if necessary.

Enablement: How do we mature a cloud program?

What happens when our client is already in the cloud? If an org has its primary data center and is already using resources in AWS or Azure, then we explore readiness or enablement. We say, “Hey let’s evaluate and figure out where you are and how you can take better advantage of security automation, Infrastructure as a code, and other Cloud benefits. Perhaps you are already doing well in these areas, but let us show you more.” Our advisors look at the entire infrastructure in real time and figure out how it’s being used to then develop a strategy to mature it.

Strategy: What are your ultimate business objectives?

Fishtech will look at governance, not merely in the traditional sense of compliance, but rather how do we actually govern inside that environment. We want to govern that environment so we can allow automation to occur without hindering any process.

We believe a core component of DevSecOps is that security is everyone’s responsibility. That means a security engineer no longer has to have their hands on the keyboard. A developer can actually do the same thing! Because of this new governance strategy, the security team will now have the process in place to build the framework, or guardrails, to enable the environment without hindering it.

During the build process, we test in run time. The developer builds an application and it goes through a testing period where we can ask — is X (scenario or result) happening? DevSecOps takes the same approach and throws security in there. We can automate the application security program, and if it fails, we have the processes in place to shoot it back. Everything is logged so the developer gets notified, is able to fix the problem, and it then goes out again. This process never stops; we just integrate everything into the process. This is the ultimate objective – to be able to continually iterate with security in mind every step of the way.

Next Steps: Where to Start

In summary, for organizations who want to move all their data or just an application or service to the cloud, understanding your business objectives will help you formulate a strategy on how you will use the cloud.

Becoming less popular is the idea of “lift and shift” where companies say “I want to just get up there first. I might just do DR (disaster recovery) up there, to learn the environment, and then I move everything over later.” Lift and shift is a common approach and a lot of companies do it. Cloud companies love it because there’s a lot of money heading their way, but in reality it’s never effective.

Why? Because orgs often fail moving over and not fail back correctly, and then have to redo everything all over again.

Every organization is different, with different objectives, goals, and outcomes desired.

It’s worthwhile to consider having a trusted cloud security expert assess your current state and draw up a plan to move to the cloud or upgrade your existing infrastructure while getting rid of excess, saving money, and optimizing business objectives.

Ready to move or upgrade your cloud? Take advantage of special year-end discounts and let our trusted advisors help secure your 2019 and beyond.

Organizations with established insider threat detection programs often deploy security solutions that are optimized to perform network log monitoring and aggregation, which makes sense given that these systems excel at identifying anomalous activity outside an employee’s typical routine — such as printing from an unfamiliar printer, accessing sensitive files, emailing a competitor, visiting prohibited websites or inserting a thumb drive without proper authorization.

But sole reliance on anomaly detection using network-focused security tools has several critical drawbacks. First, few organizations have the analytic resources to manage the excessive number of alerts they generate. They also can’t inherently provide any related ground truths that might provide the context to quickly ‘explain away’ the obvious false positives. And they leverage primarily host and network activity data, which doesn’t capture the underlying human behaviors that are the true early indicators of insider risk.

By their very nature, standalone network monitoring systems miss the large trove of insights that can be found in an organization’s non-network data. These additional information sources can include travel and expense records, on-boarding/off-boarding files, job applications and employment histories, incident reports, investigative case data and much more.

One such source that is often overlooked (and thus underutilized) is data from access control systems. Most employees have smart cards or key fobs that identify them and provide access to a building or a room, and their usage tells a richly detailed story of the routines and patterns of each badge-holder. They can also generate distinctive signals when employees deviate from their established norms.

Although not typically analyzed in conventional security analytics systems, badge data is a valuable source of context and insight in Haystax Technology’s Constellation for Insider Threat user behavior analytics (UBA) solution. Constellation ingests a wide array of information sources — badge data included — and analyzes the evidence they contain via an analytics platform that combines a probabilistic model with machine learning and other artificial intelligence techniques.

The Constellation model does the heavy analytical lifting, assessing anomalous behavior against the broader context of ‘whole-person trustworthiness’ to reason whether or not the behavior is indicative of risk. And because the model is a Bayesian inference network, it updates Constellation’s ‘belief’ in an individual’s level of trustworthiness every time new data is applied. The analytic results are displayed as a dynamic risk score for each individual in the system, allowing security analysts and decisionmakers to pinpoint their highest-priority risks.

In some cases, the badge data is applied directly to specific model nodes. In other cases, Haystax implements detectors that calculate the ‘unusualness’ of each new access event against a profile of overall access; only when an access event exceeds a certain threshold is it applied as evidence to the model. (We also consider the date the access event occurs, so that events which occurred long ago have a smaller impact than recent events. This so-called temporal decay is accomplished via a ‘relevance half-life’ function for each type of event.)

Besides the identity of the user, the time-stamp of the badge event is the minimum information required in order to glean insights from badge data. If an employee typically arrives around 9:00 AM each workday and leaves at 5:30 PM, then badging in at 6:00 AM on a Sunday will trigger an anomalous event. However, if the employee shows no other signs of adverse or questionable behavior, Constellation will of course note the anomaly but ‘reason’ that this behavior alone is not a significant event — one of the many ways it filters out the false positives that so often overwhelm analysts. The employee’s profile might even contain mitigating information that proves the early weekend hour was the result, say, of a new project assignment with a tight deadline. And the anomaly could be placed into further context with the use of another Constellation capability called peer-group analysis, which compares like individuals’ behaviors with each other rather than comparing one employee to the workforce at large.

But badge time-stamps tell only a small part of the story.

Now let’s look at insights that can be gleaned from other kinds of badge data.

Consider the case of Kara, a mid-level IT systems administrator employed at a large organization. Kara has privileged access and also a few anomalous badge times, so the Constellation ‘events’ generated from her badge data are a combination of [AccessAuthorized] and [UnusualAccessAuthorizedTime] (all events are displayed in green). But because Kara’s anomalous times are similar to those of her peers, nothing in her badge data significantly impacts her overall risk score in Constellation.

Kara’s employer uses a badge logging system that includes not just access times but also unsuccessful access attempts (aka, rejections). With this additional information, we find that Kara has significantly more access rejection events — [BadgeError] and [UnusualBadgeErrorTime] — than her peers, which implies that she is attempting to access areas she is not authorized to enter. Because there are other perfectly reasonable explanations for this behavior, we apply these anomalies as weak evidence to the [AccessesFacilityUnauthorized] model node (all nodes are displayed in red). And Constellation imposes a decay half-life of 14 days on these anomalous events, meaning that after two weeks their effect will be reduced by half.

Now let’s say that the employer’s badge system also logs the reason for the access rejection. For example, a pattern of lost or expired badges — [ExcessiveBadgeErrorLostOrExpired] — could imply that Kara is careless. Because losing or failing to renew a badge is a more serious indicator — even if there are other explanations — we would apply this as medium-strength evidence to the model node [CarelessTowardDuties] with a decay half-life of 14 days. If the error type indicates an insufficient clearance for entering the area in question, we can infer that Kara is attempting access above her authorized level [BadgeErrorInsuffClearance]. Additionally, a series of lost badge events could be applied as negative evidence to the [Conscientious] model node.

A consistent pattern of insufficient clearance errors [Excessive/UnusualBadgeErrorInsuffClearance] would be applied as strong evidence to the node [AccessesFacilityUnauthorized] with a longer decay half-life of 30 days to reflect the increased seriousness of this type of error (see image below). If the error indicates an infraction of security rules, we can infer that Kara is disregarding her employer’s security regulations, and a pattern of this behavior would be applied as strong evidence to the model node [NeglectsSecurityRules] with a decay half-life of 60 days.

Finally, let’s say Kara’s employer makes the ‘Door Name’ field available to Constellation. This not only enables us to detect location anomalies — [UnusualAccessAuthorizedLocation] and [UnusualBadgeErrorLocation] — in addition to time anomalies, but now the Constellation model can infer something about the area being accessed. For example, door names that include keywords like ‘Security,’ ‘Investigations’ or ‘Restricted’ are categorized as sensitive areas. Those with keywords like ‘Lobby’, ‘Elevator’ or ‘Garage’ are classified as common areas. Recreational areas are indicated by names such as ‘Break Room’, ‘Gym’ and ‘Cafeteria.’

This additional information gives us finer granularity in generating badge events. An anomalous event from a common area [UnusualCommonAreaAccessAuthorizedTime/Location] is much less significant than one from a sensitive area [UnusualSensitiveAreaAccessAuthorizedTime/Location], which we would apply to the model node [AccessesFacilityUnauthorized] as strong evidence with a decay half-life of 60 days. Combining this information with the error type gives us greater accuracy, and therefore stronger evidence; a pattern of clearance errors when Kara attempts to gain access to a sensitive area [UnusualBadgeErrorInsuffClearanceSensitiveAreaTime] is of much greater concern than a time anomaly for a common area [UnusualAccessAuthorizedCommonAreaTime]. If the data field for number of attempts is available, we can infer even stronger evidence: if Kara has tried to enter a sensitive area for which she has an insufficient clearance five times within one minute, we clearly have a problem.

There are even deeper insights to be gleaned from badge data. For example:

• We could infer that Kara is [Disgruntled] if she is spending more time in recreational areas than her peers.
• Similarly, if Kara is spending less time in recreational areas than her peers, we could infer that she is [UnderWorkStress].
• In some facilities, accessing the roof might even indicate a threat to oneself.

Finally, consider a scenario in which an individual has several unusual events that seem innocuous on their own, but when combined indicate a concerning behavior. If within a short timeframe Kara accesses a new building [UnusualBadgeAccessLocation] at an unusual time [UnusualBadgeAccessTime] and prints a large number of pages [UnusualPrintVolume] from a printer she has never used before [UnusualPrintLocation], a purely badge-focused or network-focused monitoring system will generate a succession of isolated alerts in a sea of them — while potentially missing the larger and more troubling picture that could have been gleaned by ‘connecting the dots.’

The Constellation model, by contrast, is designed to give events more importance when combined with other events and detected sequences of events. This combination of events would significantly impact Kara’s score (see image below), and an insider threat analyst would see the score change displayed automatically as an incident in Constellation and be able to conduct a deeper investigation.

Decades of research studies and experience gained from real-world insider threat events have strongly demonstrated that malicious, negligent and inadvertent insiders alike all exhibit adverse attitudes and behaviors sometimes months or even years in advance of the actual event.

Badge data, like network data, won’t tell the whole story on its own. But it can deliver critical insights not available anywhere else. And when its component pieces are analyzed and blended with data from other sources — for example evidence of professional, personal or financial stress — the result is contextualized, actionable insider-threat intelligence. It’s a user behavior analytics approach that focuses on the user, not the network or the device.

#  #  #

Julie Ard is the Director of Insider Threat Operations at Haystax Technology, a Fishtech Group company.

NOTE: For more information on Constellation’s ‘whole-person’ approach to user behavior analytics, download our in-depth report, To Catch an IP Thief.

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.