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…..




Big Data In, Big Threat Out

Doctor Lydia Robles was confused to the point of immobilization. She kept going over the results again and again and all the data pointed to an outbreak. A serious outbreak. An outbreak that had the potential to become a pandemic. When she made the recommendation to relocate critical medical resources and supplement vaccine stockpiles in the New York first responders command centers she had no idea that DHS would stick their nose into it and decide to move the entire southwest vaccine stockpile to New York.

But someone did.

She didn’t think her work was important enough to attract the attention of any surveillance programs, but based on what she’d heard from the Snowden leak, she guessed that what got watched by the NSA didn’t have that high a bar to go over any more. Someone must have looked “over her shoulder” and decided that it was worse then she had initially thought. But still, someone should have talked to her. There was something not quite right about it. Something that a big data analysis couldn’t see but something that her human intuition told her was just a bit off.

With a precision that rivals an Army Ranger strike force, as soon as the trucks were unloaded in New York, the pathogen started to make itself felt in San Diego. The only correlating event that they could trace so far was that many of the people clogging the emergency rooms and morgues were at a Chargers game the day before. Estimates said that it would take 18 hours just to get the vaccine stockpile back to that part of the country and another 12 hours to get in a position to administer it. This meant that they were already 2 days behind a virus that made HPAIV look tame. That was translating into another problem: where to put the bodies.

This thing was spreading fast. As fast as the model said it was supposed to spread in New York. But the data in New York was clearly wrong. Someone had salted the New York data in order to make the CDC think there was a problem. This was intentional and it was an attack. But how and who? And even more curious, why?

Whoever they were, they had significant resources and the patience of Job. Linda wondered how many computers had been secretly hacked to create the thousands upon thousands of web accesses and tweets over the past few months that were required to influence her analysis.

One thing was sure; Big Data turned a corner this week. A very dangerous and deadly corner. When she crawled out of bed this morning she no idea that her passion for data analysis would be the cause of so much misery and death. Garbage in, garbage out was the old rule. Not any more! Now, garbage in, Big Garbage out! Linda knew that her job would never be the same again. Big Data as a weapon. Shit. She was going to have to figure out a way to add a pedigree to her data in the future.

That is, assuming there was a future and she still had a job in it after this was all over. Or worse, if she was even still alive by then.

So I ask you, what went wrong here? Sometimes failures aren’t technical in nature. Yes, the technology can seem to fail us, as it might have here. But even the best technology can’t save us from poor reasoning and sloppy processes. Sometimes the assumptions we make are at the root of the failure we’re trying to analyze. As was the case here, sometimes the very behavior of the underlying technology can be used as a delivery method. The tech was just a bit player here. Also consider that the very behavior of the people and the processes they employed were targeted in very subtle ways.

And finally, what could have been done differently?

A New Way to Relate

Although the subject of information security is a very serious one, sometimes we take ourselves a bit too seriously. When I wrote my first book and put it under a publisher’s nose, she said that she loved it! To quote her, “I love your writing style! It’s engaging, fun, and easy to follow. Too bad we wouldn’t be able to sell a single book.”

She was referring to the fact that I was aiming the book at the executive layer. My intent was to write a book that made security concepts easy for executives to place within the context of business requirements. I was trying to make it easier for them to understand what it was we were trying to do and why it was important so they could make better decisions.

I was also trying to make it easier for them to spot a “poser” so as to reduce the amount of bullshit that was flooding into our solution space. Instead of waiting for the next disaster, I was hoping I could get them ahead of the curve. Unfortunately, it seemed that Robert Ludlum and Tom Clancy were a tad more popular then your garden-variety security geek.

So be it.

With that bit of advice tucked in a warm dark place, I wrote Endpoint Security. (A fantastic read by the way!) Alas, I’m still waiting for the groupies.

So, instead of droning on about solutions, vulnerabilities, risk, and how bad things are, I’m going to try a different path. I’m still going to ask hard questions, but I’m going to do it by telling some stories about how these things will affect our lives, and possibly our futures. I’m going to try to put myself in the place of the people that will be affected by our failures and try to tell their stories of how it impacted their lives and the people around them.

In short, I’m trying to get people to relate. We can build a better solution if everyone can see the possible future outcomes of not caring about it now.

So I give you our first story about how big data can go very very wrong.


Keeping People Honest

Why would I take the time to sit in front of a computer at night when I sit in front of one all day?
Why would you write a book?
Why would you bicycle across the country?

Clearly not for the money and fame.

You do it because you believe it’s important and it should be done.

That’s why this blog.

Because I think we need to look at things in a different way. We need to ask some hard questions. We may not get immediate answers, but at least the question will be asked and hopefully, just hopefully, there is someone out there that is interested enough to ask the question of someone else. New thoughts, new approaches, new people, and most of all, an open, and (probably at times) caustic discussion. Not mean, not hurtful, but probing and unbiased. People are emotionally invested in the topics of information security and privacy because of the years of effort we’ve put into them.

And on both sides! Those of us that dedicate ourselves to protecting have a counterpart who’s just as dedicated to “freeing” the information. This discussion is as much about technology as it is about ideology. Yes, ideology. For example…

Should you make security obvious or invisible?
Does anyone have a right to any data?
Is risk the only way, or even a good way, to assess security?
Are we winning?
Can we even tell if we’re winning?

Hopefully, this blog and my expressed opinion will spark some discussion on these very subjects. We’re losing the battle right now and we need to figure out why before our industry turns into the punch line of some really bad jokes. And as a side benefit, maybe we can convince some people to do the right thing and use their skills for goodness and niceness instead of badness and evil.

When we don’t ask the hard questions we don’t reach beyond our limits. When we don’t ask questions at all, we enable those that have less then honorable intentions to do what they want without any accountability. It’s about time we start being honest about our abilities, our solutions, and our future.