If we do our job, nothing happens

There is a line in a recent keynote speech by Mikko Hypponen, the CRO of F-Secure that goes something like this: “If we do our job in cyber security, then nothing happens.” It is so true, and made me think of the times when various corporate executives challenge their investments in cyber security, wanting to see something tangible. Mikko makes this point by asking them to look around at the conference room where these conversations are taking place, asking them if the rooms are cleaned to the satisfaction of the execs. If so, perhaps they should fire their cleaning staff, because they are no longer needed.

Now the difference between your security engineering staff and your janitors is obvious. You can’ t see all the virtual dirt that is building up across your network, the cruft of old software that needs updating and polishing, and the garbage that your users download on to their PCs that will leave them susceptible to attack. And that is part of the problem with cyber security: most things are invisible to mere mortals, and even some specialists can’t always agree on the best cyber hygiene techniques. Most of us have an innate sense that mopping the floor before dusting the shelves above is the wrong way to go about cleaning the room. That is because we all understand (at least on a basic level) how gravity operates. But when it comes to cyber, should we be changing our password regularly (some say yes, some say nay)? Or using complex strings of a certain length (some say 10 digits is fine, others say longer ones are needed)?

Mikko ends his talk by saying that we must assume that we are all targets by someone, whether they be a hacker who is still in high school or a government spy that is eager to get inside our company’s network. He says, “The times of building walls are over, because eventually someone will get in our enterprise. Breach detection is key, and we all have to get better at it.”

I agree with him completely. We must get better at seeing the virtual dirt on our networks. Building a better or bigger wall won’t stop everyone and will just foster a false sense of cyber security. And just because nothing happens, this doesn’t mean that cyber security folks aren’t hard at work. They are the cleaners that we don’t ever see, unless one day they leave someone’s mess behind.

 

FIR B2B Podcast Episode #122: Why techies make for great speakers

For technology companies, the conventional wisdom is wrong when it comes to pitching a conference or webinar session. Instead of having your CMO or other C-suite executive tell your story, trust the technical people in your shop. Your audiences will thank you for it.

Here are some of the reasons:

  • Audiences want black-and-white issues. CMOs usually see the world in nuance and infinite shades of gray. Techies value certainty. Think Sheldon Cooper’s character.
  • Facts are an endangered species these days.  So who better to deliver facts that a techie?
  • Audiences want to hear stories. First-person experience from people on the front lines can deliver authenticity and credibility that the audience relates to.
  • Techies steer clear of self-promotion, which is the fastest turnoff for an audience.
  • Techies can be more effective at reaching potential customers precisely because they don’t try to promote or sell.
  • Techies can be trained to be good and sometimes great speakers. We have some tips for how to do it.

I wrote more about this for Sam Whitmore’s Media Survey. It is normally gated, but today you can read the post here.

CSOonline: What is Magecart?

Magecart is a consortium of malicious hacker groups who target online shopping cart systems, usually the Magento system, to steal customer payment card information. This is known as a supply chain attack. The idea behind these attacks is to compromise a third-party piece of software from a VAR or systems integrator or infect an industrial process unbeknownst to IT. I explain what this malware does, link to some of the more notable hacks of recent history, and also provide a few suggestions on how you can better protect your networks against it.

You can read my post for CSOonline here.

RSA blog: Risk analysis vs. assessment: understanding the key to digital transformation

When it comes to looking at risks, many corporate IT departments tend to get their language confused. This is especially true in understanding the difference between doing risk analysis, the raw materials used to collect data about your risks, with risk assessment, the conclusions and resource allocation to do something about these risks. Let’s talk about the causes, challenges and why this confusion exists and how we can avoid them as we move along our various paths of digital transformation. Part of this confusion has to do with the words we choose to use than any actual activity. When an IT person says some practice is risky, oftentimes what our users hear us say is, “No, you can’t do that.” That gets to the heart of the historical IT/user conflict.

In my latest blog post for RSA, I discuss how this is more than choosing the proper words, but goes towards a deeper understanding of how we evaluate digital risks.

Taking control over your own health care: the rise of the Loopers

