Tag: Business Continuity Plan

Apply best routing practices liberally. Repeat each morning
Solve the DDoS problem? No problem. We’ll just get ISPs to rewrite the internet.In this interview Ian Levy, technical director of GCHQ’s National Cyber Security Centre, says it’s up to ISPs to rewrite internet standards and stamp out DDoS attacks coming from the UK.In particular, they should change the Border Gateway Protocol, which lies at the heart of the routing system, he suggests.
He’s right about BGP.It sucks.

ENISA calls it the “Achilles’ heel of the Internet”.In an ideal world, it should be rewritten.In the real one, it’s a bit more difficult.
Apart from the ghastly idea of having the government’s surveillance agency helping to rewrite the Internet’s routing layer, it’s also like trying to rebuild a cruise ship from the inside out.
Just because the ship was built a while ago and none of the cabin doors shut properly doesn’t mean that you can just dismantle the thing and start again.It’s a massive ship and it’s at sea and there are people living in it.
In any case, ISPs already have standards to help stop at least one category of DDoS, and it’s been around for the last 16 years.

All they have to do is implement it.
Reflecting on the problem
Although there are many subcategories, we can break down DDoS attacks into two broad types.

The first is a direct attack, where devices flood a target with traffic directly.
The second is a reflected attack. Here, the attacker impersonates a target by sending packets to another device that look like they’re coming from the target’s address.

The device then tries to contact the target, participating in a DDoS attack that knocks it out.
The attacker fools the device by spoofing the source of the IP packet, replacing their IP address in the packet header’s source IP entry with the target’s address.It’s like sending a letter in someone else’s name.

The key here is amplification: depending on the type of traffic sent, the response sent to the target can be an order of magnitude greater.
ISPs can prevent this by validating source addresses and using anti-spoofing filters that stop packets with incorrect source IP addresses from entering or leaving the network, explains the Mutually Agreed Norms for Routing Security (MANRS).

This is a manifesto produced by a collection of network operators who want to make the routing layer more secure by promoting best practices for service providers.
Return to sender
One way to do this is with an existing standard from 2000 called BCP 38. When implemented in network edge equipment, it checks to see whether incoming packets contain a source IP address that’s approved and linked to a customer (eg, within the appropriate block of IPs).If it isn’t, it drops the packet.Simple.

Corero COO & CTO Dave Larson adds, “If you are not following BCP 38 in your environment, you should be.If all operators implemented this simple best practice, reflection and amplification DDoS attacks would be drastically reduced.”
There are other things that ISPs can do to choke off these attacks, such as response rate limiting.

Authoritative DNS servers are often used as the unwitting dupe in reflection attacks because they send more traffic to the target than the attacker sends to them.

Their operators can limit the number of responses using a mechanism included by default in the BIND DNS server software, for example, which can detect patterns in incoming traffic and limit the responses to avoid flooding a target.
The Internet of Pings
We’d better sort this out, because the stakes are rising.

Thanks to the Internet of Things, we’re seeing attackers forklift large numbers of dumb devices such as IP cameras and DVRs, pointing them at whatever targets they want. Welcome to the Internet of Pings.
We’re at the point where some jerk can bring down the Internet using an army of angry toasters.

Because of the vast range of IP addresses, it also makes things more difficult for ISPs to detect and solve the problem.
We saw this with the attack on Dyn in late October, which could well be the largest attack ever at this point, hitting the DNS provider with pings from tens of millions of IP addresses.

Those claiming responsibility said that it was a dry run.
Bruce Schneier had already reported someone rattling the Internet’s biggest doors. “What can we do about this?” he asked. “Nothing, really.”
Well, we can do something. We can implore our ISPs to pull their collective fingers out and start implementing some preventative technology. We can also encourage IoT manufacturers to impose better security in IoT equipment.
Let’s get to proper code signing later, and start with just avoiding the use of default login credentials first. When a crummy malware strain like Mirai takes down half the web using nothing but a pre-baked list of usernames and passwords, you know something’s wrong.
How do we persuade IoT vendors to do better? Perhaps some government regulation is appropriate.Indeed, organizations are already exploring this on both sides of the pond.
Unfortunately, politicians move like molasses, while DDoS packets move at the speed of light.In the meantime, it’s going to be up to the gatekeepers to solve the problem voluntarily. ®
Sponsored: Want to know more about PAM? Visit The Register's hub

