Written By Dr Al Hartmann And Presented By Ziften CEO Charles Leaver


In the online world the sheep get shorn, chumps get munched, dupes get deceived, and pawns get pwned. We have actually seen another terrific example of this in the recent attack on the UK Parliament e-mail system.

Instead of admitting to an e-mail system that was insecure by design, the main statement read:

Parliament has strong steps in place to secure all our accounts and systems.

Yeah, right. The one protective procedure we did see at work was deflecting the blame – pin it on the Russians, that constantly works, while accusing the victims for their policy infractions. While information of the attack are scarce, combing numerous sources does help to put together a minimum of the gross outlines. If these accounts are fairly close, the United Kingdom Parliament email system failings are scandalous.

What failed in this scenario?

Depend on single aspect authentication

“Password security” is an oxymoron – anything password secured alone is insecure, period, no matter the strength of the password. Please, no 2FA here, may impede attacks.

Do not impose any limitation on unsuccessful login efforts

Helped by single factor authentication, this enables basic brute force attacks, no skill required. But when attacked, blame elite foreign hackers – no one can verify.

Do not carry out brute force violation detection

Enable hackers to perform (otherwise trivially detectable) brute force attacks for prolonged durations (12 hours versus the United Kingdom Parliament system), to make the most of account compromise scope.

Do not impose policy, treat it as simply recommendations

Integrated with single element authentication, no limit on unsuccessful logins, and no brute force attack detection, do not impose any password strength validation. Supply enemies with extremely low hanging fruit.

Rely on anonymous, unencrypted email for sensitive communications

If assailants are successful in jeopardizing e-mail accounts or sniffing your network traffic, offer plenty of opportunity for them to score high value message material entirely in the clear. This likewise conditions constituents to rely on readily spoofable e-mail from Parliament, developing an ideal constituent phishing environment.

Lessons learned

In addition to adding “Sound judgment for Dummies” to their summer reading lists, the UK Parliament e-mail system administrators might wish to take further actions. Reinforcing weak authentication practices, implementing policies, improving network and endpoint visibility with constant tracking and anomaly detection, and totally reassessing protected messaging are advised actions. Penetration screening would have revealed these fundamental weak points while staying outside the news headlines.

Even a few sharp high-schoolers with a free weekend could have duplicated this violation. And lastly, stop blaming Russia for your very own security failings. Presume that any weak points in your security architecture and policy framework will be penetrated and made use of by some party someplace throughout the global web. All the more incentive to discover and repair those weaknesses before the hackers do, so turn those pen testers loose. And then if your defenders do not cannot see the attacks in progress, upgrade your tracking and analytics.

Written By Charles Leaver Ziften CEO


It was nailed by Scott Raynovich. Having worked with numerous companies he recognized that one of the greatest obstacles is that security and operations are two different departments – with drastically varying goals, varying tools, and varying management structures.

Scott and his expert firm, Futuriom, recently finished a study, “Endpoint Security and SysSecOps: The Growing Pattern to Build a More Secure Enterprise”, where one of the essential findings was that contrasting IT and security objectives hamper specialists – on both groups – from accomplishing their objectives.

That’s precisely what our company believe at Ziften, and the term that Scott created to discuss the convergence of IT and security in this domain – SysSecOps – explains perfectly what we have actually been speaking about. Security teams and the IT teams must get on the very same page. That implies sharing the same objectives, and in many cases, sharing the very same tools.

Consider the tools that IT people utilize. The tools are created to ensure the infrastructure and end devices are working appropriately, and when something fails, helps them repair it. On the endpoint side, those tools help ensure that devices that are permitted onto the network, are configured correctly, have software that’s licensed and properly patched/updated, and have not registered any faults.

Think of the tools that security folks use. They work to implement security policies on devices, infrastructure, and security apparatus (like firewall programs). This might involve active tracking events, scanning for irregular behavior, analyzing files to guarantee they don’t contain malware, adopting the latest danger intelligence, matching against recently found zero-days, and performing analysis on log files.

Discovering fires, combating fires

Those are 2 different worlds. The security groups are fire spotters: They can see that something bad is occurring, can work quickly to separate the problem, and determine if harm happened (like data exfiltration). The IT teams are on the ground firefighters: They jump into action when an event strikes to guarantee that the systems are made safe and revived into operation.

Sounds excellent, right? Unfortunately, all too often, they don’t talk to each other – it resembles having the fire spotters and fire fighters using dissimilar radios, dissimilar lingo, and different city maps. Worse, the teams can’t share the same data directly.