I have been involved in tech for most of my professional career, but only recently did I realize its role in literally saving my life. Maybe that is too dramatic. Let’s just say that nothing dire has happened to me, I am healthy and doing fine. This realization has come from taking a longer view of my recent past and the role that tech has played in keeping me healthy.

Let me tell you how this has come about. Not too long ago, I read this article in The Atlantic about people with type 1 diabetes who have taken to hacking the firmware and software running their glucose pumps, such as the one pictured here. For those of you that don’t know the background, T1D folks are typically dealing with their illness from an early age, hence they are usually called “juvenile diabetics.” This occurs with problems with their pancreas producing the necessary insulin to metabolize food.

T1D’s typically take insulin in one of two broad ways: either by injection or by using a pump that they wear 24/7. Monitoring their glucose levels is either done with manual chemical tests or by the pump doing the tests periodically.

Every T1D relies on a great deal of technology to manage their disease and their treatment. They have to be extremely careful with what they eat, when they eat, and how they exercise. A cup of coffee can ruin their day, and something else can literally put them in mortal danger.

That is what got me thinking of my own situation. As I said, my case is far less dire, but I never really looked at my overall health care. To take three instances: I take daily blood pressure meds, use a sleep apnea machine every night, and wear a hearing aid. All of these things are to manage various issues with my health. All of them are tech-related, and I am thankful that modern medicine has figured them out to mitigate my problems. I would not be as healthy as I am today without all of them. Sometimes I get sad about the various regimens, particularly as I have to lug the apnea machine aboard yet another international flight or remember to reorder my meds. Yet, I know that compared to T1D folks, my reliance on tech is far less than their situation.

I know a fair bit about T1D through an interesting story. It is actually how I met my wife Shirley many years ago: we were both volunteers at a JDRF bike fundraising event in Death Valley, even though neither of us has a direct family connection to the disease. I was supposed to ride the event and had raised a bunch of money (thanks to many of your kind donations, BTW) but broke my shoulder during a training ride. Fortunately, the JDRF folks running the event insisted that I should still come, and the rest, as they say, is history.

One of the T1D folks that I know is a former student of mine, who is part of the community of “loopers” that are hacking their insulin pumps. Over the past several months he has collected the necessary gear to get this to work. Let’s call him Adam (not his real name).

Why is looping better than just using the normal pump controls? Mainly because you have better feedback and more precise control over insulin doses. “If you literally sat and watched your blood sugar 24/7 and were constantly making adjustments, sure you could get great control over your insulin levels. But it’s far easier to let the software do it for you, because it checks your levels every five minutes. In reality, I’m feeding my pump’s computer small pieces of data that is very commonly used in the T1D community for diabetes management. So it is no big deal.”

Adam also told me he took about four days to get used to the setup and understand what the computer’s algorithms were doing for his insulin management. So much information is available online in various forums and documentation of different pieces of open source software that include projects such as Xdrip, Spike, OpenAPS, Nightscout, Loop, Tidepool, and Diasend. It is pretty remarkable what these folks are doing. As Adam says, “You need to be involved in your own care — but some of the stress in decision making is gone. Having a future prediction of your glucose level makes it easier to plan for the longer term and feel more confident.”

But looping has another big benefit, because it is monitoring you even when asleep. It also gives you a new perspective on your care, because you have to understand what the computer algorithms are doing in dispensing insulin. “The most powerful way to use an algorithm is when you combine the human and computer together — the algorithm is not learning. It’s just reusing well established rules, “ says Adam. “It’s pretty dumb without me and I’m way better off with it when we work together. That’s why I say that my setup is a thousand times better than what I had before. I have an astonishingly better tool in this fight.”

There are a few down sides: you do need to learn how to become your own system integrator, because there are different pieces you have to knit together. The pumps have firmware that could disable the looping: this was done for the patient’s protection, when it was found that some of them were hackable (at close distances, but still) and for their protection. If you upgrade your pump, your looping could be disabled.

You also need to have a paid Apple Developer account to put everything together, because the iPhone app that is used to connect his pump requires this developer-level access. “It is more than worth the $100 a year,” Adam told me. There are also Android solutions, but he has been an iPhone user for so long it didn’t make sense for him to switch.

