Bread and butter attacks

Guardicore Labs has uncovered an SSH brute force attack that has stayed under the radar for years. The attack deploys a RAT with DDoS capabilities and a cryptocurrency miner. In this post, we describe the attack, payload and different preventive steps.

Guardicore Integrates with AWS Security Hub

Today at re:Invent, Amazon revealed the AWS Security Hub, a security service that provides AWS cloud customers with a comprehensive view of their security state within AWS. Guardicore has worked with AWS over the past weeks to provide support and integration to this service. While AWS provides some built-in security capabilities, customers require additional capabilities that can only be provided by third-party companies like Guardicore.

Both Guardicore Centra and Infection Monkey now integrate with the AWS Security Hub. This integration provides a lot of value to customers. Early feedback is extremely positive and AWS customers would find it interesting to test both integrations:

GuardiCore Centra Integration with AWS Security Hub

GuardiCore Centra, our flagship product, secures any cloud-private or public. Security Incidents will be forwarded to the AWS Security Hub and can be managed through the console or consumed by other security products.

Infection Monkey Integration with AWS Security Hub

The Infection Monkey is an open source Breach and Attack Simulation (BAS) tool that assesses the resiliency of private and public cloud environments to post-breach attacks and lateral movement. Its integration with the AWS Security Hub allows anyone to verify and test the resilience of their AWS environment and correlate this information with the native security solutions and benchmark score.

Working on the integration was fun. Since both Centra and Infection Monkey have integration points and can run on AWS, adding reporting interfaces to the Security Hub was a straightforward task.

We believe that the AWS Security Hub represents a good approach, allowing for more shared security insights from more vendors in order to improve the overall security posture of your environment. It detects security findings and alerts generated by other AWS security services, other security solutions (like GuardiCore Centra and Infection Monkey) and aggregates those findings and alerts within each supported AWS region.

During the beta period the service provided integration with Amazon GuardDuty, Amazon Inspector, and Amazon Macie and added new capabilities by running CIS benchmark check for AWS workloads. We are looking forward to your feedback. Tell us- what do you think about the integration?

Policy Enforcement Essentials for your Micro-Segmentation Strategy Policy

Using micro-segmentation to achieve maximum security means creating network policy enforcement that finds the right balance for scope and uses a flexible policy engine that can enforce at both the network and the process levels.

What’s New in Infection Monkey Release 1.6

We are proud to announce the release of a new version of the Infection Monkey, GuardiCore’s open-source Breach and Attack Simulation (BAS) tool. Release 1.6 introduces several new features and a few bug fixes.

Implementing Micro-Segmentation Insights, Part 2: Getting Internal Buy-In

In a recent blog, I revealed part one of my insights from implementing micro-segmentation projects with large customers. Vendors don’t always get the perspective of deep involvement in the execution of these projects, but I have been fortunate enough to cultivate relationships with our customers and have thus been granted an inner view. In my first blog of this series, I discussed short versus long-term objectives and the importance of knowing your goals and breaking them down into phases to ensure that you’re truly working on the important matters first and foremost. In this blog, I want to get into the importance of getting internal buy-in from other teams in order to enable improved implementation. To make the process easier for all involved, “selling” the project to other teams is an important early step.

More often than not the segmentation project is driven by the security organization and they are the ones who see immediate value out of it, but they need the collaboration of other teams to help them deploy the product. It doesn’t really matter if the product is an overlay (usually based on agents) or underlay (comes as a part of the infrastructure).

Some teams will need to carry more of the weight and bear more in the processes of deploying such a project- networking, application, infrastructure, system etc. To achieve collaboration of those teams it helps to carry a carrot, not just a stick. Getting early buy-in on these projects and planning out collaboration from the right people will make the process much easier in the long run. In order to do so, the solution needs to be “sold” internally. And just like with any sales process, the more you are prepared and equipped for this, the smoother it will go.

As is true with any sales process, there will be the “early adopters” and the “late adopters.” In our experience, when the project team was well prepared and presented the benefits of the solution to the other teams, the impact was significant. If you can show the application team how they can benefit from the solution they will not just ease up on the objections, in fact they will be pushing the deployment.

But, there is a significant BUT to this. The product you choose for your segmentation needs to be able to deliver those carrots. It needs to be able to support use cases that are not the clear immediate concern of its direct, original audience. Here is a small example: let’s say you need to convince the application owner to install the agents that will enforce the policy. The application owner usually has little interest in the security use case and might object or hesitate because of the additional player introduced in the mix: wondering how will it affect the stability, and performance etc. But if you are able to demonstrate that he will gain value from the product, he in fact will become the one who pushes the deployment.