Our technique to SysSecOps is to supply both the IT and security teams with the exact same resources – and that indicates the exact same reports, presented in the proper ways to professionals. It’s not a dumbing down, it’s working smarter.

It’s ludicrous to work in any other way. Take the WannaCry infection, for instance. On one hand, Microsoft released a patch back in March 2017 that attended to the underlying SMB defect. IT operations groups didn’t set up the patch, due to the fact that they didn’t believe this was a big deal and didn’t speak with security. Security teams didn’t understand if the patch was installed, because they do not speak to operations. SysSecOps would have had everyone on the same page – and could have potentially avoided this issue.

Missing out on data suggests waste and danger

The inefficient space in between IT operations and security exposes organizations to threats. Preventable threats. Unneeded threats. It’s simply inappropriate!

If your company’s IT and security groups aren’t on the same page, you are sustaining risks and expenses that you shouldn’t need to. It’s waste. Organizational waste. It’s wasteful due to the fact that you have numerous tools that are providing partial data that have gaps, and each of your groups only sees part of the picture.

As Scott concluded in his report, “Coordinated SysSecOps visibility has already shown its worth in helping companies examine, analyze, and avoid considerable threats to the IT systems and endpoints. If these objectives are pursued, the security and management dangers to an IT system can be considerably decreased.”

If your teams are interacting in a SysSecOps sort of way, if they can see the very same data at the same time, you not only have much better security and more efficient operations – however likewise lower danger and lower expenses. Our Zenith software application can assist you attain that performance, not only working with your existing IT and security tools, but also filling in the gaps to make sure everyone has the right data at the right time.

Written by Joel Ebrahami and presented by Charles Leaver


WannaCry has produced a lot of media attention. It might not have the huge infection rates that we have seen with a number of the previous worms, however in today’s security world the amount of systems it had the ability to infect in one day was still somewhat incredible. The objective of this blog post is NOT to provide an in-depth analysis of the exploit, but rather to look how the threat behaves on a technical level with Ziften’s Zenith platform and the integration we have with our technology partner Splunk.

WannaCry Visibility in Ziften Zenith

My very first action was to reach out to Ziften Labs danger research group to see exactly what info they could provide to me about WannaCry. Josh Harriman, VP of Cyber Security Intelligence, directs our research study team and notified me that they had samples of WannaCry presently running in our ‘Red Laboratory’ to look at the behavior of the risk and conduct more analysis. Josh sent me over the details of exactly what he had discovered when analyzing the WannaCry samples in the Ziften Zenith console. He sent over those information, which I provide in this post.

The Red Lab has systems covering all the most popular typical os with different services and configurations. There were already systems in the lab that were deliberately vulnerable to the WannaCry exploit. Our worldwide threat intelligence feeds utilized in the Zenith platform are upgraded in real-time, and had no trouble detecting the virus in our lab environment (see Figure 1).


Two laboratory systems have been determined running the harmful WannaCry sample. While it is great to see our worldwide hazard intelligence feeds updated so quickly and determining the ransomware samples, there were other behaviors that we found that would have identified the ransomware hazard even if there had not been a risk signature.

Zenith agents gather a large quantity of information on what’s happening on each host. From this visibility data, we develop non-signature based detection methods to take a look at generally destructive or anomalous habits. In Figure 2 below, we show the behavioral detection of the WannaCry threat.


Investigating the Scope of WannaCry Infections

Once discovered either through signature or behavioral techniques, it is really easy to see which other systems have actually also been infected or are displaying comparable behaviors.


Detecting WannaCry with Ziften and Splunk

After reviewing this details, I decided to run the WannaCry sample in my own environment on a susceptible system. I had one vulnerable system running the Zenith agent, and in this case my Zenith server was currently configured to integrate with Splunk. This enabled me to look at the very same information inside Splunk. Let me explain about the integration we currently have with Splunk.

We have 2 Splunk apps for Zenith. The first is our technology add-on (TA): its function is to ingest and index ALL the raw information from the Zenith server that the Ziften agents produce. As this information comes in it is massaged into Splunk’s Common Information Model (CIM) so that it can be normalized and simply browsed in addition to used by other apps such as the Splunk App for Enterprise Security (Splunk ES). The Ziften TA likewise includes Adaptive Response capabilities for acting from actions that are rendered in Splunk ES. The 2nd app is a dashboard for displaying our information with all the charts and graphs readily available in Splunk to facilitate digesting the data a lot easier.

