Why DIARMF, "Continuous Monitoring," and other FISMA-isms Fail

I've posted about twenty FISMA stories over the years on this blog, but I haven't said anything for the last year and a half. After reading Goodbye DIACAP, Hello DIARMF by Len Marzigliano, however, I thought it time to reiterate why the newly "improved" FISMA is still a colossal failure.

First, a disclaimer: it's easy to be a cynic and a curmudgeon when the government and security are involved. However, I think it is important for me to discuss this subject because it represents an incredible divergence between security people. On one side of the divide we have "input-centric," "control-compliant," "we-can-prevent-the-threat" folks, and on the other side we have "output-centric," "field-assessed," "prevention eventually fails" folks. FISMA fans are the former and I am the latter.

So what's the problem with FISMA? In his article Len expertly discusses the new DoD Information Assurance Risk Management Framework (DIARMF) in comparison to the older DoD Information Assurance Certification and Accreditation Process (DIACAP). DIARMF is a result of the "new FISMA" emphasis on "continuous monitoring" which I've discussed before.

Len writes "DIARMF represents DoD adoption of the NIST Risk Management Framework process" and provides the diagram at left with the caption "The six major steps of Risk Management Framework aligned with the five phases of a System Development Lifecycle (SDLC)."

Does anything seem to be missing in that diagram? I immediately key on the "MONITOR Security Controls" box. As I reminded readers in Thoughts on New OMB FISMA Memo, control monitoring is not threat monitoring. The key to the "new" FISMA and "continuous monitoring" as seen in DIARMF is the following, described by Len:

Equally profound within DIARMF is the increased requirements for Continuous Monitoring activities. Each control (and control enhancement) will be attributed with a refresh rate (daily, weekly, monthly, yearly) and requisite updates on the status of each control will be packaged into a standardized XML format and uploaded into the CyberScope system where analysis, risk management, and correlation activities will be performed on the aggregate data.

Rather than checking on the security posture every three years or whatever insane interval that the old FISMA used, the new FISMA checks security posture more regularly, and centralizes posture reporting.

Wait, isn't that a good idea? Yes, it's a great idea -- but it's still control monitoring. I can't stress this enough; under the new system, a box can be totally owned but appear "green" on the FISMA dashboard because it's compliant with controls. Why? There is no emphasis on threat monitoring -- incident detection and response -- which is the only hope we have against any real adversary.

Think I'm wrong? Read Len's words on CyberScope:

CyberScope is akin to a giant federal-wide SEIM system, where high-level incident management teams can quickly pull queries or drill down into system details to add analysis on system defenses and vulnerabilities to the available intelligence on an attack. CyberScope data will also be used to track trends, make risk management decisions, and determine where help is needed to improve security posture.

If you're still not accepting the point, consider this football analogy.

Under the old system, you measured the height, weight, 40 yard dash, and other "combine" results on a player when he joined the team. You checked again three years later. You kept data on all your players but had no idea what the score of the game was.

Under the new system, you measure the height, weight, 40 yard dash, and other "combine" results on a player when he joins the team. You check again more regularly -- maybe even every hour, and store the data in a central location with a fancy Web UI. You keep data on all your players but still have no idea what the score of the game is.

Until DoD, NIST, and the other control-compliant cheerleaders figure out that this approach is a failure, the nation's computers will remain compromised.

Note: There are other problems with DIARMF -- read the section where Len says "This shakes out to easily over a hundred different possible control sets that can be attributed to systems" to see what I mean.

Tweet

Read More

Thoughts on New OMB FISMA Memo

I read the new OMB memorandum M-10-15, "FY 2010 Reporting Instructions for the Federal Information Security Management Act and Agency Privacy Management." This InformationWeek article pretty well summarizes the memo, but I'd like to share a few thoughts.

Long-time blog readers should know I've been writing about FISMA for five years, calling it a "joke," a "a jobs program for so-called security companies without the technical skills to operationally defend systems," and other kind words. Any departure from the previous implementation is a welcome change.

However, it's critical to remember that control monitoring is not threat monitoring. Let's take a look at the OMB letter to see if we can see what is really changing for FISMA implementation.

For FY 2010, FISMA reporting for agencies through CyberScope, due November 15, 2010, will follow a three-tiered approach:

1. Data feeds directly from security management tools
2. Government-wide benchmarking on security posture
3. Agency-specific interviews

I wonder how long before CyberScope is compromised?

Turning to the three points, what does #1 really mean?

Beginning January 1, 2011, agencies will be required to report on this new information monthly. The new data feeds will include summary information, not detailed information, in the following areas for CIOs:

• Inventory
• Systems and Services
• Hardware
• Software
• External Connections
• Security Training
• Identity Management and Access

So it looks like OMB is requiring agencies to basically report asset inventory information, training status for employees, and some IDM information? And monthly? I guess if you're moving from a three-year cycle to a monthly cycle, that sounds "continuous," but monthly in the modern enterprise is recognized as a snapshot.

How about #2?

A set of questions on the security posture of the agencies will also be asked in CyberScope. All agencies, except microagencies, will be required to respond to these questions in addition to the data feeds described above.

Now I see OMB will be asking agencies questions, which they will have to answer?

And #3:

As a follow-up to the questions described above, a team of government security specialists will interview all agencies individually on their respective security postures.

This looks like another question-and-answer session, except I expect OMB to spend time with the problem cases identified in steps 1 and 2.

