In Which Our Protagonist Discovers We Need More Good Public Policy People Who Understand Security

November 4th, 2008 by rybolov

If you're new here and would like to see more of what I'm saying, you may want to subscribe to my RSS feed (I can even email my blog posts to you when I publish a new one) or have a look at my papers and presentations page for downloads of stuff that you can share or "borrow heavily from". You also might find my guidelines for posting comments interesting, especially if you're a government employee. If you want to see me blog about anything in particular, drop me a private email on how you think I'm completely full of myself, extend me an invitation to speak at your next security meeting/event, or just to ship a huge bag of money in my direction, you can do that through my contact page. Thanks for visiting and happy hacking!

Note the emphasis on good.  Note the emphasis on public policy.

Yes, folks, we need good policy people.  Think about the state of security and public policy today:

  • We have FISMA which is a law.  Everybody’s whipping boy but it’s exactly where it needs to be to have risk-based management of IT security.
  • We have a framework for implementing FISMA.  It’s a pretty good set of process, policy, and standards that have spilled over into the private sector.
  • You need a crowbar to get good/smart security people to deal with politics, it takes a death ray to get them to deal with public policy.
  • We don’t have high-level policy-makers who understand risk management and they are co-opting the model of compliance.
  • Public policy is the upstream neighbor of information security and what public policy people do influences what we do.
  • If we want to succeed in security at the operational and tactical level, we need to have the right decisions made at the strategic level, and that includes public policy.
  • I’m not just talking about security and the Government, this is also with things like breach laws; compliance frameworks (PCI, HIPAA); and how unpatched and zombified desktops hurt everybody else.

So in true Guerilla CISO style, I’m doing something about it.  Armed with my favorite govie (who is actually the lead on this, I’m just a straphanger), The New School of Information Security (Hi Adam and Andrew), some government policy directives, and the National Strategy to Secure Cyberspace, I am teaching an Information Security Management and Public Policy class for Carnegie Mellon’s Heinz School.

The more I work with the Masters of Science in Public Policy Management program, the more I’m sold on it.  Basically the students do a year on-campus in Pittsburg, then they have the option of staying there or coming to DC.  The students who come to DC work a 32-hour week (some do more), 2 night classes, and class for most of Friday.  Our information security class fits in as a sector-specific deep-dive, the other one being healthcare (which needs smart public policy people, too).

Which is where we need some help.  It’s a little behind the game, but we’re constantly looking for Government agencies, NGOs/NPOs, and contractors who are interested in taking on interns.  Even better if you have jobs that don’t have a US citizenship requirement.  If you want to be linked up, just drop me a line.

And oh yeah, my blogging has slowed down because I’m working 2 new projects and traveling to Tennessee and teaching Thursday nights and my life just got way busy.  =)

 

Alexander Hamilton Statue photo by dbking.

Posted in The Guerilla CISO, What Works | No Comments »

The Cost of S.3474

October 31st, 2008 by rybolov

Something fun and new for you guys:  the estimated cost of S.3474 (.pdf caveat applies) if it were to be signed into law in its current state.  Thank you Congressional Budget Office.

Bottom line: $40M in 2009 and $570M from 2009-2013.

A quick update on S.3473:  it’s not going to get voted on by this Congress–the bill ran out of time and all of the politicians ran into campaign season so it’s hard to pin them down and get anything done.  In fact, none of the handful of security bills are going to get looked at until the next Congress.  So yeah, their fate depends on both the presidential and congressional elections next week, then let’s see if there is enough congressional bandwidth to push these bills through after the new administration transitions in.

Some of my S.3474 coverage if you’re interested.

Posted in FISMA | No Comments »

Digital Forensics: Who should make the keys?

October 22nd, 2008 by ian99