Given that I currently had the information on how the WannaCry exploit behaved in our research laboratory, I had the advantage of knowing exactly what to find in Splunk utilizing the Zenith data. In this case I was able to see a signature alert by utilizing the VirusTotal integration with our Splunk app (see Figure 4).


Danger Searching for WannaCry Ransomware in Ziften and Splunk

But I wanted to wear my “event responder hat” and examine this in Splunk using the Zenith agent information. My very first thought was to browse the systems in my laboratory for ones running SMB, because that was the preliminary vector for the WannaCry attack. The Zenith data is encapsulated in various message types, and I knew that I would most likely find SMB data in the running process message type, nevertheless, I utilized Splunk’s * regex with the Zenith sourcetype so I could search all Zenith data. The resulting search appeared like ‘sourcetype= ziften: zenith: * smb’. As I expected I got one result back for the system that was running SMB (see Figure 5).


My next action was to utilize the very same behavioral search we have in Zenith that searches for common CryptoWare and see if I might get outcomes back. Once again this was extremely simple to do from the Splunk search panel. I used the very same wildcard sourcetype as previously so I might browse throughout all Zenith data and this time I included the ‘delete shadows’ string search to see if this behavior was ever released at the command line. My search looked like ‘sourcetype= ziften: zenith: * delete shadows’. This search returned outcomes, displayed in Figure 6, that showed me in detail the procedure that was created and the full command line that was carried out.


Having all this info within Splunk made it really easy to identify which systems were vulnerable and which systems had already been jeopardized.

WannaCry Removal Using Splunk and Ziften

Among the next steps in any type of breach is to remediate the compromise as quick as possible to prevent further damage and to do something about it to prevent other systems from being compromised. Ziften is among the Splunk founding Adaptive Response members and there are a number of actions (see Figure 7) that can be taken through Spunk’s Adaptive Response to mitigate these hazards through extensions on Zenith.


When it comes to WannaCry we truly might have utilized nearly any of the Adaptive Response actions currently offered by Zenith. When aiming to minimize the effect and prevent WannaCry in the first place, one action that can happen is to close down SMB on any systems running the Zenith agent where the version of SMB running is understood to be susceptible. With a single action Splunk can pass to Zenith the agent ID’s or the IP Address of all the susceptible systems where we wanted to stop the SMB service, hence avoiding the exploit from ever occurring and permitting the IT Operations team to get those systems patched prior to starting the SMB service once again.

Avoiding Ransomware from Spreading or Exfiltrating Data

Now in the event that we have actually currently been compromised, it is vital to prevent more exploitation and stop the possible exfiltration of sensitive details or company intellectual property. There are truly three actions we might take. The very first 2 are similar where we could kill the malicious procedure by either PID (process ID) or by its hash. This is effective, but considering that many times malware will simply spawn under a brand-new process, or be polymorphic and have a various hash, we can apply an action that is guaranteed to prevent any inbound or outbound traffic from those contaminated systems: network quarantine. This is another example of an Adaptive Response action available from Ziften’s integration with Splunk ES.

WannaCry is already decreasing, however ideally this technical blog shows the worth of the Ziften and Splunk integration in handling ransomware hazards against the end point.

Written By Roark Pollock And Presented By Charles Leaver CEO Ziften


The Endpoint Security Buyer’s Guide

The most typical point for a sophisticated relentless attack or a breach is the endpoint. And they are definitely the entry point for many ransomware and social engineering attacks. Making use of endpoint security products has actually long been considered a best practice for securing end points. Unfortunately, those tools aren’t staying up to date with today’s danger environment. Advanced risks, and truth be told, even less advanced risks, are typically more than appropriate for fooling the average employee into clicking something they should not. So organizations are looking at and assessing a huge selection of next-gen endpoint security (NGES) solutions.

With that in mind, here are ten tips to think about if you’re looking at NGES solutions.

Idea 1: Begin with the end first

Do not let the tail wag the dog. A danger decrease technique should always start by evaluating issues and then looking for possible solutions for those problems. However all too often we get captivated with a “glossy” brand-new technology (e.g., the most recent silver bullet) and we wind up trying to shoehorn that innovation into our environments without totally evaluating if it solves an understood and identified problem. So exactly what issues are you aiming to resolve?

– Is your current end point security tool failing to stop dangers?
– Do you require much better visibility into activities at the end point?
– Are compliance requirements dictating constant end point tracking?
– Are you trying to reduce the time and expense of incident response?

Specify the problems to resolve, and then you’ll have a measuring stick for success.

Suggestion 2: Understand your audience. Exactly who will be using the tool?

