DOJ National Security Division Pursuing Cyber Espionage

I just read Justice Department trains prosecutors to combat cyber espionage by Sari Horowitz, writing for the Washington Post. The article makes several interesting points:

Confronting a growing threat to national security, the Justice Department has begun training hundreds of prosecutors to combat and prosecute cyber espionage and related crimes, according to senior department officials.

The new training is part of a major overhaul following an internal review that pinpointed gaps in the department’s ability to identify and respond to potential terrorist attacks over the Internet and to the rapidly growing crime of cyber espionage, the officials said, describing it for the first time.

In recent weeks, Justice has begun training more than 300 lawyers in Washington and nearly 100 more across the county in the legal and technical skills needed to confront the increase in cyber threats to national security...

Under the reorganization, teams of specialized lawyers within NSD in Washington will work with other agencies, the military and companies facing cyber intrusions. They will develop protocols for the intelligence community and federal agents in how to deal with private companies that are victims of cyber attacks. The issues revolve around how to build possible prosecutions within guidelines covering information sharing, privacy and civil liberties.

At least one prosecutor in each of the 94 U.S. attorney’s offices around the country has been designated and will be trained to gather evidence and prosecute cyber espionage and similar Internet-related cases.

This is very interesting if the focus is truly on cyber espionage cases. DOJ persecutes physical espionage cases routinely (albeit with difficulty due to the nature of the laws). Cyber espionage cases are almost never pursued. Working with private companies will be key to this problem, and that aspect is mentioned specifically in the article.

Let's see what happens!

Tweet

Read More

TSA Lessons for Security Analysts

In the past I've run several security teams, such as the Air Force CERT's detection crew and the MSSP division of a publicly traded company. In those positions I was always interested in assessing the performance of my security analysts. The CNN article TSA tester slips mock bomb past airport security contains several lessons which apply to this domain.

Jason, a covert tester for the Transportation Security Administration, has been probing airport weaknesses for five years, beginning with big mock bombs before switching to ever smaller devices as the TSA adapts to evolving terrorist threats...

Even before the September 11, 2001, terror attacks, government agencies deployed "red teams" such as this one to look for holes in airport security...

But instead of running from tests, the agency has embraced the idea that testing has a value that goes beyond measuring the performance of individual screeners.

Tests, the TSA says, can show systemwide security vulnerabilities...

[S]creeners who fail to detect contraband are "pulled off the line" and retrained before being allowed back.

The test CNN witnessed was conducted by the TSA's Office of Inspection, which the agency calls the most sophisticated of its covert tests. But there are others.

For starters, every TSA X-ray machine has a Threat Image Projection system, which digitally inserts images of guns, knives and bombs into the X-rays of luggage, to keep screeners alert...

If screeners observe a suspicious object, they can check with the simple click of a computer mouse. If they detect a threat object, the computer congratulates them. Successes and failures are recorded for use in a screener's performance evaluation and are factors in determining pay.

Some 69,929 threat image tests are conducted on an average day, or more than 25 million tests per year. An array of other tests also are conducted to assess screeners, including the red team ones.

I've described elsewhere why I support red teams. I certainly recognize that one of my Three Wise Men savages red teams, but I've never seen anything else -- short of an actual incident -- make a dent in the attitudes of management. Furthermore, red teaming, as a real-life test, tends to discover and link vulnerabilities in ways not anticipated by some vulnerability assessors (blue teams) and general security architects. There's no ground truth like saying "I accomplished the mission using this method" when someone is claiming their network is "secure."

I also like the method to test analysts by inserting false images. Fighting analyst boredom is a big problem in some operational teams.

Read More

Feds Plan to Reduce, Then Monitor

According to OMB directs agencies to close off most Internet links, by June 2008 the Federal government plans to reduce the number of Internet connections it maintains, and then monitor them more closely:

The Office of Management and Budget's Trusted Internet Connections (TIC) initiative likely is to be the last publicized program in the Bush administration's stepped-up focus on cybersecurity, some experts say. More importantly, the new initiative requires agencies to implement real-time gateway monitoring, which has been a deficit in federal network protection.

The TIC initiative mandates that officials develop plans for limiting the number of Internet connections into their departments and agencies. OMB officials want to reduce the number of gateways from the more than 1,000 to about 50, said Karen Evans, OMB's administrator for e-government and information technology. (emphasis added)

This sounds promising. The story continues:

