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.
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 is one of those terms that can have varied meanings depending on the context. In the context of data center security, application and network policy enforcement refers to any controls that your business uses to govern behavior and access to your network and applications, with special emphasis on east-west (E-W) traffic patterns. Every data center needs a set of rules for how a network is managed and traffic and communications are directed. This enables companies to meet their own governance, security, and compliance requirements. The data center and your clouds are harder to manage than other parts of your network, due to the special characteristics of the virtualization layers. In addition, inside the data center, most of the traffic never traverses a choke point, and so businesses lose the ability to use these parts of a topology as a control point.
Setting up flexible security policies for data centers can therefore be challenging, especially creating policy that finds the right scope, reducing your attack surface in case of a breach but allowing you to remain adaptable. This task is even more challenging in case of networks with thousands or more workloads, varied locations and multiple cloud architectures. To provide maximum risk-reduction, security policies should be built and enforced both on the network and process levels.
Micro-segmentation technology was invented to solve the challenges of how to secure the data center from the inside, prevent lateral movements, meet compliance requirements and gain east-west traffic visibility. Using the right micro-segmentation policy, these rules can be truly granular – not only keeping environments from interacting with one another with coarse segmentation, but also making fine-grained policy. With GuardiCore Centra, your micro-segmentation project is enabled with enforcement capabilities that enable you to orchestrate at the flow level and even down to the process level on all platforms, allowing you to meet different security and compliance mandates and use micro-segmentation as a security solution as well as a compensating control for compliance where other tools can’t be used.
Finding the Right Scope for your Policy Enforcement Strategy
Anyone involved in compliance and security knows that defining the scope is the biggest initial challenge. One of the first stages of creating effective micro-segmentation policy is to be clear about your policy objectives, both for business and security. If you’re just looking at security, the more granular your policies are, the stronger your security posture is. However, this could also limit communication and flexibility. The wrong policy choice could cause frustration or delays for your business. Overall, smart micro-segmentation policy allows you to enforce a strong security policy without compromising your communications or your business goals.
Network policy enforcement is well known as a method to help businesses meet compliance regulations. Take PCI DSS for example. By reducing the scope of what can reach your CDE, you are dramatically reducing the work it takes to achieve compliance. By building application-aware policies, you can enforce system access to specific data. If your policies segment all the way to Layer 7, the application layer, attackers who have breached your perimeter still can’t pivot from an out-of-scope area to one that is in scope. With tier segmentation, this can be enforced even within the same application cluster.
Strategies for Practical Implementation of Micro-segmentation Policy
First, you will want to map out your business objectives and gain visibility of your environment, understanding application dependencies and flows within your architecture as a whole. Then, you can start to think about the kinds of controls that are required for your business and teams. This will allow you to set the right policy enforcement. A good security solution will allow you to start with global, high-level rules, and then add layers, increasing the granularity of your policies.
Some rules will apply to large segments, such as only allowing the sales staff to access the sales applications, or allowing DNS resolving through the internal, secure DNS cluster, keeping the production environment separate from the test environment altogether. With GuardiCore you can also define blocking rules as part of your micro-segmentation policy strategy. In fact, you can combine both allow rules and block rules within the same policy. This will enable you to define rules like blocking non-admin access to SSH on the network.
Micro-segmentation policy should allow you to be creative, providing the ability to use different collection and enforcement methods based on your clouds and network topologies. With this technology, you can set up the rules that balance your unique needs for flexibility and security.
The following are some examples of policy creation ideas. Some are coarse, while others show the benefits of enforcing at a granular level.
- Separating between Development, Production and Test environments (as requested by regulations like PCI-DSS)
- Restricting access to servers from non-server environments
- Application segmentation inside environments, for example allowing the Sharepoint applications to communicate with internal storage while limiting other types of traffic
- Tier segmentation inside application environments, such as communication between a web server and a DB server
- Restricting admin access to servers to comply with EU regulations such as GDPR
- Blocking all un-encrypted protocols such as FTP or Telnet within your data center traffic
- Denying a specific application tier or data center area from communicating with the internet
Building Flexible Policy Enforcement That Works in the Real World
Businesses are increasingly moving away from static business environments that have flat structures or on-premise data centers. Whichever policy engine a company chooses needs to be future-proof, allowing policy creation that gives control over auto-scaled workflows, expanding and contracting services, or processes that are constantly changing and adapting. Hybrid-cloud data centers are a great example of this kind of environment, where traditional inflexible policy engines can’t provide adequate dynamic provision.
In contrast, a flexible policy engine will support the latest breakthroughs in policy enforcement, such as the ability to support auto-scaling environments , or to allow the policy to follow the workload, no matter what platform it is on or on which kind of cloud it is deployed. This is impossible if policy is expressed in IP address, ranges, or VLANs. In order to really get the benefits of micro-segmentation technology in network policy enforcement, your policy engine and labeling need to be able to breathe with your data center, providing different models of control methods, able to give both quick wins and ongoing risk-reduction. In other words, you are able to see clearly how the entire data center behaves and communicates, application-wise and turn it into a policy using allow rules, while adding block rules to enforce compliance and best-practice security requirements.
Being Smart About Network Policy Enforcement
Not all micro-segmentation policy enforcement solutions are created equally. With the help of a flexible policy engine that supports both allow and block rules and includes policies built and enforced on a process level as well as a network level, you can take policy enforcement to the next level. Firstly, you can achieve visibility over your entire environment. Secondly, it allows you to enforce at a level of granularity that your organizational maturity can tolerate. Thirdly, it allows you to eliminate a lot of risk fast, using a small number of rules.
Using a micro-segmentation policy enforcement engine that supports granular deep visibility and micro-segmentation policies makes your investment yield even more results, faster. With such an engine, the real-time view of the dependencies and communication on your network can be turned into policies that suit the context of your unique business objectives and needs, strengthening your security posture without limiting business agility.
For more information on micro-segmentation, visit our Micro-Segmentation Hub.
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.
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.
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.
As regulations for compliance become increasingly stringent, the consequences for failing an audit go far beyond a bureaucratic headache. As well as damage to your public image, you could be subject to financial penalties and even a halt to your business operations altogether until safety measures have been put into place.
Relying on a security solution that employs micro-segmentation can be a powerful tool that provides unparalleled control over the traffic cross your hybrid IT ecosystem. The right approach will be able to isolate and segment all applications, monitoring and routing all traffic, including east-west. By doing this, micro-segmentation can effortlessly check boxes for your compliance regulations, whether that’s PCI-DSS, HIPAA, or others.
PCI DSS Micro-Segmentation through Separation of Zones
When it comes to PCI DSS, micro-segmentation can support you in reducing scope. The compliance regulations are very clear. “To be considered out of scope for PCI DSS, a system component must be properly isolated from the cardholder data environment (CDE), such that even if the out-of-scope system component was compromised it could not impact the security of the CDE.” A similar rule is found for HIPAA compliance, but this time regarding Protected Health Information (PHI).
It is likely that some systems can be physically separated from your CDE or PHI. In the past, firewalls could enforce network zones, as could virtual LANs with strong ACLs. However, more complex architecture such as cloud-based VMs or containers have this made this difficult. Even simple compliance regulations, such as placing a firewall, become a challenge. Additionally, dynamic workloads mean you need granular visibility of where changes are happening within the CDE in real-time. This has encouraged businesses to look for a solution that allows for continuous process or identity level detail and control.
Ensuring that you have rich visibility into the flow of traffic is number one on the list for any auditor. This has two benefits. Firstly, it shows the regulatory board that you have a strong understanding of the data and access in your network. Secondly, it proves that you can automatically detect a threat or breach if the worst happens.
Reduced Impact of a Breach
Once you have established visibility, controlling traffic to isolate and resolve an attack should be next on the agenda. By starting with broad micro-segmentation policies and then creating more specific layers you can achieve the right balance between under and over segmenting your network. This should be done gradually, allowing you to gain the perfect amount of control without losing functionality and flexibility. Because the policies you build for micro-segmentation are application-aware, you can use them to enforce system access to specific regulated data, such as PHI for HIPAA compliance. Even if a breach happens to your perimeter, a hacker would not be able to move from an out of scope area to one that threatens compliance posture. Companies that only focus on protecting their perimeter between external and internal systems are behind the times. If attackers get through your perimeter, your entire data center or network is up for grabs. For PCI-DSS, micro-segmentation can provide a deeper level of security on all the important systems on your network. It can also stop attackers from making lateral moves within your network, pivoting dangerously from an out of scope area to one which can reach your CDE or PHI.
Another benefit for HIPAA or PCI DSS, micro-segmentation can meet the requirement of maintaining a vulnerability management program. For this to work best, your solution needs to work in tandem with a strong breach detection and mitigation solution, protecting your system against malware. Micro-segmentation works with the principle of least privilege, perfect for verticals like healthcare dealing with HIPAA compliance, where 70% of organizations cite employee negligence as the most worrying reason for breaches.
Another important element to keep in mind for compliance is having separate development and testing environments from production environments. Top tip: Make sure that scanning and auditing is done in a continuous cycle, not just periodically.
Locking Down Systems with PCI DSS Micro-Segmentation
PCI DSS dictates that more in-depth security features should be implemented for what they call “insecure” services, daemons or protocols. An example of this could be using a VPN for file sharing. Using a flexible policy engine is an important element of a compliance-ready micro-segmentation approach. This can enable you to validate administrative access to each system, and restrict specific protocols to using additional security measures.
Another element of compliance is ensuring that only one primary function can be implemented on each server. This means that functions with different security levels cannot be on the same server, preventing lateral moves from weaker entry points. By implementing PCI DSS micro-segmentation, process level policies can be enforced so that only necessary services are making connections, and only one secure function is implemented per server.
Logging all Systems and Mapping Vulnerabilities in PHI or PCI Micro-Segmentation
As well as showing that you’ve created zones in your network, nearly all compliance regulations will expect you to have visibility into the traffic that moves among them and the ability to log this information for later. Traditionally, companies have had visibility into north-south traffic which moves between client and server. The best approaches can now analyze and monitor east-west traffic, also known as server to server traffic, from within the data center itself. The policies that you define for your micro-segmentation approach can be used as documentation of your compliance, and the granular detail of east-west traffic serves as proof that you have a strong security posture that meets regulations.
Many businesses struggle to prove the systems that they have deemed out of scope actually are separate from their CDE or PHI, especially when dynamic boundaries are part of their IT infrastructure. If you choose a PCI micro-segmentation approach with labeling functionality, you can examine the PCI or PHI environments and inspect the flows and communications in granular detail. Filtering where necessary can allow you to drill down to specific protocols at process level, granting you unparalleled levels of control in comparison to traditional network segmentation.
Finding an All-Inclusive Solution for Compliance
There are many requirements for ongoing compliance, and companies will need to have various security controls in place to establish they are meeting the regulations of complex standards like PCI DSS or HIPAA. For example, when you’re employing PCI DSS micro-segmentation to meet regulations, you will need a distributed firewall to separate the CDE from other applications, as well as file integrity monitoring on your CDE itself. For mapping and documentation you’ll benefit from powerful process level visibility on traffic and data flows.
Lastly, especially important in compliance-heavy industries like healthcare where attacks are so common, your micro-segmentation approach should integrate with tools that allow you to secure the environment and maintain overall vulnerability control. These could include powerful breach detection tools like honeypots and malware detection, Choose a solution that covers many requirements in one, and you’ll take on less risk and management overall, simplifying the road to ongoing compliance.
For more information on micro-segmentation, visit our Micro-Segmentation Hub.
Learn more about micro-segmentation and PCI compliance.