Let's be clear: there's no "continuous monitoring" happening here. This is basic housekeeping, although the scale of the government and bureaucratic inertia make this a difficult problem. I hope this is only the first round of change.

I found the frequently asked questions to be more interesting than the main memo.

30. Why should agencies conduct continuous monitoring of their security controls?

Continuous monitoring of security controls is a cost-effective and important part of managing enterprise risk and maintaining an accurate understanding of the security risks confronting your agency’s information systems. Continuous monitoring of security controls is required as part of the security authorization process to ensure controls remain effective over time (e.g., after the initial security authorization or reauthorization of an information system) in the face of changing threats, missions, environments of operation, and technologies.

Ah ha, finally we see it in print: "continuous monitoring of security controls." There's no continuous monitoring of threats here. Furthermore, I'm wondering why OMB considers asset inventory, training, and IDM to be so crucial to security risks. Sure, they are important, but where's the real "security" in those controls? In other words, they could still observe controls, but those controls could be implementation of filtering Web proxies, firewalls, anti-malware, and other traditional security measures.

36. Must Government contractors abide by FISMA requirements?

Yes... Because FISMA applies to both information and information systems used by the agency, contractors, and other organizations and sources, it has somewhat broader applicability than prior security law. That is, agency information security programs apply to all organizations (sources) which possess or use Federal information – or which operate, use, or have access to Federal information systems (whether automated or manual) – on behalf of a Federal agency. Such other organizations may include contractors, grantees, State and local Governments, industry partners, providers of software subscription services, etc. FISMA, therefore, underscores longstanding OMB policy concerning sharing Government information and interconnecting systems.

This concerns me. Is the government further pushing on contractors to adopt FISMA in private business?

FISMA is unambiguous regarding the extent to which security authorizations and annual IT security assessments apply. To the extent that contractor, state, or grantee systems process, store, or house Federal Government information (for which the agency continues to be responsible for maintaining control), their security controls must be assessed against the same NIST criteria and standards as if they were a Government-owned or -operated system. The security authorization boundary for these systems must be carefully mapped to ensure that Federal information:

(a) is adequately protected,

(b) is segregated from the contractor, state or grantee corporate infrastructure, and

(c) there is an interconnection security agreement in place to address connections from the contractor, state or grantee system containing the agency information to systems external to the security authorization boundary.

It's probably going to take .gov-savvy lawyer to really explain what these points mean, but private enterprise working with government data should probably take a close look at these new FISMA developments.

Read More

Consensus Audit Guidelines Are Still Controls

Blog readers know that I think FISMA Is a Joke, FISMA Is a Jobs Program, and if you fought FISMA Dogfights you would always die in a burning pile of aerial debris.

Now we have the Consensus Audit Guidelines (CAG) published by SANS. You can ask two questions: 1) is this what we need? and 2) is it at least a step in the right direction?

Answering the first question is easy. You can look at the graphic I posted to see that CAG is largely another set of controls. In other words, this is more control-compliant "security," not field-assessed security. Wait, you might ask, doesn't the CAG say this?

What makes this document effective is that it reflects knowledge of actual attacks and defines controls that would have stopped those attacks from being successful. To construct the document, we have called upon the people who have first-hand knowledge about how the attacks are being carried out.

That excerpt means that CAG defines defensive activities that are believed to be effective by various security practitioners. I am not doubting that these practitioners are smart. I am not doubting their skills. What I am trying to say is that implementing the controls in CAG does not tell you the score of the game. CAG is all about inputs. After implementing CAG you still do not know any outputs. In other words, you apply controls (an "X"), but what is the outcome (the "Y"). The controls may or may not be wonderful, but if you are control-compliant you do not have the information produced by field-assessed security.

Does anyone real think we do not have controls already? The CAG itself shows how it maps against NIST SP 800-53 Rev 3 Controls. Five are shown below as an example.



For example, looking at CAG, how many of these strike you as something you didn't already know about?

Critical Controls Subject to Automated Measurement and Validation:

1. Inventory of Authorized and Unauthorized Hardware.


2. Inventory of Authorized and Unauthorized Software.


3. Secure Configurations for Hardware and Software on Laptops, Workstations, and Servers.


4. Secure Configurations of Network Devices Such as Firewalls and Routers.


5. Boundary Defense


6. Maintenance and Analysis of Complete Security Audit Logs


7. Application Software Security


8. Controlled Use of Administrative Privileges


9. Controlled Access Based On Need to Know


10. Continuous Vulnerability Testing and Remediation


11. Dormant Account Monitoring and Control


12. Anti-Malware Defenses


13. Limitation and Control of Ports, Protocols and Services


14. Wireless Device Control


15. Data Leakage Protection

Additional Critical Controls (not directly supported by automated measurement and validation):

1. Secure Network Engineering


2. Red Team Exercises


3. Incident Response Capability


4. Data Recovery Capability


5. Security Skills Assessment and Training to Fill Gaps

Don't get me wrong. If you are not implementing these controls already, you should do so. That will still not tell you the score of the game. If you want to see exactly what I proposed, I differentiated between control-compliance "security" and field-assessed security in my post Controls Are Not the Solution to Our Problem.

So, to answer my second question, CAG is a step in the right direction away from FISMA. It doesn't change the game, especially if you are already implementing NIST guidance.

---

Richard Bejtlich is teaching new classes in Europe in 2009. Register by 1 Mar for the best rates.

Read More

FCW on Comprehensive National Cybersecurity Initiative