Comprehending the issue that has to be fixed is an essential first step in understanding who owns the problem and who would (operationally) own the solution. Every functional group has its strengths, weak points, choices and prejudices. Define who will need to utilize the solution, and others that could gain from its usage. Is it:

– Security group,
– IT group,
– The governance, risk and compliance (GRC) group,
– Helpdesk or end user assistance group,
– Or perhaps the server group, or a cloud operations team?

Idea 3: Know what you suggest by endpoint

Another typically overlooked early step in defining the problem is defining the endpoint. Yes, all of us used to know what we implied when we stated endpoint however today end points come in a lot more varieties than before.

Sure we want to secure desktops and laptop computers but how about mobile devices (e.g. smartphones and tablets), virtual endpoints, cloud based endpoints, or Internet of Things (IoT) devices? And how about your servers? All of these devices, obviously, can be found in several tastes so platform assistance needs to be attended to also (e.g. Windows only, Mac OSX, Linux, etc?). Likewise, consider assistance for end points even when they are working remote, or are working offline. What are your needs and exactly what are “nice to haves?”

Tip 4: Start with a structure of continuous visibility

Continuous visibility is a fundamental ability for resolving a host of security and functional management problems on the end point. The old adage is true – that you can’t manage what you cannot see or determine. Even more, you can’t secure exactly what you cannot effectively manage. So it must start with constant or all the time visibility.

Visibility is foundational to Management and Security

And think of what visibility implies. Enterprises need one source of truth that at a minimum monitors, saves, and analyzes the following:

– System data – events, logs, hardware state, and file system details
– User data – activity logs and habit patterns
– Application data – attributes of installed apps and usage patterns
– Binary data – attributes of set up binaries
– Procedures data – tracking info and stats
– Network connection data – stats and internal behavior of network activity on the host

Suggestion 5: Monitor your visibility data

End point visibility data can be kept and analyzed on the premises, in the cloud, or some mix of both. There are advantages to each. The suitable technique differs, but is typically driven by regulative requirements, internal privacy policies, the end points being monitored, and the total cost considerations.

Know if your company needs on-premise data retention

Know whether your company enables cloud based data retention and analysis or if you are constrained to on premise services only. Within Ziften, 20-30% of our clients keep data on-premise simply for regulative factors. Nevertheless, if legally an alternative, the cloud can offer cost advantages (to name a few).

Pointer 6: Know what is on your network

Understanding the problem you are attempting to solve requires comprehending the assets on the network. We have found that as many as 30% of the endpoints we at first find on customers’ networks are un-managed or unknown devices. This obviously produces a huge blind spot. Minimizing this blind spot is a vital best practice. In fact, SANS Critical Security Controls 1 and 2 are to perform an inventory of authorized and unauthorized devices and software applications attached to your network. So search for NGES solutions that can finger print all connected devices, track software stock and usage, and perform ongoing constant discovery.

Suggestion 7: Know where you are exposed

After finding out exactly what devices you need to monitor, you need to make certain they are operating in up to date setups. SANS Critical Security Controls 3 advises ensuring safe and secure configurations tracking for laptops, workstations, and servers. SANS Critical Security Controls 4 advises making it possible for continuous vulnerability evaluation and remediation of these devices. So, look for NGES services that supply constant tracking of the state or posture of each device, and it’s even of more benefit if it can help enforce that posture.

Also look for solutions that provide constant vulnerability evaluation and remediation.

Keeping your general endpoint environment solidified and free of important vulnerabilities prevents a huge quantity of security concerns and removes a great deal of backend pressure on the IT and security operations teams.

Tip 8: Cultivate constant detection and response

An essential objective for numerous NGES solutions is supporting constant device state monitoring, to allow reliable risk or incident response. SANS Critical Security Control 19 recommends robust incident response and management as a best practice.

Search for NGES solutions that provide all-the-time or continuous danger detection, which leverages a network of global risk intelligence, and multiple detection methods (e.g., signature, behavioral, machine learning, etc). And try to find incident response solutions that help prioritize determined dangers and/or issues and provide workflow with contextual system, application, user, and network data. This can help automate the proper response or next steps. Finally, understand all the response actions that each solution supports – and look for a service that supplies remote access that is as close as possible to “sitting at the endpoint keyboard”.

Pointer 9: Consider forensics data collection

In addition to event response, organizations need to be prepared to attend to the need for forensic or historical data analysis. The SANS Critical Security Control 6 suggests the upkeep, monitoring and analysis of all audit logs. Forensic analysis can take numerous types, but a structure of historic end point monitoring data will be key to any examination. So try to find solutions that maintain historical data that permits:

