Bill’s Security Blog

Over the past semester, I have had the opportunity to assist a co-worker who was taking an “Introduction to C++” class.

I was a C++ tutor in my undergraduate program, and I helped a lot of my fellows in the Master’s Degree program I was in at JMU. Though I’m no expert, and haven’t done any C++ since graduation, I have probably written close to 25,000 lines of C++, and was excited to get involved.

My coworker was taking the class in the context of an IT Management class that has a focus on security and disaster recovery.

After she submitted her last project, she sent me an email talking about how tough the class was for her.

Below was my reply. I felt it worth capturing in a blog post…

…
Also, don’t worry if you didn’t leave this class as the world’s best developer.

I think the real take-away is that coding is hard. It’s really, really hard.

It’s easy to make mistakes, very easy.

And it’s easy to hack something together, just enough to get the project done. It happens ALL the time. With the simple tools at our disposal, even novice developers can develop huge, web enabled, and EXTREMELY BUGGY software.

And from a security perspective, you must remember that fact ALL the time. That is the big learning lesson!

Not only will the software you buy have bugs.
But so will your firewalls, your anti-virus, you name it.

Coding is hard. It is F’ING hard.

And even worse, you can take two completely secure pieces of code, and put them together. And you know what, the result may have security bugs!!!

Remember your experiences in this class. Use that experience to govern your thinking in future security related projects.

The experiences you have had are why my number one motto is: “Security through simplicity.”

It’s my opinion that every piece of hardware or software increases risk through it’s very nature.

Even a security countermeasure has some implicit security risk that must be assumed.

On the business side, when implementing software, or installing a new piece of hardware you make a business case. Does the hardware or software save money, or allow sufficient increase in revenue to justify the cost.

From the security perspective, particularly with security countermeasures, that equation is a little different. The “cost” is measured in risk.

So the consideration must be: Does the amount of risk offset by the countermeasure, adjusted for the inherent risk associated with the countermeasure itself, reduce the overall risk sufficiently to justify the use of the countermeasure.

It’s a tough equation, given that it can be tough to calculate the risk inherent in a security countermeasure.  Why?  Because we want to think that security systems are secure.  But we know the truth.  We know how deep the rabbit hole goes.

For example, what’s the risk profile of a firewall?

Well, there’s a lot. Among them:

• Potential for flaws in firewall hardware and software that could allow unacceptable traffic through.
• Potential for human error in configuring rule sets.
• Potential for the firewall to fail in an unsafe mode.

And there are plenty of associated costs.

• Cost of the system.
• Cost of maintenance.
• Cost of developing security processes and procedures to manage the firewall.
• Cost of developing and maintaining trained staff to manage the firewall.
• Cost to accurately monitor the system.

The logic is cyclical.  The more risk you offset, the more you assume.

Hence my motto:

Security through simplicity.

Bill

From the Register:
Citect yanks ‘misleading’ SCADA bug advisory

Citect, a designer of software used by manufacturing plants and other industrial facilities, has removed an advisory that played down a vulnerability in one of its popular pieces of software.

Citect’s move followed last week’s release of proof-of-concept code that exploited a vulnerability in CitectSCADA, which is used to manage industrial control mechanisms known as SCADA (Supervisory Control And Data Acquisition) systems. The bug meant systems that relied on the software could potentially be exposed to tampering by disgruntled employees or terrorists.

Traditional IT software vendors have been learning this lesson for a long time.

Apple and Microsoft are still slow to the table.

But it looks like the tide is rising.

Vendors of SCADA system software are starting to feel the heat.

Many of these companies are used to writing systems that will be in place for decades. And from what I’ve read over the past few months, most of these companies use security modeling from decades ago.

I’m an advocate of two things:
1) A central set of cyber security requirements for all power related critical infrastructure.
2) US Government putting it’s money where it’s mouth should be.

The goal of the above two goals is to push security requirements into the front end of the procurement process. This pushes security needs back onto the vendors who are in the best place to ensure secure products.

Ask me about the secure composition problem later. For now, I’d settle for just one secure product…

PS - this article reminds me of the Helm’s Deep battle scene from The Two Towers, for those of you into LOTR (start at 8:40). You can say you are secure, but what say you when your defenses are obliterated?

Bill

From Electric Light & Power:
FERC proposes to close nuke cyber security gap