The initiative also asks chief information officers to develop a plan of action and milestones for participating in the Homeland Security Department's U.S. Computer Emergency Readiness Team's Einstein initiative. The program offers agencies real-time gateway monitoring capabilities and helps them react more quickly to security incidents. About 13 agencies voluntarily participate in the Einstein program.

"The reduction of access points to trusted Internet connections will improve our situational awareness and allow us to address potential threats in an expedited and efficient manner," Evans said. "While we optimize and improve our security, it is also our goal to minimize overall operating costs for services through economies of scale."

Reduction of gateways + enhanced monitoring = better, stronger, faster -- and cheaper.

The story With Internet gateways, less is more adds:

A June deadline for agencies to consolidate their Internet connections coincides with another OMB deadline. June is also when agencies must upgrade their backbone networks to run the next-generation Internet protocol, IPv6...

“The [TIC] initiative is saying, ‘We have to know what we own in order to protect it,’ ” Evans said. “We also must know we are managing risk at an acceptable level.”

Evans said the federal government has more than 1,000 gateways to the public Internet.

The target number is 50, but that is not an absolute number, she said. “We know 1,000 or more is not the way to do it. At a minimum, 50 is two per department.”

Fifty gateways is a reasonable number, Evans said, adding that the Defense Department has reduced its Internet gateway count to 18. The Homeland Security Department expects to have only two Internet gateways after it completes its OneNet initiative.

“The 50 or so points of presence [would] become the perimeter of the federal government,” Evans said. (emphasis added)

Kudos to Karen Evans. I am hopeful that someone who realizes FISMA Is a Joke has begun steering the Federal government away from worthless documentation and towards real network security operations.

Read More

A Plea to the Worthies

You may have seen stories like Cybersecurity Experts Collaborate with subtitles like A think tank has tapped several heavyweight security experts to staff a commission that will advise the president. That story continues:

The Center for Strategic and International Studies (CSIS) wants the commission to come up with a list of recommendations that the new president who takes office in January 2009 "can pick up and run with right away," said James Lewis, director of the CSIS Technology and Public Policy Program. The commission, made up of 32 cybersecurity experts, plans to finish its work by the end of 2008. I am fairly confident that nothing of value will come from this group, but there is one task which could completely reverse my opinion. Rather than wasting time on recommendations that will probably be ignored, how about taking a step in a direction that will have real impact: security metrics. That's right. Spend the first day (or two, if you are a slow reader or can't sit still for long periods) reading Andy Jaquith's book. Next, and this is the crucial part:

Figure out how to play and score the game before you pretend to think you can improve the score.

What does this mean? Just a few ideas include:

• Propose definitions for security, risk, threat, vulnerability, inside threat, external threat, and all the other words we use yet upon which we never agree. Hold hearings and invite real security people (not just digital security people) to express their views.


• Propose some metrics and see how other operations define success. Hold hearings on the results of that process.


• Apply metrics to some real organizations and gain a baseline set of numbers. Repeat the process at determined time intervals. Try to identify correlations and if possible causations. Be anonymous if necessary, but use a real methodology and not the self-selection applied by CSI/FBI and others.

Do you see where I am going here? At the end of the process we could have a framework for seeing just what is happening. I defy anyone to tell me just how bad or good our digital security situation is right now. Some say the sky is falling, others say we're happy! happy!, others say we're just as secure as we need to be to continue limping along. It is a proper role for a panel of worthies to help figure out how the game is played and then what the score is. It is a waste of time to make recommendations before those basic steps have been taken.

Read More

DHS Debacle

Thanks to the Threat Level story FBI Investigates DHS Contractor for Failing to Protect Gov't Computer I learned of the Washington Post story Contractor Blamed in DHS Data Breaches:

The FBI is investigating a major information technology firm with a $1.7 billion Department of Homeland Security contract after it allegedly failed to detect cyber break-ins traced to a Chinese-language Web site and then tried to cover up its deficiencies, according to congressional investigators.

At the center of the probe is Unisys Corp., a company that in 2002 won a $1 billion deal to build, secure and manage the information technology networks for the Transportation Security Administration and DHS headquarters. In 2005, the company was awarded a $750 million follow-on contract.

On Friday, House Homeland Security Committee Chairman Bennie Thompson (D-Miss.) called on DHS Inspector General Richard Skinner to launch his own investigation.