– Forensic tasks include tracing lateral threat movement through the network gradually,
– Determining data exfiltration efforts,
– Determining source of breaches, and
– Figuring out proper remediation actions.

Suggestion 10: Tear down the walls

IBM’s security team, which supports an outstanding ecosystem of security partners, estimates that the typical business has 135 security tools in place and is dealing with 40 security suppliers. IBM customers definitely tend to be large businesses however it’s a common refrain (complaint) from companies of all sizes that security services don’t integrate well enough.

And the complaint is not just that security services don’t play well with other security solutions, however likewise that they do not always integrate well with system management, patch management, CMDB, NetFlow analytics, ticketing systems, and orchestration tools. Organizations need to think about these (and other) integration points as well as the supplier’s willingness to share raw data, not just metadata, through an API.

Additional Pointer 11: Prepare for customizations

Here’s a bonus idea. Assume that you’ll want to customize that glossy brand-new NGES solution quickly after you get it. No solution will satisfy all of your needs right out of the box, in default setups. Find out how the solution supports:

– Custom data collection,
– Signaling and reporting with custom data,
– Custom-made scripting, or
– IFTTT (if this then that) performance.

You know you’ll want new paint or brand-new wheels on that NGES solution quickly – so ensure it will support your future customization jobs easy enough.

Look for support for easy personalizations in your NGES solution

Follow the bulk of these tips and you’ll undoubtedly prevent many of the common pitfalls that plague others in their assessments of NGES services.

Written By Ziften CEO Charles Leaver


Do you want to handle and protect your endpoints, your data center, the cloud and your network? In that case Ziften can provide the ideal solution for you. We collect data, and allow you to associate and utilize that data to make decisions – and remain in control over your enterprise.

The details that we receive from everybody on the network can make a real world difference. Think about the proposition that the 2016 U.S. elections were influenced by cyber criminals from another nation. If that holds true, hackers can do almost anything – and the concept that we’ll go for that as the status quo is merely ridiculous.

At Ziften, we believe the best method to fight those hazards is with higher visibility than you have actually ever had. That visibility crosses the entire enterprise, and links all the major players together. On the back end, that’s real and virtual servers in the data center and the cloud. That’s applications and containers and infrastructure. On the other side, it’s laptops and desktops, irrespective of how and where they are connected.

End-to-end – that’s the thinking behind all that we do at Ziften. From end point to cloud, right the way from an internet browser to a DNS server. We connect all that together, with all the other elements to give your organization a complete solution.

We likewise catch and keep real-time data for up to 12 months to let you know exactly what’s occurring on the network today, and supply historical pattern analysis and cautions if something changes.

That lets you find IT faults and security problems instantly, as well as be able to search out the root causes by looking back in time to see where a breach or fault may have first happened. Active forensics are a total requirement in security: After all, where a breach or fault tripped an alarm may not be the place where the problem started – or where a hacker is running.

Ziften supplies your security and IT groups with the visibility to understand your existing security posture, and identify where enhancements are needed. Endpoints non-compliant? Found. Rogue devices? Found. Off-network penetration? This will be detected. Out-of-date firmware? Unpatched applications? All found. We’ll not just assist you find the problem, we’ll help you fix it, and ensure it remains repaired.

End to end security and IT management. Real time and historic active forensics. Onsite, offline, in the cloud. Incident detection, containment and response. We have actually got it all covered. That’s exactly what makes Ziften better.

Written by Roark Pollock and Presented by Ziften CEO Charles Leaver


According to Gartner public cloud services market surpassed $208 billion in 2016. This represented about a 17% rise year over year. Pretty good when you consider the on-going issues most cloud clients still have regarding data security. Another particularly interesting Gartner finding is the typical practice by cloud clients to contract services to several public cloud providers.

According to Gartner “most businesses are already using a combination of cloud services from different cloud providers”. While the commercial rationale for using multiple suppliers is sound (e.g., preventing vendor lock in), the practice does produce additional intricacy inmonitoring activity across an organization’s significantly fragmented IT landscape.

While some suppliers support more superior visibility than others (for example, AWS CloudTrail can monitor API calls across the AWS infrastructure) companies have to comprehend and attend to the visibility issues related to transferring to the cloud irrespective of the cloud supplier or companies they work with.

Unfortunately, the ability to track application and user activity, and networking communications from each VM or endpoint in the cloud is limited.

