Why carbon monoxide alarm rules should apply to data security

We have a house in Maine that I fondly refer to as the dumbest smart house on the planet. Don’t get me wrong, I love the house and spending time there after an action-packed week. I smile when we pull into the driveway on Friday nights, and sigh heavily when we leave to head back to the “real world” on Sundays. Though if I’m honest, I don’t believe I could ever live there full time – but that’s a story for another blog.

Over the summer, our CO (carbon monoxide) detector starting going off at random, inconvenient times. Naturally, when we first started to hear the alarm, we thought we had a real problem. Then as it continued to go off, it became apparent that the issue was with the sensors themselves and not with our house having poisonous gas within it. To further complicate things, our alarm system is tied into a security monitoring company that relays the information to the local police and fire departments so that they can immediately dispatch help.

Each time the sensor went off, the fire department would send a crew to check out the house. It didn’t matter that they had already been at our house a half dozen times before and that no issue was ever found. It didn’t matter that we’d call them and say things were fine. Every time the alarm went off, firemen approached the house as though there was potentially a real problem. Wearing precautionary equipment, they went through the areas of the house, assessing the situation with test equipment to see if there was a problem. We felt a little like we were starring in the children’s classic “The Boy Who Cried Wolf.”

The crew was always polite and understanding. When we told them there was no need to respond to future alarms until we were able to replace the sensors, and that we were working with our new security company to fix the problem, the fire department said they needed to come each time because our judgment could be impaired and we might not realize that we had an issue, meaning they could not rely on our input. The policy is such that when an alarm is triggered, they are required to do a thorough check and assess of the situation, each and every time. However, interestingly enough, when we had similar issues with our fire alarm, a simple call to the fire department was all we needed to prevent them from having to make an unnecessary trip.

This got me thinking about all the security alarms that an IT organization sees. Can you really investigate all of them, each and every time? The answer – in theory – is yes, you can and you should. But the reality is that the signal to noise ratio can often be higher than your team can manage, and you may not have the time or even the staff dive deep into every issue. So how do you decide when you’re hearing a false fire alarm that can be ignored without any risk to the business, or a legitimate carbon monoxide detection that requires immediate and careful attention?

I asked our CISO, Andrew Hay, which data security alarms fall into the CO alarms category – requiring a follow up with the full protocol every time they are triggered. Of course, his initial response was that best practices tell you that you should look at everything each time. However, if that doesn’t align to the reality of your day, here were the top 12 alarms security and IT teams should never ignore:

  1. Anomalous file activity (deletes/changes) in mass
  2. Multiple failed authentication/authorization events followed by a successful one
  3. Lack of any alerts for an extended period of time
  4. Malformed events
  5. Alerts with time stamps from the past (or the future)
  6. Impossible sequences of events (file delete followed by file ownership change)
  7. Impossible logins from two geographic regions at the same time (i.e. China and Detroit)
  8. Communications to or from a country with which the business has no dealings
  9. Off-hours logins/access
  10. Configuration changes
  11. Failed backups
  12. Attempts to access sensitive systems from “strange” parts of the network (e.g. a web server on DMZ trying to access the HR file share)

IT and security teams are busy, but as the first responders for keeping an organization’s data – its most critical assets – safe, you can’t ignore warning signs, no matter how many times they don’t result in a real issue. Just like in the case of a carbon monoxide leak, a security alarm could indicate that your data faces serious risks.

Learn how to recover your critical data from security threats with a live demo.

2 Likes

Paula Long

Paula Long is the CEO and co-founder of DataGravity. She previously co-founded storage provider EqualLogic, which was acquired by Dell for $1.4 billion in 2008. She remained at Dell as vice president of storage until 2010. Prior to EqualLogic, she served in engineering management positions at Allaire Corporation and oversaw the ClusterCATS product line at Bright Tiger Technologies. She is a graduate of Westfield State College.