Brian Robinson's FCW article Unlocking the national cybersecurity initiative caught my attention. I found these excerpts interesting, although my late 2007 article Feds Plan to Reduce, Then Monitor discussed the same issues.

The cybersecurity initiative launched by the Bush administration earlier this year remains largely cloaked in secrecy, but it’s already clear that it could have a major and far-reaching effect on government IT operations in the future.

Everything from mandated security measures and standard desktop configurations across government to a recast Federal Information Security Management Act (FISMA) could influence the way agencies buy and manage their IT.

Overseeing all of this will be a central office run by the Homeland Security Department, the first time that the government’s efforts in cybersecurity will run through a single office tasked with coordinating the work of separate federal cybersecurity organizations...

[First was the] creation of a National Cybersecurity Center (NCSC), which will serve as the focus for improving federal government network defenses. Rod Beckstrom [mentioned here], a well-known technology entrepreneur, was appointed the center’s director in March...

[Second,] Trusted Internet Connections (TIC)... this program is designed to reduce the number of external connections that agencies have to the Internet to just a few centralized gateways that can be better monitored for security. In January, more than 4,300 agency Internet connections existed, and those had been cut to some 2,700 by June. The target is less than 100 connections.

[Third,] Einstein is a system that automatically monitors data traffic on government networks for potential threats. As a program under the CNCI, Einstein will be upgraded ["Einstein II"] to include intrusion-detection technology. [I thought that was dead!]

Also, participation in Einstein for those agencies managing Internet access points will no longer be voluntary, as it was before. If Einstein finds a connection is not being properly managed, DHS will be able to shut it down.

[Finally, the] Federal Desktop Core Configuration (FDCC)... initiated by OMB last year, mandates that agencies adopt a common [desktop]...

As part of the CNCI, NIST proposed in February to extend the FDCC to other operating systems, applications and network devices beyond the existing support for Windows XP and Vista. (emphasis and comments added)

I loved this part:

The expansion of Einstein, for example, is a major change because it mandates the use of network security monitoring tools that are controlled by an entity outside the agencies.

“Before, they would do this [monitoring] themselves and not necessarily be forthcoming if anything happened,” he said. “Now it’s out of their hands.”

Now, my sources tell me that Einstein is basically garbage, and that the data from it (purely flows) is fairly useless unless it is used to identify traffic to or from know bad IP addresses. That's still worthwhile in my opinion, but it demonstrates why real NSM needs all four forms of data (alert, statistical, session, and full content) to have a chance at winning. What is more significant than simply deploying Einstein capabilities would be getting "hardware footholds" at each gateway.

If each TIC gateway is only forwarding flow data via router NetFlow exports, that's nice but insufficient. If each TIC gateway is tapped and connected to a stand-alone, preferably open source platform, then the game changes. Once a centralized monitoring agency can deploy its own tools and utilize its own tactics and techniques on a platform it controls, you will see real improvements in network-based enterprise visibility and situational awareness. That's what you get when you can implement what I've called self-reliant NSM, and the final story excerpt alluded to that idea as well.

Of course, it is important to implement these programs as openly as possible, with plenty of oversight and defined goals and governance. That is my biggest problem with the secrecy around CNCI. Overclassification breeds paranoia and ultimately reduces security by underminding the faith of the citizenry in our government.

Read More

FISMA 2007 Scores

The great annual exercise of control-compliant security, the US Federal government 2007 FISMA report card, has been published. Since I've been reporting on this farce since 2003, I don't see a reason to stop doing so now.

If you're the sort of sports fan who judges the success of your American football team by the height of the players, their 40-yard dash time, their undergraduate school, and other input metrics, you'll love this report card. If you've got any shred of sanity you'll realize only the scoreboard matters, but unfortunately we don't have a report card on that.

Thanks to Brian Krebs for blogging this news item.

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

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

CIO Magazine on IP Theft

CIO magazine, which features an impossible-to-navigate Web site but decent print version, published Hacked: The Rising Threat of Intellectual Property Theft and What You Can Do About It by Stephanie Overby. I liked these excerpts:

“There’s a ceiling on how much money can be made by stealing identities,” says Scott Borg, director and chief economist of the U.S. Cyber Consequences Unit, an independent nonprofit institute set up at the request of the federal government to examine the economic and strategic consequences of cyberattacks. “You can actually steal the business—its processes, its internal negotiating memos, its merchandising plans, all the information it uses to create value. That’s a very large payoff.”

I agree, but what's up with the USCCU Web site? I had to find an archive from February 2006 to see what this group does. Spend a little of that DHS money on a Web site, folks.

CIOs may be less aware of the threat to IP than to their systems, and therefore less prepared to protect the former. “Companies are thinking about worms and viruses, things that will not have very bad consequences and have always been wildly exaggerated,” says Borg. “Or they’re thinking about ID theft, which attracts a lot of attention, even though the number of cases is remarkably low.”

There’s a difference, too, in the systems an intruder looking for corporate secrets may target. IP thieves “won’t necessarily look at obvious financially sensitive areas,” says Borg, thereby escaping detection. “They may be looking at technical data, controls systems, automation software.” And the results of IP theft can be hard to see—a slow degradation of one’s competitive position in the market may easily be attributed to other, noncriminal factors.

