My Focus on Integrity

Over the last few weeks I've been engaged with the editorial staff at WiseGate as I strive to understand the result of some informal polling I did about Integrity - Change Monitoring, Security Monitoring, and maintaining the integrity of computing environments for security and compliance.

I won't dive into those results here, except to say they have revealed something that, perhaps, I should have already known: there's a gap between what we want to do and what we're able to do.

I've been having a back-and-forth with one such editor, and following is my e-mail where I tried to both distill the meaning of Integrity, and show how the focus on Integrity starts with the system - not the data.

This is my classic method - use examples, preferably car examples, to describe the more intellectual subjects of information security.  Sadly, this shows that what you see here in my blog is exactly how I write - and how I think.

After reading this e-mail, the editor said it needed to be published.  So, here it is.  Enjoy.

(Note: the editor I was talking to is British, hence the selective use of a few words in here like "petrol" for "gas".)

---

I think I need to take another run at explaining Integrity.

Yes, it’s all about the data.  But, sometimes, it’s about the systems, too.

Take a system like your car.  You’re the data, the car is the system that handles the data.  The purpose of the car is to deliver the data safely at its destination while allowing some changes (aircon, heating) and not allowing others (theft), and protecting from the eventuality of yet others (seat belts, airbags).

Think about all the components of that car.  As a driver, you’re relying on the integrity of every component – the steering, the engine, the suspension, the brakes, the tires – but the only assurance you have that your car still has integrity is the garage it’s parked in, a check engine light, and a penetration car alarm.

A criminal picks you.  They put a pinhole in the fuel line feeding petrol to the engine.  Sure enough, the car alarm goes off – but, of course, car alarms go off ALL THE TIME, so no one checks it.  (Barking dog syndrome.)  A fuel line won’t trigger the Check Engine Light.  Do you know your car’s integrity has been compromised?  No, and somewhere along your drive to your next destination, your system flames out and self-destructs.  Hopefully you get out safely (probably, since cars are designed to handle engine fires).

What happens if the pinhole is in the brake system?  One time you go to stop – no brakes.  That’s much worse.

Now, a real hacker wouldn’t even set off the penetration car alarm.  They’d sit and wait, capture the signal from your remote keyless entry, and use that to disable the alarm before opening the (now unlocked) car.  They’d put a camera and GPS in the car to see all the data and track the use of the system.  They’d accumulate the information, periodically re-entering the system to retrieve the captured information.  The most you’d notice is a new rattle in the dash and finding your car strangely unlocked some random mornings – which you attribute to old age.

The garage is the company firewall.  The car alarm is the host IDS.  The check engine light is the SIEM.  Each suits their purpose perfectly, but each can be circumvented in the process of compromise of the overall system.

Integrity monitoring would catch these events.  It would see that the fuel line has been modified, the brake line has been modified.  It would even report the hood being opened.  It will even alert you when your oil was changed – but, since you planned that, you’ll dismiss it.

As an aside, encryption tints the windows.  No one can see the data within the car, but everyone still knows there’s a car carrying data – and, now, suspects it’s valuable.

So, as much as it’s about the data, it’s about the systems too.  Forget the data for a moment, think about those systems and the implications they have on the data we find so valuable.