Test Your ATT&CK Before the Attack With Guardicore Infection Monkey
https://www.guardicore.com/wp-content/uploads/2020/04/aatck-cover-header.jpg 501 2000 Shay Nehmad https://www.guardicore.com/wp-content/uploads/2019/02/guardicore-logo-white-space.png Shay Nehmad2020-04-27 16:10:562020-04-30 02:04:56Test Your ATT&CK Before the Attack With Guardicore Infection Monkey
https://www.guardicore.com/wp-content/uploads/2020/04/vmw-vul-blog-header-v2-3.jpg 551 1920 JJ Lehmann https://www.guardicore.com/wp-content/uploads/2019/02/guardicore-logo-white-space.png JJ Lehmann2020-04-15 13:42:562020-04-16 04:03:36What’s a 10? Pwning vCenter with
Guardicore Labs provides a full, detailed technical analysis of the latest vulnerability from VMware – CVE-2020-3952. The bug, which hit the maximal score of CVSS 10.0, allows a malicious actor to take over the complete vSphere infrastructure, with all its machines and servers.
https://www.guardicore.com/wp-content/uploads/2020/03/vollgar-blog-header-logo-scaled.jpg 522 2560 Ophir Harpaz https://www.guardicore.com/wp-content/uploads/2019/02/guardicore-logo-white-space.png Ophir Harpaz2020-04-01 07:54:292020-06-29 11:47:10The Vollgar Campaign: MS-SQL Servers Under Attack
Guardicore Labs uncovers an attack campaign that’s been under the radar for almost two years, breaching MS-SQL servers and infecting them with remote-access tools and cryptominers.
https://www.guardicore.com/wp-content/uploads/2020/01/blog-cover.jpg 550 2000 Daniel Goldberg https://www.guardicore.com/wp-content/uploads/2019/02/guardicore-logo-white-space.png Daniel Goldberg2020-01-15 11:32:032020-01-21 03:40:49January 2020’s Patch Tuesday
Guardicore Labs extracts what you need to know regarding the January 2020 Patch Tuesday and data centers.
https://www.guardicore.com/wp-content/uploads/2020/01/zoll-featured-image.png 500 1903 Guardicore Labs Team https://www.guardicore.com/wp-content/uploads/2019/02/guardicore-logo-white-space.png Guardicore Labs Team2020-01-13 06:27:282020-01-14 07:00:02Threats Making WAVs – Incident Response to a Cryptomining Attack
Guardicore security researchers describe and uncover a full analysis of a cryptomining attack, which hid a cryptominer inside WAV files. The report includes the full attack vectors, from detection, infection, network propagation and malware analysis and recommendations for optimizing incident response processes in data centers.
https://www.guardicore.com/wp-content/uploads/2020/01/Iran-2.jpg 500 1903 Daniel Goldberg https://www.guardicore.com/wp-content/uploads/2019/02/guardicore-logo-white-space.png Daniel Goldberg2020-01-08 12:17:452020-01-14 06:07:57Iran Cyber Threats and Defenses
Guardicore Labs explains the danger and current status of online Iranian attacks
https://www.guardicore.com/wp-content/uploads/2019/12/win7eol-blog-cover-v1-80.jpg 500 2700 Daniel Goldberg https://www.guardicore.com/wp-content/uploads/2019/02/guardicore-logo-white-space.png Daniel Goldberg2019-12-15 17:25:402019-12-22 05:10:39Windows Server 2008 R2 and Windows 7 are End of Life
Discover the steps to harden machines running Windows 7, Windows Server 2008 and Windows Server 2008 R2 against the inevitable unpatched vulnerability that will be disclosed for these systems.
https://www.guardicore.com/wp-content/uploads/2019/10/zt-blog-cover-label-sticker.png 4801 15201 Shay Nehmad https://www.guardicore.com/wp-content/uploads/2019/02/guardicore-logo-white-space.png Shay Nehmad2019-10-29 04:08:262020-04-07 00:27:15Guardicore Infection Monkey for Zero Trust
Guardicore Labs releases new Zero Trust features to the Infection Monkey to help organizations assess their zero trust security posture quickly and easily.
https://www.guardicore.com/wp-content/uploads/2019/07/Security-Field-Day_1_931x187.jpg 187 931 Avishag Daniely https://www.guardicore.com/wp-content/uploads/2019/02/guardicore-logo-white-space.png Avishag Daniely2019-07-18 04:07:362019-07-19 03:30:49Guardicore’s Insights from Security Field Day 2019
We had such a great time speaking at Security Field Day recently, presenting the changes to our product since our last visit, and hearing from delegates about what issues concern them in micro-segmentation technology.
The last time we were at Field Day was four years ago, and our product was in an entirely different place. The technology and vision have evolved since then. Of course, we’re still learning as we innovate, with the help of our customers who continually come up with new use cases and challenges to meet.
For those who missed our talk, here’s a look at some of what we discussed, and a brief recap of a few interesting and challenging questions that came up on the day.
Simplicity and Visibility First
At Guardicore, we know that ease of use is the foundation to widespread adoption of a new technology for any business. When we get into discussions with each enterprise, customer, or team, we see clearly that they have their own issues or road map to address. As there is no such thing as the ultimate or only use case for micro-segmentation, we can start with the customer in mind. Our product can support any flavor, any need. Just as examples, some of the most popular use cases include separation of environments such as Dev/Prod, ring fencing critical assets, micro-segmenting digital crown jewels, compliance or least privilege and more general IT hygiene like vulnerable port protocols.
To make these use cases into reality, organizations need deep visibility to understand what’s going on in the data center from a human lens. It’s important to have flexible labeling so that you can physically see your data center with the same language that you use to speak about it. We also enhance this by allowing users to see a particular view based on their need or their role within the company. A compliance officer would have a different use for the map than the CTO, or a developer in DevSecOps for example. In addition, organizations need to enforce both blacklist and whitelist policy models for intuitive threat prevention and response. Our customers benefit from our cutting edge visibility tool, Reveal, which is completely customizable and checks all of these boxes. They also benefit from our flexible policy models that include both whitelisting and blacklisting.
To learn more about how our mapping and visibility happen, and how this helps to enforce policy with our uniquely flexible policy model as well and show quick value, watch our full presentation, below.
Addressing Questions and Challenges
With only one hour for presenting our product, there were a lot of questions that we couldn’t get to answer. Maybe next time! Here are three of the topics we wanted to address further.
Q. How does being agent-based affect your solution?
One of the questions raised during the session was surrounding the fact that Guardicore micro-segmentation is an agent-based solution, as the benefits are clear, but people often want to know what the agent’s impact is on the workload.
The first thing we always tell customers who ask this question is that our solution is tried and tested. It is already deployed in some of the world’s biggest data centers such as Santander and Openlink, and works with a negligible impact on performance. Our agent footprint is very small, less than 0.1% CPU and takes up 185MB on Linux and 800MB on windows. Our resources are also configurable, allowing you to tailor the agent to what you need. At the same time, we support the largest amount of operating systems as compared to other vendors.
If the agent is still not suitable, you can use our L4 collectors, which sit at the hypervisor level or switch level, and give you full visibility, and use our virtual appliance for enforcement, as we touched upon during the talk. As experts in segmentation, we can talk you through your cybersecurity use cases, and discuss which approach works best, and where.
Q. Which breach detection capabilities are included?
Complementary controls are an important element of our solution, because they contribute to the ease of use and simplicity. One tool for multiple use cases offers a powerful competitive edge. Here are three of the tools we include:
- Reputation Analysis: We can identify granular threats, including suspicious domain names, IP addresses, and even file hashes in traffic flows.
- Dynamic Deception: The latest in incident response, this technique tricks attackers, diverting them to a honeypot environment where Labs can learn from their behavior.
- File Integrity Monitoring: A prerequisite for many compliance regulations, this change-detection mechanism will immediately alert to any unauthorized changes to files.
Q. How do you respond to a known threat?
Flexible policy models allow us to respond quickly and intuitively when it comes to breach detection and incident response. Some vendors have a whitelist only model, which impedes their ability to take immediate action and is not enough in a hybrid fast-paced data center. In contrast, we can immediately block a known threat or undesired ports by adding it to the blacklist. One example might be blocking Telnet across the whole environment, or blocking FTP at the process level. This helps us show real value from day one. Composite models can allow complex rules like the real-world example we used at the presentation, SSH is only allowed in Production environment if it comes from Jumpboxes. With Guardicore, this takes 2 simple rules, while with a whitelist model it would take thousands.
Until Next Time!
We loved presenting at Field Day, and want to thank all the delegates for their time and their interesting questions! If you want to talk more about any of the topics raised in the presentation, reach out to me via LinkedIn.
In the meantime, learn more about securing a hybrid modern data center which works across legacy infrastructure as well as containers and clouds.
https://www.guardicore.com/wp-content/uploads/2018/11/incident-response-plan-blog-pic-resize-1.jpg 187 686 Ron Shahnovsky https://www.guardicore.com/wp-content/uploads/2019/02/guardicore-logo-white-space.png Ron Shahnovsky2018-11-08 04:41:532019-12-25 05:56:00Do 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.