In an April 8, 2008 public joint meeting of FERC and the NRC, NRC staff indicated that the agency has proposed regulations to address cyber security at nuclear generating plants, but raised a concern about a potential gap in regulatory coverage because the requirements only will be directly associated with reactor safety security and emergency response, and will not extend to power continuity systems.

I’ve pondered the ramifications of this for a while.

One company, two regulatory bodies.

In the end, I believe that safety and security will be the casualty.

Nuclear power generating facilities in the US are regulated by the United States Nuclear Regulatory Commission.

Over the last year, NRC has gotten on the cyber security bandwagon. They have released a draft regulatory guide that, in theory, will increase the cyber security posture of nuclear power facilities.

In the absence of broad guidance, the industry has been operating under a policy developed by the industry, and approved by the NRC as an acceptable approach for ensuring cyber security.

Both these documents (much to my distress) are withheld from public disclosure.

The NRC’s job is to oversee the nuclear fleet (and other non-military nuclear related industry) and protect the public from potential harmful effects of radiation. After all, nuclear power plants in the US are using a radioactive isotope of Uranium (U235) as a heat source.

Since safety is the NRC’s primary mission, continuity of power concerns may be secondary.

The Federal Energy Regulatory Commission, on the other hand, is tasked with ensuring the safety, security, and continuity of the power grid.

In non-nuclear facilities, there is not an additional regulatory body concerned with the fuel source. The entire scope of operations falls under the regulatory oversight of the FERC.

The gap in regulatory oversight of nuclear generating facilities lies in the area between those set of assets that can be considered “safety related” and those that are considered non-safety related, but are important to continuity of power.

And things get really ugly when certain devices play both roles.

And that’s where this ball of wax gets really out of hand.

NRC is developing one set of standards for securing safety systems, and FERC (via NERC) has developed standards to ensure continuity of power.

Anyone who’s made it past basic algebra knows you can’t maximize two variables in an equation. You can maximize safety, or you can maximize your ability to ensure continuity of power, but not both.

Having grown up in Washington, I think I can smell which way the wind is blowing here.

The result will be that many systems will be under the regulation of two different entities, both with competing interests.

In the end, the operator will have to make a choice, and no matter which he chooses, he fails at achieving the requirements of either body.

In the situation, the best the operator can do is to shoot for the minimum set of configurations that meets all the requirements that match both sets of regulation.

I have to tell you, given that we are talking about a nuclear power reactor, I’d rather the operator not skimp on safety to ensure continuity of power.

What should be done?

It’s my opinion, having read the NRC’s draft regulatory guide, and spent some time looking over the NERC CIP’s that what we really need to do is take a step back.

I believe that continuity of power is a byproduct of the secure operation of any power facility.

I believe as well that safety is a byproduct of the same secure operation.

That said, I believe that what is best will be the development of a set of cyber security policies and procedures that are facility agnostic, and that ensure that digital systems within power generating facilities are secured.

Let the chips fall where they may. Implementing such a plan my require major modifications to the regulatory framework, but if it is what needs to be done, it needs to be done.

I can assure you that crackers do not care if FERC or NRC is running the show.

Bill

I had a long list of titles for this one…

• Tax dollar - Fail
• How to spend a whole lot of money for nothing
• Movie plot software (in a nod to Schneier’s Movie Plot Threats)

Below are some quotes from the article.  I’ll focus on the simple capability of the system, and will leave to others a discussion of the significant privacy issues involved.

Source: “Dalhousie to help U.S. catch cyber terrorists” - The ChronicleHerald Metro section on August 22…

 A major software project is underway by the U.S. Department of Homeland Security to monitor levels of Internet traffic and detect possible security breaches — and Dalhousie University is going to help build it.

“We’re just looking at bytes and addresses.”

Mr. McHugh said the new software will be used by government and businesses to monitor who’s trying to access their computer networks. It will look at the amount of information being sent from network to network and turn that complex raw data into some type of graph or chart.

Analysts will read those charts and look for patterns that can help reveal the work of hackers, spammers and cyber terrorists. Mr. McHugh said shady characters on the web will often contact hundreds of different Internet addresses, trying to look for weaknesses or important places to target. Sometimes they’ll try to contact addresses that aren’t even hooked up to a machine.

“If you try to make contact to a lot of addresses where there are no machines, it indicates you’re probing around the network because you don’t know what’s there,” Mr. McHugh explained Thursday.

The technology could eventually be used to track child pornographers, Mr. McHugh said. From a known child pornography site, the program could follow the trail back to an offender’s computer.

Carrie Gates is a Canadian computer scientist and Dalhousie alumnae working at CA Labs in New York. Researchers there and in Halifax work together on the project. She said once the software is complete, it will be released to the public so anyone can use it to monitor their computer networks.

Ok, so let me summarize:

• The system will be used by: government, companies, and individuals.
• The system will only look at source, destination, and packet size.
• The system will only reveal the ISP source.

I have lots of issues with this.

First, if you are a company or individual, then this system is nothing more than a glorified firewall.  It’s not even an IDS, since it does not do anything but reporting.

Install a firewall and Snort, and call it a day.  If you are really interested, look at the logs/alerts once in a while.  This new system is useless for you.

If you are the Government, then you can, if you can get this thing installed in the right place, monitor traffic at a high enough level to determine some anomalous or suspect activity.

But can you tell the source of the attacker?

This leads to my second issue, suppose you can get this device at some sort of critical juncture in the Net, can you really track a hacker?

Let’s consider this for a second.  They may really be on to something.

Oh, wait: TOR, okbye.

Third.  Well, now that I think this device is completely useless, they could tweak it a little and make it useful.

They could put some content filtering on it and use it to kill spam.

But I think there might already be solutions for this, blink, blink.

Ah well, back to the drawing board.

Bill

Computer World Security reprinted a 2003 CIO.com article entitled: 2010: The Future of Security.

While I don’t like articles/news that engage in fear mongering, this article does lay out some likely outcomes of the growing perception of insecurity in computer system.

I say “growing perception” not to say that things are all fine and dandy in the security arena, but to indicate that the average Joe, and Joe’s elected official, are starting to notice.

Two things I’d like to address.

First, the article cites some work and quotes from perhaps one of my favorite software engineers, Watts Humphrey:

 We’re letting creative artists build bridges, he says, then trying to stabilize them with unlicensed laborers while they’re collapsing.

“I want the technical community to become professionals,” Humphrey says, “to say, This is how we do our job.”

TSP and PSP have already been found to reduce coding errors by factors of up to 10 or more. Microsoft tried it and reduced bugs within a 24,000-line program from more than 350 to about 25.

Humphrey also has conceived of even more radical changes, including a software engineering curriculum modeled on medical school, complete with professional internships.

Now, I’m not bashing Microsoft here, I’m trying to make a point.  Microsoft engaged in the endeavor to increase their security and reliability because of customer demand.  People got sick and friggin tired of the crap they were being fed for huge cost.

A big driver of this frustration was the infamous BSOD.  The blue screen of death put a tangible face to the problem.

The insecurity inherent in our digital world is mostly faceless.  This fact, in my opinion, will make it harder to get wide-scale changes to happen.

If we want to eradicate the enemy of insecurity, we have to put a face on it…

Second, the article describes how we go from “free and open” to a “police state” very well.  Summarizing:

1. The first response is litigation.
2. After litigation comes regulation.
3. “What follows regulation?” asks Jeff Schmidt. “Standards.”
4. The final phase of the corrective response to the digital Pearl Harbor will be a reformation, a cultural shift toward better, more proactive security.

But the article fails in taking this picture to it’s logical end.

I don’t believe 3 and 4 will happen.  What will happen is “governmental oversight” stemming from regulations.

Lets look at the track record of, say, the TSA.  Are we prepared to have an organization like that managing our country’s networks and infrastructure?

Likely, however, we’ll end up there.  The sad truth is, that TSA has done little to improve transportation security, and future governmental organizations will do just as ineffectively.

But the general public can SEE the TSA, and though they hate it, are somehow drinking the cool-aid and believing that things Must be more secure.

The result - why do something else?  “The TSA is there, we’re safe, aren’t we?”

In my mind, that’s the end fallacy of governmental regulation.  It:

• gives a false sense of security
• puts organizations in the position where they’ll do the bare minimum to comply.

I do believe that government can do things to change how this whole security thing shakes out, but their track record is very bad.

The best thing the government can do, in my opinion, is demand security, built-in, from the bottom-up, in everything they do.  Every contract they develop, every system they buy, every contractor they hire.

The government’s initiative in this arena would give vendors the financial incentive they need to build security into the process.

The effect is that everyone benefits.

Bill

Definitions

What is Attack Surface?

Imagine you and a few friends are in a snowball fight.

Let’s say target number 1 is 4′9” tall and weighs 75 lbs.

Lets say target number 2 is 6′2” tall and weighs 290 lbs.

Now you start throwing snowballs.

Who are you more likely to hit, Skinny Bob, or Big-A$$ Charlie?

In the Infosec space, we refer to this as Attack Surface.

We measure size by quantifying the number of installed software or services available in an information system.

Mitigation

Say Big-A$$ Charlie hates getting hit by snowballs.

Now, unless he get some major plastic surgery and possibly significant amputations, he’s still going to be a pretty easy target.

But in the IT space things are a little different.

We have the ability to decrease the attack surface with little loss in capability.

Rant

So why don’t we?

Convenience.

Bruce Schneier in his book with Niels Ferguson, “Practical Cryptography” state:

“There are no complex systems that are secure.  Complexity is the worst enemy of security, and it almost always comes in the form of features or options.”

We need to quit thinking about security as something we can address whenever we get an IDS alert.

Security should be pervasive.

It must influence decisions from the start of a project.

When we do a project, we look at cost-benefit.

Security issues can pose significant costs.  Ask any company with a large data breach…

It’s time to quit acting like a bunch of little sissies and start taking this stuff seriously.

I can assure you, motivated and financially backed attackers are…

Bill

Background

The information security field is maturing.

But there are still challenges.

The information security field has not matured to the level of other broad reaching institutions.

One particular area of concern for me is in how the industry deals with events that cut across the entirety of the infosec space.

How does the US Centers for Disease Control (CDC) handle, or prepare to handle, large-scale outbreaks?

How does a country like Japan, for example, mature their processes to the point where they can train millions of people how to properly prepare for, and execute an evacuation of an entire city in the event of an earthquake or Tsunami?

The events surrounding the recent DNS issue further exemplifies and illustrates the weaknesses in the security space’s abilities to handle large scale critical security incidents.

My fiance is in the public health field and works closely with US Centers for Disease Control (CDC) on the topic of food safety.  They recently dealt with a nation-wide samonila outbreak.  I was fortunate to learn a little about how they deal with these events.

Throughout this post, I’ll refer to what I’ve learned about how CDC is able to coordinate disparate groups to accomplish a common objective.

Overview

Off-the-cuff, I came up with a list of the primary phases of large-scale incident handling.  I tried to think beyond just the infosec space…

The phases I’ll discuss are:
Discovery
Analysis
Vetting
Damage Control
Recovery and Response
Post-Incident Analysis and Process Enhancement

I’ll discuss what goes into each phase and refer to how the DNS incident highlights where we need to improve.

I’ll end with some remarks and a vision of what I’d like to see happen.

Objective

The objective of this post is to raise the level of discourse beyond the DNS incident, and focus on the future.  I want to leverage this incident to take a step forward.

I’ll refer often to how the DNS incident was handled, but the reader should try to avoid interpreting judgement on my part.  I’m not trying to debate how person X did Y, or should A have done B.  I make references to events only to illustrate how we can learn and improve.

I want the reader to walk away thinking about how we can do better…

Discovery

This one is a bit of a no brainer.  This is where an issue is identified.

It can come up as the part of a risk assessment, a vulnerability assessment, incident response, or read on a blog post.

Humorously, in this case, Dan’s discovery was, as he admits, quite by accident.

In the infosec space, we can classify the discoverers into two broad classes:

• Bad guys - for example, those with a vested financial interest in exploiting the vulnerability without the consent of legitimate users.
• Good guys - for example, vulnerability researchers or incident handlers discovering where the bad guys are one step ahead.

Like the security sector, CDC has to deal with threats introduced by good guys and bad guys.

We also both have good guys with a vested interest in “getting to the fix first.”

Now, I’m not trying to claim that the CDC is perfect, but they have something we lack.  Coordinated discourse at the national level respecting incident handling.

Discovery, for them, may involve a little of the, “OMG!  Did you read about…”  But they also take a very proactive approach.

CDC works aggressively with hospitals and institutions to correlate “event data” to determine if there is an outbreak.

This high level of interaction builds collaboration, enhances communication, and keeps all levels aware of the significance of what they are doing.  CDC deals with serous stuff.  And the DNS vulnerability is the equivalent of a cyber bird-flu.

In our space, there is no focused point of aggregation of vulnerability information.  We have public (federal agencies), private, and underground channels.  Can we do better?

Using the Risk = Vulnerability * Threat * Consequence equation, discovery results in the identification of a vulnerability.

Analysis

Analysis involves considering the impact of the vulnerability identified in the discovery phase.  What’s the threat?

Dan, after doing more research on what he found, pulled together a team of industry insiders, experts, leaders.

I suspect the conversation was a bit like, “I think what I found is huge, here’s the details, what do you think?”

This conversation undermines the entire process if the people in that room can’t be trusted.

At this point, trust enters the equation.

As I discussed earlier, CDC can pull together public officials, industry leaders, and other key players.  One of CDC’s big concerns is pannic.  For example, it has to consider that if it says “tomatoes have been identified as the source” that there may be farmers that may loose everything as the result of the disclosure and resulting demand reduction for tomatoes.  Trust must exist.  CDC must trust that people receiving information will handle it properly, responsibly.

In Dan’s case, he was able to pull such a team together.

Though we are starting to develop this capacity as an industry, we definitely need to focus some attention here.

Vetting

Once consensus is reached that the vulnerability carries a reasonable level of threat, vetting allows us to determine consequence.

At this point, additional research might need to be done.

In the DNS case, I’m sure there was consideration of how quickly a remedy could be introduced, how long it would take to formulate a hack once the vulnerability hit the public, and what the consequence would be in the time between exploit and remediation.

In this case, I think the CDC has it a little easy.  Historical information can help inform the risk to humans.  Lost work, impact on the health infrastructure, potential for death can be analyzed from previous incidents.

In the Security space, we have a bit of a challenge here.

How do you calculate, at a national level, the consequence of the DNS vulnerability?  Every organization may have different consequences, and I don’t think there’s really any solid mechanism to statistically analyze cyber security costs at the level needed to inform the analysis.

This situation is further compounded by the lack of institutionalized communication channels.

As an industry we’ve historically struggled with senior management on budgetary issues because consequence is hard to calculate.

This is beginning to change somewhat, but we need to get to a point where we understand the costs to business, and can communicate clearly to representatives who are working at analysis.

In Dan’s case, from what I understand, there was pretty immediate acceptance that the consequence was very high.  It may not have needed to be calculated as a dollar figure, but consensus resulted in a good outcome.

We know have the pieces of information needed to determine the overall risk.

Damage Control

Cognizant of the risk, we can develop a reasonable mitigation strategy.

In the DNS case, it involved the coordinated effort of 16 key vendors develop, test, and prepare to deploy patches to over 60 DNS products.

In the CDC case, for example, this is the development of a vaccine.

Consensus must be reached on how the risk mitigation strategy will be implemented.  With the DNS vulnerability, the plan was to release patches and announcements simultaneously, and for Dan to do a full disclosure roughly 30 days later.

What Dan and his team did successfully was to come up with a good risk mitigation plan.

In the ideal world, it would have come off without a hitch.

But we’re still maturing, and the plan didn’t work out.

I’m not passing judgement, but I think that we can learn a great deal from how the risk mitigation played out.

So far, this is where I see most of the post-incident analysis focusing.  I’m reading a lot of how the disclosure and subsequent events ’should’ have been handled.  But We have to look broader…

What we need is an informed process on how to handle recovery and response, and the key players must be bought in.

Recovery and Response

Recovery and response is where we execute our risk mitigation strategy.

When the strategy is “patch”, the infosec space has vastly improved.

Almost all major OS and software vendors have implemented easy update processes that can often be automated.

There are cases where automatic updating is not advisable, and our risk mitigation strategies must consider this.

But a coordinated communication hierarchy can help improve information dissemination.  Our system administrator must know that “tonight is a stay late and patch” night.

When handling a virus outbreak, CDC would take this time to issue alerts to hospitals or other health facilities, and begin, if necessary, distribution of vaccines.  CDC, for the most part, has these communication channels nailed down.

In my opinion, this phase highlights the communication conundrum in the infosec space.  The DNS vulnerability, in my opinion, was a once-in-a-decade if not lifetime event.  How did this message get to Joe-Q system administrator?

We need to change and improve.

Post-Incident Analysis and Process Enhancement

At this point in the process, we can take a look at how we performed.

We have the opportunity to review and analyze our processes and procedures and see how we can do better next time.

In my opinion, the IT sector as a whole does a pretty bad job here.  Generally we are off to work on the next project.

I think this is a big mistake.

We need to focus attention here.

Conclusion

The recent DNS vulnerability and how it was handled gives the information security sector an excellent opportunity to take a look at how far we’ve come, and where we need to go.

We have smart people in this space.  Over the last 3 weeks I’ve read over a thousand blog posts, listened to over 10 podcasts, and done a lot of discussing with colleagues respecting this issue.

What I came away with was, “Damn, there are some smart people here!”  And I’m not talking just plain geek smartness.  I heard a lot of business savvy, a lot of common sense, and a lot of critical thinking and analysis.

But where can we do better?

The infosec space has some unique characteristics, but there is a lot we can learn from other, more mature, institutions.

We’ve come a long way, and we need to focus on how we develop industry-wide collaboration.  IR&R is a great opportunity for us to begin this process.

We should be looking at institutions that do this stuff regularly.  What do they do?  What can we take away?  Lets take a look outside the box.

This stuff may be rocket science to the infosec sector at the national or international level, but in other sectors they’ve already got men on the moon…

I’d like to take a minute to address the issue of those with a vested interest in early disclosure.  Penetration testing companies don’t need to be kicked to the curb here.  They can bring a lot to the discussion, and can benefit from being at the table at all phases too.

The issue is that responsibility must be to more than the bottom line.

Everyone should be engaged, and I don’t think we should shut anyone out.

We may need to find ways of addressing things like the buying and selling of vulnerabilities, but let’s have an informed discussion.

A vision

I think that a lot of discussion needs to happen, but I do have a vision for where I’d like to see us end up…

What would I like to see?

• A trusted tier-one group of multi-sector representatives that meet frequently, and have a good ability to determine consequence quickly.
• This group has accepted procedures for handling events through the remediation phase and perform post incident analysis.
• A group of mid-tier folks who know the seriousness of what’s coming out of group 1. and have have the tools, and resources needed to hit the ground running.
• This group interfaces regularly with the tier-one group on process analysis and improvement.
• I want to see a broadly known, easy mechanism for vulnerabilities to be introduced to the vetting cycle and be handled appropriately, and I want the process for doing this to be no-risk to the discloser.

I want the obscure, high-school kid who discovers a flaw in a critical system to have a place to go and have his concerns vetted.

I’d like to see the intelligence agencies come to the tier-one group and discuss an issue without the risk that sources might be compromised, or that the information would be mishandled.

At the moment, that’s a pipe-dream :/

The security industry has come a long way, but we have a long way to go.

Keep your eyes on the prize.

Bill

The recently released bug in Altiris Notification Server allowing privilege escalation echo’s a sentiments I’ve held for a long time:

• Security products, in general, are no less vulnerable to attack than your average piece of software. (Note that this product had a similar vulnerability just a few months previously…)
• Adding security products increases your install base.
• Increasing your install base increases your attack surface.

I believe big strides toward a more secure, robust computing environment can be achieved through:

• Allowing the least required access to the minimum required services
• Reducing the install base to support least access to least services

If you can’t get those simple things right, don’t bother adding security products on top.

Every additional service (software, protocol, etc) and each additional role compounds your attack surface.

Get down to basics.

Bill

The March 15, 2008 SploitCast podcast was recorded at SchmooCon and consisted of a panel discussion including some notables in the InfoSec space: Johnny Long, Rodney Thayer, Simple Nomad, Landon Lewis, Squidly, and Matt Hillman.

Though the entire cast is a must-hear, with an extensive discussion SCADA and critical infrastructure security, the conversation turned toward practical security in a space where the boundary of the ‘network perimeter’ is rapidly vanishing.

Simple Nomad made the observation that end users don’t, and won’t, care about security.  Paraphrasing, it’s not that they are dumb, or stupid, but that they have different areas of expertise, and security may not be it.

The group agreed that security awareness is important, but it can’t be ‘the fix’.  Users will not become security experts.  Users can, however, be taught basics, such as not clicking on untrusted links in email.

At this point, Johnny Long stepped in.

He stated that awareness is good, and perhaps policy as well, but that when we really boil this security thing down, it reduces to three basic principles:

1. A server should not be a client
2. A client should not be a server
3. Peers should only connect in certain ways

He noted that when a computer changes roles, that’s when we know there’s a problem.

For example, when a laptop gets infected with bot malware and begins phoning home, it starts acting like a server, and that’s the behavior we should be looking for.

Important points, and I subscribe to this view of the network.

It doesn’t matter if the device is completely controlled by our IT team, or an iPhone connected inside our network… If it’s a client, it should be acting like a client…

Imagine the simplicity of this view.

Suppose we had the simple tools necessary to determine if our machines are abiding by their designated role, then what will we need to ensure about the device.

Do we have to ensure that the box is 100% patched?
Do we have to pay lots of cash for anti-virus, anti-phishing, anti-this and anti-that?
Do we have to make sure that the user has a 100% crack-resistant password?
Do we have to spend countless hours configuring our network to prevent unauthorized hosts?

Perhaps not.

One simple reason, it takes much less time to re-ghost a PC than it does to keep it ’secure’.

In my organization, for example, we could let the desktops and laptops run free on the Internet.

As long as we know what clients are allowed to do on the network, and what they are not allowed to do, then we are far better off.

Imagine this… Say you have all the latest updates, and anti-virus scanners and whatnot.  Well, do you know you are safe, or do you believe you are safe?

If you believe you are safe, then I’ll be happy to show you how you are wrong.  And if you know you are safe, then I’ll call you ignorant.

Why? Because security degrades over time.  Even the most secure system on earth is only secure until an attacker finds out a new way into the system.

For example, social engineering always works…  Plain and simple, it doesn’t matter how secure the system, if I convince you to reveal the appropriate information, I will own you.

Perhaps I need to ponder this a little more, but it seems logical that we can dramatically simplify our IT infrastructure if we focus on separation of duties in the hardware/software space, and then focused our security dollars on making sure that those roles were being followed.

The old conceptions of the network no longer apply in a space where the network perimeter is porous, or non-existent.  We need to change our thinking to match reality.

Bill

On June 2, CSO Magazine Online published an interview with Bruce Schneier entitled, “The Endless Broadening of Security.”

At one point, Bruce makes the followng observation about human behavior.

Making security trade-offs is fundamental to being alive. After figuring out how to eat and reproduce, the next most important thing for a species to figure out is how to avoid predators. So with security such a fundamental driver of brain development, it’s not surprising that very primitive parts of our brain control some of our basic security reflexes. The amygdala, for example, is an ancient part of the human brain that first evolved in primitive fishes. It’s what controls the fight-or-flight response: increased heart rate, increased muscle tension, sweaty palms, and so on. That part of the brain is so fast that when you see a snake, your amygdala starts working even before your conscious brain knows what you’re looking at. You can override your amygdala. That’s part of what makes you uniquely human, and it happens whenever you take a dressing-down from your boss and just listen instead of either running away or stabbing him with a spear. But it’s hard.

Over the past year or two, I’ve read much of the evolution of Bruce’s thinking on the role basic human behavior plays in the realm of security.

And I must say that I agree, for the most part. Cerebrally, it makes sense.

When I read the above quote from him, I had somewhat of an “Ah-ha” moment.

As many of you know, I’m an avid runner.

I love running. I believe that running is as basic to human nature as eating.

I believe in the greater evolutionary chain, running was critical to the success of the human species.

Over the years, I began to believe that the simple act running put me in touch with the animal that I really am.

Humans are animals, plain and simple. We have needs for food, shelter, more food, sleep, reproduction, and more food :)

Yes, I live in an amazing “shelter” and spend a great deal of time gardening, but deep down inside, I’m just an animal.

When it all comes down to it, this is my cave, my primary shelter. I stock it with food, and it’s where I want to raise my spawn (grin).

It is my belief that despite all the trappings of modern society, we really have evolved very little in the past several million years. We just “wear different clothes”.

That belief system came to me because of running…

But I never took the realization to the logical conclusions.

If all of us are just animals, then what does that mean about the way we behave collectively?

We operate out of needs. Needs to protect our food, shelter, personal security, etc.

And that’s where Bruce has been focusing.

What and how do humans behave regarding their need to feel secure?

So, where my understanding of Bruce’s thinking was pretty cerebral before, it’s now been connected to me in a more personal way.

Interesting stuff. I’ll have to spend some time today contemplating.

Fortunately, I have lots on the honey-do list. That’ll supply me ample time.

I wonder if I would be pulling weeds outside my cave 50,000 years ago…

Jocelyn doesn’t understand that excuse though, so I’m off to get my gloves.

Cheers,
Bill