No Fly, No Browse!

We’ve all heard about the idea that if someone is on the US “No Fly” list that they should be denied access to firearms. It’s been popularly called “No Fly, No Buy!” The core of this idea is that if you’re too dangerous to fly, you’re clearly too dangerous to own a gun. Extending the logic, if you can’t legally own a gun, you can’t kill people! By doing this, we’re making it safer and better for the American People. Ignoring the obviously glaring disregard for a politically inconvenient document called the United States Constitution, it seemed like it might work. I thought about this for a while, putting dangerous people on a list, and I decided that it could indeed work! Sure, we do have to ignore some pesky constitutional rights, create some new regulatory controls, and impose some administrative burdens on the people we’re trying to protect, but what is Congress for if not to keep us safe so we can do business?

It’s not as if there isn’t a precedent for this. A really old precedent too. Those that are steeped in US history may recall the incident in the Black Hills of Dakota where the Lakota People (also referred to as the Sioux Confederacy) were chased off their land so that the gold buried in those Black Hills could be mined. The Black Hills gold rush started in 1874 and went to a peak in 1877. Some people proffer evidence that the US Government created an incident and used it to enable the relocation of the Lakota to reservations and the taking over of their land, thereby enabled the mining of the buried gold by those seeking a better life. Some people believe this was all done for the betterment of the US economy and the safety and prosperity of the American People. Although it didn’t end well for General George Armstrong Custer, Sitting Bull, Crazy Horse, or the Lakota People, a bunch of people made a big-ass pile of money. In today’s dollars, estimates were over $150M a year for about 5 years.

So, leaping forward to the 21st century, we’re now talking about another threat to our economy: hackers, spies, and thieves. The worst case threat: if hackers continue to undermine our information protection technology, consumers will cease to use electronic payment or electronic information exchanges. It’s already costing us zillions of dollars a year to deal with the results of our inability to stop these financial and healthcare terrorists. Between the amount of money lost to theft and fraud and the amount of money we spend trying to prevent theft and fraud, it’s a big-ass pile of money. Add to that a total and complete collapse of our digital economy and it’s clear that we MUST TAKE ACTION!

So, what is the core of my “No Fly, No Browse” solution? It’s as simple as the “No Fly, No Buy” solution: you use a list! The No Fly list! It’s there, law enforcement is already watching it, so it makes sense to start there.

The US government “partners” with industry to add to the No Fly list those people that are suspected of being financial or healthcare terrorists! The finance industry can contribute names, the health care industry can contribute names and last but not least, the US government can contribute the names of suspected hackers, spies and thieves. When you go to buy a computer, you must submit your name for a background check. If you’re on the list, you can’t buy a computer! Voila! Information security problem SOLVED! The fact that they can no longer fly is just a lucky perk. Do you want to share a plane with a potential financial or healthcare terrorist? I sure don’t!

So, you say, what about the people that already have a computer? How do we stop them Mark? Great question! Again, a simple answer! To browse, you need an Internet connection! When you sign up for an Internet connection, the provider MUST CHECK THE LIST! If your name is on the “No Fly” list, you are denied an account! This is actually great because us security geeks LOVE belt and suspender solutions! This is double good since you get checked when you buy a computer AND you get checked when you buy an Internet account.

But, those of you intrepid and determined to find a loophole will point out “WAIT!! What if I can convince a friend to lend me a computer, or better yet, convince a friend to actually buy me a computer?” Great question. In the gun world, that’s called a “straw man purchase” and it’s AGAINST THE LAW! We simply make it illegal to buy a computer for someone that can’t pass a background check!

As you can see, each and every contingency has a solution. We just need to make sure that people understand that to ensure our security, we must give up a little bit of our constitutional protections. We must put our faith in administrative and regulatory solutions that ignore the actual problem while imposing higher costs and burdens on those that are most affected by the problem. History shows that only the Government can solve this problem for us. Only the Government has the track record that proves that increased administrative burden, regulatory control, and of course, the erosion of constitutional rights can solve our problems.

Trust them. Trust the list.

No Fly, No Browse. It can work.


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!

Security Architecture, Part 1

I have been in this industry for a hell of a long time.

Pretty much since the beginning.

I remember sharing a cube with a guy that decided to write some software that he thought would identify when viruses made their way on to your computer. I remember looking forward to the clock speed increase to 5 MHz as a watershed event. I remember wondering what the hell I was going to do with 5MB of storage space on a hard disk drive and remember coining the phrase “on a clear disk you can seek forever”. I remember thinking that 5MB was huge. And I remember the BAUD speed debates with some folks saying that they could never break the 28.8K barrier. Those folks thought they had some sound engineering behind their claims. Thankfully, innovation and disruptive technology tend to ignore contemporary “sound engineering” principles.

And that’s where we find ourselves today – hampered by what our contemporaries consider “sound engineering” principles and what our industry has come to call “best practices”. So, “best practices” is defined in multiple ways by multiple sources but they all boil down to: “A method or technique that has consistently shown results superior to those achieved with other means, and that is used as a benchmark. See also best in class and leading practice.

I kinda like that definition. It implies RESULTS! It implies SUCCESS! And I like success. What security person doesn’t? If you go to any security conference you will most likely hear or see either a speaker or vendor referring to best practices as the basis for their process definition and the source of their success.

Let’s look at the word “success” for a minute. Achieving a goal! We achieve we win. Through the mathematical principle of substitution we can do some quick grammatical math and say that winning is success! Right? We equate success with winning. Beating the opposition! Forging ahead! RESULTS!! And, with a minor leap using the exact same reasoning, we get to, wait for it…..PROGRESS!

Bullshit. Pure self-deluding bullshit.

How we can even define our “success” in the security field as progress is beyond me. We continue to have “surprises” and we continue to fight a battle that can best be described as strategic compromise. Each day we see new vendors hawking new technology in the hopes that their solution is “The One”. The one that changes everything.

So, what’s missing? Why, in a world where we can do such amazing things and have such amazing technology, has a solution to the problem of enterprise security eluded us for so long?

Well, I think the answer is actually quite simple: we’re too selfish.

We all want privacy, but we don’t want to give up anything to get it. What I mean here is similar to wanting to be safe on the airlines while you have a cheap ticket and don’t have to wait in TSA lines. You can get it good, you can get it fast, you can get it cheap. Pick any two. The problem is that the solution requires us to integrate systems that normally don’t integrate with one another. Our personal lives don’t usually touch law enforcement systems because we’re law-abiding citizens. Unfortunately, the system is set up to deal with those that would ignore the law in order to hurt us or to gain ground in their objectives. For them, the lawbreakers, it’s a lifestyle and a war. They don’t care about the law and count on the fact that our systems don’t talk, don’t share information, and aren’t integrated as an engineered system.

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

So, how do we do that?

Stay tuned…..