Irrespective of where computing resources live, companies must address the questions of “Which users, machines, and applications are interacting with each other?” Organizations require visibility across the infrastructure so that they can:

  • Quickly identify and focus on problems
  • Speed root cause analysis and identification
  • Lower the mean time to repair problems for end users
  • Rapidly identify and eliminate security hazards, minimizing overall dwell times.

Alternatively, bad visibility or bad access to visibility data can minimize the efficiency of existing management and security tools.

Businesses that are used to the ease, maturity, and reasonably cheapness of keeping track of physical data centers are sure to be disappointed with their public cloud alternatives.

What has been missing is a basic, common, and stylish solution like NetFlow for public cloud infrastructure.

NetFlow, naturally, has had 20 years approximately to become a de facto standard for network visibility. A typical implementation includes the monitoring of traffic and aggregation of flows where the network chokes, the collection and storage of flow data from multiple collection points, and the analysis of this flow information.

Flows consist of a standard set of destination and source IP addresses and port and protocol info that is usually gathered from a router or switch. Netflow data is relatively cheap and easy to collect and supplies almost ubiquitous network visibility and allows for analysis which is actionable for both network tracking and performance management applications.

Most IT personnel, particularly networking and some security teams are incredibly comfy with the technology.

However NetFlow was developed for solving exactly what has become a rather limited problem in the sense that it only gathers network info and does this at a minimal number of potential places.

To make better use of NetFlow, 2 crucial changes are needed.

NetFlow to the Edge: First, we need to expand the useful deployment scenarios for NetFlow. Instead of just collecting NetFlow at networking choke points, let’s expand flow collection to the edge of the network (cloud, servers and clients). This would considerably broaden the overall view that any NetFlow analytics provide.

This would permit companies to augment and utilize existing NetFlow analytics tools to remove the growing blind spot of visibility into public cloud activities.

Rich, contextual NetFlow: Secondly, we need to use NetFlow for more than simple network visibility.

Instead, let’s utilize an extended variation of NetFlow and include information on the user, device,
application, and binary responsible for each tracked network connection. That would allow us to rapidly connect every network connection back to its source.

In fact, these 2 changes to NetFlow, are exactly what Ziften has actually achieved with ZFlow. ZFlow supplies an expanded version of NetFlow that can be released at the network edge, including as part of a VM or container image, and the resulting information gathering can be taken in and analyzed with existing NetFlow tools for analysis. Over and above conventional NetFlow Internet Protocol Flow Info eXport (IPFIX) visibility of the network, ZFlow offers greater visibility with the addition of info on application, device, user and binary for each network connection.

Eventually, this allows Ziften ZFlow to deliver end-to-end visibility in between any two endpoints, physical or virtual, getting rid of traditional blind spots like East West traffic in data centers and enterprise cloud deployments.

Written By Jesse Sampson And Presented By Charles Leaver CEO Ziften


In the first post on edit distance, we looked at searching for destructive executables with edit distance (i.e., how many character edits it requires to make 2 text strings match). Now let’s look at how we can utilize edit distance to search for malicious domains, and how we can develop edit distance functions that can be integrated with other domain name functions to pinpoint suspect activity.

Case Study Background

Exactly what are bad actors playing at with malicious domains? It might be merely utilizing a close spelling of a typical domain name to fool careless users into looking at ads or picking up adware. Legitimate sites are gradually picking up on this technique, sometimes called typo-squatting.

Other malicious domains are the result of domain name generation algorithms, which might be used to do all types of nefarious things like evade counter measures that obstruct recognized jeopardized sites, or overwhelm domain name servers in a dispersed DoS attack. Older variants use randomly generated strings, while further advanced ones include tricks like injecting typical words, additionally puzzling protectors.

Edit distance can aid with both use cases: here we will find out how. First, we’ll exclude common domain names, given that these are usually safe. And, a list of regular domain names provides a standard for spotting abnormalities. One good source is Quantcast. For this discussion, we will stick to domains and prevent subdomains (e.g. ziften.com, not www.ziften.com).

After data cleansing, we compare each prospect domain (input data observed in the wild by Ziften) to its prospective next-door neighbors in the very same top-level domain (the tail end of a domain name – classically.com,. org, and so on and today can be practically anything). The standard task is to discover the nearby next-door neighbor in regards to edit distance. By discovering domain names that are one step removed from their nearest next-door neighbor, we can easily find typo-ed domain names. By discovering domain names far from their next-door neighbor (the normalized edit distance we introduced in Part 1 is useful here), we can likewise discover anomalous domains in the edit distance area.

Exactly what were the Outcomes?

Let’s look at how these results appear in reality. Be careful when browsing to these domain names since they might include malicious material!

