Legacy security products are not keeping up.
The network is your security tool. Sound familiar?
Addy draws interpretations from the data ExtraHop is picking up real-time.
Curtail shuts down infected servers and moves customers to a fresh copy.
Watson can spot anomalies in the network.
In the first post on DDoS, I considered some mechanisms to disperse an attack across multiple edges (I actually plan to return to this topic with further thoughts in a future post). The second post considered some of the ways you can scrub DDoS traffic. This post is going to complete the basic lineup of reacting to DDoS attacks by considering how to block an attack before it hits your network—upstream.
The key technology in play here is flowspec, a mechanism that can be used to carry packet level filter rules in BGP. The general idea is this—you send a set of specially formatted communities to your provider, who then automagically uses those communities to create filters at the inbound side of your link to the ‘net. There are two parts to the flowspec encoding, as outlined in RFC5575bis, the match rule and the action rule. The match rule is encoded as shown below—
There are a wide range of conditions you can match on. The source and destination addresses are pretty straight forward. For the IP protocol and port numbers, the operator sub-TLVs allow you to specify a set of conditions to match on, and whether to AND the Continue reading
VMware NSX Micro-segmentation Day 1 is available for free download! VMware NSX Micro-segmentation Day 1 is a concise book that provides the necessary information to guide organizations interested in bolstering their security posture through the implementation of micro-segmentation.VMware NSX Micro-segmentation Day 1 highlights the importance of micro-segmentation in enabling better data center cyber hygiene. It also provides the knowledge and guidance needed to effectively design and implement a data center security strategy around micro-segmentation.
VMware NSX Micro-segmentation covers the following topics.
The post VMware NSX Micro-segmentation Day 1 Book Available! appeared first on The Network Virtualization Blog.
NSX-V 6.2 introduced the Cross-NSX feature to allow for NSX logical networking and security across multiple vCenter domains. The ability to apply consistent networking and security across vCenter domains provides for mulitple use cases for Cross-VC NSX: workload mobility, resource pooling, multi-site security, ease of automation across sites, and disaster avoidance/recovery. With the recent release of NSX-V 6.3, several enhancements have been added to the Cross-VC NSX feature to provide for additional capabilities and overall robustness of the solution. In this blog post I’ll discuss the new Cross-VC NSX security enhancements in NSX-V 6.3. For additional information on Cross-VC NSX check-out my prior Cross-VC NSX blog posts.
The security enhancements for Cross-VC NSX can be grouped into two categories:
Active/Active and Active/Standby above refers to if the application is active at both sites or if it is active at one site and standby at another site (ex: disaster recovery). Enhancements for both of these respective categories are discussed in more detail below.
1.) General Enhancements (Apply Across both Active/Active and Active/Standby deployment models)
It happens time and time again with any new technology. Coders create this new thing, it gets deployed as an experiment and, if it is an open source project, shared with the world. As its utility is realized, adoption suddenly spikes with the do-it-yourself crowd that is eager to solve a particular problem. And then, as more mainstream enterprises take an interest, the talk turns to security.
It’s like being told to grow up by a grownup, to eat your vegetables. In fact, it isn’t like that at all. It is precisely that, and it is healthy for any technology …
Locking Down Docker To Open Up Enterprise Adoption was written by Timothy Prickett Morgan at The Next Platform.
Demisto's platform automates triage among third-party security tools.
Containers are changing how we view apps and infrastructure. Whether the code inside containers is big or small, container architecture introduces a change to how that code behaves with hardware – it fundamentally abstracts it from the infrastructure. Docker believes that there are three key components to container security and together they result in inherently safer apps.
A critical element of building safer apps is having a secure way of communicating with other apps and systems, something that often requires credentials, tokens, passwords and other types of confidential information—usually referred to as application secrets. We are excited to introduce Docker Secrets, a container native solution that strengthens the Trusted Delivery component of container security by integrating secret distribution directly into the container platform.
With containers, applications are now dynamic and portable across multiple environments. This made existing secrets distribution solutions inadequate because they were largely designed for static environments. Unfortunately, this led to an increase in mismanagement of application secrets, making it common to find insecure, home-grown solutions, such as embedding secrets into version control systems like GitHub, or other equally bad—bolted on point solutions as an afterthought.
We fundamentally believe that apps are safer if Continue reading
AT&T, IBM, Palo Alto Networks, Symantec, and Trustonic are members.
In the next session of Network Automation Use Cases webinar (on Thursday, February 16th) I’ll describe how you could implement automatic deployment of network services, and what you could do to minimize the impact of unintended consequences.
If you attended one of the previous sessions of this webinar, you’re already registered for this one, if not, visit this page and register.
Biggest announcement ever! (In terms of volume.)
Organizations must build key programming skills in their network engineers.
10-year-old company starts watching devices from afar.
Your first line of defense to any DDoS, at least on the network side, should be to disperse the traffic across as many resources as you can. Basic math implies that if you have fifteen entry points, and each entry point is capable of supporting 10g of traffic, then you should be able to simply absorb a 100g DDoS attack while still leaving 50g of overhead for real traffic (assuming perfect efficiency, of course—YMMV). Dispersing a DDoS in this way may impact performance—but taking bandwidth and resources down is almost always the wrong way to react to a DDoS attack.
But what if you cannot, for some reason, disperse the attack? Maybe you only have two edge connections, or if the size of the DDoS is larger than your total edge bandwidth combined? It is typically difficult to mitigate a DDoS attack, but there is an escalating chain of actions you can take that often prove useful. Let’s deal with local mitigation techniques first, and then consider some fancier methods.
DANZ addresses customer's concerns for more security.
A weak Q3 is now a distant memory.
Welcome to Technology Short Take #77. I’ve got a new collection of links and articles from around the Web on various data center-focused technologies.