One of such value propositions that we constantly see is the value of “getting visibility into your application.” This is of course a great promise, but for the application owner to actually be able to gain value from this visibility, the visibility should have certain properties: it needs to be L7 with application context, it needs to collect data and store it historically (pay attention here that for the sake of building policy the historical aspect of the data is not important at all, you just need to know what connections might happen), and it needs to be searchable and filterable to allow simple and convenient consumption by the application owner. This of course is just one example, but the important lesson is to show the many ways in which the solution can expand beyond the obvious reason for implementation to help ensure buy-in of other teams through the illustration of other benefits.

So, when starting to deploy a segmentation solution make sure that you prepare an on-boarding package for the teams you need to cooperate with that includes ways they can leverage the product to expedite the adoption process and make the projects deadlines. Equally as important, when doing so make sure that the product you choose can actually cater to those use-cases, and many of the products on the market today miss that important point.

Learn more on our micro-segmentation hub or read about GuardiCore Centra for best practices.

Read part one of my insight from implementing micro-segmentation.

Do You Have an Effective Security Incident Response Plan? – Assess your Readiness

The Ponemon Institute has found that the survival rate for businesses without a security incident response plan is just 10%. Enterprises will often focus on creating a strong security posture to detect and thwart attackers, but fail to detail what to do if and when a breach actually occurs. That’s not unusual; it can feel defeatist to prepare for the worst. However, with new attacks being discovered all the time, and increasingly connected networks putting us all at risk, an incident response plan is essential.

1. Understanding the Consequences of Ignoring a Security Incident Response Plan

The first stage in your security incident response strategy needs to be recognizing the ramifications of an attack. From the obvious problems, such as asset and data breach, to reputational damage, compliance failures and public image breakdown, it’s in your company’s best interests to be fully prepared. Detailing these threats in writing can help your staff focus on maintaining a strong security posture to prevent attacks, and encourage everyone to work together with a mutual understanding of what’s at risk if the worst happens.

2. Assigning Roles Before an Emergency

Especially in large organizations, it can be hard to keep everyone in the loop when there is a crisis. Identifying the core stakeholders for a security incident before a breach occurs is therefore essential. Here are some key personnel who need to be detailed in your security incident response plan. In some cases they may be obvious, while in others you might need to choose staff to take on responsibilities for some of these roles in your cyber-security incident response team.

  • Incident response managers . It’s worth having at least two members of staff on hand who can oversee and prioritize the incident response plan, communicating information and tasks throughout the business.
  • Security analysts. Maintain the investigation, support the managers in following the plan, and filter out false positives. They may also alert others to potential attacks. It’s essential to ensure that they are given the right tools to be able to manage their role effectively.
  • Threat researchers. These personnel will be the port of call for contextual information around a threat. Using the web, as well as other threat intelligence, they can build and maintain a database of intelligence internally.
  • Key internal stakeholders. Who needs to be kept in the loop when a threat occurs? From board level personnel who may need to sign off on your actions or give the go-ahead for your response plan, to your CISO or human resources representative if human error is involved.
  • Third-party organizations, such as legal counsel, law enforcement, forensics experts or breach remediation companies.

3. Create a High-Level Document Outlining the Security Incident Response Procedure

Many organizations have multiple playbooks with granular detail on the technical side of an attack, in order to help IT manage and contain a breach. However, if you’ve ever experienced a security incident, you know that IT are far from the only department affected by an attack. Your incident response plan needs to be easily communicated and understood by C-suite employees, Human Resources, Vendor Management and all other lines of business stakeholders including global offices or teams in the field. As regulation increasingly dictates that customers are kept informed when their data is at risk, you may even need customer experience managers to be able to relay your position.

Some of the best security incident response plans are one or two pages, and give a high-level overview of how to manage the consequences of an incident. While playbooks might hold specific information for targeting a type of attack, such as Ransomware, your incident response plan should be written so that it can be read by anyone and understood easily in a moment of crisis.

4. Outline Response Priorities

Not every key stakeholder is going to have the same priorities when an attack hits, and not all priorities can be taken into consideration. For example, your board might want to get your operations up and running as quickly as possible, while legal counsel may suggest staying offline until vendors have been notified or customers contacted. Without a clear outline of whose priorities take precedence, existing relationships can dictate what procedure is followed after a breach, following tribal knowledge rather than smart decision making.

Assessing the scale of an attack and making quick decisions about revenue over security for example should not be done in the moment, or by whomever has the ear of the CISO that day. While you’re building your incident response plan, think about who should have autonomy over decisions that manage risk, and engage them in creating priorities based on levels of threat.

Detailed performance objectives can help here. In the event of a customer data breach, your security team might be tasked with finding out what has been exposed and how many customers are affected within a given amount of time. Making smart decisions about the action needed before a problem becomes a reality means all relevant teams can hit the ground running.

5. Simulate Breaches to Troubleshoot in a Safe Environment