Finally, looping is not legal, and not yet approved by the FDA. Many other countries have recognized this pattern of treatment, and the FDA is considering approval.

This is the way of the modern tech era, and how savvy patients have begun to take back control over their care. It is great that we can point to this example as a way that tech can literally save lives, and that patients today have such powerful tools at their disposal too. And the looping story hopefully should inspire you to take control over your own medical care.

FIR B2B podcast episode #121: Standouts from The Conference Board’s 2019 Excellence in Marketing & Communications Awards

Paul and I first met Jen McClure (left) more than a decade ago and shortly after she founded the Society for New Communications Research (SNCR) in 2005. Jen, who has been a frequent guest on Shel Holtz’s FIR main podcast, was one of the first people to see the potential of social media in business communications. SNCR merged with The Conference Board three years ago, and fortunately the awards program Jen created at SNCR has continued as The Conference Board’s Excellence in Marketing & Communications Awards. This week we discuss three outstanding winners of the awards, which will be presented in New York City on June 26th, in conjunction with The Conference Board’s 24th Annual Corporate Communications Conference. Two of our picks are B2B.

  • SAP used Dynamic Signal to track and encourage employee engagement and brand advocacy. Staffers now share more than 15,000 social posts monthly and drive an impressive amount of traffic to the main SAP website.
  • Southern California Edison adopted Sprout Social’s chatbot technology to supplement the two staffers who respond to customers inquiries. The utility has not only increased the volume of questions it can field without adding staff but has maintained high satisfaction ratings and is now able to respond more quickly to major power outages. The project succeeded on all metrics.
  • Siemens used augmented and virtual reality technology to greatly expand the variety of equipment is can show at trade shows. These large and expensive machines are costly to ship and take up a lot of floor space. With AR/VR, Siemens was able to deliver a virtual experience that was in many ways better than a live demo.

Congratulations to these and all the other finalists and winners in this year’s awards program. The quality of entries keeps getting better every year. You can listen to our 16 min. podcast here:

HPE Enterprise.nxt: Six security megatrends from the Verizon DBIR

Verizon’s 2019 Data Breach Investigations Report (DBIR) is probably this year’s second-most anticipated report after the one from Robert Mueller. In its 12th edition, it contains details on more than 2,000 confirmed data breaches in 2018, taken from more than 70 different reporting sources and analyzing more than 40,000 separate security incidents.

What sets the DBIR apart is that it combines breach data from multiple sources using the common industry collection called VERIS – a third-party repository where threat data is uploaded and made anonymous. This gives it a solid authoritative voice, and one reason why it’s frequently quoted.

I describe six megatrends from the report, including:

  1. The C-suite has become the weakest link in enterprise security.
  2. The rise of the nation state actors.
  3. Careless cloud users continue to thwart even the best laid security plans.
  4. Whether insider or outsider threats are more important.
  5. The rate of ransomware attacks isn’t clear. 
  6. Hackers are still living inside our networks for a lot longer than we’d like.

I’ve broken these trends into two distinct groups — the first three are where there is general agreement between the DBIR and other sources, and last ones . are where this agreement isn’t as apparent. Read the report to determine what applies to your specific situation. In the meantime, here is my analysis for HPE’s Enterprise.nxt blog.

RSA blog: Managing the security transition to the truly distributed enterprise

As your workforce spreads across the planet, you must now support a completely new collection of networks, apps and endpoints. We all know this increased attack surface is more difficult to manage. Part of the challenge is having to create new standards and policies to protect your enterprise and reduce risk as you make the transformation to become a more distributed company. In this blog post for RSA, I examine some of the things to look out for. My thesis is that you’ll want to match the risks with the approaches, so that you focus on the optimal security improvements to make the transition to a distributed staffing model.

AI is both a boon and a bane for IT security

Next week I am giving a speech at the Inside AI/LIVE event in San Francisco. I have been working for Inside.com for nearly three years, producing a daily email newsletter on infosec topics. The speech will cover the current trends in how AI is both the bane and the boon of IT security. In my talk, I will point to some of the innovators in this space that I have found in my travels. I thought I would touch on what I will be talking about here.

