Google Advanced Operators and Government Website Leakage

Posted August 24th, 2010 by

Ah yes, the magic of Google hacking and advanced operators.  All the “infosec cool kids” have been having a blast this week using a combination of filetype and site operators to look for classification markings in documents. I figure that with the WikiLeaks brouhaha lately, it might be a good idea to write a “howto” for government organizations to check for web leaks.

Now for the search string:, “enter document marking here” site:agency.gov filetype:rtf | filetype:ppt | filetype:pptx | filetype:csv | filetype:xls | filetype:xlsx | filetype:docx | filetype:doc | filetype:pdf looks for typical document formats on the agency.gov website looking for a specific caveat.  You could easily put in a key phrase used for marking sensitive documents in your agency.  Obviously there will be results from published organizational policy describing how to mark documents, but there will also be other things that should be looked at.

Typical document markings, all you have to do is pick out key phrases from your agency policy that have the verbatim disclaimer to put on docs:

  • “This document contains sensitive security information”
  • “Disclosure is prohibited”
  • “This document contains confidential information”
  • “Not for release”
  • “No part of this document may be released”
  • “Unauthorized release may result in civil penalty or other action”
  • Any one of a thousand other key words listed on Wikipedia

Other ideas:

  • Use the “site:gov” operator to look for documents government-wide.
  • Drop the “site” operator altogether and look for agency information that has been published on the web by third parties.
  • Chain the markings together with an “or” for one long search string: “not for release” | “no part of this document may be released” site:gov filetype:rtf | filetype:ppt | filetype:pptx | filetype:csv | filetype:xls | filetype:xlsx | filetype:docx | filetype:doc | filetype:pdf

If you’re not doing this already, I recommend setting up a weekly/daily search looking for documents that have been indexed and follow up on them as an incident.



Similar Posts:

Posted in Hack the Planet, Technical, What Works | 2 Comments »
Tags:

Privacy Camp DC–April 17th

Posted April 7th, 2010 by

Just a quick post to shill for Privacy Camp DC 2010 which will be taking place on the 17th of April in downtown DC.  I went last year and it was much fun.  The conversation ranged from recommendations for a rewrite of

The basic rundown of Privacy Camp is that it’s run like a Barcamp where the attendees are also the organizers and presenters.  If you’re tired of going to death-by-powerpoint, this is the place for you.  And it’s not just for government-types, there is a wide representation from non-profits and regular old commercial companies.

Anyway, what are you waiting for?  Go sign up now.



Similar Posts:

Posted in Odds-n-Sods, Public Policy, The Guerilla CISO | 1 Comment »
Tags:

LOLCATS, Eric Schmidt, and Privacy

Posted December 10th, 2009 by

So now that His Esteemed Highness Eric Schmidt has declared privacy dead, our IKANHAZFIZMA team of LOLCATS wants to know if they can resume their usual collection of cellular traffic.

References:
Gawker: Google CEO: Secrets Are for Filthy People

Schneier Blog: My Reaction to Eric Schmidt

Download Squad: Only naughty people should be afraid of Google, says CEO Eric Schmidt

The Register: Google chief: Only miscreants worry about net privacy

no rly, iz lawful intersepshun of fonez



Similar Posts:

Posted in IKANHAZFIZMA | 2 Comments »
Tags:

Web 2.0 and Social Media Threats for Government

Posted September 30th, 2009 by

So most of the security world is familiar with the Web 2.0 and Social Media threats in the private sector.  Today we’re going to have an expose on the threats specific to Government because I don’t feel that they’ve been adequately represented in this whole push for Government 2.0 and transparency.

Threat: Evil Twin Agency Attack. A person registers on a social media site using the name of a Government entity.  They then represent that entity to the public and say whatever it is that they want that agency to say.

What’s the Big Deal: Since for the most part there is no way to prove the authenticity of Government entities on social media sites short of a “catch us on <social media site>” tag on their .gov homepage.  This isn’t an attack unique to Government but because of the authority that people give to Government Internet presences means that the attacker gains perceived legitimacy.