Until recently, the most conclusive public evidence that sustained industrial espionage has taken place in cyberspace has come from the military. Titan Rain was “the most systematic and high-quality attack we have seen,” says Ira Winkler, author of, most recently, Zen and the Art of Information Security. Chinese hackers successfully breached hundreds of unclassified networks within the Department of Defense, its contractors and several other federal agencies. One Air Force general admitted at an IT conference last year that China had downloaded 10 to 20 terabytes of data from DoD networks. (emphasis added)

Forget about "slow degradation." In some future war over the Taiwan Straight an American jet fighter is going to dogfight a Chinese plane and lose the battle because some sensitive design or technical data was stolen. This is a constant in warfare as I mentioned in my post FISMA Dogfights.

To defend against targeted attacks, Motorola uses traditional controls such as firewalls, intrusion detection tools, antivirus software and digital forensics—but with a difference. “We’re operating our information security toolkit with a counterintelligence mind-set,” says Boni [Motorola CIO]. Like the military, Boni assumes there’s an enemy looking for an advantage and it’s his job to outwit him. “Putting those tools together with an understanding of what is or could be of greatest interest to competitors allows a more granular focus on the data,” says Boni, “not just on the network.”

Bingo. CI is exactly right.

“The thought process is no longer making sure nothing bad ever happens,” says DuBois [general manager of information security and infrastructure services security for Microsoft]. “There may be a bug in the Cisco code or someone might misconfigure a device. If [attackers] get at that chess piece we left unprotected, what will we do?”...

“If eternal vigilance is the price of freedom,” says Boni, paraphrasing Thomas Jefferson, “continuous monitoring and preparation to respond quickly is the cost associated with global digital commerce.” (emphasis added)

Again, exactly right. Prevention Eventually Fails. Detection. Response. Hopefully more CIOs will pay attention.

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

FISMA Dogfights

My favorite show on The History Channel is Dogfights. Although I wore the US Air Force uniform for 11 years I was not a pilot. I did get "incentive" rides in T-37, F-16D, and F-15E jets as a USAFA cadet. Those experiences made me appreciate the rigor of being a fighter pilot. After watching Dogfights and learning from pilots who fought MiGs over North Vietnam, one on six, I have a new appreciation for their line of work.

All that matters in a dogfight is winning, which means shooting down your opponent or making him exit the fight. A draw happens when both adversaries decide to fight another day. If you lose a dogfight you die or end up as a prisoner of war. If you're lucky you survive ejection and somehow escape capture.

Winning a dogfight is not all about pilot skill vs pilot skill. Many of the dogfights I watched involved American pilots who learned enemy tactics and intentions from earlier combat. Some of the pilots also knew the capabilities of enemy aircraft, like the fact that the MiG 17 was inferior to the F-8 in turns below 450 MPH. Intelligence on enemy aircraft was derived by acquiring planes and flying them. In some cases the enemy reverse engineered American weapons, as happened with the K-13/AA-2 Atoll -- a copy of the Sidewinder.

All of this relates to FISMA. Imagine if FISMA was the operational theme guiding air combat. Consultants would spend a lot of time and money documenting American aircraft capabilities and equipment. We'd have a count of every rivet on every plane, annotated with someone's idea that fifty rivets per leading edge is better than forty rivets per leading edge. Every plane, every spare part, and every pilot would be nicely documented after a four to six month effort costing millions of dollars. Every year a report card would provide grades on fighter squadrons FISMA reports.

What would happen to these planes when they entered combat? The FISMA crowd would not care. American aircraft could be dropping from the sky and it would not matter to FISMA. All of the FISMA effort creates a theoretical, paper-based dream of how a "system" should perform in an environment. When that system -- say, a jet fighter -- operates under real life combat conditions, it may perform nothing like what the planners envisioned. Planners range from generals setting requirements for a new plane, engineers desiging the plane, and tacticians imagining how to use the plane in combat.

Perhaps the guns jam in high-G turns. Perhaps the missiles never acquire lock and always miss their targets. Maybe the enemy has stolen plans for the aircraft (or an actual aircraft!) and know that the jet cannot perform as well as the enemy plane doing vertical rolling scissors.

Furthermore, the enemy may not act like the planners imagined. This is absolutely crucial. The enemy may have different equipment or tactics, completely overpowering friendly capabilities.

Maybe FISMA would address these issues in three years, the next time a FISMA report is due. Meanwhile, the US has losts all its pilots and aircraft, along with control of its airspace.

Maybe this analogy will help explain the problems I have with FISMA. I already tried an American football analogy in my post Control-compliant vs Field-Assessed Security. My bottom line is that FISMA involves control compliance. That is a prerequisite for security, since no one should field a system known to be full of holes. However, effective, operational security involves field assessment. That means evaluating how a system performs in the real world, not in the mind of a consultant. Field-assessed security is absolutely missing in FISMA. Don't tell me the tests done prior to C&A count. They're static, controlled, and do not reflect the changing environment found on real networks attacked by real intruders.

Incidentally, I also really liked the BBC series Battlefield Britain and I may check out the other History Channel series Shootout!.

Read More

FISMA 2006 Scores

There are FISMA scores for 2006, along with 2005, 2004, and 2003 -- some of which I discussed previously. What I wrote earlier still stands:

Notice that these grades do not reflect the effectiveness of any of these security measurements. An agency could be completely 0wn3d (compromised in manager-speak) and it could still receive high scores. I imagine it is difficult to grade effectiveness until a common set of security metrics is developed, including ways to count and assess incidents.

I still believe FISMA is a joke and a jobs program for so-called security companies without the technical skills to operationally defend systems.

