Written By Josh Harriman And Presented By Charles Leaver Ziften CEO

 

Another infestation, another nightmare for those who were not prepared. While this newest attack is similar to the earlier WannaCry risk, there are some distinctions in this newest malware which is a variant or new strain similar to Petya. Dubbed, NotPetya by some, this strain has a great deal of issues for anyone who encounters it. It might encrypt your data, or make the system completely inoperable. And now the e-mail address that you would be needed to call to ‘perhaps’ unencrypt your files, has been removed so you’re out of luck getting your files back.

A lot of information to the actions of this hazard are openly readily available, however I wished to touch on that Ziften customers are safeguarded from both the EternalBlue exploit, which is one mechanism utilized for its proliferation, and even much better still, an inoculation based upon a possible flaw or its own kind of debug check that gets rid of the danger from ever operating on your system. It might still spread nevertheless in the environment, however our defense would currently be rolled out to all existing systems to halt the damage.

Our Ziften extension platform enables our customers to have defense in place versus particular vulnerabilities and harmful actions for this danger and others like Petya. Besides the particular actions taken against this particular variation, we have taken a holistic approach to stop particular strains of malware that conduct numerous ‘checks’ versus the system prior to executing.

We can also utilize our Browse ability to search for residues of the other proliferation techniques used by this danger. Reports show WMIC and PsExec being utilized. We can look for those programs and their command lines and usage. Despite the fact that they are legitimate procedures, their usage is usually unusual and can be alerted.

With WannaCry, and now NotPetya, we expect to see an ongoing increase of these kinds of attacks. With the release of the current NSA exploits, it has actually provided enthusiastic cyber criminals the tools required to push out their items. And though ransomware risks can be a high commodity vehicle, more harmful hazards could be released. It has always been ‘how’ to get the hazards to spread (worm-like, or social engineering) which is most tough to them.

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

wannasplunk-figure1

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.

wannasplunk-figure2

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.

wannasplunk-figure3

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

wannasplunk-figure4

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

wannasplunk-figure5

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.

wannasplunk-figure6

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.

wannasplunk-figure7

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 Charles Leaver Ziften CEO

 

Whatever you do don’t ignore cybersecurity criminals. Even the most paranoid “normal” person would not fret about a source of data breaches being taken qualifications from its heating, ventilation and a/c (A/C) specialist. Yet that’s what occurred at Target in November 2013. Hackers got into Target’s network using credentials given to the professional, most likely so they might track the heating, ventilation and a/c system. (For an excellent analysis, see Krebs on Security). And after that hackers had the ability to utilize the breach to spread malware into point of sale (POS) systems, then offload payment card information.

A number of ludicrous errors were made here. Why was the HEATING AND COOLING specialist given access to the business network? Why wasn’t the A/C system on a separate, completely separated network? Why wasn’t the POS system on a different network? And so on.

The point here is that in an extremely intricate network, there are uncounted potential vulnerabilities that could be exploited through negligence, unpatched software applications, default passwords, social engineering, spear phishing, or insider actions. You get the point.

Whose job is it to find and repair those vulnerabilities? The security team. The CISO’s office. Security experts aren’t “typical” individuals. They are paid to be paranoid. Make no mistake, no matter the particular technical vulnerability that was exploited, this was a CISO failure to expect the worst and prepare appropriately.

I cannot speak to the Target HEATING AND COOLING breach specifically, however there is one overwhelming reason breaches like this occur: A lack of budgetary top priority for cybersecurity. I’m not sure how typically businesses cannot fund security merely since they’re inexpensive and would rather do a share buy back. Or maybe the CISO is too shy to ask for what’s needed, or has actually been told that he gets a 5% increase, irrespective of the need. Perhaps the CEO is worried that disclosures of large allotments for security will spook investors. Perhaps the CEO is simply naïve enough to believe that the business will not be targeted by hackers. The problem: Every company is targeted by cyber criminals.

There are huge competitions over budget plans. The IT department wants to fund upgrades and enhancements, and attack the backlog of demand for brand-new and enhanced applications. On the flip side, you have line-of-business managers who see IT projects as directly assisting the bottom line. They are optimists, and have lots of CEO attention.

By contrast, the security department frequently has to defend crumbs. They are viewed as a cost center. Security decreases enterprise risk in such a way that matters to the CFO, the CRO (chief risk officer, if there is one), the basic counsel, and other pessimists who care about compliance and track records. These green-eyeshade people consider the worst case circumstances. That does not make friends, and spending plan dollars are allocated grudgingly at a lot of organizations (till the business gets burned).

Call it naivety, call it established hostility, however it’s a genuine obstacle. You cannot have IT offered great tools to move the enterprise forward, while security is starved and making do with second-best.

Worse, you don’t want to wind up in situations where the rightfully paranoid security groups are dealing with tools that don’t fit together well with their IT equivalent’s tools.

If IT and security tools do not mesh well, IT might not have the ability to quickly act to react to risky circumstances that the security groups are monitoring or are concerned about – things like reports from risk intelligence, discoveries of unpatched vulnerabilities, nasty zero-day exploits, or user behaviors that indicate risky or suspicious activity.

One idea: Discover tools for both departments that are developed with both IT and security in mind, right from the beginning, instead of IT tools that are patched to offer some very little security ability. One spending plan product (take it out of IT, they have more money), however two workflows, one developed for the IT expert, one for the CISO team. Everyone wins – and next time somebody wishes to give the HEATING AND COOLING contractor access to the network, possibly security will see exactly what IT is doing, and head that catastrophe off at the pass.

Written By Michael Vaughn And Presented By Charles Leaver Ziften CEO

 

Answers To Your Questions About WannaCry Ransomware

The WannaCry ransomware attack has actually contaminated more than 300,000 computer systems in 150 nations so far by exploiting vulnerabilities in Microsoft’s Windows os.
In this quick video Chief Data Scientist Dr. Al Hartmann and I talk about the nature of the attack, as well as how Ziften can assist companies secure themselves from the vulnerability known as “EternalBlue.”.

As mentioned in the video, the issue with this Server Message Block (SMB) file sharing service is that it’s on the majority of Windows os and found in the majority of environments. Nevertheless, we make it simple to identify which systems in your environment have or haven’t been patched to date. Importantly, Ziften Zenith can also from another location disable the SMB file-sharing service entirely, offering organizations valuable time to make sure that those computers are correctly patched.

If you wonder about Ziften Zenith, our 20 minute demo consists of a consultation with our specialists around how we can assist your organization prevent the worst digital disaster to strike the internet in years.

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

ed2-1

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

ed2-2

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

ed2-3