Dispatch helps us effectively manage security incidents by deeply integrating with existing tools used throughout an organization (Slack, GSuite, Jira, etc.,) Dispatch leverages the existing familiarity of these tools to provide orchestration instead of introducing another tool. —Kevin Glisson, Marc Vilanova, Forest Monsen
No ideal hash function exists, of course, but each aims to operate as close to the ideal as possible. Given that (most) hash functions return fixed-length values and the range of values is therefore constrained, that constraint can practically be ignored. —Jeff M Lowery
Now we can all appreciate at a fundamental level what it feels like in the datacenter most days, and why Ethernet switch ASIC makers are all trying to push the bandwidth envelope. —Timothy Prickett Morgan
Extending the Internet of Things (IoT) everywhere on the planet comes down to two essential factors, network availability and cost. Over 20 new companies promise to lower IoT satellite equipment and monthly service pricing by leveraging mass market production and using constellations of low-cost low-flying “nanosatellites” (the size of a wine bottle box or smaller) to collect data from devices in the remotest part of the world – or at least outside of cell phone tower range. —Doug Mohney
The last few weeks have reinforced the importance of modern communication networks to societies. Health care providers, schools, governments, and businesses all rely on networks that enable us to connect and collaborate remotely. Had we encountered a similar pandemic ten years ago, we would not have been able to continue our activities on the level that is possible today. —Juha Holkkola
At the beginning of March 2020, Fifth Domain reported that Colorado-based aerospace, automotive and industrial parts manufacturer Visser Precision LLC had suffered a DoppelPaymer ransomware infection. Those behind this attack ultimately published information stolen from some of Visser’s customers. Those organizations included defense contractors Lockheed Martin, General Dynamics, Boeing and SpaceX. —David Bisson
As of this writing, the long-term effects of the coronavirus pandemic remain uncertain. But one possible consequence is an acceleration of the end of the megacity era. In its place, we may now be witnessing the outlines of a new, and necessary, dispersion of population, not only in the wide open spaces of North America and Australia, but even in the megacities of the developing world. —Joel Kotkin
Many network operators have a regulatory requirement to incorporate Lawful Interception (LI) capabilities into their networks, so that Law Enforcement Agencies (LEAs) can perform authorized electronic surveillance of specific target individuals. —Shane Alcock
Yet for many businesses, managing an entirely remote workforce is completely new, which means they may lack the processes, policies, and technologies that enable employees to work from home safely and securely. In addition, many employees may be unfamiliar or uncomfortable with the idea of working from home. As a result, organizations are scrambling to quickly roll out security awareness initiatives that enable their workforce to work from home safely and securely. —Lance Spitzner
This episode of the History of Networking is a little different. Because it is the first of April, we have a roundtable of several April 1 RFC authors discussing their work, and a short discussion on the history of the April 1 RFC series. The authors we have on the episode are Donald Eastlake, RFC3092, the Etymology of Foo; Richard Hay, RFC5841, TCP Option to Denote Packet Mood; Carlos Pignataro and Joe Clarke, RFC6593, Service Undiscovery Using Hide-and-Go-Seek for the Domain Pseudonym System; Carlos Pignataro, RFC6592, The Null Packet; and Ross Callon, RFC1925, The Twelve Networking Truths.
The massive numbers of people staying home to work because of the ongoing pandemic are placing a lot of strain on network infrastructure. One area many operators are not considering, however, is security—how does having a lot of remote workers impact DDoS? Is split tunneling really the right way to manage remote connectivity? Roland Dobbins joins Eyvonne Sharp and Russ White to discuss security in times of mass remote work on this episode of the Hedge.
The last few weeks have seen a massive shift towards working from home because of the various “stay at home” orders being put in place around the world—a trend I consider healthy in the larger scheme of things. Of course, there has also been an avalanche of “tips for working from home” articles. I figured I’d add my own to the pile.
A bit of background—I first started working from home regularly around twenty years ago, while on the global Escalation Team at Cisco. I started by working from home one day a week, to focus on projects, slowly increasing over time, ultimately working from the office one day a week when I transitioned to the Deployment and Architecture Team. Since that team was scattered all over the world—we had a few folks in Raleigh, two in Reading (England), one Brussels, one in Scott’s Valley, and one or two in the San Jose (California) area, we had to learn to work together remotely if we had any hope of being effective. Further, we (as a family) have home-schooled “all the way through”—my oldest daughter is nearing the end of high school, currently overlapping with some college work. I have always had the entire family at home most of the time.
So, forthwith, some thoughts and experiences, including some you might not have ever heard, and some myth busting along the way.
Probably the most common piece of advice I hear is you should set a schedule and stick to it. On the other hand, the most common thing people like about working from home is the flexibility of the schedule. Somehow no-one ever seems to put these two together and say “hey, one of these things just doesn’t belong here!” (remember that old song, courtesy of public television). When you are working from home, setting a fixed schedule similar to being in an office is precisely the wrong thing to do. This is a myth.
Instead, what you should do is to try to intentionally carve out several hours a day of “quiet time” to get things done. This might be different times in the day for your house, and its not likely to be consistent on a daily, weekly, or monthly basis. The most productive times of the day are going to shift—get used to it. Most of my family are late sleepers or tend to get up in the morning and do “quiet things,” so the mornings tend to be much more productive for me than the afternoons. This isn’t always true; sometimes the evenings are quieter. There are few days, however, when there isn’t some quiet time during each day.
The key to scheduling is to plan project work for these quiet times, whenever they happen to be. Given the schedule of my house, I get up in the morning and immediately dive into project work. I leave email and reading RSS feeds for the afternoon, because I know I won’t be able to concentrate as well during those time. On the other hand, I try not to get frustrated if my routine is broken up—just put off the project work until the time when it is quiet. Roll with the punches, rather than trying to punch against the rolls, when it comes to time. The only fixed point should be to think about how many hours of quiet time you need per week and figure out how to get it.
Don’t worry about having 8 hours solid, or whatever. Take breaks to eat lunch with family or friends. Take breaks to have a cup of hot liquid. Run out to the store in the afternoon. Exercise in the middle of the day. Take advantage of the flexible schedule to break work up into multiple pieces, rather than being glued to an office desk for 8 hours, regardless of your productivity level through that time. This is not the office—don’t act like it is.
The second most common piece of advice I hear is find a space and stick to it. This is not a myth—it is absolutely true. I have a table in the basement in one place, and a dedicated room as an office in another. When we go on vacation as a family, I either make certain to have a large enough room to have space to work, or I scope out someplace I can “set up shop” someplace in the hotel. Space is just that important.
Sometimes you hear get the right equipment. This, also, I can attest to. Tools, however, are a bit of an obsession for me; I will spend hours perfecting a tool, even if it does not, ultimately, save me as much time as I originally thought. I am a stickler for the right monitory, chair, desk space, footrests, and keyboards. I play with lighting endlessly; I have finally settled on a setup with a dim monitor, dim room lighting, bias lighting behind the monitor, and a backlit keyboard. I’ve concluded that reducing the sheer amount of light being poured into my eyes, across the board, helps increase the amount of time I can keep working. Some people prefer two monitor setups—I prefer a single large monitor (31in right now). I don’t use a mouse, but a Wacom tablet. I’ve recently added an air purifier to my office space—I think this makes a difference. I don’t have a trash can close by—its useful to force myself to get up every now and again. Your physical environment is a matter of personal preference but pay attention to it. This will probably have as much impact on your productivity as anything else you do.
Overall, don’t let other people tell you what tools are the best. I’ve been told for more years I can remember that I should stop using Microsoft Word for long-form writing. You should switch to markdown, you should switch to Scrivener, you should use FocusWriter… Well, whatever. I’ve written … around 13 books, and I have two more in progress. I’ve written thousands of blog posts and articles. I’ve written thousands of pages of research papers, and I’m currently working on my dissertation. All in Microsoft Word. I’ve tried other tools, but ultimately I’ve found that Word, with my own customized interface settings, to be just as fast or faster than anything else I’ve worked with.
One thing you almost never hear is a team change. If one person is remote, act like everyone is. There is nothing more disruptive, or less useful, than having one person on the phone while everyone else is sitting in a conference room. If one person has to dial in, everyone should dial in. Setting up times to “just hang out” as a “meeting” is also sometimes helpful. If you have a fully remote team, dedicate “in real life” time to doing things you cannot do on meetings, and dedicate meeting time to things you cannot do through email, a chat app, or some other means.
Finally, some people are neat nicks while others are sloppy. I tend towards the extreme neat end of things, arranging even my virtual desktop “just so” (I actually do not have any icons on my desktop at all, and I’m very picky about what I put in my start menu and/or command bar).
The key thing is, I think, to pay attention to what helps and what doesn’t, and not be afraid to experiment to find a better way.
In this blog, the first of a new series on uCPE, I take a look at why communications services providers and enterprises should invest in uCPE-based services and the business opportunities these are already bringing to the early adopters. —Simon Stanley
Shadowserver provides free daily live feeds of information about systems that are either infected with bot malware or are in danger of being infected to more than 4,600 ISPs and to 107 national computer emergency response teams (CERTs) in 136 countries. In addition, it has aided the FBI and other nations’ federal law enforcement officials in “sinkholing” domain names used to control the operations of far-flung malware empires. —Krebs on Security
The Transportation Security Administration announced Friday that due to the coronavirus outbreak, it’s waiving the familiar 3.4-ounce limit for liquids and gels—for hand sanitizer only.* You may now bring a bottle of Purell as large as 12 ounces onto the plane to assist in your constant sanitizing of yourself, your family, your seat, your bag of peanuts, and everything else. All other liquids and gels, however, are still restricted to 3.4 ounces. —Dan Kois
The most important finding is that the average data consumed by households grow by 27% from 2018 to 2019 – in the fourth quarter of 2019 the average US home used 344 gigabytes of data, up from 275 gigabytes a year earlier. —Doug Dawson
This post starts by discussing the Internet connection from the AWS VPC Control Plane operation perspective. The public AWS documentation only describes the basic components, such as an Internet Gateway (IGW) and a subnet specific Implicit Routers. —Toni Pasanen
Many U.S. government Web sites now carry a message prominently at the top of their home pages meant to help visitors better distinguish between official U.S. government properties and phishing pages. Unfortunately, part of that message is misleading and may help perpetuate a popular misunderstanding about Web site security and trust that phishers have been exploiting for years now. —Krebs on Security
Distributed denial-of-service (DDoS) attacks remain a popular attack vector but have undergone changes as cybercriminals shift their strategies. Today’s attackers are turning to mobile and Internet of Things (IoT) technologies to diversify and strengthen their DDoS campaigns, research shows. —Kelly Sheridan
Following our initial blog on the subject of Internet sites and domains seeking to profit from the ongoing COVID-19 health crisis, we dug deeper into the topic. Appdetex looked at keywords within domain names, website content, social media handles and marketplace listings that would likely be related to the coronavirus outbreak.
It’s easy to think of urban cable systems as up-to-date and high tech and ready and able to deliver fast broadband speeds. While this is true in some cities and in some neighborhoods, the dirty secret of the cable industry is that their networks are not all up to snuff. Everybody is aware of the aging problems that have plagued the telephone copper network – but it’s rare to hear somebody talking about the aging of the cable company copper networks. —Doug Dawson
This last might be a little controversial, but the point is the way you handle data has real-world consequences. We often want to “sanitize” the work we do by disconnecting it from the consequences, but you cannot.
Note: Henk has pointed out that since the original article was posted, Neil Ferguson has “clarified” the comments discussed in the article below. Rather than taking the link down, however, I’ve included this note here—because the original point was not whether he anyone was right or wrong, only that caution is in order when dealing with these things. This article also points out a few of the issues in dealing with data of this kind—again, the point is to remember we should have some humility when we are doing things that impact real lives.
British scientist Neil Ferguson ignited the world’s drastic response to the novel Wuhan coronavirus when he published the bombshell report predicting 2.2 million Americans and more than half a million Brits would be killed. After both the U.S. and U.K. governments effectively shut down their citizens and economies, Ferguson is walking back his doomsday scenarios. —Madeline Osburn
Intent based networking is on the upslope of the hype cycle right now. In this episode of the Hedge, Alex Clemm and Jeff Tantsura join Alvaro Retana and Russ White for a discussion of Intent-Based Networking – Concepts and Definitions, a draft working its way through the Internet Research Task Force.
Security often lives in one of two states. It’s either something “I” take care of, because my organization is so small there isn’t anyone else taking care of it. Or it’s something those folks sitting over there in the corner take care of because the organization is, in fact, large enough to have a separate security team. In both cases, however, security is something that is done to networks, or something thought about kind-of off on its own in relation to networks.
I’ve been trying to think of ways to challenge this way of thinking for many years—a long time ago, in a universe far away, I created and gave a presentation on network security at Cisco Live (raise your hand if you’re old enough to have seen this presentation!).
Reading through my paper pile this week, I ran into a viewpoint in the Communications of the ACM that revived my older thinking about network security and gave me a new way to think about the problem. The author’s expression of the problem of supply chain security can be used more broadly. The illustration below is replicated from the one in the original article; I will use this as a starting point.
This is a nice way to visualize your attack surface. The columns represent applications or systems and the rows represent vulnerabilities. The colors represent the risk, as explained across the bottom of the chart. One simple way to use this would be just to list all the things in the network along the top as columns, and all the things that can go wrong as rows and use it in the same way. This would just be a cut down, or more specific, version of the same concept.
Another way to use this sort of map—and this is just a nub of an idea, so you’ll need to think about how to apply it to your situation a little more deeply—is to create two groups of columns; one column for each application that relies on network services, and one for network infrastructure devices and services you rely on. Rows would be broken up into three classes, from the top to bottom—protection, services, and systems. In the protection group you would have things the network does to protect data and applications, like segmentation, preventing data exfiltration, etc. In the services group, you would mostly have various forms of denial of service and configuration. In the systems group, you would have individual hardware devices, protocols, software packages used to make the network “go,” etc. Maybe something like the illustration below.
If you place the most important applications towards the left, and the protection towards the top, the more severe vulnerabilities will be in the upper left corner of the chart, with less severe areas falling to the right and (potentially) towards the bottom. You would fill this chart out starting in the upper left, figuring out what each kind of “protection” the network as a service can offer to each application. These should, in turn, roll down to the services the network offers and their corresponding configurations. These should, in turn, roll across to the devices and software used to create these services, and then roll back down to the vulnerabilities of those services and devices. For instance, if sales management relies on application access control, and application access control relies on proper filtering, and filtering is configured on BGP and some sort of overlay virtual link to a cloud service… You start to get the idea of where different kinds of services rely on underlying capabilities, and then how those are related to suppliers, hardware, etc.
You can color the squares in different ways—the way the original article does, perhaps, or your reliance on an outside vendor to solve this problem, etc. Once the basic chart is in place you can use multiple color schemes to get different views of the attack surface by using the chart as a sort of heat map.
Again, this is something of a nub of an idea, but it is a potentially interesting way to get a single view of the entire network ecosystem from a security standpoint, know where things are weak (and hence need work), and understand where cascading failures might happen.