As part of the contract, Unisys, based in Blue Bell, Pa., was to install network-intrusion detection devices on the unclassified computer systems for the TSA and DHS headquarters and monitor the networks. But according to evidence gathered by the House Homeland Security Committee, Unisys's failure to properly install and monitor the devices meant that DHS was not aware for at least three months of cyber-intrusions that began in June 2006.

Through October of that year, Thompson said, 150 DHS computers -- including one in the Office of Procurement Operations, which handles contract data -- were compromised by hackers, who sent an unknown quantity of information to a Chinese-language Web site that appeared to host hacking tools.

The contractor also allegedly falsely certified that the network had been protected to cover up its lax oversight, according to the committee.

"For the hundreds of millions of dollars that have been spent on building this system within Homeland, we should demand accountability by the contractor," Thompson said in an interview. "If, in fact, fraud can be proven, those individuals guilty of it should be prosecuted."

Wow. This is huge. I cannot remember any case like it. So what happened?

In the 2006 attacks on the DHS systems, hackers often took over computers late at night or early in the morning, "exfiltrating" or copying and sending out data over hours -- in one case more than five hours, according to evidence collected by the committee.

Five hours. That indicates one means of detecting this sort of activity: time-based analysis of session records.

In July 2006, a Unisys employee detected a possible intrusion but "downplayed it and low-level DHS security managers ignored it," the committee aide said.

It was not until Sept. 27, 2006, that two DHS systems managers noticed that their machines had been accessed with a hacking tool.

Unisys information technology employees began a probe and determined that the break-in affected more computers. They discovered that it reached back as far as June 13 that year and had continued through at least Oct. 1, eventually reaching 150 computers.

Among the security devices Unisys had been hired to install and monitor were seven "intrusion-detection systems," which flag suspicious or unauthorized computer network activity that may indicate a break-in. The devices were purchased in 2004, but by June 2006 only three had been installed -- and in such a way that they could not provide real-time alerts, according to the committee. The rest were gathering dust in DHS storage closets and under desks in their original packaging, the aide said. (emphasis added)

This explains a lot!

Let's finish with this thought:

A Unisys spokeswoman, Lisa Meyer... said that Unisys has provided DHS "with government-certified and accredited security programs and systems, which were in place throughout 2006 and remain so today."

Exactly. C&A has absolutely zero operational security value, as I wrote in FISMA 2006 Scores.

I commend the Congressional committee tracking this problem and I welcome future reporting. I would love to be the expert witness in any trial between the government and Unisys, but that is outside the scope of my current employment!

Read More

DHS Einstein Demonstrates Value of Session Data

If you're looking for case studies to show management to justify collecting session data, check out Einstein keeps an eye on agency networks. I've known about this program for several years but waited until a high-profile story like this to mention it in my blog. Basically:

Since 2004, Einstein has monitored participating agencies’ network gateways for traffic patterns that indicate the presence of computer worms or other unwanted traffic. By collecting traffic information summaries at agency gateways, Einstein gives US-CERT analysts and participating agencies a big-picture view of bad activity on federal networks.

US-CERT’s security analysts use Einstein data to correlate cross-agency security incidents. Participating agencies can go to a secure Web portal to view their own network gateway data.

Einstein doesn’t eliminate the need for intrusion-detection systems on agencies’ networks, said Mike Witt, deputy director of US-CERT. But the 24-hour monitoring program does give individual agencies a view of activity in other parts of the federal network infrastructure that could affect their own networks...

Ten agencies participate in Einstein, and four or five others have indicated they plan to join by the end of the year. Witt said DHS officials hope to have most Cabinet-level agencies in the program by the end of 2008. DHS will try to expand participation to more of the midsize and small federal agencies later, he said.

“Einstein is not mandatory, so we have to do a sales job with agencies,” Witt said. Witt wouldn’t name the agencies that have signed up. In a public presentation last year, however, a DHS official identified eight participants. They were DHS, DOT, the departments of State, Treasury and Education, the Federal Trade Commission, the Securities and Exchange Commission, and the U.S. Agency for International Development. The Justice Department has since joined the program.

This is just the sort of project I'd like to roll out at my new job, possibly combining Argus with ArgusEye, or maybe just Sguil without Snort. The idea is to be an internal security awareness provider for business units, offering them better insights into their network activity while using that data to monitor for attacks and respond to incidents more effectively.

After a pilot program to demonstrate the value of the approach, I would consider more robust options like an internally-developed product or a commercial option. I know of at least one large customer of mine who read my first book and built their own session and full content capture appliance for about $50,000, rated up to OC-48 for full content collection.

