Threat Intelligence |
Sponsored by |
The Network Time Protocol (NTP) has been in the news a number of times over the past couple of years because of attacks on the protocol, vulnerabilities in the daemon, and the use of NTP in DDoS attacks. In each case, the developers of NTP have responded quickly with fixes or recommendations for remediating these attacks. Additionally, the development team has continued to look ahead and has worked to enhance the security of NTP. Unfortunately, that has not translated to an improved security picture for NTP.
The dividing line between developers and IT operations used to be distinct. Developers were responsible for adding new features securely, but it was IT operations who had responsibility for infrastructure and network security. For the most part, developers didn't have to think too much about the wider security context. With the advent of the cloud, and of devops, things changed radically.
Hacking remains a huge problem for businesses. As noted by MarketWatch, more than 175 data breaches have already happened this year, and in 2015 approximately 105 million adults in the United States had their personal information stolen. For companies, the stakes are huge: Compromised systems not only damage the bottom line but can severely impact public opinion.
For more than 30 years, the industry has used a service and protocol named WHOIS to access the data associated with domain name and internet address registration activities... The challenge with WHOIS is that it was designed for use at a time when the community of users and service operators was much smaller and there were fewer concerns about data privacy.
One of the most interesting and important changes to the internet's domain name system (DNS) has been the introduction of the DNS Security Extensions (DNSSEC). These protocol extensions are designed to provide origin authentication for DNS data. In other words, when DNS data is digitally signed using DNSSEC, authenticity can be validated and any modifications detected.
FireEye announced a new piece of malware yesterday named MULTIGRAIN. This nasty piece of code steals data from Point of Sale (PoS) and transmits the stolen credit card numbers by embedding them into recursive DNS queries. While this was definitely a great catch by the FireEye team, the thing that bothers me here is how DNS is being used in these supposedly restrictive environments.
What appears to be a leaked copy of the Burr-Feinstein on encryption back doors. Crypto issues aside -- I and my co-authors have written on those before -- this bill has many other disturbing features. (Note: I've heard a rumor that this is an old version. If so, I'll update this post as necessary when something is actually introduced.) One of the more amazing oddities is that the bill's definition of "communications" (page 6, line 10) includes "oral communication", as defined in 18 USC 2510.
The 24th DNS-OARC meeting was held last week in Buenos Aires -- a two-day DNS workshop with amazingly good, consistent content. The programme committee are to be congratulated on maintaining a high quality of presentations. Here are my picks of the workshop. They fall into three groups, covering themes I found interesting... These presentations related to the ongoing problem of DNS as a source of reflection attacks, or a victim of attempted DDoS...
This week, the RightsCon Silicon Valley 2016 conference is taking place in San Francisco. Since the use of encryption in general and the Apple/FBI case in particular are likely to be debated, I want to share a perspective on system security. My phone as a system The Apple/FBI case resolves around a phone. Think of your own phone now. When I look at my own phone I have rather sensitive information on it.
As you probably know, the FBI has gotten into Syed Farook's iPhone. Many people have asked the obvious questions: how did the FBI do it, will they tell Apple, did they find anything useful, etc.? I think there are deeper questions that really get to the full import of the break. How expensive is the attack? Security - and by extension, insecurity - are not absolutes. Rather, they're only meaningful concepts if they include some notion of the cost of an attack.