The only benefit I've seen from FISMA is that low-scoring agencies are being embarrassed into doing more certification and accreditation. C&A is a waste of time and money. However, if security staff can redirect some of that time and money into technical security work that really makes a difference, then FISMA is indirectly helping agencies with poor scores. Agencies with high scores are no more secure than agencies with low scores. High-scoring agencies just write good reports, because FISMA is a giant paperwork exercise that makes no difference on the security playing field.

If you believe otherwise you're welcome to your opinion. You're also welcome to the lack of a future job when the FISMA consulting boondoggle ends and report jockeys are left without any marketable technical skills. If you want to know more about this, reading my old FISMA posts is sufficient. I don't need to restate my arguments when they're archived.

If I sound bitter, it's because I've seen my taxpaying dollars wasted for the past five years while various unauthorized parties have their way with these agencies. FISMA is not working.

Read More

SANS Software Security Institute

Today I attended a free three-plus-hour seminar offered by the new SANS Software Security Institute. This is part of SANS dedicated to software security. I recommend reading their press release (.pdf) for the full scoop, but basically SANS is introducing a Secure Programming Skills Assessement, additional training (eventually), and a certification path. Other people will summarize the program, so I'd like to share a few thoughts from the speakers at today's event.

• Michael Sutton from SPI Dynamics said that the idea of assembling a team of security people to address enterprise vulnerabilities worked (more or less) for network and infrastructure security because the team could (more or less) introduce elements or alter the environment sufficiently to improve their security posture. The same approach is not working and will not work for application security because addressing the problem requires altering code. Because code is owned by developers, the security team can't directly change it. This is an important point for those who think they can just turn their CSIRT loose on the software security problem in the same way they attacked network security.
  
  Michael also said no security is trustworthy until trusted. (He actually said "trusted." There's a difference. Anyone can "trust" software. The question is whether it is worthy of trust, i.e., "trustworthy.")


• Alan Paller made a few comments. He said we have 1.5 million programmers in the world, so training all of them probably isn't an option. He said SANS is working with Tipping Point to create a "Programmer's @Risk" newsletter like the existing vulnerabilities @Risk newsletter. Alan repeated a recommendation made my John Pescatore that organizations should run security tests against bids as well as upon acceptance.
  
  Alan noted that software testing should be considered a part of a "building permit" (pre-development) and a second "occupancy permit" (deployment in the enterprise). Alan also said PCI is the only worthwhile security standard. Others just require writing about security, while PCI requires a modicum of doing security. (Mark Curphey disagrees!)


• Jim Routh of DTCC said it's important for developers to recognize that security flaws are software defects, and not the security team's problem! His team of 450 inhouse developers uses three stages of testing: 1) white box for developers; 2) black box for integrators; and 3) third party for deployment.


• Mike Willburn from the FBI said FISMA C&A results in "well-documented" systems that score well on report cards but are "full of holes." Bravo.


• Andrew Wing from Teranet said he doesn't let an inhouse project progress to user acceptance training unless it scores a certain rank using an automated software security assessment tool.


• Jack Danahy from Ounce Labs stressed the importance of contract language for procuring. The OWASP Legal Project also offers sample language. Alan stressed the need to build security into contracts, rather than relying on the vague concept of "negligence" when security isn't explicitly included in a contract.


• Michael Weider from Watchfire said he fears user-supplied content will be the next exploitation vector. I shuddered at the horror of MySpace and the like.


• Steve Christey mentioned SAMATE (Software Assurance Metrics And Tool Evaluation).

That's what I can document given the time I have. Thanks to SANS for their leadership in this endeavor.

Read More

Reviews of FISMA and Wireshark Posted

Yes, you are reading that title correctly. After four months of inactivity I managed to read and review two new books. The first is FISMA by Laura Taylor. From my four star review:

I am no fan of the FISMA law. I've posted several stories on my blog explaining why I think FISMA is a waste of taxpayer money. Laura Taylor's FISMA Certification and Accreditation Handbook, however, is a good book if you are unfortunate enough to be tasked with performing FISMA work.

The second is Wireshark & Ethereal Network Protocol Analyzer Toolkit by Angela Orebaugh. From my four star review:

Despite the new title, Wireshark & Ethereal Protocol Analyzer Toolkit (WEPAT) is a second edition of Ethereal Packet Sniffing (EPS). I reviewed that book almost three years ago, in May 2004. WEPAT has replaced all of the earlier screen captures with Wireshark replacements. Unfortunately, WEPAT is largely a repeat of EPS, really only featuring a new wireless chapter. If you own EPS, you don't need to upgrade. If you don't own EPS but want to learn how to use Wireshark, I recommend buying WEPAT.

I'm still reading and plan to continue posting reviews going forward.

Read More

FISMA Redux

Late last year I mentioned I planned to read and review FISMA Certification & Accreditation Handbook by Laura Taylor. You know if I read a book on Cisco MARS on one leg of my last trip, I probably read a different book on the return leg. FISMA was that book. These comments are going to apply most directly to FISMA itself, based on what I learned reading Ms. Taylor's book. I'll save comments on the book itself for a later date.

Last year I wrote FISMA is a joke.. I was wrong, and I've decided to revise my opinion. Based on my understanding of FISMA as presented in this book,

FISMA is a jobs program for so-called security companies without the technical skills to operationally defend systems. This doesn't mean that if you happen to conduct FISMA work, you're definitelTy without technical skills. I guarantee my friends at ClearNet Security are solid guys, just based on their ability to detect the C&A project they joined was worthless. Anyway, I guess it's time to put on a flame-retardant suit.