Note that Einstein is session data only, and from what I hear some people find its capabilities and data format lacking -- hence the desire to run something else, pairing session data with full content. Session data is very helpful but never sufficient for real investigations.

Read More

What Should the Feds Do

Recently I discussed Federal digital security in Initial Thoughts on Digital Security Hearing. Some might think it's easy for me to critique the Feds but difficult to propose solutions. I thought I would try offering a few ideas, should I be called to testify on proposed remedies.

For a long-term approach, I recommend the steps offered in Security Operations Fundamentals. Those are operational steps to be implemented on a site-by-site basis, and completing all of them across the Federal government would probably take a decade.

In the short term (over the next 12 months) I recommend the following. These ideas are based on the plan the Air Force implemented over fifteen years ago, partially documented in Network Security Monitoring History along with more recent initiatives.

1. Identify all Federal networks and points of connectivity to the Internet. This step should already be underway, along with the next one, as part of OMB IPv6 initiative. The Feds must recognize the scope and nature of the network they want to protect. This process must not be static. It must be dynamic and ongoing. Something like Lumeta should always be measuring the nature of the Federal network.


2. Identify all Federal computing resources. If you weren't laughing with step 1, you're probably laughing now. However, how can anyone pretend to protect Federal information if the systems that process that data are unknown? This step should also be underway as part of the IPv6 work. Like network discovery, device discovery must be dynamic and automated. At the very least passive discovery systems should be continuously taking inventory of Federal systems. To the extend active discovery can be permitted, those means should also be implemented. Please realize steps 1 and 2 are not the same as FISMA, which is static and only repeated every three years for known systems.


3. Project friendly forces. You can tell these steps are becoming progressively difficult and intrusive into agency operations. With this step, I recommend third party government agents, perhaps operated by OMB for unclassified networks and a combination of DoD and ODNI for classified networks, "patrol" friendly networks. Perhaps they operate independent systems on various Federal networks, conducting random reconnaissance and audit activities to discover malicious parties. The idea is to get someone else besides intruders and their victims into the fight at these sites, so an independent, neutral third party can begin to assess the state of enterprise security. The Air Force calls this friendly force projection, which is a common term but they are performing it now on AF networks.
   
   This step is important because it will unearth intrusions that agencies can't find or don't want to reveal. It is imperative that end users, administrators, and managers become separated from the decision on reporting incidents. Right now incident reporting resembles status reports in the Soviet Union. "Everything is fine, production is exceeding quotas, nothing to see here." The illusion is only shattered by whistleblowers, lawsuits, or reporters. Independent, ground-truth reporting will come from this step and from centralized monitoring (below).


4. Build a Federal Incident Response Team. FIRT is a lousy name for this group, but there should be a pool of supreme technical skill available to all Federal enterprises. Each agency should also have an IRT, but they should be able to call upon FIRT for advice, information sharing, and surge support.


5. Implement centralized monitoring at all agencies. All agencies should have a single centralized monitoring unit. Agents from step three should work with these network security monitoring services to improve situational awareness. Smaller agencies should pool resources as necessary. All network connectivity points identified in step 1 should be monitored.


6. Create the National Digital Security Board. As I wrote previously:
   
   The NDSB should investigate intrusions disclosed by companies as a result of existing legislation. Like the NTSB, the NDSB would probably need legislation to authorize these investigations.
   
   The NDSB should also investigate intrusions found by friendly force projection and centralized monitoring.

None of these steps are easy. However, there appears to be support for some of them. This is essentially the formula the Air Force adopted in 1992, with some of the steps (like friendly force projection) being adopted only recently. I appreciate any comments on these ideas. Please keep in mind these are 30 minutes worth of thoughts written while waiting for a plane.

Also -- if you read this blog at taosecurity.blogspot.com, you'll see a new theme. Blogger "upgraded" me last night, removing my old theme and customizations. I think most people use RSS anyway, so the change has no impact. I like the availability of archives on the right side now.

Update: I added step 6 above.

Read More

Initial Thoughts on Digital Security Hearing

Several news outlets are reporting on the hearing I mentioned in my post When FISMA Bites. There following excerpts appear in Lawmakers decry continued vulnerability of federal computers:

The network intrusions at State and Commerce follow years of documented failure to comply with the Federal Information Security Management Act (FISMA), which requires agencies to maintain a complete inventory of network devices and systems. Government and industry officials at the hearing acknowledged a disconnect between FISMA's intent and effecting improved network security.