Having an incident response plan is not enough in and of itself. Without testing and simulation, there is no way to recognize gaps in protocol or resources, or to uncover changes in third-party procedure. Regular simulations can ensure that your security incident response strategy remains up to date and nothing falls through the cracks. This can include finding replacements for staff who took on security roles and have now left the company, or for external vendors with lapsed service agreements. It can also help you keep up with changes in regulation, and keep new staff informed of the process in case of a breach.

A simulation can be as in-depth as you would like and can range from table top exercises to injecting your system with a known and containable malware, but a few basics to cover include:

  • Going over the lines of communication from detection to resolution
  • Understanding who is authorized to make decisions on security and risk
  • Confirming you have the third-party services in place you need to control a breach
  • Who needs to be contacted in case of a breach for continued regulatory compliance/operations?

The more you make simulation and testing part of your usual security posture, the more likely it will be second nature for the relevant stakeholders when the incident is no longer theoretical.

6. Identify the Scope of a Breach

Many companies act too quickly when they see a threat. Failing to recognize the size of a breach can cause more problems in the long run. Finding one point of entry does not mean that you’ve identified all the endpoints that have been compromised for example. Acting like you have found patient zero when it’s actually patient 10 or 15 can slow down recovery time overall. Modern day attacks are stealthy and subtle, and could have caused more damage than you might have first assumed.

The best security solutions will intercept suspicious activity on threat detection and reroute it to where it cannot do any harm using dynamic deception. The full extent of the breach can then be searched for and contained in real-time, giving your security team an accurate dynamic map of your entire data center and network. Your automatically generated report shows you the deception incidents, including integral information you need to investigate the breach. What passwords were used, and where did the attacker gain entry? Were there malicious binaries used, or suspicious C&C servers? With this level of detail, your security teams are able to start building up a clear picture of root cause.

Containment of this kind can also give you more time to understand what you’re dealing with in a safe environment. By rerouting an attacker using dynamic deception, you can isolate them safely, and monitor and learn from their activities rather than frighten them away by alerting them that you know they’ve gained entry. In this way, you can take back the upper hand, responding to the attackers behavior without going into crisis mode, calmly following your incident response plan priorities – risk free.

7. Limit Dwell Time

Having this level of granular visibility manages the next part of your incident response plan, limiting the amount of time that attackers are on your network. The SANS Institute found that a shocking 50% of organizations didn’t notice a breach for more than 48 hours, while 7% had no idea how long an attacker had breached their network for, even after the fact. The longer an attack continues for without being stopped, the more damage can be done, so having a plan for limiting this is essential.

Your security solution should be able to limit dwell time by provide application layer visibility. This uncovers and tracks process-level activity (not just at the transport layer) across applications in real-time. This can then be automatically correlated with network events and context, allowing you to access reports on suspected incidents and any anomalies detected across all workloads. With this, even new attack vectors are isolated in real-time. With nowhere for attackers to hide, dwell time is automatically minimized at a policy level.

8. Including Recovery Plans

The clearest part of your security incident response plan should outline what happens when a breach has been confirmed. Detail the processes that are automated so that all key stakeholders understand what has already been put into place.

Does your security solution allow IOCs (Indicators of Compromise) to be automatically exported to your SIEM or security gateways to speed up incident response? Can you update your micro-segmentation policies quickly and seamlessly in response to traffic violations? There might be different automated procedures needed for various environments. For example, stopping the spread of damage from VMs or Containers could involve an IOC halting or disconnecting service entirely. The best solutions will provide an integrated platform that shows the full picture from both a security and an infrastructure point of view.

Recovery plans might need their own smaller security incident response plans or playbooks. A DDoS attack is different from an injection of malware. An external bad actor is a different adversary from an insider with high level access who has compromised the network. Your company might have one set of response plans for a breach to customer data, another for artificial intelligence, and yet another for asset recovery. Make sure the right documentation is ready for any event, and the right personnel are equipped with a plan of action.

9. What Lessons Can You Add to Your Security Incident Response Plan?

By utilizing a smart incident response plan, you can use a breach to help prepare for the future. Once the attack is contained and eradicated, make sure to complete any incident documentation for regulation or internal records. You can also perform your own analysis internally to learn from the attack and your responses to it as a company. With the lessons you’ve learned, you can update your security incident response plan. What can you improve for next time, and what gaps did you uncover if any?

A strong security incident response plan is a must-have in today’s increasingly interconnected IT environment. If and when a breach occurs, your business will be asked how you prepared for an incident. This could be used to establish regulatory compliance as well as assessment of the attack and even blame. Creating a detailed analysis of how your company prepares for a threat, as well as responds in the moment and learns from the experience puts you one step ahead, and ready for anything.

5 Ways that PCI DSS Micro-Segmentation Can Help You Achieve Compliance

The consequences of non-compliance with regulations such as PCI-DSS and HIPAA are increasingly serious, while achieving compliance is only becoming more difficult because of dynamic workloads and hybrid IT environments. How can micro-segmentation make compliance easy again?