The Network Time Foundation's Network Time Protocol Project has patched multiple denial-of-service vulnerabilities with the release of ntp-4.2.8p9.

The last update to the open source protocol used to synchronize computer clocks was in June.
"NTP users are strongly urged to take immediate action to ensure that their NTP daemons are not susceptible to being used in DDoS (distributed denial-of-service) attacks," the project maintainers wrote in the security advisory.
NTP is a widely used protocol, and has been hijacked several times over the past two years in distributed denial-of-service attacks.

Attackers harness the power of the servers running NTP and amplify the amount of traffic -- as much as 1,000 times the size of the initial query -- sent to victim systems. Research from network security company Arbor Networks estimated that 85 percent of volumetric DDoS attacks exceeding 100Gbps in size were NTP reflection attacks.
Some of the vulnerabilities are easy to exploit, and there is a proof of concept already available for one of them.

Attackers are increasingly exploiting the limitations of older protocols like NTP to generate large volumes of junk traffic used for large DDoS attacks, network company Akamai said in a previous State of the Internet report.
Issues fixed in ntp-4.2.8p9
The most serious vulnerability lets attackers crash Windows systems by sending "too big" packets (CVE-2016-9312).

The update also includes fixes for two medium, two medium-low, and five low-severity vulnerabilities, all of which can be exploited to cause a denial of service. One of the medium-severity flaws (CVE-2016-7431) was related to a regression in the handling of some Zero Origin timestamp checks. One of the low-severity flaws (CVE-2016-7433) was related to a previously fixed bug where the jitter value was higher than expected and affected initial sync calculations.
Two vulnerabilities were related to the trap service in NTPD. While trap is not enabled by default, if the service is explicitly enabled, attackers can send specially crafted packets to cause a null pointer dereference (CVE-2016-9311) that will crash NTPD.

The configuration modification vulnerability in the control mode (mode 6) functionality of NTPD (CVE-2016-9310) can be exploited by a remote, unauthenticated attacker.
"If, against long-standing BCP recommendations, restrict default noquery is not specified, a specially crafted control mode packet can set NTPD traps, providing information disclosure and DDoS amplification, and unset NTPD traps, disabling legitimate monitoring," according to the advisory.
Two of the low-severity vulnerabilities exploited NTP's broadcast mode.

They were originally intended to be used only on trusted networks, but now attackers with access to the broadcast service can abuse the replay prevention functionality (CVE-2016-7427) and the poll interval enforcement functionality (CVE-2016-7428) to cause NTPD to reject broadcast mode packets from legitimate NTP broadcast servers.
If NTPD is configured to allow mrulist query requests, a server sending malicious mrulist queries will crash NTPD (CVE-2016-7434).

The researcher who reported this vulnerability, Magnus Stubman, has publicly released the proof of concept, likely because the low-severity vulnerability, with a score of 3.8 on the Common Vulnerability Scoring System, is highly exploitable.
"The vulnerability allows unauthenticated users to crash NTPD with a single malformed UDP packet, which causes a null pointer dereference," Stubman wrote.
If the server response on a socket corresponds to a different interface than what was used for the request, NTPD updates the peer structure to use the newer interface. On hosts with multiple interfaces in separate networks and where the operating system isn't checking the packet's source IP address, attackers can send a packet with spoofed source addresses to trick NTPD to select the wrong interface (CVE-2016-7429). Repeating the attack even once per second is enough to prevent NTPD from synchronizing with the time server.
Rate limiting prevents brute-force attacks on the origin timestamp, but if the server is misconfigured, it can be abused in a DDoS attack.

Attackers can send packets with spoofed source addresses and keep the rate limiting activated, which would prevent NTPD from accepting valid responses from other sources (CVE-2016-7426).
Mitigations and recommendations
Along with updating to ntp-4.2.8p9, the project maintainers recommended implementing Ingress and Egress filtering through BCP-38 to "defeat denial-of-service attacks." Many DoS attacks rely on IP source address spoofing to hide the packet's point of origin, making it hard for defenders to know where the network traffic is coming from.