Here are a few prospective typos. Typo squatters target popular domains since there are more opportunities somebody will check them out. Numerous of these are suspect according to our threat feed partners, however there are some false positives too with charming names like “wikipedal”.


Here are some strange looking domain names far from their next-door neighbors.


So now we have produced 2 beneficial edit distance metrics for searching. Not just that, we have three features to potentially add to a machine-learning model: rank of nearby neighbor, range from next-door neighbor, and edit distance 1 from neighbor, showing a threat of typo shenanigans. Other features that might play well with these include other lexical functions such as word and n-gram distributions, entropy, and string length – and network functions like the number of unsuccessful DNS requests.

Streamlined Code that you can Experiment with

Here is a streamlined variation of the code to have fun with! Created on HP Vertica, but this SQL should run with many advanced databases. Note the Vertica editDistance function may vary in other executions (e.g. levenshtein in Postgres or UTL_MATCH. EDIT_DISTANCE in Oracle).


Written by Charles Leaver Ziften CEO


If your enterprise computing environment is not appropriately managed there is no way that it can be absolutely secure. And you can’t successfully manage those intricate business systems unless there’s a good sense that they are protected.

Some may call this a chicken and egg circumstance, where you do not know where to start. Should you start with security? Or should you begin with system management? That’s the incorrect approach. Think of this instead like Reese’s Peanut Butter Cups: It’s not chocolate initially. It’s not peanut butter first. Rather, both are mixed together – and dealt with as a single delicious reward.

Numerous companies, I would argue a lot of organizations, are structured with an IT management department reporting to a CIO, and with a security management team reporting to a CISO. The CIO team and the CISO team do not know each other, talk with each other only when definitely needed, have distinct budgets, definitely have different priorities, read various reports, and use different management platforms. On an everyday basis, what makes up a task, a concern or an alert for one team flies completely under the other group’s radar.

That’s bad, since both the IT and security groups should make assumptions. The IT group thinks that all assets are safe and secure, unless someone tells them otherwise. For instance, they presume that devices and applications have not been compromised, users have actually not escalated their privileges, etc. Similarly, the security team assumes that the servers, desktops, and mobiles are working properly, operating systems and apps are up to date, patches have been used, and so on

Given that the CIO and CISO groups aren’t talking to each other, do not comprehend each others’ functions and goals, and aren’t utilizing the same tools, those presumptions might not be appropriate.

And again, you cannot have a secure environment unless that environment is properly managed – and you can’t manage that environment unless it’s secure. Or to put it another way: An environment that is not secure makes anything you do in the IT organization suspect and irrelevant, and implies that you cannot understand whether the information you are seeing is correct or controlled. It may all be fake news.

How to Bridge the IT / Security Space

Ways to bridge that gap? It sounds easy but it can be difficult: Ensure that there is an umbrella covering both the IT and security teams. Both IT and security report to the very same individual or structure somewhere. It might be the CIO, it might be the CFO, it might be the CEO. For the sake of argument here, let’s state it’s the CFO.

If the business doesn’t have a safe and secure environment, and there’s a breach, the value of the brand name and the business can be reduced to zero. Likewise, if the users, devices, infrastructure, application, and data aren’t managed well, the business can’t work effectively, and the value drops. As we have actually talked about, if it’s not properly handled, it cannot be secured, and if it’s not protected, it cannot be well handled.

The fiduciary duty of senior executives (like the CFO) is to secure the value of company assets, which implies making certain IT and security speak to each other, understand each other’s concerns, and if possible, can see the exact same reports and data – filtered and displayed to be meaningful to their specific areas of responsibility.

That’s the thinking that we adopted with the design of our Zenith platform. It’s not a security management tool with IT abilities, and it’s not an IT management tool with security abilities. No, it’s a Peanut Butter Cup, developed equally around chocolate and peanut butter. To be less confectionery, Zenith is an umbrella that provides IT groups what they need to do their tasks, and provides security groups exactly what they need also – without coverage spaces that could weaken assumptions about the state of business security and IT management.

We have to make sure that our business’s IT infrastructure is built on a protected foundation – and also that our security is executed on a well-managed base of hardware, infrastructure, software applications and users. We can’t operate at peak performance, and with complete fiduciary duty, otherwise.

Written By Roark Pollock And Presented By Ziften CEO Charles Leaver


If you are a student of history you will observe numerous examples of extreme unintended repercussions when brand-new technology has actually been presented. It typically surprises individuals that brand-new technologies might have nefarious intentions in addition to the positive purposes for which they are brought to market however it happens on a very regular basis.