"The current system that provides letter grades seems to have no connection to actual security," said Rep. Zoe Lofgren, D-Calif. (emphasis added)

WOW -- does Zoe Lofgren read my blog?

Some lawmakers are considering whether the Department of Homeland Security should be given primary responsibility for overseeing federal network security, but officials at DHS and elsewhere suggested that wouldn't be the best idea. Noting that DHS has not performed well on the annual FISMA report card and has not implemented all of the recommendations put forth for improved analysis and warning capabilities for attacks, Greg Wilshusen, director of information security issues at the Government Accountability Office, said it would be problematic from an organizational standpoint to put DHS in the position of compelling other agencies to comply.

I agree DHS is not in a position to defend the entire Federal government, but centralized network security is a good idea when skilled defenders are in short supply and high demand. It's clear that some agencies are not capable of defending themselves, while others do a better job. Perhaps a "center of excellence" model might work, where an agency with a very good monitoring team might watch the entire network. Another agency with a very good red team might assess the whole network, and so on.

Further news about the State intrusion appears in Response to May-July 2006 Cyber Intrusion on Department of State Computer Network and State Department got mail -- and hackers.

It's important to note that State was compromised by a zero-day, and a patch from Microsoft took eight weeks to be appear.

The article Intruders infect 33 US government computers with Trojans talks about a compromise an the Department of Commerce:

[T]he cyberintrusion affecting the Commerce Department's Bureau of Industry and Security systems was first noticed last July, when a Bureau of Industry and Security deputy under secretary reported being locked out of his computer. An investigation showed that the system had been compromised and someone had installed malicious code on it that was causing it to make unauthorised attempts to access another computer on the bureau's network...

Investigations also showed that the infected system had attempted to access two external IP address[es] after business hours when the computer was no longer being used...

Over the next 10 days or so, investigators at Bureau of Industry and Security noticed about 10 other computers making similar attempts to connect with suspicious IP addresses. By 18 August, 32 the bureau systems and one non-bureau system had tried to communicate with at least 11 suspicious IP addresses...

To date, an analysis of the forensic data has shown no evidence that information was actually stolen, despite the compromises, Jarrell said. At the same time, it remains unclear just when the first breach occurred or for how long intruders might have had access to the Bureau’s systems.

That's interesting. The initial incident is found through non-technical means ("Hey, my PC no workie!") but extrusion detection would have noticed the outbound connections. If BIS had been collecting session data they would have known when the first attempt to access those external IPs occurred, thereby helping to scope the incident.

Read More

When FISMA Bites

After reading State Department to face hearing on '06 security breach I realized when FISMA might actually matter: combine repeated poor FISMA scores (say three F's and one D+) with publicly reported security breaches, and now Congress is investigating the State Department:

In a letter sent to Secretary of State Condoleeza Rice on April 6, committee Chairman Bennie Thompson asked the department to provide specific information regarding how quickly department security specialists detected the attack, whether the department knows how long the attackers had access to the network and what other systems may have been compromised during the attack. The three-page letter also asks the department to provide evidence that it completely eliminated any malicious software the attackers may have planted, as well as documentation of all of the communications between State and the Department of Homeland Security regarding the incident.

I'm going to keep an eye on the Subcommittee on Emerging Threats, Cybersecurity, and Science and Technology to see what is published on these matters. It's ironic that FISMA scores really have nothing to do with State's problems, and no aspect of FISMA can answer any of the questions cited above.

Read More

Full Content

Thanks to this story I learned of the latest 2006 FISMA Report. If you want a summary of the findings, read the story. Here I'd like to highlight an amazing paragraph on page 14.

B. Incident Detection

Agencies must be able to quickly detect and respond to incidents. During the next year, OMB will work with federal agencies to increase the exchange of packet level (full content) information regarding incidents which have penetrated an agency’s perimeter. Sharing this data will enable more effective analysis of attacks targeting multiple Federal agencies, and may enable more timely responses to new threats. The sharing of intrusion data will also improve the knowledge base of analysts in Federal agencies. (emphasis added)

I have a feeling the person who wrote that part of the report has read Tao or another one of my works.

I am detecting a trend. People are starting to realize they cannot understand or even detect incidents without having facts to analyze. Most security products provide inferences in the form of alerts; the product makes a judgement on what it's seen. Alerts are helpful but never sufficient. Analysts are driven to investigate NSM data in the form of facts; amateurs are satisfied with managing inferences in the form of alerts.