Countermeasures: Monitoring by the agencies looking for their official and unofficial presences on Social Media and Web 2.0 sites.  Any new registrations on social media are vetted for authenticity through the agency’s public affairs office.  Agencies should have an official presence on social media to reserve their namespace and put these account names on their official website.

References:

.

Threat: Web Hoax. A non-government person sets up their own social media or website and claims to be the Government.

What’s the Big Deal: This is similar to the evil twin attack only maybe of a different scale.  For example, an entire social media site can be set up pretending to be a Government agency doing social networking and collecting data on citizens or asking citizens to do things on behalf of the Government.  There is also a thin line between parody and

Countermeasures: Monitoring of URLs that claim to be Government-owned.  This is easily done with some Google advanced operators and some RSS fun.

References:

.

Threat: Privacy Violations on Forums. A Government-operated social media site collects Personally Identifiable Information about visitors when they register to participate in forums, blog comments, etc.

What’s the Big Deal: If you’re a Government agency and going to be collecting PII, you need to do a Privacy Impact Assessment which is overkill if you’re collecting names and email which could be false anyway.  However, the PIA is a lengthy process and utterly destroys the quickness of web development as we know it.

Countermeasures: It has been proposed in some circles that Government social media sites use third-party ID providers such as OpenID to authenticate simple commenters and forum posts.  This isn’t an original idea, Noel Dickover has been asking around about it for at least 9 months that I know of.

References:

.

Threat: Monitoring v/s Law Enforcement v/s Intelligence Collection. The Government has to be careful about monitoring social media sites.  Depending on which agency is doing it, at some point you collect enough information from enough sources that you’re now monitoring US persons.

What’s the Big Deal: If you’re collecting information and doing traffic analysis on people, you’re most likely running up against wiretap laws and/or FISA.

Countermeasures: Government needs Rules of Engagement for creating 2-way dialog with citizens complete with standards for the following practices:

  • RSS feed aggregation for primary and secondary purposes
  • RSS feed republishing
  • Social networking monitoring for evil twin and hoax site attacks
  • Typical “Web 2.0 Marketing” tactics such as group analysis

References:

.

Threat: Hacked?  Not Us! The Government does weird stuff with web sites.  My web browser always carps at the government-issued SSL certificates because they use their own certificate authority.

What’s the Big Deal: Even though I know a Government site is legitimate, I still have problems getting alert popups.  Being hacked with a XSS or other attack has much more weight than for other sites because people expect to get weird errors from Government sites and just click through.  Also the sheer volume of traffic on Government websites means that they are a lucrative target if the attacker’s end goal is to infect desktops.

Countermeasures: The standard web server anti-XSS and other web application security stuff works here.  Another happy thing would be to get the Federal CA Certificate embedded in web browsers by default like Thawt and Verisign.

References:

.

Threat: Oh Hai I Reset Your Password For You AKA “The Sarah Palin Attack”.  The password reset functions in social media sites work if you’re not a public figure.  Once the details of your life become scrutinized, your pet’s name, mother’s maiden name, etc, all become public knowledge.

What’s the Big Deal: It depends on what kind of data you have in the social media site.  This can range anywhere from the attacker getting access to one social media site that they get lucky with to complete pwnage of your VIP’s online accounts.

Countermeasures: Engagement with the social media site to get special considerations for Government VIPS.  Use of organizational accounts v/s personal accounts on social media sites.  Information poisoning on password reset questions for VIPs–don’t put the real data up there.  =)

References:

Tranparency in Action photo by Jeff Belmonte.



Similar Posts:

Posted in Risk Management | 2 Comments »
Tags:

OMB Wants a Direct Report

Posted August 28th, 2009 by