Let's start with p xxiii in FISMA to understand the thought process of those who believe in it. Foreword author Sunil James, "Former Staff Director of the FDIC," writes that the FISMA "process has been proven to reduce risk to federal information systems." I think he means that FISMA reduces the risk of unemployment for those who perform C&A on federal information systems.

Without saying anything else, I think I know the problem with the FISMA-supporting crowd. I bet they do not do any other work, especially not technical work and certainly not incident response work for the agencies they "certify" and "accredit." If they did have operational security responsibilities for their C&A clients they'd wonder "why are these systems repeatedly being 0wned if their C&A packages are up-to-date?" Those that keep one foot in the C&A world and another in the operational world realize their FISMA feet are wet and smelly and not doing anyone any good, period.

Another sad truth about FISMA, despite Mr. Porter's unsubstantiated claim, is that there is zero connection between high FISMA scores and lower impact or number of intrusions. If you don't believe me, keep your eyes open for the next FISMA report card from the House Committee on Oversight and Government Reform. A look at the 2006 scores is interesting. Figure out who has good scores, and then see how they fared in this staff report on Federal breaches since January 2003. Hint: everyone's been 0wned, is 0wned, and will continue to be 0wned while money is spent paying consultants to write FISMA C&A packages.

Let's see what this FISMA book has to say about C&A packages. Page 34 claims a good ISSO can maintain C&A packages for 6 systems, and that writing each package can take 3-6 months. They need to be updated every 3 years. The C&A handbook guiding the writing of packages is usally 200+ pages and needs to be kept current. The packages themselves are usually 500+ (!) pages, and require 2-4 weeks to be read by the accreditors.

On p 34 we come to a root of the problem:

Since once C&A package could easily take a year for a well-versed security expert to prepare, it is considered standard and acceptable for ISSOs to hire consultants from outside the agency to prepare the Certification Package.

Page 38 continues:

Since C&A, if done properly, is usually a much bigger job than most people realize, I cannot emphasize enough the value in using outside consultants. Putting together a Certification Package is a full-time job.

I do not have a problem with consultants. Heck, I am a consultant. However, the vast majority of my work does not revolve around writing 500 page reports based on self-assessments every three years.

Laura Taylor writes on pp 8-9:

C&A is essentially a documentation and paperwork nightmare... prepare yourself to write, write, and write some more. If you detest writing, you're in the wrong business.

Basically, preparing a Certification Package is writing about security -- extensive writing about security. When you are preparing a Certification Package, you usually don't perform any sort of hands-on security. You review the existing security design and architecture documents, interview various IT support and development folks familiar with the infrastructure, and document your findings. (emphasis added)

I am not making this up. The really sad part is this: the author then says

...why C&A exists -- it is a process that enables authorizing officials to discover the security truths about their infrastructure so that informed decisions can be made.

Security truths? What are they based on?

In chapter 8 we read about "security self-assessments." Maybe those are helpful? Hmm, probably not: "A security self-assessment is a survey-based audit that is essentially a long list of questions." What's worse, page 115 says:

[I]n September 2003 a report put out by the Office of Inspector General at the Environmental Protection Agency found that 36 percent of the responses to security self-assessments contained inaccurate information.

Ms. Taylor's recommendation?

Tip: Encourage self-assessment respondents to answer questions truthfully.

Maybe some other aspect of C&A and FISMA shows merit. Chapter 12, discussing Security Tests and Evaluation (ST&E), begins with this:

A Security Test & Evaluation, known among security experts as an ST&E, is a document that demonstrates that an agency has performed due diligence in testing security requirements and evaluation the outcome of the tests.

The ST&E is a C&A document that tends to give agencies lots of trouble. It's not clear to many agencies what tests they should be doing, who should be doing them, and what the analysis of the tests should consist of.

That's another winner in my book.

FISMA fans out there are going to cite the vulnerability scans which are usually part of ST&E as a sign that something technical happens during C&A. Believe me, I am sparing the author of this book and her "technical editors" by not reproducing their recommendations for assessments. (One word: Strobe.)

We could also look at the Privacy Impact Assessment, but guess what -- it's another self-survey.

The bottom line is that FISMA doesn't mention C&A at all, but the author thinks that's ok because C&A fulfill's FISMA's goals. The reality is far different. According to the act itself, the first "purpose" is to:

provide a comprehensive framework for ensuring the effectiveness of information security controls over information resources that support Federal operations and assets. (emphasis added)

FISMA is failing miserably. It's ironic that this FISMA book begins each chapter with a quote, and this begins chapter 2:

It is common sense to take a method and try it. If it fails, admit it frankly and try another. But above all, try something. -- FDR

It's time for the FISMA fans to admit this five year FISMA experiment has been a waste of taxpayer money and agency resources.

Returning to my football analogy, C&A is an expensive, extensive practice session controlled by the players and overseen by agents who get paid the longer the team is on the field. Success is measured not by the score of the next game but by the number of worthless statistics written about the players prior to the first snap. Once the team takes to the field they are annihilated by the opposition, but the agents don't care because they're spending their money elsewhere.

If you are a C&A Package-writing company, I strongly recommend you gain some operational capabilities or look for a new line of business. I am committed to eliminating your position in the Federal government. Laura Taylor writes with some apparent regret that "most private and public companies don't put nearly as much time, effort, and resources into documenting their security as government agencies do." Let's keep it that way. At least it frees up resources for work that has a chance of stopping an intruder.