BCP-38 filtering lets administrators block IP packets that have forged IP addresses.If the device is not allowed to send packets with source addresses other than its own, then that device can't be hijacked to spew junk traffic as part of a DDoS attack.
Other recommendations included:
Monitoring NTPD instances and autorestarting the daemon without the -g flag if it stops running
Using restrict default noquery in the ntp.conf file to allow only mode-six queries from trusted networks and hosts
Using broadcast mode only on trusted networks
Creating a firewall rull to block oversized NTP packets, especially on Windows
Allowing mrulist query packets only from trusted hosts
Configuring the firewall to control what interfaces can receive packets from which networks, especially if the operating system isn't performing source address checks
Configuring rate limited with restrict source in the ntp.conf file, instead of restrict default limited
The Department of Homeland Security's Computer Emergency Response Team at Carnegie Mellon University's Software Engineering Institute maintain a list of vendors implementing NTP.

At the moment, the status of most vendors is listed as "Unknown."
Update or replace?
Whenever there is a security vulnerability in a widely used open source project, a segment of IT and security folks pounce on the report as proof people should abandon using the software and switch to something else. NTP is no different, as the 30-year-old protocol lacks security features and is vulnerable to abuse.

There are many who think administrators should use secure alternatives, but most tend to be complex or not yet mature enough for widespread adoption.
The "don't update, replace," argument is impractical. Replacing crucial services without thinking through how the new tool would be supported causes more administrative headaches.It may be a simple enough task to uninstall NTPD, but if administrators don't know how to configure the new tool correctly, monitor the performance, and troubleshoot resulting issues, then the replacement tool doesn't do much to improve overall security.

Any replacement should come after a thorough review of the alternatives, be tested thoroughly in a nonproduction environment, and have controls to monitor and secure the software.

Networks also need to grab a mirror and look at themselves
Last Friday's Mirai botnet attack against Dyn must force everybody's hands – vendors, regulators, and Internet infrastructure operators.
It's going to be a while before research gets as far as attribution to an attacker, but in the meantime, there's plenty of culpability to go around.
Two things are clear, however: the freewheeling idiots of the Internet of Things business need the fear of regulation put into them – and so do network owners and operators.
Vendors
We don't just mean the specific vendor, XiongMai, named by Flashpoint as making the cameras exploited by Mirai.

Buggy cameras and DVRs, to pick out just one product segment, are all over the place.
Since the White House asked Mudge to create a “Cyber UL” last year, the industry got busy with a flurry of activity designed, we suspect, to prove it could handle things without Washington getting involved.
Within a month, the industry formed a committee, in the Online Trust Alliance.
Then it formed another, the IoT Security Foundation.
Then another, the http://www.theregister.co.uk/2016/02/20/new_iot_foundation/ Open Connectivity Foundation.
The Industrial Internet Consortium, late to the party, recently came up with its own guidelines.
What are the outputs from all of these talking-shops? Nowhere near enough.
The Online Trust Alliance needed 15 month to finally come up with a vision for IoT security.
The IoT Security Foundation promises best practice guidelines by the end of this year.
The Open Connectivity Foundation has gone further, opening certification labs this month to let its members certify products (including one at Underwriters Laboratory in the US), and has published an open source software framework.
It's just as well for the various vendor love-ins that Mirai happened after last week's conference with the National Telecommunications and Information Administration, or vendors might have genuinely been hauled over the coals.
Why are there so many mostly slow-moving IoT security gatherings?
Partly it's because nobody wants to standardise their interfaces or APIs when Google (try Threading or Weaving your way to a thorough understanding of where Brillo fits, and why Nest doesn't like any of them), Apple (HomeKit), Samsung (SmartThings), LG (SmartThinQ), or Amazon still all reckon they can corner the market.
And as we said, partly it's probably to prove to the Feds that regulation isn't needed.
Too late, everybody: Mirai proves you're not going to march in step without a whip at your back.