For example, Train robbers using dynamite (“You think you used enough Dynamite there, Butch?”) or spammers using email. Just recently making use of SSL to conceal malware from security controls has actually become more typical because the legitimate use of SSL has made this technique better.

Because new technology is frequently appropriated by bad actors, we have no need to think this will not be true about the brand-new generation of machine-learning tools that have reached the market.

To what degree will these tools be misused? There are most likely a number of ways in which hackers could utilize machine learning to their advantage. At a minimum, malware writers will test their new malware against the brand-new class of innovative hazard security products in a bid to modify their code to ensure that it is less likely to be flagged as destructive. The effectiveness of protective security controls constantly has a half life due to adversarial learning. An understanding of machine learning defenses will assist attackers become more proactive in reducing the effectiveness of artificial intelligence based defenses. An example would be an enemy flooding a network with phony traffic with the intention of “poisoning” the machine learning model being constructed from that traffic. The goal of the opponent would be to fool the defender’s machine learning tool into misclassifying traffic or to develop such a high degree of false positives that the protectors would dial back the fidelity of the notifications.

Machine learning will likely likewise be utilized as an attack tool by attackers. For example, some scientists forecast that attackers will make use of machine learning techniques to sharpen their social engineering attacks (e.g., spear phishing). The automation of the effort it takes to customize a social engineering attack is especially troubling provided the effectiveness of spear phishing. The ability to automate mass customization of these attacks is a potent economic incentive for hackers to embrace the techniques.

Expect breaches of this type that deliver ransomware payloads to rise dramatically in 2017.

The need to automate tasks is a major driver of financial investment choices for both attackers and protectors. Artificial intelligence promises to automate detection and response and increase the functional pace. While the innovation will increasingly become a standard part of defense in depth methods, it is not a magic bullet. It ought to be understood that hackers are actively dealing with evasion approaches around machine learning based detection solutions while also utilizing machine learning for their own attack purposes. This arms race will require defenders to progressively achieve incident response at machine pace, further exacerbating the requirement for automated incident response capabilities.

Written By Roark Pollock And Presented By Ziften CEO Charles Leaver


There may be a joke somewhere concerning the forensic expert that was late to the incident response celebration. There is the seed of a joke in the concept at least however of course, you need to comprehend the differences between forensic analysis and incident response to value the potential for humor.

Forensic analysis and incident response are related disciplines that can leverage similar tools and associated data sets however also have some important distinctions. There are four particularly essential distinctions between forensic analysis and incident response:

– Goals.
– Data requirements.
– Group skills.
– Advantages.

The difference in the goals of forensic analysis and incident response is possibly the most essential. Incident response is concentrated on determining a quick (i.e., near real-time) reaction to an instant hazard or concern. For instance, a house is on fire and the firemen that show up to put that fire out are associated with incident response. Forensic analysis is usually performed as part of an arranged compliance, legal discovery, or law enforcement investigation. For example, a fire detective may examine the remains of that home fire to figure out the overall damage to the house, the cause of the fire, and whether the origin was such that other houses are also facing the same risk. To puts it simply, incident response is concentrated on containment of a danger or concern, while forensic analysis is concentrated on a complete understanding and extensive remediation of a breach.

A second significant distinction between the disciplines is the data resources required to attain the goals. Incident response groups normally just require short-term data sources, frequently no greater than a month or so, while forensic analysis teams usually need a lot longer lived logs and files. Keep in mind that the typical dwell time of an effective attack is somewhere in between 150 and 300 days.

While there is commonness in the personnel skills of incident response and forensic analysis groups, and in fact incident response is typically considered a subset of the border forensic discipline, there are important distinctions in job requirements. Both kinds of research require strong log analysis and malware analysis abilities. Incident response requires the capability to quickly separate a contaminated device and to establish ways to remediate or quarantine the device. Interactions have the tendency to be with other security and operations team members. Forensic analysis generally requires interactions with a much broader set of departments, including legal, compliance, operations and HR.

Not remarkably, the viewed benefits of these activities likewise differ.

The capability to get rid of a risk on one machine in near real-time is a significant determinate in keeping breaches separated and limited in effect. Incident response, and proactive danger hunting, is first line of defense in security operations. Forensic analysis is incident responses’ less attractive relative. However, the benefits of this work are undeniable. A comprehensive forensic examination enables the removal of all hazards with the mindful analysis of an entire attack chain of events. Which is no laughing matter.

Do your endpoint security processes allow both instant incident response, and long term historical forensic analysis?