Do I have anything "nice" to say? Yes -- if you are so cursed as to be responsible for a FISMA C&A project, I do recommend reading this book. Forget the technical aspects and concentrate on understanding the FISMA maze. I thought Laura Taylor wrote a clear and well-organized book with lots of practical advice and good templates. I would much rather see her not have to write about this subject again, though!

Read More

Thoughts on Latest SANS Whitepaper

I read about the new SANS paper IT Security Industry Changes: Trouble on the Horizon (September 2006) (.pdf) in this NewsBites issue. Here are some excerpts and my reactions.

Over the past six months, SANS Technology Institute's Stephen Northcutt has been gathering data and stories from security managers in more than 100 US organizations searching for patterns in job changes of security managers and the consultants who support them. The research was triggered by multiple emails from security managers who were facing reorganizations. His conclusions, albeit preliminary, paint a worrisome picture of job prospects for ill-equipped security managers, but also offer promise of some opportunities for success and advancement.

That's an interesting project. Let's read more.

[S]enior executives began to feel more comfortable voicing their frustration that they were wasting money paying for hugely expensive people and compliance reports that probably were not needed and that often had no impact on their ability to stop attacks or avoid disclosure of private information. The senior executives pushed back on budget requests, asking exactly what they would get in decreased risk from each of the expenditures. When they got answers they didn't like, they looked for ways to reorganize. Numerous security managers were pushed out as their responsibilities were moved to IT operations or audit or risk management groups.

Stephen continues by implying that these fired security managers lacked real technical skills and could not do much more than write reports. However...

Government is the one area where soft security skills, like policy and report writing, are still in demand, both in security staff and in consultants. The US Congress and the White House passed and implemented legislation (the Federal Information Security Management Act) that rates federal agencies less on whether their systems are protected from attack and more on whether agencies have written security evaluation reports for every system. Consulting firms have gotten rich writing those reports. One CEO reported that his firm had grown from three people doing security evaluations to 175 people writing FISMA reports, in just five years.

Does that make any else sick? It makes me ill.

Recent public disclosure of huge security failings, however, have caused government officials to review FISMA, particularly how it is implemented. Change seems to be in the air. That same CEO reported that 75% of his 175 FISMA folk today have soft skills and only 25% have solid technical security skills. He sees the need for that mix of skills to be reversed, within the next year or so, or the business "will dry up."

That is awesome. It probably explains why TaoSecurity continues to receive calls from firms inside-the-Beltway (and beyond) wishing to "team" to provide technical services to .gov clients, instead of just certification and accreditation.

Read More

Soft Skills: The End is Nigh

I read the following in the latest SANS NewsBites:

The lead story contains an important notification by Major General Lord of broad-based US federal IT security failure. As senior officials discover how bad federal security really is, they have begun looking for solutions (some are also looking for scapegoats.)

The first and most important change they will make is to begin cutting budgets for policy and report writers, and transfer budget and responsibility to operational technical security projects and professionals who can actually protect their systems. The transformation has already begun.

If you have soft skills (policy writing, security awareness, risk assessment, C&A report writing, etc.) and want to have great, long-term job prospects in security, it makes sense to move quickly to add hands-on technical skills so you can lead the teams of people who will be needed to turn the tide against the attackers.

The "lead story" refers to this post.

Alan Paller continues in the newsletter:

Major General Lord is simply saying out loud what White House and DoD officials have known for almost three years; that's how long the hacking and data thefts are known to have been going on. What he did not say was that the same techniques (and attackers) have proven successful in penetrating DoD contractors such as Lockheed Martin and Raytheon, and penetrating many other government agencies including some you would not expect the Chinese military to care about.

The failure of federal agencies and contractors to protect sensitive information was instigated by misallocation of resources caused by OMB and Congressional metrics measuring the wrong things. It is time to revitalize FISMA and the C&A process.

If Government Reform Chairman Davis doesn't feel the problem is worth his time, he might consider transferring responsibility for FISMA and federal security to the House Homeland Security Committee where Chairman King's targeted subcommittee chairs have fostered real progress in improving security of critical infrastructure control systems.

I wonder how much of the "soft skills" comment is wishful thinking and how much is based on actual events.

If we're truly realizing that "hard skills" are needed for real defense, then maybe my prediction from January is materializing:

Is this [MBAs instead of techs] why companies continue to be compromised? Are the MBAs running around wondering why their self-defending networks are failing? I guarantee we will see a "back-to-basics" movement in the next few years, where "hands-on" tech skills will be emphasized again.

Here's hoping.

Read More

Notes from Last ISSA-NoVA Meeting

I realized I never published my notes from the July ISSA-NoVA meeting. This was another managerial-type talk, by James Golden, Manager of IT Governance at the USPS. The USPS is huge -- 153,000 desktops, 22,000 servers, 18,000 laptops, 7,000 offices, 175,000 internal email users, and 2,000 external users. Their Web site gets over one million visitors per day.

Mr. Golden said security is like Y2K -- "If everything fails, critics say you spent too little money. If everything works, critics say you spent too much money." He defined "IT governance" as "doing the right things right." I had never heard of IT governance, let alone the IT Governance Institute. He said the USPS is not covered by FISMA -- "Thank goodness!" -- and that SOX is "the biggest waste of money we spend in IT." By now you could imagine me liking Mr. Golden's style.