Paraben is a leading vendor for digital forensics products (http://www.paraben.com/). However, within this huge international market, Paraben specializes in digital forensic products for mobile devices such as PDA and phones. Paraben just recently released a very nice product called the Cell Seizure Investigator (CSI) Stick (http://www.csistick.com/index.html).

Aside from the overly-dramatic marketing embedded in the name of the product, this seems to be another solid addition to the Paraben product line. The device is designed to make a forensically correct copy of the data on your mobile phone–including call records, address books, and text messages. The devices look basically like a USB flash memory drive with the addition of an adapter/interface unit.

The copying process is largely automatic and the CSI Stick is quite reasonably priced at $99 -199, depending on the software bundle. The market reaction to this product is also quite positive. My friends in the industry who have used the device consider it an indispensable time-saving device. I can hardly wait until I get my have on one myself. In the past when, I was tasked to recover such data it was much more time consuming and hardware intensive process.

Equally fascinating, is the release (if you can call it that) of a product with a similar form-factor from Microsoft. The product is released on a flash drive and is called COFEE (Computer Online Forensic Evidence Extractor — http://www.microsoft.com/presspass/features/2008/apr08/04-28crantonqa.mspx).  Microsoft indicates that COFEE contains 150 commands that facilitate the collection of digital evidence from computers that it is physically connected to. In addition, COFEE can decrypt passwords, and collect information on a computer’s Internet activity, as well as data stored in the computer. Microsoft has indicated that COFEE has been made available to law-enforcement agencies only. And, according to one report, law-enforcement agencies in 15 nations have been provided with the device.

My initial reaction to this news was that it was not an unexpected development and that the announcement would be greeted with inevitable jokes about the need for Microsoft to also release a companion product called DONUTS. In fact, the reaction of the technical press has been largely negative and suspicious. Most of the concerns seem to center on privacy and individual rights. However, there isn’t a single capability associated with COFEE that I have been able to confirm, that doesn’t exist in some other commercial or open-source product. I do wish that I could get my hands on a trial or lender copy of COFFEE so that I could confirm this position.

Locksmith Sign photo by Meanest Indian.

While I admit that I have always been concerned about the safeguarding individual’s civil liberties, I am largely puzzled at the negative reactions. One element of the outcry that I do understand is an emotional one and that centers on the concept that a company that is paid to protect your secrets should not also be selling the tools and techniques to compromise those secrets. On an emotional level this makes sense.

However, the real world is very different. For example, every major automobile manufacturer cooperates with locksmiths to insure that there are low-cost and non-destructive means to circumvent you car locks in the event that you lock you keys in your cars or just loose you car key outright. Without getting into the details of defeating car locks, may automobile manufactures even provide specialized equipment and technical materials directly to locksmiths to facilitate this process.

If there are concerns that Microsoft my be caught in a ethical conflict of interest, we need to look at similar conflicts in other industries, and that’s food for thought.

Posted in Rants, Technical | No Comments »

When the Feds Come Calling

October 21st, 2008 by rybolov

I’ve seen the scenario about a dozen times in the last 2 months–contractors and service providers of all sorts responding to the Government’s security requirements in the middle of a contract.  It’s almost reached the stage where I have it programmed as a “battle drill” ala the infantryman’s Battle Drill 1A, and I’m here to share the secret of negotiating these things.

Let’s see, without naming names, let’s look at where I’ve seen this come up:

  • Non-Government Organizations that assist the Government with para-Government services to the citizens
  • Companies doing research and development funded by the Government–health care and military
  • Universities who do joint research with the Government
  • Anybody who runs something that the Government has designated as “critical infrastructure”
  • State and local governments who use Federal Government data for their social plans (unemployment system, food stamps, and ) and homeland security-esque activities (law enforcement, disaster response)
  • Health Care Providers who service Government insurance plans

For the purposes of this blog post, I’ll refer to all of these groups as contractors or service providers.  Yes, I’m mixing analogies, making huge generalizations, and I’m not precise at all.  However, these groups should all have the same goals and the approach is the same, so bear with me while I lump them all together.

Really, guys, you need to understand both sides of the story because this a cause for negotiations.  I’ll explain why in a minute.

On the Government side:  Well, we have some people we share data with.  It’s not a lot, and it’s sanitized so the value of it is minimal except for the Washington Post Front Page Metric.  Even so, the data is PII that we’ve taken an anonymizer to so that it’s just statistical data that doesn’t directly identify anybody.  We’ve got a pretty good handle on our own IT systems over the past 2 years, so our CISO and IG want us to focus on data that goes outside of our boundaries.  Now I don’t expect/want to “own” the contractor’s IT systems because they provide us a service, not an IT system.  My core problem is that I’m trying to take an existing contract and add security requirements retroactively to it and I’m not sure exactly how to do that.

Our Goals:

  • Accomplishing the goals of the program that we provided data to support
  • Protection of the data outside of our boundaries
  • Proving due-diligence to our 5 layers of oversight that we are doing the best we can to protect the data
  • Translating what we need into something the contractor understands
  • Being able to provide for the security of Government-owned data at little to no additional cost to the program

On the contractor/service provider side:  We took some data from the Government and now they’re coming out of the blue saying that we need to be FISMA-compliant.  Now I don’t want to sound whiney, but this FISMA thing is a huge undertaking and I’ve heard that for a small business such as ourselves, it can cripple us financially.  While I still want to help the Government add security to our project, I need to at least break even on the security support.  Our core problem is to keep security from impacting our project’s profitability.

Our Goals:

  • Accomplishing the goals of the program that we were provided data to support
  • Protection of the data given to us to keep the Government happy and continuing to fund us (the spice must flow!)
  • Giving something to the Government so that they can demonstrate due-diligence to their auditors and IG
  • Translating what we do into something the Government understands
  • Keeping the cost of security to an absolute minimum or at least funded for what we do add because it wasn’t scoped into the SOW

Hmm, looks like these goals are very much in alignment with each other.  About the only thing we need to figure out is scope and cost, which sounds very much like a negotiation.

Hardcore Negotiation Skills photo by shinosan.

Little-known facts that might help in our scenario here:

  • Section 2.4 of SP 800-53 discusses the use of compensating controls for contractor and service-provider systems.
  • One of the concepts in security and the Government is that agencies are to provide “adequate security” for their information and information systems.  Have a look at FISMA and OMB Circular A-130.
  • Repeat after me:  “The endstate is to provide a level of protection for the data equivalent or superior to what the Government would provide for that data.”
  • Appendix G in SP 800-53 has a traceability matrix through different standards that can serve as a “Rosetta Stone” for understanding each other.  Note to NIST:  let’s throw in PCI-DSS, Sarbanes-Oxley,  and change ISO 17799 to 27001.

So what’s a security geek to do?  Well, this, dear readers, is Rybolov’s 5-fold path to Government/contractor nirvana:

  1. Contractor and Government have a kickoff session to meet each other and build raport, starting from a common ground such as how you both have similar goals.  The problem really is one of managing each others’ expectations.
  2. Both Government and Contractor perform internal risk assessment to determine what kind of outcome they want to negotiate.
  3. Contractor and Government meet a week later to negotiate on security.
  4. Contractor provides documentation on what security controls they have in place.  This might be as minimal as a contract with the guard force company at their major sites, or it might be just employee background checks and
  5. Contractor and Government negotiate for a 6-month plan-of-action.  For most organizations considering ISO 27001, this is a good time to make a promise to get it done.  For smaller organizations or data , we may not even

Assumptions and dependencies:

  • The data we’re talking about is low-criticality or even moderate-criticality.
  • This isn’t an outsourced IT system that could be considered government-owned, contractor-operated (GO-CO)

Posted in FISMA, Outsourcing | 1 Comment »

Evolution of Penetration Testing: Part 1

October 13th, 2008 by ian99

Penetration testing is a controversial topic with an interesting history. It is made all that much more controversial and perplexing because of an common disconnect between the service provider and the consumer.

Penetration started as a grey-art that was often practiced/delivered in an unstructured and undisciplined manner by reformed or semi-reformed hackers. Penetration testers used their own techniques and either their own home-grown tools or tools borrowed or traded with close associates. There was little reproducibility or consistency of results or reporting. As a result, the services were hard to integrate into a security program.

As the art evolved it became more structure and disciplined and tools, techniques, and reporting became more standardized. This evolution was driven by papers, articles, technical notes that were both formally published and informally distributed. In the end, a standardized methodology emerged that was largely based on the disciplined approach used by the most successful hackers.

Hakker Kitteh photo by blmurch.

At about the same time open-source, government and commercial tools began to emerge that automated many of the steps of the standardized methodology. These tools had two divergent impacts on the art of penetration testing. As these tools were refined and constantly improved they reinforced the standard methodology, provided more consistent and reproducible results and improved and standardized penetration reporting. All of this made penetration testing easier for the consumer to absorb and integrate into security programs. As a result, regulations and security protocols emerged that required penetration and security assessments. Nmap and Nessus are excellent examples of the kind of tools that help shape and push this evolution. And, because of their utility they are still indispensable tools today.

However, Nessus also helped to automate both data collection and analysis, it has lowered the bar for the skills and experience needed to conduct portions of the penetration testing methodology. This lowered the cost of penetration testing and made them much more broadly available. Thus, giving rise to so-called “boutique firms.” The problem with penetration testing “boutique firms” is that they fall into two broad categories; specialized highly professional firms led by experienced and technical security professionals who can translate automated tool output into root-cause analysis of vulnerabilities, and security program flaws. The second category of firm consists of opportunist firms with just enough knowledge to run automated tools and cut and paste the tool output into client reports. The later firms are some times called “tool-firms” and their employees “tool-boys.”

The later flourish for two reasons. The first is that they can offer their services at rock bottom prices. The second reason is that security organizations are often so ill-informed of the intricacies of the penetration testing process that can’t make a meaningful distinction between the professional firms and the tool-boys except on the basis of costs.

Posted in Rants, Technical | 2 Comments »

Keeping The Lights On: Cybersecurity Law for the Electric Grid

September 23rd, 2008 by DanPhilpott

Ever wondered if your electricity supply was safe from computer attack? Congress wondered that too. So they asked the Federal Energy Regulatory Commission (FERC) to find out. The answers they received in October of 2007 were not encouraging.

After 9/11 there was concern about the safety of the Bulk Power Supply (BPS). The President’s Commission on Critical Infrastructure Protection released a report which was explicit about the dangers faced. A frightening example of these dangers was demonstrated by the Aurora vulnerability, essentially a software hack that made a generator crash hard. When faced with this example industry moved to mitigate the problem with some prodding from Department of Homeland Security (DHS), Nuclear Regulatory Commission (NRC) and FERC. The Nuclear Sector, which is regulated by NRC, issued a requirement to address the problem. The Electric Sector was issued a recommendation to address the problem by the Electric Sector Information Sharing and Analysis Center (ES-ISAC). Guess which industry has moved forward with successful mitigation efforts and which has not. FERC reported back on these findings in October of 2007.

Fast forward to now. On September 11th the Bulk Power System Protection Act (BPSPA) of 2008 (PDF link) was put forward by Rep. Rick Boucher (D-VA), chairman of the House Subcommittee on Energy and Air Quality. In addition to the September 11th hearing on the BPSPA a closed door hearing was expected to be conducted the following week. The goal of this legislation is to expand the emergency power of FERC to regulate cybersecurity for the BPS. The act itself does not appear to be strongly opposed by the energy industry but, as always, the devil is in the details.

Diablo Canyon Nuclear Power Plant photo by emdot.

The draft legislation is disputed on three major points; whether to include national security threats, disclosure of threat information and a sunset provision.

FERC recommends wording that would make explicit the requirement to address national security threats. This seems an implicit and reasonable expectation that the people of the United States would have of the agency regulating the BPS but the Energy Sector considers this too expansive a role. They argue that it might cause expensive requirements to be issued such as stockpiling fuel.

The disclosure of threat information is a sore point. Here you can understand the pain of the industry in dealing with government intelligence agencies who would like to keep details of a threat spare to preserve the source of that information. Unfortunately the government must preserve their sources while providing enough information for the industry to react.

Both FERC and the Energy Sector agree on the idea of a sunset provision. The sunset provision in this case stipulates that so long as an order is implemented as a standard it should terminate one year after issuance unless renewed by the President or the Secretary of Energy. The issue is whether this sunset will include the orders to address existing problems (such as the Aurora vulnerability) in addition to orders issued for future vulnerabilities. FERC recommends that only future orders should be sunsetted while the Energy Sector recommends both current and future orders should be sunsetted.

One element which is not adequately addressed in this legislation is how FERC will build the capability to assess and manage cybersecurity issues for the BPS. What should be in place is a bipartite separation of duties between FERC and NIST similar to what is in place with the dual OMB/NIST FISMA roles. FERC would oversee the security while NIST would provide technical guidance on what security should be put in place. FERC does not have the experience in security frameworks or in depth expertise in SCADA security which is required for a cybersecurity initiative of this magnitude.

It is worth noting that Energy Policy Act of 2005 (PDF link) established a process through which the North American Electric Reliability Corporation’s (NERC) was authorized to enforce cybersecurity in the Energy Sector. NERC had gone so far as to create Critical Infrastructure Protection (CIP) standards to include with their Reliability Standards and had present them to FERC for approval by late 2007.

A review of the NERC CIP standards (CIP-001 through CIP-009) does not inspire confidence in NERC’s cybersecurity capabilities. I will discuss the shortcomings of this guidance in a subsequent post.

Posted in What Doesn't Work | 2 Comments »

Ooh, “The Word” is out on S 3474

September 19th, 2008 by rybolov

Federal Computer Week: Senate Panel Rejects Weakening S 3474

Gene Schultz: Goodbye FISMA (as We Know It)

Let’s talk through the FCW article first, shall we?   =)

“The measure would amend the original FISMA legislation, which outlined compliance activities for agencies to meet each year. However, many agencies have turned FISMA compliance into a paperwork exercise, Carper said.”

Um, no, I don’t get that.  The original FISMA is an information security management law, this law mostly formalizes the role, responsibility, and authority of the CISO.  They intentionally named it FISMA 2008 to make people think that it was ammending the original FISMA, but it doesn’t do that.

Don’t believe the hype, this will not change the original FISMA, it’s just an addition.

“Carper said CIOs primarily develop and oversee policy, but the CISO handles the daily information security activities. He suggested that a CISO council could have a sunset date of two or three years. If the council demonstrated benefits, it could be extended, Carper said.”

OK, fair enough on the cost and coordination, but what the CISO council objectionists don’t understand is that the CIOs don’t know all of the nuts and bolts of security, that’s why we have CISO as a mandatory position in this bill–so that the CIO has a subject-matter-expert to help them out.  Yes, it’s that specialized as a profession.

Now for Gene Schultz:

“First and foremost, to comply with this statute involves generating huge amounts of paperwork to document actions (or lack thereof) taken to address the many areas that FISMA describes. A completely ineffective security practice can get high FISMA marks, as has happened numerous times before.”

OK, this is a little lesson on FISMA paperwork:  people are doing 4x what they should be doing for the following reasons:

  • The people doing the writing do not know what they are actually doing
  • The agency’s security program is not mature enough to have shared/common controls
  • In the world of auditors, if it’s not written down, it doesn’t exist
  • CYA purposes–I told you this was a risk

So you think you’re going to do any better with any other framework/law and the same people executing it?

“Two US Senators, Joseph Lieberman of Connecticut and Tom Carper of Delaware, have recently introduced a Senate bill that would render the 2002 version of FISMA obsolete.”

No, to be bluntfully honest, the old version of FISMA will still be around.  Somebody’s been drinking the kool-aid from the lawmakers and the press machine.  If anything, this adds more junk that you can get audited on and an additional layer of paperwork to demonstrate that you have met the provisions of FISMA 2008.

Post No Bills photo by striatic.

Note to our nation’s Lawmakers: as long as you approach information security from the compliance angle, we as a government are doomed to failure and to turn the entire thing into the checklist activity because the people who evaluate compliance are auditors who only know checklists–it’s not a law problem, it’s a people and skills problem.

This bill is actually pretty good with the exception of divorcing the mission owners from the security of the systems that support their mission.

However, if you think that you can reduce the compliance trap by adding more things that will end up on a compliance checklist, you have to be kidding yourself or you don’t understand the auditor mentality.

I keep reconvincing myself that the only way the government can win at security is to promote programs to develop people with security skills.  Of course, that isn’t as sexy as throwing out a bill that you can claim will make FISMA obsolete.

And finally, for those of you playing along at home, the Thomas entry for S 3474, the bill’s page on Washington Watch and the bill’s page on GovTrack.

Posted in FISMA | 2 Comments »

« Previous Entries


Visitor Geolocationing Widget: