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.

Focus on Fundamentals

Ok.  Let's face it.  The fundamentals are hard.  They're also boring.

They're also fundamental; they're the foundation.  Nothing can survive (long) without a foundation, and success will ultimately be limited by the limitations of the foundation on which that success is built.

In bicycling, our foundation is called the "base".  Base is earned through long miles in the saddle riding at a consistent and moderate pace, repeated over and over.  The typical training plan has 2-3 months of this stuff, mile after mind-numbing mile, as much as 3-4 days a week, with length based on how long races will be later in the year.  60 mile races?  4+ hours on the bike getting in base.

So, yeah, it's hard, and it's boring.

Bicycling, and Information Security, are both like building a pyramid.  If you want to go faster, ride longer, you need to build a wider base first.  You need a solid foundation, one that will support you when the time comes to drive a break 70 miles into a 100 mile race.

Information Security is the same.  If you want to deliver better protection, higher capability, you need to ensure you have a complete and supporting foundation - fundamentals.  If there's cracks or missing sections, there's room for the whole system to collapse under the weight of the stacked stones.

That raises the (obvious) question: what is fundamental to information security?  You have to have Anti-Malware.  And a Firewall.  Mix in some Intrusion Detection, log analysis.

Fact: none of those are fundamental.

Seriously.  You don't need this.

Put down the pitchforks for a moment.  Use of technologies like these are absolutely required, they just don't make up the foundation of a solid information security program.

So what does?

The National Institute for Standards and Technology (NIST) has put together some excellent documentation about managing information technology and information security.  One of their recent products is the CyberSecurity Framework, a product that provides a clear and executable map to measuring information security risk in a practical and illustrative way.

One of the key components of NIST's model is the list of core functions: Identify, Protect, Detect, Respond, Recover.

The Sequence of Core Functions - Each Drives the Next

These are sequential risk-reduction, information security management functions.  Investment only provides mitigation to the right, such investment is best served further to the left.  That means your foundation is the item to the left: Identify.

You can only act on what you've delivered.

Stealing liberally from NIST's documentation, this is what Identify means:

Develop the organizational understanding to manage cybersecurity risk to systems, assets, data, and capabilities

Understanding is fundamental to information security, the level of understanding is the ceiling for any information security program.  And understanding is hard, we always want to fast forward past it to get on to the sexy part of information security (if such a thing exists).

But you cannot secure that which you do not understand.  So let's dive in:


Understand Business Strategy

Information Security cannot operate without alignment with business purpose and strategy.  Use this knowledge to capture (or develop) a list of Threats that apply to the business model, vulnerabilities of the business based on the line of work, then cross to find enterprise class risks.  It is here that technology and information risks can be latched.

This is where we'd capture "Risk Tolerance", and a good place for a short soap box.  Risk tolerance should be a dying term as it's typically used in place of "willing ignorance": a willingness to accept risk due to perception the risks can't manifest (i.e., don't apply).  Risk tolerance should be a business case, financial-driven decision based on potential losses and impact of manifest risk.  But I digress.

This is where the information security program will take root and where it'll find reliance and support as it delivers business cases for risk reduction; the Why of Information Security.


Establish Management Intent

Utilize the knowledge generated in understanding the business strategy to establish over-arching management intent.  This starts with the Security Policy; the policies, procedures, and standards designed to deliver controls that orient to the risks the organization faces. 

The quickest, easiest way to establish intent is to select a control framework and write it into Policy and Procedure.  This becomes a simple process of selecting controls that relate to the risk posture of the company, setting standards within those controls according to the level of risk, and establishing metrics and measurements to enable assessment of compliance to controls.

Intent should also integrate Information Security into other organizations, enabling upstream and downstream delivery of controls throughout the organization.  Information Security has cross-organizational concerns in Vendor Management, Human Resources Management, among others.

The intent of Intent is to establish the rules for how security will operate, aligned to the risks and strategies of the company; the How of Information Security.


Capture Inventory

This isn't a real Datacenter.

This is where the rubber meets the road in the statement "you cannot secure that which you do not understand."  In practical terms, this inventory is the list of stuff that needs to be protected.  There's a lot to think about, but they fall into a few broad categories with the depth of detail driving the maturity of downstream controls.  This is the "What" of Information Security.

Design and Architecture Assets: Network and system diagrams, the "as-built" for the technology system as a whole.

Physical Assets:  There are the traditional technology devices with a few added items.  Servers, laptops, mobile devices, printers, network equipment, security equipment.  Each should be uniquely identified via some electronic means, each should have pertinent information such as responsible part, purpose, and similar.