Full content data is the best form of network-centric fact since it completely represents a conversation. Session data is another excellent form of network-centric fact, but it sacrifices some granularity. Statistical data is a third form of network-centric fact, but it is least helpful because so much detail has been lost.

In an attempt to head off a blizzard of complaints, note I say "network-centric." As I've said many times elsewhere, sometimes a single accurate log statement like "File X containing Y was transferred between hosts A and B at time C over an encrypted channel using protocol Z" is more helpful than a million packets. However, sometimes the only data you have is that which you can gather passively and independently. I call that self-reliant Network Security Monitoring.

Expect to hear more on this topic at my ShmooCon talk. (Why oh why did they schedule me against Joe Stewart? I really looked forward to seeing his talk. Argh.)

I am not alone in these thoughts. Please read this blog post by Tate Hansen. I'd reproduce the whole thing here since I like all of it.

Read More

Thoughts from IATF Meeting

I try to attend meetings of the Information Assurance Technical Forum once a year. I last visited in 2003 and 2005. The following are some thoughts from the meeting I attended two weeks ago. They are not an attempt to authoritatively summarize or describe years of net-centric thought and work by the US Department of Defense. These are just a few thoughts based on the presentations I saw in an unclassified environment.



Prior to seeing this diagram I had heard a lot about "net-centric warfare" but I had no real grasp of the underlying. It seemed more of a buzzword. Now I understand the idea of getting information from any source to the people who need it, instead of, say Air Force sensors sending data to Air Force decision-makers who feed Air Force assets.