Since this was an ISSA meeting, Mr. Golden did discuss aligning COBIT, ITIL, and ISO 17799. Thanks to the APWU you can find the AS-805 series of manuals the USPS uses for information security.

My ears perked up when Mr. Golden discussed metrics. He said "metrics seek to change behavior," and asked "are you getting the behavior you wanted from your metrics?" and "why is performance changing?" I was amazed by the details counts he had for the following:

• Number of XP workstations with non-standard service packs


• Number of workstations with latest anti-virus signatures


• Number of power users or administrators


• Days of backups missed


• Number of workstations with ISS RealSecure Desktop (RSDP)


• Number of CIRT incidents

That last item drew my attention. I asked how the USPS handles incident reporting, and I got an answer similar to that of Dennis Heretick from DoJ -- USPS wants users to report security incidents. Therefore, USPS doesn't track meaningful metrics like those in my previous post -- days since last compromise of type X, system-days compromised, pen-test time, etc.

Again, this is terrible. Somehow we, the security community, must overcome the idea that the number of security incidents is outside the control of the enterprise. I know many of you are screaming at me now, but this is true whether you like it or not. While you cannot have absolute control of your security destiny, you can certainly influence it.

Consider this scenario. What happens to the police chief of a city where crime is out of control? Barring corruption, ignorance, laziness, bureaucratic inertia, and a dozen other problems, the mayor will fire the police chief. What happens to the mayor of a city where crime remains out of control? Barring the same problems, he/she is voted out of office. I could continue, but the point is that people in other fields can be held accountable in security situations. The "customers" of security can exert pressure for improvement, regardless of the power of the objects of their attention to actually do anything about it. It's the "Do something!" impulse, which in many cases yields unintended or sometimes malicious consequences. The fact remains that the choices made by those in power are expected to have a positive effect -- or else they will be removed from power.

Bringing this back to the digital security realm, what is the problem? Unlike physical theft, murder, and other blatantly obvious crimes, it is usually difficult to directly observe digital crime. People are now becoming aware of cybercrime by seeing fraudulent credit card charges (just happened to me again), identity theft, spyware, and the like. This is only the tip of the iceberg, and it's certainly not clear who is at fault. Therefore, customer pressure is unfocused. At some point we cybercrime victims may inflict the "Do something!" impulse, and hold someone accountable.

The CEO of a company that suffered constant intrusion, might direct a "Do something!" impulse at the CISO. If the pressure became too great, the company might decide to abandon its Microsoft Windows systems for something with a better security record. This relates to IT governance, which I've decided is poorly named.

Regarding Mr. Golden's role as "manager, IT governance": those with interests outside security may recognize the term "corporate governance," which in some respects for public companies means safeguarding shareholder interests/assets. Within the corporation, multiple sources of value are resident:

1. Physical assets


2. Financial instruments


3. Brand


4. Human resources (employees)


5. Inventory


6. Intellectual property


7. Information

Each of those items has a level of governance associated with it, meaning implementation, operation, and maintenance of value. Of those seven items, however, only the last might be considered a mix of value inherent to the company and value inherent to its customers. In other words, part of the value of information is derived from data about customers. Sure, the company feels obligated to protect this data to exploit it for sales, but that does not align with the customers' desire to keep the same data out of the hands of thieves.

In situations with split incentives, poor information regarding abuse of customer data, and a lack of power on the customers' part to influence the company (aside from avoiding future purchases), the government usually regulates. We are seeing this happen now.

The major thoughts I took from Mr Golden's talk were:

1. We need an independent group to determine the level of compromise in government agencies. Perhaps GAO?


2. IT governance is really information governance, since the technology is far less important than the data.

Point one reminds me of problems with business financials, water quality, food and drug safety, and related issues; all involve independent agencies which report upon the state of affairs. All of the responsible parties would more than likely prefer to keep the lid on potential problems. Security is no different.

Read More

FISMA Is a Joke

Thanks to SANS Newsbites I read the article FISMA Fizzles. I've written about FISMA before. The new article points me to a potential wise man who understands that FISMA is a joke: ex-Energy Department CIO Bruce Brody. This comment cut straight to the problem with FISMA:

OMB's FISMA implementation basically boils security down to paperwork exercises, and score card pressure ensures it stays that way. But that's not how cybersecurity works; it requires real-time monitoring, updating and patching, Brody says, which isn't necessarily reducible to a paper trail. (emphasis added)

Did I read "real-time monitoring"? Wow. Mr. Brody "gets it." Consider the alternative point of view:

FISMA has its defenders. An agency fully compliant with FISMA is a secure agency, says Scott Charbo, Homeland Security Department CIO. The law and cybersecurity are "the same thing in my mind," he says.

I see. Reading the DHS' grade history shows they have a perfect F record for the last three years. Just because DHS is in a sorry state and its scores are an F doesn't mean that an agency with straight A's is secure!

Let's get back to monitoring. Mr. Brody has correctly recognized that the absolute first priority for a security program is to figure out what is happening. If you have no idea what is happening in your enterprise, how can you expect to "secure" it? It doesn't even make sense to figure out what systems you have before you start monitoring. When you start watching traffic, intruders will show you your systems. The most vulnerable and/or interesting targets will get the most attention from the adversary, and you should address those first.

If you are a federal agency and you want to learn more about implementing monitoring, please contact me: richard at taosecurity dot com. I can teach you what to do, efficiently and cheaply. I may not be wearing my blue uniform any more, but I want to do my part. FISMA is not helping.

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