Service Assets: These are the delivered technologies supporting business functions, such as the HRMS, FMS, ERP, along with smaller services such as Reporting, Project Management, and other solutions.  These should have owning business organizations and/or responsible individuals associated to each.

Integration Assets: Flow diagrams showing the movement of information between services (information systems) and the relationships of business processes to information flow.

Software Assets: The list of approved operating systems and software packages utilized on the environment.

Information Assets: The types of information utilized and where they are intended to be located with owning business organization and/or responsible individuals.

Identity Assets: The complete list of individuals who should have some level of access to the technology systems with information on their role and area of responsibilities.

Access Control Assets: The complete list of defined access credentials for each service and system, and a complete list of the roles and privileges provided within each.

(It's hopeful, and hopefully likely, that the Identity and Access assets are already linked; else, this is low hanging fruit.  Get it done.)

Threats and Vulnerabilities: The last two are a little less palpable but no less important, the list of Threats and Vulnerabilities within the organization.  These are necessary to create a risk profile for the assets inventoried above, enabling decisions on how to deliver protection, detection, response, and recovery in appropriate measure.

Threat Inventory: A list of known potential sources of impact to the organization's technology systems.  This list should be based on the inventory generated above; i.e., threats that are specific to the technologies and services being consumed; and based on how the business is operated, linking threats to parties that may be interested in disrupting the services provided, such as organized crime for retail.

Vulnerability Inventory: A list of known vulnerabilities within the environment.  This should be developed by both technology (scanning) and research, and contain vulnerabilities that impact information security and the application of controls over technology such as environmental and human influences.


It is all about the fundamentals; it's not possible to implement an information security program without having a strong grasp on what needs to be secured, why it needs to be secured, and how it should be secured.  The Identification process provides the knowledge needed to define the necessary technical and procedural mechanisms of information security.

Sorry.  Obligatory.

Without having a solid foundation, vulnerability manifests in cracks, eventually manifesting as failure in controls and, possibly, failure in the information security program.

Sometimes in spectacular fashion.  The pyramid comes crashing down because of a single failed stone.

The investment in time in fundamentals will lead to a more successful program.  Take the time to figure out the gaps, act on them, and the program will be better for it.

Collaboration: A Tired, Overused, Yet Under-Expressed Term

I prefer to talk.

I'm sure the comes as a complete surprise to anyone who has spent the time to read much of my ramblings over the last couple weeks.

(I'm also a little sarcastic, but that comes with the territory.)

But, seriously, I like to talk.

I think the art of communication is slowly being lost.  This isn't going to be a diatribe against the malevolence of e-mail, instant messenger, SMS, blogs, or smartphones.  I just believe we've allowed ourselves to become too impatient to have real conversation.

And that's what I really like.  Discussion.  Exploration of a subject.  Understanding the point of view of everyone involved.  Appreciating differences in positions and opinions.  Arriving at common ground.

My problem is that I'm in technology.  As a general rule, we don't communicate well, and don't relate well.  As I was once told, a good IT person is "cocky, arrogant, and difficult to work with."

Of, course, the anal retentive side of me pointed out that "cocky" and "arrogant" are synonyms so the statement was redundant.  That didn't get a good response.

Worse, I'm in Information Security.  All those habits, with the natural air of suspicion and concern for revealing anything that could breach confidentiality.  (Right.  Take that technical orientation and wrap it up with a CIA triad bow and see what you get.)

In short, we're really, really, bad at communicating.  We rely on so-called "subject matter experts" to tell us what we need to know.  We listen to vendor slime tell stories about the wonders of their technology, trying to glean why, precisely, they exist in the first place.

(Oh crap!  I have no idea what problem they're trying to solve!  Did I miss something?)

I like to talk.  We all do.  This is why, when you go to a conference, the roundtables always fill first, why they always have waiting lists, and why we end up getting stuck in presentations about how the position of a dot on a quad chart is so very meaningful when compared to the position of another dot that is below or to the left of the first which illustrates the value proposition of.....

.....zzzzzzzzzzZZZZZZZZZZZZZ.

Sorry.  Back on topic.

I like to talk.  And there's a reason I say that.  I genuinely appreciate organizations that allow me, and people like me, to talk.

I believe there is tremendous value in having an open, honest conversation about any subject; tactical / technical, operational / organizational, or strategic / enterprise.  There needs to be an outlet where we, as technology and security professionals, can lower the guard of arrogance, drop the shields of confidentiality, and talk about the common problems we all face.  We're not on an island, as much as we like to paint ourselves to be.

But we need help.  Collaboration, true open discussion, cannot happen without these:

Neutrality.  We need an environment where people can be candid.

Purpose.  Conversation started and driven by questions from individuals with real problems and needs.  Not personal; relevant.

Tone.  "What works, what didn't," with perspective as to reasons and implications.  No professional sales pitch ("look at all I've done"), no company marketing ("we've been doing this forever").  And no hype.

I draw tremendous value from open and candid conversations.  I've learned more in a single discussions than I've ever picked up in a 1 hour presentation or webinar.  I might get some ideas for tools and practices, but it's the real-world knowledge of how to apply those tools and practices that gets things done.

And to be quite honest, there's only two reasons there's a presentation - someone has figured out how to do something, and you'd learn more by talking about how it was done; or someone has a new way to do something and is trying to advocate for it.

The latter makes my early risk warning radar go off.

Clearly, we need to talk.  More.  We aren't so good at doing it ourselves, that's why we go to conferences.  We need help to make it happen.

Find your resources; I've found mine.   Local ISACA chapters (depending on their culture), roundtable events at conferences (you and everyone else), set them up yourself, or work with companies that specialize in enabling conversations.

There's a lot of knowledge out there waiting to be shared.  Some of it is locked in your head.

So get out there and talk.

Avoiding Hyperbole

Yes.  I heard about Target.

It happens every time.  Something big happens.  The news outlets turn on the bullhorn.  Affected constituents (customers) drive the furor.  Punditry on the event and effects.

Someone asks me about it on our group ride, expecting a reaction in line with what they've seen in the news.  Hyperbole, exaggeration, sky-is-falling.

(Heartbleed was probably a rare understatement of the risks.)

As an information security professional, I seize these moments to drive attention to the risks every company has when it dabbles in technology.  These moments provide a unique opportunity to add a little more darkness, a little more creaking wood and whistling wind to resident fears.

"Could it happen to us?"  Yes.  (Intellectually inaccurate, but too deep for the moment.)

"What should we do about it?"  I'm glad you asked.

This is where the conversation would typically flow toward talking about dollars, gee-wiz technologies with brilliantly flashing LEDs, all resulting in the constant whirr of user hard drives, CPUs sweating as cooling fans desperately try to overcome the heat of constant workload.

But that's not where this conversation goes.  Yes, I need money for my security program.  Everyone does.  I have another avenue I need to pursue first.

Security in our technological environment is like controlling a swimming pool.  We work very hard to maintain it, but we're constantly struggling with algae, PH levels, crap dropping from trees or deposited by wind.  Let alone the people who use it; they're the worst thing that a pool could ever experience.  Sweaty, suntan-lotion covered, beer (margarita!) drinking, swimmy-wearing people.

We put up fences to keep undesirable people out.  We have water surface alarms to warn us when the kid, the dog, (or a stranger) tries to take a dip without our knowledge.  We even have heaters and coolers.  Or wondrous, LED-filled technologies; automated pool management systems that keep water temperature just so, keep PH in range, automatically turn on lights; it even alerts me when anything is out of line.

Of course, if I can't do the fundamentals, if I can't keep water levels up, if I can't keep the chlorine basket filled, if I can't consistently empty the filter, I'll eventually turn off the pool automation alerts.

Sound familiar?

I want consistency in controls.  I control where the refill water comes from, the same way every time.  I control who can use my pool, and what they have to do before entering.  And, no, there's just no peeing in my pool.  Even in the shallow end.

Security is like that swimming pool.  Simply put, your pool is only as good as the worst part of it.  Try leaving a section of algae in your pool next time, see how that works for you.

Verizon has great charts describing how breaches occur, and those datapoints are incredibly important.  Knowing where the vulnerability manifests, critically important.  Just don't turn them into a game of whack-a-mole.

The real lesson from Target is that controls must be consistent in order to be effective.  Leave aside all the discussion about ignored warnings, missed opportunities; ask yourself these questions:

Why was a critical, protected infrastructure accessible from common, low(er) security networks?

Why was a third party, any third party, connected into a company network without documentation; worse, lacking separation from general corporate systems, let alone critical infrastructure?

What are the core security competencies, the core controls in alignment with business risk necessary to protect the operations of the company?

And, root cause for Target: Why wasn't there a single point of authority over all information security to serve as the foundation for application of standards and compliance?

Target's CEO's departure is the final nail, and with due respect a righteous kill.  Management never had intent to implement solid security controls, and such never named an individual to have ultimate responsibility for those controls.

There's my message.  No, Target can't happen here.  you, Mr(s). Executive, express management intent to maintain security - which is why I'm here.  I intend, first and foremost, to be solid in the basics; to do the basics consistently flawlessly.  Your intent to support that mission is imperative.  We'll talk more when, with your support, I've driven the risk out of the fundamentals.

And, yes, I'll need money to do it.  We need to know there isn't a peeing section in our pool.