The world knows your products can at least pass a standard, basic security test suite, and will get recalled if they can't.
And while things move slowly in Washington, we're heartened that Mudge's efforts have given rise to research to try and quantify security risks, here.
Internet infrastructure companies
From the edge to the core, Internet minnows and whales knew that DNS can be blasted by a botnet, because it's happened before – when DNS-changer-infected PCs attacking the system were quarantined in a then-unprecedented cooperation between Internet companies and the FBI.
Paul Vixie has was at the heart of that response, and is so disheartened by things that in March of this year, he suggested governments get involved, by way of penalties for network operators that don't block attack traffic.
The Internet Society (ISOC) warned last year that the Internet is in danger from the IoT, and while it's put forward routing security proposals, the MANRS initiative needs a lot more members before it could prevent something like the Dyn outage.
ISOC warned in 2014 that network owners' failure to implement the BCP 38 anti-spoofing standard (authored in 2000) puts the internet at risk.
It's no surprise, though: another key measure to secure the DNS, DNSSec, was first written in 1997 and after nearly 20 years has gone nearly nowhere.
DNS Changer proved that network operators can put responses in place: that Dyn succumbed to the Mirai botnet is because they choose not to.
The Internet is too embedded in nearly every business operation for repeats of the Dyn attack.
Operators who have known how to fix the DNS, and IoT vendors who don't care about security, are both inviting the heavy hand of regulation. ®

- Provider named a Niche Player in 2016 Magic Quadrant for DRaaS -London-based provider Databarracks has been recognised in Gartner’s June 2016 Magic Quadrant for Disaster Recovery as a Service.

Gartner, Inc., a leading IT research and advisory firm, has positioned Databarracks in the Niche Players quadrant for a second consecutive year.
Peter Groucutt, managing director at Databarracks, commented on the announcement:“We’re thrilled to be included in Gartner’s Magic Quadrant for Disaster Recovery as a Service for a second year. We believe that to be recognised as a niche player in the global market is a testament to our success over the past 12 months.
“We provide flexible management processes and rapid failover times. Providing a service that meets each of our customers’ requirements is something that we pride ourselves on. We’re not a one-size-fits-all operation, we build personal relationships with our clients to really understand their needs.
“We were early to the cloud disaster recovery market and coined the term Virtual Disaster Recovery.In the last few years there has been a surge in interest in cloud based DR.

DRaaS is so significant because organisations can reduce their costs and improve their recovery compared with traditional disaster recovery services.
“Organisations don’t want the expense of running secondary data centres purely for disaster recovery. With DRaaS, they get the flexibility of cloud computing combined with recovery experts they can rely on to get them up and running again in the event of a disaster.
“We’ve worked very hard over the last year, developing our services and educating the market on recovery best practice. We introduced a suite of tools to allow organisations to track and measure their risk, benchmark their resilience and map their technology dependencies to the systems that support their business. We developed a DR testing simulator and have recently launched The Business Continuity Podcast to show organisations without dedicated BCP practitioners how the experts do it.
“We have also been investing in developing the next generation of disaster recovery services which we will be launching in the coming months.”
Gartner evaluates providers based on their ability to execute and their completeness of vision.

Groucutt is especially proud of his organisation’s position due to its relative size within the market:“Compared to a lot of our competitors in the disaster recovery area, we’re considered a fairly small organisation.

As a UK-only provider, we were ecstatic to be recognised in a report that is so globally revered.

To be recognised alongside such big, global providers and to be edging ever-closer toward the “visionaries” quadrant, we believe is proof that our hard work is paying off.”
To get a copy of Gartner’s Magic Quadrant for Disaster Recovery, please click here: http://www.databarracks.com/disaster-recovery-as-a-service/databarracks-named-in-gartners-magic-quadrant-form/
- Ends -
About the Magic QuadrantGartner does not endorse any vendor, product or service depicted in its research publications, and does not advise technology users to select only those vendors with the highest ratings or other designation.

Gartner research publications consist of the opinions of Gartner's research organization and should not be construed as statements of fact.

Gartner disclaims all warranties, expressed or implied, with respect to this research, including any warranties of merchantability or fitness for a particular purpose.
About Databarracks:Databarracks provides ultra-secure, award winning Disaster Recovery, Backup and Infrastructure services from UK-based, ex-military data centres.
Databarracks is certified by the Cloud Industry Forum, ISO 27001 certified for Information Security.

CATEGORIES

Cyber Parse was created to provide knowledge to help everyone understand and deal with the ever increasing threats we all face by Cyber Crime (Malware, Social Engineering, Phishing and hacking).
Our purpose is to provide the right information to our readers by breaking down and communicating knowledge relating to Cyber Crime, Cyber Security, Information Security and Computer Security, then using Risk Management practices to help translate the technical aspects of the Risks, Threats, Vulnerabilities and controls to reduce the risk into business language.