Architecture 101, Part 2

In a previous rant, I discussed how I thought we were a bit self diluting about our perceived success and “winning”. To sum up, and quite possibly piss off some security people, we’re not winning.

If we want to win, we need to change how we think!

Am I saying that we should declare war on hackers, spies and thieves? No. That’s fighting the same battle we’ve been fighting since the beginning. Declaring war on hackers, spies and thieves is aiming the gun at the wrong adversary. That would be like attacking a gang bar because your home got robbed instead of putting in cameras, an alarm and a safe. A bad plan with a very predictable outcome.

What I am saying is that we need to change our approach to one that is a bit more expansive in scope then the present “what is the vendor je jure for today” approach we’ve been executing for the last 35 freak’n years!

We need to start thinking that our data security solutions should be integrated in a way that predicts outcomes in a measurable way. I’m not talking about just making “metrics”, but producing secure outcomes in a meaningful way by basing them on sound engineering principles. What we need to do is start with a set of operating principles that govern how we make decisions during an engineering effort and how we execute against those decisions.

That means:

  • We have a documented set of operating principles
  • We have an agreed upon set of desired architectural behaviors
  • We have a policy foundation that is used to measure minimal compliance
  • We have a documented security architecture that is NOT vendor specific
  • We have a documented test and evaluation process
  • We have a rigid configuration management process
  • We have an enforced software assurance program
  • We have reliable telemetry systems that produce accurate data
  • We can consume our telemetry and use metrics to make management decisions

We have a documented set of operating principles

This would seem like a brain-dead assumption, but most groups run off to engineer something without the discipline of actually coming up with a plan. A documented set of operating principles enables the group to detect and manage scope-creep. This would mean ignoring the “threat de jure” and keeping your eye on the horizon. You may be considering a cloud architecture or an internal solution. You may have a hybrid. Whatever the decision, you should pick one and plan for it!

We have an agreed upon set of desired architectural behaviors.

So, what do we want our security architecture to do? Do we want it to detect? Do we want it to deter? Do we want it to prevent? Do we want something aggressive or passive? How fast do we want it to be? How sensitive do we want it to be? Keep in mind that NO security solution is perfect and we will always be dealing with hackers, spies and thieves. That means new threats. Do you want to be able to detect a change in how you react to those threats? In short, can you postulate how the system will react when placed under stress and can you verify that behavior?

We have a policy foundation that is used to measure minimal compliance.

Policy. Policy. Policy. Without it, we are but a piece of driftwood being driven at the will of the currents. Policy drives the foundation for all other decisions. Without policy, what the hell are you spending money on security for? Might as well spend the money on a boat trip for the entire company.! You need the policy to create that baseline of desired behaviors. For example, it is company policy not to give hackers, spies, and thieves access to the company jewels. Now, how do you execute against that?

We have a documented security architecture that is NOT vendor specific.

Sometimes it’s easier to cite a negative example then a positive one. One of the first questions I ask potential customers is “can you show me your security architecture?”  In more times then I can recall, the immediate answer is either “McAfee” or “Symantec,” Ignore the fact that the answer is actually not addressing the question, the amount of signal in those answers is immense. And scary. If you can’t answer the first question, how can you even get to the follow on questions? Such as….How does this security technology integrate into the IT infrastructure? What are the various domains of protection? Where is the critical data and can you even draw a line around it? (Don’t get me started on that no-perimeter bull) If you’re using a cloud solution, how does it interface with your existing security tools, processes, and procedures? How well do those interfaces work?

We have a documented test and evaluation process.

I should also add >exercised< here. What this means is if you have spent the money to build a security solution, how do you know that it’s actually working as planned? Those annual evaluations? Right. Every single organization that has suffered a major attack can hold up a document that says they were either HIPAA-compliant or passed a PCI audit. Folks, THIS IS NOT TESTING THE SYSTEM! Penetration testing is also NOT TESTING THE SYSTEM!! Testing the system means injecting a signal into it and seeing how the system, including ALL of your security vendors, react to it from end-to-end. How long does this take? How sensitive is it? How long until you can detect the threat? How long until you can even notify the right people that you’re under attack? Most pen testing occurs under rigid controls and very highly contrived circumstances. All it does is meet a requirement to check a box. In many cases it intentionally doesn’t include the IRP!

We have a rigid configuration management process.

You wouldn’t just pop in a new core router or change a core software function in your product without some thought and planning, right? So why would you even consider making changes to your security systems without the same amount of forethought? Any kind of changes you make MUST be integrated into your environment, not just squirted in like RTV sealant into a crack in your bathtub.

We have an enforced software assurance program.

Most of you know what this means to your development teams, but how does it apply to your security software and hardware? Well….how about making sure that ALL of your security vendors have a software assurance (SA) program that they can articulate in the form of a policy or procedure? Trust begins with the tools you’re using, and if your vendors can’t demonstrate that they have a process that creates and maintains that trust, how can you trust their products? No software should be introduced into the architecture that does not pass the SA evaluation. Hope is NOT a good plan. The very first question I ask any vendor is “why should I trust your product?” The responses are at least entertaining!

We have reliable telemetry systems that produce accurate data.

The only way we can defend ourselves in this age of hyper-speeds is to automate. We knew this 15 years ago when we did the lessons learned after Code Red. (They were summarily ignored by the security industry) That means creating systems that can acquire data that we can use to make security decisions. I talked about this in my last book “Endpoint Security,” and after a few years of observation, I’ve come to believe that a process-control model is the only way forward. That means being able to get and classify telemetry quickly, reliably, and accurately. Your metrics cannot be “gameable” such that you can interpret them in a way that makes you look good. If a group of people look at your metrics, they should all reach the exact same conclusion every time regardless of the political situation. And, by the way, the number of patched systems isn’t a metric that’s high on my list of important security things to do. There is a reason for this….

We can consume our telemetry and use the metrics to make management decisions.

The last part of this is actually another brain-dead thing that seems to be ignored in the heat of battle. What good are the metrics if you can’t use them to make decisions? Granted, much of it is in support of the automated systems, but at a high level, you can use them to make budget decisions. For example, if your present vendor solution isn’t fast enough to detect and mitigate your test threats, perhaps it’s time to get a new vendor? By having objective data with which to make a decision, you make decisions that are good for your organization instead of good for your vendors.

I suspect that’s the bottom line here. By following these basic engineering principles, you can engineer solutions that meet your organization’s requirements, build in some innovation tolerance (or even, gasp, acceptance!) and provide some sorely needed budgetary predictability. That last part is pretty important to your CFO, your board, and your CEO. By having a plan and being able to show progress against it, you should be able to manage costs in a much more predictable way while protecting your corporate data and building a trustworthy data environment.

Now that’s progress!


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s