Given the net-centric model, DoD needs to move away from a "System High" model of security to a "Transactional" model. In the System High world, you essentially define a perimeter by classification (e.g., "Secret"), build a network for that classification (e.g., SIPRNET), and let anyone with a Secret clearance see anything on SIPRNET. This is procedure-based security at its best (actually, it's worst).



This figure shows how DoD wants to transition from the existing model to the new model. It's moving away from the current "baseline" in "increments," starting with Increment 1. Completion of Increment 1 is expected with the conclusion of the next five-year DoD plan, lasting 2008-2013 (!).

DoD's experience with coalition warfare in Iraq and Afghanistan is driving these changes. One example involved the need to establish a separate network for every coalition partner. In one so-called "coalition village," DoD had to build 14 separate networks (US-UK, US-Poland, US-Italy, etc.). This is obviously costly and time-consuming. In the new model, these coalition partners will share one network but have access regulated by the transactional security model. Virtualization and Digital Rights Management are going to be key for implementing these ideas.



This figure explains the layers present in the Enterprise Sensor Grid, and the idea that DoD is moving away from a strictly perimeter-based monitoring model to one that reaches all the way to end hosts.

One of the briefers offered a set of metrics that I found interesting.

• % of Red Team simulated attacks that are successful


• % of remote access to DoD information systems and DoD access to the Internet regulated by positive technical controls such as proxy services and screened subnets
  (DMZs)


• % of DoD systems and applications that conform to the DoD Ports, Protocols, and Service Policy


• % of standardized and approved IA and IA enabled COTS products available to protect DoD sensitive and classified data (vs. GOTS)


• % of NIPRNet Traffic that is encrypted

I found the first metric to be especially interesting because the DoD uses it to measure the number of attacks they are missing. In other words, DoD (wisely) understands that it doesn't detect all attacks. They use Red Team exercises to estimate the number of attacks they don't detect. This is exactly the sort of metric I believe to be useful. DoD also measures (and wants to vastly decrease) the amount of time needed to detect and respond to intrusions. Again, they base their metrics on Red Team exercises.

I left the conference with a few concerns. First, I heard an emphasis on "pushing systems to DMZs." The idea is to remove systems accessible to the public or coalition partners out of internal networks and into DMZs. While I agree that security zones are important, I wondering if DoD is fighting the last war again. Server-side attacks were the predominant model of the 1990s, bleeding somewhat into this decade. For the last three or four years, however, client-side attacks have been all the rage. DoD is moving to persistent and then pervasive monitoring (which includes end hosts), but I hope they don't ignore client-side vulnerabilities. On the other hand, the rise of Web Services might reinvigorate DMZ-focused security.

After hearing one briefer joke about not understanding so-called "honey" technologies (honeypots, etc.) I worried that some of these decision-makers don't understand the attacks facing DoD networks. They of course understand the threat, because those groups change but not as quickly as the tools and techniques they employ. Keeping up with the vulnerabilities and ways to exploit them is extremely challenging, and does not map at all to five-year plans.

A second problem involves the so-called "black core." This is an encrypted network which will eventually dominant the DoD enterprise security model. This is similar to Microsoft's reported internal use of IPSec everywhere.

The black core emphasizes confidentiality, and to a certain degree integrity. It seems to sacrifice visibility. An IATF attendee made this point in a question. If just about everything is encrypted, what's the point of network-based monitoring? One of the speakers replied that flow-based monitoring (i.e., analyzing session data) will still be helpful, but sessions only take you so far. I wonder if DoD might implement some "visibility taps" that decrypt-inspect-encrypt at various points in the black core?

Speaking of encryption, crypto appeared to be a major factor in DoD plans. This isn't surprising, given the IATF's sponsor. Still, most security incidents don't happen because of failed crypto. Intrusions are often the result of improper configuration and operation. I didn't hear much about addressing those problems, yet I heard that DoD is cutting IA personnel and funding!

Third, IPv6 wasn't formally mentioned in any of the presentations. An attendee had to ask about it specifically. An audience member from the Office of the Secretary of Defense said IPv6 would work with DoD's plans, but I think the audience was skeptical.

Finally, DoD is relying heavily on vendors to build the equipment and technology needed to implement its vision. Ideas of "protecting data in transit" (PDIT) and "protecting data at rest" (PDAR) are great concepts, but implementation questions remain. DoD also seemed not interested in data stored outside of its own systems. An attendee questioned how DoD is going to handle that concern, but it appears to have been largely ignored. This is a growing issue as we approach the end of this decade, and I predict it will be a major issue in the next decade.

Incidentally, while driving to the IATF meeting I listened to a story on NPR about Boeing's plans for border security. One of the engineers in the story talked about the false positive problems caused by tumbleweed! Maybe I should consider investigating cross-discipline intrusion detection problems (i.e., digital, financial, homeland security, and so on)?

References

• Net-Centric Environment Joint Functional Concept (.pdf)


• IA Component of the GIG Version 1.1 (.ppt)


• Enterprise Sensor Grid (.ppt)

Read More

Comment on Draft NIST Publications

Thanks to SANS I read this FCW story about new NIST draft publications, specifically Draft Special Publication 800-94, Guide to Intrusion Detection and Prevention (IDP) Systems (.pdf). I am worried about this document because it seems to imply that detection and prevention are equivalent functions. Recent Dark Reading stories like IDS/IPS: Too Many Holes? and IPS Technology: Ready for Overhaul have been critical of both technologies, but especially IPS.

Despite some vendor claims to the contrary, customers realize that the same inspection logic used to "detect intrusions" is supposed to be applied to the "prevent intrusions" problem. Since so-called "intrusion prevention" products were sold as devices that overcame "false positive" problems, many customers are disappointed are end up running their "IPS" in detect only mode. From this perspective, it makes sense for NIST to lump IDS and IPS in the same category.

From an operational and consequences-based perspective, IDS and IPS are completely different. Management generally permits an IDS team with passive sensors to do just about anything it wants, shy of using RST tricks to deny traffic. Management does not take the same approach with IPS, since an IPS is just a smarter firewall. One bad IPS rule and business traffic is interrupted.

While on this subject, I consider it unfortunate that the terms IDS and IPS even exist. Neither describes the actual function of either device. IDS as used by the vast majority of people seldom "detects intrusions." Rather, the technology is an Attack Indication System.

IPS is even more poorly named. An IPS is just a layer 7 firewall, so I would just as soon call an IPS a smarter firewall.

Finally, I read this press release:

[McAfee] announced that it has been selected to be deployed as the standard network intrusion prevention solution for the U.S. Air Force. The Air Force will use McAfee® IntruShield Network Intrusion Prevention System (IPS) and McAfee IntruShield Security Manager appliances to provide comprehensive and proactive protection for its worldwide non-classified and classified networks. The task order was awarded by the Air Force's Combat Information Transport System (CITS) program office to prime contractor Booz Allen Hamilton under the U.S. Air Force NETCENTS contract.

I'm guessing this is the end of ASIM?

Read More

Another Sign C&A is Really Broken

I just read an exceptionally interesting post at the ClearNet Security Blog. It explains the Certification and Accreditation (C&A) process implemented by the US Department of Veteran's Affairs. Yes, those are the same guys who lost that laptop with my Air Force records. Consider this blog excerpt:

Right about this time the second bomb shell went off.... The guy up front promptly says that all test results we collect are to be given to the VA. This makes sense as it is their computers and they are entitled to our analyzed results right? Wrong! The guy corrects himself and says that the results are not to be analyzed by the auditors but by VA personnel. Hmm...so at this point I am not touching a computer nor am I analyzing the results for risk or what is wrong. Something seems very broken about this process at this point.

Please read the whole post for the entire story. I hope CNS continues to share their experiences.

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

GAO Hammers Common Criteria

I've written about Common Critera before. If you also think CC is a waste of money, read GAO: Common Criteria Is Not Common Enough by Michael Arnone. It summarizes and comments upon a report by the Government Accounting Office titled INFORMATION ASSURANCE: National Partnership Offers Benefits, but Faces Considerable Challenges. Mr. Arnone writes:

GAO also criticized the National Information Assurance Partnership (NIAP) for not providing metrics or evidence that the Common Criteria actually improves product security. In addition, the Common Criteria process takes so long to complete that agencies often find that the products they need are not on the list of certified offerings or that only older versions have been accredited, GAO’s report states...

Pescatore said GAO’s call for increased education and awareness of NIAP’s function is overblown. Large vendors already know the process well and can afford millions of dollars for tailor-made product evaluations, he said.

Any education efforts should target smaller vendors — with $10 million to $50 million a year in annual revenue — that don’t know about the NIAP process, don’t know how expensive it is and have trouble affording it, Pescatore said. NIAP must do more than educate, he added. It must provide subsidies or reduce prices so smaller vendors can participate, he said.

It sounds like Common Criteria is becoming nothing but a hurdle to keep smaller companies from providing products to government agencies.

Read More

Feds Hurry, Slow Down

In my post Opportunity Costs of Security Clearances I ranted about needing security clearances for assessment work. Now I read Security clearance delays still a problem by Florence Olsen:

"Security clearance delays are the same, if not worse, than a year ago, before lawmakers made changes designed to help clear the backlog...

[N]ewly enacted reciprocity rules have made no dent in a problem that is creating mounting costs for high-tech companies. Those rules permit agencies to accept clearances initiated by other agencies."

Wonderful. Not only do agencies not trust employees, they don't trust other government agenices. That is understandable, but pathetic; jobs are left vacant because .gov entities want to play petty games. It gets worse:

"ITAA officials said 27 member companies that responded to a survey are coping with the backlog by hiring cleared employees from one another, sometimes paying premiums of up to 25 percent."

Great. This means the same cadre of cleared people are being shuffled among agencies. New blood with potentially more enthusiasm, skill, and (gasp) lower salaries (which would appeal to any commercial endeavor) are left to watch this dance from the outside.

So how bad are the delays?

"21 companies, said they had encountered delays of 270 or more days in getting top-secret clearances for employees. Last year, when ITAA conducted a similar survey, 70 percent reported equally lengthy delays.

The longest waits occurred in seeking clearances for employees to work at the CIA and the Defense Department."

So, in places were skilled security practitioners are most needed, they are not available.

Those that are already in place must cram before 2005 FISMA scores arrive. In my NSA-IAM class last week, a State Dept. worker told us he had to work a disaster recovery scenario on Sunday 28 August in order to meet his 31 August deadline.

Companies that cannot properly manage their workforces go out of business. Governments just lumber along. There is no mechanism to correct deficiencies, aside from massive intelligence or defense failures like 9/11, the Iraq war, and so on. Sorry for the depressing post, but I don't see a light at the end of this tunnel!

Read More

Feds Adopt IPv6 by June 2008?

I read OMB: IPv6 by June 2008 today, which says:

"The federal government will transition to IP Version 6 (IPv6) by June 2008, said Karen Evans, the Office of Management and Budget’s administrator of e-government and information technology.

'Once the network backbones are ready, the applications and other elements will follow,' she said today while testifying before the House Government Reform Committee."

Riiight. Be prepared to see this slip to, oh, maybe never. The Federal government is also supposed to be securing its systems, and its report card is still lousy. Agencies have also known since Homeland Security Presidential Directive 12 (Aug 04) that they needed to implement smart cards, but problems are anticipated in meeting the deadlines.

Marcus Ranum pointed me towards a talk by Bill Cheswick (.ppt) on IPv6 transition realities. It mentions several problems that might prevent IPv6 adoption, like unreasonable demands on routers, hosts which can pick a new IPv6 address for every connection, and other issues.

Read More