The big news in OMB’s M-09-29 FY 2009 Reporting Instructions for the Federal Information Security Management Act and Agency Privacy Management is that instead of fiddling with document files reporting will now be done directly through an online tool. This has been covered elsewhere and it is the one big change since last year.  However having less paper in the paperwork is not the only change.

Piles of Paper photo by °Florian.

So what will this tool be like? It is hard to tell at this point. Some information will be entered directly but the system appears designed to accept uploads of some documents, such as those supporting M-07-16. Similar to the spreadsheets used for FY 2008 there will be separate questions for the Chief Information Officer, Inspector General and Senior Agency Official for Privacy. Microagencies will still have abbreviated questions to fill out. Additional information on the automated tool, including full instructions and a beta version will be available in August, 2009.

Given the required information has changed very little the automated system is unlikely to significantly ease the reporting burden. This system appears primarily designed to ease the data processing requirements for OMB. With Excel spreadsheets no longer holding data many concerns relating to file versions, data aggregation and analysis are greatly eased.

It is worth noting that a common outcome of systems re-engineered to become more efficient is that managers look to find ways to utilize the new efficiency. What does this mean? Now that OMB has the ability to easily analyze data which took a great amount of effort to process before they may want to improve what is reported. A great deal has been said over the years about the inefficiencies in the current reporting regime. This may be OMB’s opportunity to start collecting an increased amount of information that may better reflect agencies actual security posture. This is pure speculation and other factors may moderate OMB’s next steps, such as the reporting burden on agencies, but it is worth consideration.

One pleasant outcome to the implementation of this new automated tool is the reporting deadline has been pushed back to November 18, 2009.

Agencies are still responsible for submitting document files to satisfy M-07-16. The automated tool does not appear to allow direct input of this information. However the document requirements are slightly different. Breach notification policy document need only be submitted if it has changed. It is no longer sufficient to simply report progress on eliminating SSNs and reducing PII, an implementation plan and a progress update must be submitted. The requirement for a policy document covering rules of behavior and consequences has been removed.

In addition to the automated tool there are other, more subtle changes to OMB’s FY 2009 reporting. Let’s step through them, point by point:

10. It is reiterated that NIST guidance is required. This point has been expanded to state that legacy systems, agencies have one year to come into compliance with NIST documents new material. For new systems agencies are expected to be in compliance upon system deployment.

13 & 15. Wording indicating that disagreements on reports should be resolved prior to submission and that the agency head’s view will be authoritative have been removed. This may have been done to reduce redundancy as M-09-29’s preface indicates agency reports must reflect the agency head’s view.

52. The requirement for an central web page with working links to agency PIAs and Federal Register published SORNs has been removed.

A complete side-by-side comparison of changes between the two documents is available at FISMApedia.org.

All in all the changes to OMB’s guidance this year will not change agencies reporting burden significantly. And that may not be a bad thing.



Similar Posts:

Posted in FISMA, NIST, Public Policy | 1 Comment »
Tags:

Privacy Camp DC on June 20th

Posted June 11th, 2009 by

Saturday, June 20, 2009 from 8:00 AM – 5:00 PM (ET) in downtown DC.

I’ll be going.  This will be a “Bar Camp Stylie” event, where you’re not just an attendee, you’re also a volunteer to make it all happen.  You might end up running a conversation on your favorite privacy topic, so you have been warned. =)

*Most* of the folks going are of the civil libertarian slant.  With my background and where I work, I usually “bat for the other team on this issue”.  The organizers have assured me that I’ll be welcome and can play the heretic role.

How to play:

Some themes that I’ve seen develop so far:

  • How some concepts (System of Record) from the Privacy Act are outdated or at least showing their age
  • How the open government “movement” and the push for raw data means we need to look at the privacy concerns
  • FOIA and privacy data
  • Ending the political robocalls

See Y’all there!



Similar Posts:

Posted in Public Policy, Speaking | No Comments »
Tags:

« Previous Entries


Visitor Geolocationing Widget: