Public Class Only Two Weeks Away

My only public Network Security Operations class scheduled for 2006 begins in two weeks. The class is almost full, but I have a few seats left. I've published new prices:

• Register by 5 June 2006: $2595/student


• Register by noon on 12 June 2006: $2695/student

I will not be able to accept any more students past noon on Monday 12 June.

ISSA members receive a 10% discount.

This week I will also teach a one day course on Network Security Monitoring with Open Source Tools at the USENIX 2006 Annual Technical Conference in Boston, MA on Friday, 2 June 2006. This is the course to attend if you want to learn the essential components of network security monitoring. We will use tools on my Sguil VM in this class.

Later this summer I will teach a brand new, two day course called TCP/IP Weapons School at USENIX Security 2006 in Vancouver, BC on 31 July and 1 August 2006. Are you a junior security analyst or an administrator who wants to learn more about TCP/IP? Are you afraid to be bored in routine TCP/IP classes? TCP/IP Weapons School is the class you need to take!

Finally, some of you have asked if I might offer courses on the weekend. I am considering a few options.

1. Teach two two-day courses on weekends, with one course on Saturday-Sunday of week one and a second course on Saturday-Sunday of week two. Students could choose to end either or both classes.


2. Teach on one day of the weekend -- probably Saturday, for two or four weeks.

These would be public classes in northern Virginia, probably Fairfax.

For 2007 I am considering offering public classes in one or more of the following locations: northern VA, New York city, Silicon Valley, San Antonio. Do you have any comments on these locations?

Read More

Recommended Reading on Federal IT

CIO Magazine absolutely hammered government IT in its lengthy story Federal I.T. Flunks Out. You wouldn't read that news in FCW. Commenting on the problem is this former IRS CIO:

"Ultimately this is a security threat," says John Reece, a former IRS CIO and now a consultant to the federal government. "If we can't get beyond the legacy systems we have today, while our enemies are starting off with state-of-the-art technology, what's going to happen is they're going to absolutely tear us to pieces again."

Wrong. It's not a security threat. Poor IT management is a vulnerability. Argh.

Read More

Three Threats

I thought three examples of threats, with corresponding vulnerabilities, etc., might help convince those who doubt the proper use of these terms. Let's start with a mythical example: Achilles. I'll use Achilles' point of view.

• Risk: Death of Achilles.


• Asset: Achilles' life.


• Vulnerability: Achilles' heel. (Achilles was invulnerable, save the portion of his heel where his mother held while dipping him in the River Styx. This is the most popular version of the myth.)


• Threat: Paris, who shot Achilles in the heel with an arrow.


• Exploit: The arrow show by Paris.

Let's now look at an example from one of the best movies of all time: The Karate Kid. I'll use Daniel's point of view.

• Risk: Loss of tournament, thereby letting Johnny Lawrence win.


• Asset: Daniel LaRusso's fighting ability.


• Vulnerability: Leg injured in previous fight.


• Threat: Johnny Lawrence.


• Exploit: Strike to the injured leg.

Man, that was funny. Here is the third example, from Star Wars. (Don't make me quote the episode -- this is geeky enough already.) I'll use the Empire's point of view.

• Risk: Loss of the Death Star and Imperial prestige.


• Asset: The Death Star.


• Vulnerability: "An analysis of the plans provided by Princess Leia has demonstrated a weakness in the battle station... It's a small thermal exhaust port, right below the main port. The shaft leads directly to the reactor system. A precise hit will start a chain reaction which should destroy the station."


• Threat: X-Wings, e.g: "[T]he Empire doesn't consider a small one-man fighter to be any threat, or they'd have a tighter defense." (Bravo Lucas!)


• Exploit: "The shaft is ray-shielded, so you'll have to use proton torpedoes."

Getting the hang of it? Try representing the Star Wars example from the Rebellion's point of view. It's fun, really.

Read More

Threat Term Used Properly in Government Report

It's time once again to talk about threats! Yes, you guessed it. While reading back issues of FCW I encountered good -- and bad -- uses of the term "threat." Mostly, threat was used where vulnerability should have appeared. Let's briefly review the definition I provided in my books:

A threat is a party with the capabilities and intentions to exploit a vulnerability in an asset.

A vulnerability is a weakness in an asset that could lead to exploitation.

For example, an intruder (the threat) exploits a hole (the vulnerability) in Microsoft IIS to gain remote control of a Web server. In other words, threats exploit vulnerabilities.

I've written about proper use of the term threat many times before. Let's look at a few examples from FCW that show why it's important to use the right term when communicating among security professionals.

First, consider the article Cybersecurity research plan identifies threats. The story discusses the Federal Plan for Cyber Security and Information Assurance Research and Development (.pdf).

Using proper terminology, I would expect this article to discuss plans by mostly law enforcement, intelligence, and military groups to investigate organized crime, state-sponsored groups, foreign intelligence services, and so on. Perhaps honeypot operators would also be involved tracking botnet herders and the like. I can't tell from reading the article. Here are two places where "threat" is used:

The report identifies critical threats to the nation’s information technology infrastructure and recommends that the government pay for research that would enable manufacturers to build IT security safeguards into infrastructure systems before they are delivered to power plants or other high-risk facilities.

That sounds like a discussion of vulnerabilities. When the term "safeguard" is used, it's a synonym for "countermeasure."

One of the action points is the following:

Focusing on threats with the greatest potential impact.

Again, I can't tell if the article is correctly referring to malicious parties, or incorrectly referring to the most serious vulnerabilities.

Thankfully, when I read the report, I see proper terminology in play:

Cyber threats are asymmetric, surreptitious, and constantly evolving ­ a single individual or a small group anywhere in the world can inexpensively and secretly attempt to penetrate systems containing vital information or mount damaging attacks on critical infrastructures. Attack tools and resources. (p. ix)

Bravo. Page 5 offers definitions:

A vulnerability is a flaw or weakness in the design or implementation of hardware, software, networks, or computer-based systems, including security procedures and controls associated with the systems. Vulnerabilities can be intentionally or unintentionally exploited to adversely affect an organization's operations (including missions, functions, and public confidence), assets, or personnel.

A threat is any circumstance or event with the potential to intentionally or unintentionally exploit one or more vulnerabilities in a system resulting in a loss of confidentiality, integrity, or availability. Threats are implemented by threat agents. Examples of threat agents are malicious hackers, organized crime, insiders (including system administrators and developers), terrorists, and nation states.

Risk is a combination of the likelihood that a particular vulnerability in an organization's systems will be either intentionally or unintentionally exploited by a particular threat agent and the magnitude of the potential harm to the organization's operations, assets, or personnel that could result from the loss of confidentiality, integrity, or availability.

Notice this report recognizes that vulnerability and threat are not synonyms! The report later names Malicious Hackers, Organized Crime, Terrorists, and Nation States as threats.

Let's close with an example of how not to use the term threat: SCADA on thin ice: Industrial control systems pose little-noticed security threat. "Little-noticed threat"? Maybe SCADA is little noticed as a "threat" because it suffers vulnerabilities.

Elsewhere in the story, however, the term vulnerability is used properly, and threat doesn't make a repeat appearance, save the following. For example:

Control systems security is one of six areas of critical vulnerabilities Borg included in a new cybersecurity checklist released in April by the research group...

Even if a facility has not been attacked, that doesn’t mean it’s secure or the threat isn’t real, said Michael Assante.

What is happening here? Reporters usually don't choose the titles for their stories. My guess is some editor at FCW decided to use the term "threat" where "vulnerability" should have appeared. Threat is shorter (fewer syllables = good) and sexier -- too bad it's wrong in this case.

Read More

DoD Certification Program Update

I've had a chance to read issues of Federal Computer Weekly delivered while I was on vacation. I like reading FCW because it gives me some insight into the madness found inside the Beltway.

I enjoyed reading Wanted: Information assurance-savvy people, which discussed DoD's plans for certifying IT staff. I've examined this issue before. Here's a quote by someone who understands the problems with DoD's plan:

Alan Paller, director of research at the SANS Institute, said DOD should have no problem meeting its initial target of 80,000-plus employees trained and accredited in information assurance. But he doesn’t think the baseline certification that DOD requires will produce a workforce capable of securing the military’s systems.

“The problem is that the bulk of the certifications don’t teach people how to do security,” Paller said. “Certified people will be able to talk about security, but they won’t know how to do it — to actually encrypt data and do the necessary work.”

Instead, DOD needs a way to evaluate actual information assurance work, Paller said. That requires hand-on training and scenario-based testing, he added.

Alan is absolutely right. A DoD certification program which accepts the CISSP as the top technical certification indicates the program designers are absolutely clueless.

Speaking of clueless:

Robert Lentz, DOD’s director of information assurance, said he respects Paller’s opinion but is not worried that the program is headed in the wrong direction. The important thing is to get baseline certifications awarded and then work from there, Lentz said.

Assuming the reported depicted Mr. Lentz's words accurately, I am extremely disappointed by this opinion. This attitude sounds to me like the following: "Who cares if our program is wrong? Let's just get it started." That is a recipe for failure, especially considering this quote from the article:

DOD’s success with IA training and certification could have wider implications, said Jim Flyzik, president of the Flyzik Group, a consulting firm. If successful, DOD’s approach would probably be adopted in other areas of government, he said.

Great. DoD starts down the wrong path, and the rest of the government follows? Ouch.

Read More

The Worst of All Possible Worlds

Sometimes I read configuration guides that advise installing anti-virus products on servers. Since I don't run Windows servers in production environments, I can usually ignore such advice. The proponents of the "anti-virus everywhere" mindset think that adding anti-virus is, at the very least, a "defense-in-depth" measure. This was debated last year, actually.

A lesson I learned from the excellent book Protect Your Windows Network is that "defense-in-depth" is not a cost-free justification for security measures. Every configuration and installation aspect of a system provides benefits as well as costs. Something implemented for "defense-in-depth" (whether truly believed to be helpful, or ignorantly applied) may turn out to harm a system.

Thanks to Harlan Carvey, I learned of another example of a defense-in-depth technique damaging security. This is the worst of all possible worlds -- adding a security measure that results in massive vulnerability. This upcoming eEye advisory warns:

A remotely exploitable vulnerability exists within the Symantec Antivirus program. This flaw does not require any end user interaction for exploitation and can compromise affected systems, allowing for the execution of malicious code with SYSTEM level access.

So you add anti-virus to a server, and BANG. 0wn3d.

Harlan focused on the following quote in the email he sent me:

"People shouldn't panic," [eEye's] Maiffret said. "There shouldn't be any exploits until a patch is produced."

This is a reference to the fact that once a patch is released, white, gray, and black hat security researchers race to analyze it to identify the vulnerable code fixed by the patch. Harlan wonders (accurately) if the underground (or others) already know about this vulnerability, and whether they are already exploiting it.

Keep this case in mind if you believe that "adding security" is a cost-free endeavor.

Read More

Security Clearance Story Continues

Apparently the Defense Security Service has resumed "processing initial Secret requests." That is "security officer"-speak meaning DSS is again working on requests for Secret clearances from people who have not held them before.

The notice continues: "DISCO [Defense Industrial Security Clearance Office] will begin processing initial Top Secret requests and periodic reinvestigation requests for both Secret and Top Secret upon receipt of additional funding." That means those who have not held a Top Secret clearance but require one will still wait. Also in the queue are those needing a periodic reinvestigation for their Secret or TS clearance.

The Washington Post noted that Congressman Davis planned to hold a hearing a week ago on the affair, but I can't find any transcripts.

I thought the comments in the SANS Newsbites Vol 8 Issue 41 (link will work shortly) were astute:

Editor's Note (Pescatore): What is really needed is a review to determine if the clearance process actually provides any security value, and if security clearances are being required for positions that really don't need them. A knee jerk reaction to just throw more money to pay for more background investigations just perpetuates long time problems in the entire process.

I agree with the first point, but the second would require a huge overheaul of the Federal information classification system. This is definitely needed (see a recent Schneier post) but wouldn't affect the clearance issue for years.

(Weatherford): I wonder if this temporary shutdown was simply a way for DSS to cry for help and get the government's attention. This has been a problem for years. Maybe now they will get the funding required to eliminate the backlog.

Wonderful comment. It's funny that DSS "identified funding" right before a Congressional hearing.

(Shpantzer): The situation is so bad that some technical staffing companies providing cleared employees to the government actually put the cart before the horse: They find cleared people first, then train them up to technical requirements... If that's not scary, I don't know what
is.

Here's a scarier thought: that is standard practice. Everyone does it.

(Paller): The "clearance first" policies of many agencies has led them to make people who have never secured a system responsible for telling people how to secure systems. In other agencies, contractors with abominable delivery records are being kept on, over the objections of those who take security seriously, because the ineffective contractors have people with clearances.

Another scary thought: these same clearance-holding contractors are exchanged between employers when the employee decides to switch jobs.

Incidentally, I put security officer in quotes when I mentioned the term earlier. I did that because it reminded me of the different sorts of people who perform work under the "security" umbrella. Far too many "security officers" are just paper-pushers. They are experts in the arcane world of passing clearance information when people visit remote locations. They read people into programs and out of programs. The maintain a lot of paperwork. They hold a lot of clearances but generally do not use the information in a productive manner.

These sorts of people can be in demand due to the clearances they hold, but they bring absolutely no expertise to technical problems. In some ways they remind me of "security auditors" who understand checklists but have no real idea if the checklist corresponds to any true security value.

If you thought I disliked the CISSP as a worthless indicator of practical security knowledge, imagine my attitude towards security clearances.

Read More