Usually, when we first hear about AI, we tend to go towards what I call the “Skynet scenario.” For those of you who haven’t seen any of the Terminator movies, this is that point in the future where the machines take over and kill all of the humans, and we are left with Arnold-as-robot and Kyle Reese to save us all from extinction. That isn’t a great place to start thinking about the relationship between AI and security to be sure.

Certainly, we have heard many of the more recent notable AI fails, such as the gender-bias of the AI-based HR recruiting tool from Amazon, the self-driving Uber car that killed a pedestrian, and where Google Photo confused a skier with a mountain peak. But we need to get beyond these scenarios.

Perhaps a better place to start is to understand the workflow of machine learning (ML). Here we see that AI isn’t all that well suited to infosec. Why? Because the typical ML process tries to collect data, build an algorithm to model something that we think we know, and then use the model to predict some outcomes. That might work well for certain situations, but the infosec world is far too chaotic and too reliant on human interpretation of the data to work well with AI techniques.

On top of this is that the world of malware is undergoing a major transformation these days. Hackers are moving from being mere nuisances like script kiddies to professional criminals that are interested in making money from their exploits. Malware is getting more complex and the hackers are getting better at hiding their craft so that they can live longer inside our corporate networks and do more targeted damage. Adversaries are moving away from “spray and pray,” where they just blanket the globe with malware and towards “target and stay,” where they are more selective and parsimonious with their attacks. This is also a way to hide themselves from detection too.

One issue for using AI techniques is that malware attribution is hard, something that I wrote about in a blog post for IBM’s Security Intelligence last year. For example, the infamous WannaCry ransomware was eventually attributed to the North Koreans, although at first it seemed to come from Chinese agents. It took a lot of research to figure this out, and one tell was the metadata in the code which showed the Korean time zone. AI can be more of a hindrance than help sometimes.

Another problem for security-related AI is that oftentimes developers don’t think about security until they have written their code and they are in their testing phase. Certainly, security needs to be top-of-mind. This post makes some solid reasons why this needs to change.

In the past several years, Amazon, Google, (most recently Microsoft) and many other IaaS players have come out with their ML toolkits that are pretty impressive. For a few bucks a money, you can rent a very capable server and build your own ML models for a wide variety of circumstances. That assumes that a) you know what you are doing and b) that you have a solid-enough dataset that you can use for creating your model. Neither of those circumstances may match your mix of skills or situation.

So there is some hope in the AI/security space. Here are a few links to vendors that are trying to make better products using AI techniques.

First is a group that is using what is called homomorphic encryption. This solves the problem where you want to be able to share different pieces of the same database with different data owners yet encrypt the entire data so that no one can inadvertently compromise things. This technology has been the darling of academia for many years, but there are several startups including ICE CybersecurityDuality Technologies’ SecurePlus, Enveil’s ZeroReveal, Capnion’s Ghost PII, and Preveil’s email and file security solutions. A good example of this is the San Diego-based Community Information Exchange, where multiple social service agencies can share data on their clients without revealing personal information.

Google’s Chronicle business has a new security tool it calls Backstory. While still in limited release, it has the ability to ingest a great deal of data from your security logs and find patterns of compromise. In several cases, it identified intrusions that happened years ago for its clients – intrusions that had not been detected by other means. That is showing the power of AI for good!

Coinbase is using ML techniques to detect fraudulent users, such as those that upload fake IDs to try to open accounts. It matches patterns in these uploads, such as if someone uses a fake photo or makes a copy of someone else’s ID.  And Cybraics has developed an AI engine that can be used to scan for vulnerabilities across your network.

Probably one of the more interesting AI/security applications is being developed by ZeroEyes. While not quite in production, it will detect weapons in near-real time, hopefully identifying someone before they commit a crime. This isn’t too far afield from the thesis of Minority Report’s pre-crime activities. We have certainly come a long way from those early Skynet days.

You can view the slide deck for my presentation at the conference below:

 

Sometimes, the tin-foil hat types are right

A recent story in the NY Times caught my attention. It is about a block in the Cleveland area where some of their wireless car key fobs and garage door openers stopped working. The block is near a NASA research facility, so that was an obvious first suspect. But it wasn’t. The actual source of the problem turned out to be an inventor that was flooding the radio spectrum at the same frequency as the fobs use: 315 Mhz. Once the radio emitter was turned off, the fobs and garage doors started working again. The issue was the inventor’s radio signal was so strong it was preventing anything else from transmitting on that frequency. He had no idea that he was the source of the radio interference.

This story reminds me of an experience that I had back in 1991 or so. At the time, I was the editor-in-chief of Network Computing magazine for what was then called CMP. It was a fun and challenging job, and one day I got a call from one of my readers who was the IT manager for the American Red Cross headquarters in DC. This was Jon Arnold, who spent a long career in IT, sadly dying of a heart attack several years ago. Turns out they had a chapter in Norfolk Va. that was having networking issues. Their office was a small one, of about 25 or so staffers as I recall. Every day their network would start slowing down and then eventually go kaput for several hours. It was at a different time during the day, so it wasn’t the Cleaning Person Problem (I will get to that in a moment). It would come back online sometimes by itself, sometimes with a server reboot. The IT manager asked if I would be willing to lend and hand, and the first person that I thought of to help me was Bill Alderson.

I first met Bill when he was a young engineer for Network General, which made the fabulous Sniffer protocol analyzer. Many of you who are not from that generation may not realize what this tool was or how much of a big deal it was to have a device that could record packet traffic and examine it bit by bit. Today we have open source tools that do the same thing for free, but back then the Sniffer cost four or five figures and came with a great deal of training. Bill cut his teeth on this product and now has his own company, HopZero that has an interesting way to protect your servers by restricting their hop count.

Bill and I first met back in 1989 when I worked at PC Week and we wanted to test the first local area network topologies. We set up three networks, running Ethernet, Token Ring and Arcnet in a networked classroom at UCLA during spring break. All were connected to the same Novell Netware server. Ethernet won the day (as you can see in this copy of the story), and the other topologies died of natural causes. But I digress.

Jon, Bill and I flew to Norfolk and spent a day with the Red Cross staff to try to figure out what was happening with their Novell network. We did all sorts of packet captures that weren’t conclusive. Our first thought was that it had to be something wrong with the server, but we didn’t see anything wrong. Our second thought was more insidious. Being in Norfolk, we were directly down the road from the naval base (you could say that about much of the town, it is a big base). We actually managed to get through to the base commander to find out if their radar was active when they were coming into port. Imagine making that phone call these days in our post-9/11 world? Anyway, the answer we got was negative. Eventually, after hours of shooting down various theories, we figured out the cause of the problem was a wonky network adapter card in someone’s PC. It usually operated just well enough that it didn’t interfere with the network most of the time. Once we replaced the card, everything went swimmingly, and we could put away our tin-foil hats.

Okay, so what is the Cleaning Person Problem? This sounds like folklore, but another reader told me about a problem they had on their network years ago. The reader was periodically disconnected from his network at the same time every night. He was one of the few people online at the time in their office, so it wasn’t like there was high traffic across the network. Eventually, after several evenings he figured out the problem: The cleaning crew was vacuuming the rug in the server room, and the network cable to the server was being run over by the vacuum. Because the cable wasn’t properly crimped and because it was run under the carpet (who knows why this was done), it was shaken just loose enough to disconnect it from the server. When the crew was finished, the cable would operate just fine. Thankfully, they made a better cable and ran it elsewhere where no one could step on it.

The Cleveland folks that had their car fobs disabled actually had it easy: the fault was in a very deliberate emitter that – while initially difficult to trace – was a very binary cause. Their challenge was that not every car fob and garage door was affected. The two scenarios that I mention here were not so cut-and-dried, which made troubleshooting them more difficult. So keep these stories in mind when you are troubleshooting your next computer or networking problem, and don’t be so quick to blame user error. It could be something not as obvious as the odd radio transmission.