I’m on the OWASP Podcast

Posted October 1st, 2009 by

I sat down with Jim Manico a month or so ago when he was in DC and recorded a podcast for the OWASP Podcast.  It’s now live, check it out.



Similar Posts:

Posted in FISMA, NIST, Public Policy, Rants, Speaking, The Guerilla CISO | No Comments »
Tags:

The Guerilla CISO Rants: Don’t Write a System Security Plan

Posted October 1st, 2009 by

OK, I know you’re shocked…I’m saying something controversial.  But hear me out on this one, I’ll explain.

Now this is my major beef with the way we write SSPs today:  this is all information that is contained in other artifacts that I have to pay people to do cut-and-paste to get it into a SSP template.  As practiced, we seriously have a problem with polyinstantiation of data in various lifecycle artifacts that is cut-and-pasted into an SSP.  Every time you change the upstream document, you create a difference between that document and the SSP.

This is a practice I would like to change, but I can’t do it all by myself.

This is the skeleton outline of an SSP from Special Publication 800-18, the guide to writing an SSP:

  1. Information System Name/Title–On the investment/FISMA inventory, the Exhibit 300/53, etc
  2. Information System Categorization–usually on a FIPS-199 memorandum
  3. Information System Owner–In an assignment memo
  4. Authorizing Official–In an assignment memo
  5. Other Designated Contacts–In an assignment memo
  6. Assignment of Security Responsibility–In assignment memos
  7. Information System Operational Status–On the investment/FISMA inventory, the Exhibit 300/53, etc
  8. Information System Type–On the investment/FISMA inventory, the Exhibit 300/53, etc
  9. General System Description/Purpose–In the design document, Exhibit 300/53
  10. System Environment–Common controls not inside the scope of our system
  11. System Interconnections/Information Sharing–from Interconnection Security Agreements
  12. Related Laws/Regulations/Policies–Should be part of the system categorization but hardly ever is on templates
  13. Minimum Security Controls–800-53 controls descriptions which can easily be done in a Requirements Traceability Matrix
  14. Information System Security Plan Completion Date–specific to each document
  15. Information System Security Plan Approval Date–specific to each document

Now some of this has changed in practice a little bit–# 10 can functionally be replaced with a designation of common controls and hybrid controls.

So my line of thinking is that if we provide a 2-6-page system description with the names of the “guilty parties” and some inventory information, controls-specific Requirements Traceability Matrix, and a System Design Document, then we have the functional equivalent of an SSP.

Why have I declared an InfoSec fatwah against SSPs as currently practiced?

Well, my philosophy for operation is based on some concepts I’ve picked up through the years:

  • Why run when you can walk, why walk when you can sit, why sit when you can lay down.  There is a time to spend effort on determining what the security controls are for a project.  You need to have them documented but it’s not cost-effective to be worried about format, which we do probably too much of today.
  • Make it easy to do the right thing.  If we polyinstantiate security information, we have made something harder to maintain.  Easier to maintain means that it will get maintained instead of being shelfware.  I would rather have updated and accurate security information than overly verbose and well-polished documents that are inaccurate.
  • Security is not a “security guy thing”–most problems are actually a management and project team problem.  My idea uses their SDLC artifacts instead of security-specific versions of artifacts.  My idea puts the project problems back in the project space where it belongs.
  • If I have a security engineer who has a finite amount of hours in a day, I have to choose what they spend their time on.  If it’s a matter of vulnerability mitigation, patching, etc, or correcting SSP grammar, I know what I want him to do.  Then again, I’m still an infantryman deep down inside and I realize I have biases against flowery writing.

Criticisms to not writing a dedicated SSP document:

“My auditors are used to seeing the information in the same format at someplace they worked previously”. Believe it or not, I hear this quite a bit.  My response is along the lines of the fact that if you make your standard be what I’m suggesting for a security plan, then you’ve met all of the FISMA and 800-53 requirements and my personal requirement to “don’t do stupid stuff if you can help it”.

“My auditors will grill me to death if they have to page back and forth between several documents”.  This one also I’ve heard.  There are a couple of ways to deal with this.  One way to deal with this is that in your 800-53 Requirements Traceability Matrix you reference the source document.  Most auditors at this point bring up that you need to reference the official name, date of publication, and specific page/section of the reference and I think they need to get a life because they’ve taken us back to the maintainability problem.

“This is all too new-school and I can’t get over it”. Then you are a dinosaur and your kind deserves extinction.  =)

.

This blog post is for grecs at novainfosecportal.com who perked up instantly when I mentioned the concept months ago.  Finally got around to putting the text somewhere.

How to Plan the Perfect Dinner Party photo by kevindooley.



Similar Posts:

Posted in FISMA, NIST | 11 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:

IKANHAZFIZMA and Transparency

Posted September 24th, 2009 by

It’s a complete change on how the Government does business, but agency CISOs are marching along to the transparency and openness beat, still feeling like somehow somewhere it;s not really the right idea security-wise.  Welcome to life in the fish bowl.  =)

On another note, I know that one day I’ll walk into somebody’s office or cubicle and they will have IKANHAZFIZMA lolcats pinned to the wall and it will be the highlight of the week for me. If you’re a lolcat printer, drop me an email.

ciso kitteh gears up for transparensee



Similar Posts:

Posted in IKANHAZFIZMA | No Comments »
Tags:

CIO Council Guidelines on Social Media Meet IKANHAZFIZMA

Posted September 21st, 2009 by

Due to the the CIO Council’s Guidelines on Social Media being carried by, well, just about everybody out there who can spell “Gov 2.0” (including the crazy folks at GovTwit), we here at the Guerilla CISO have decided to release an out-of-cycle lolcat to commemorate the event.

cio kounsil



Similar Posts:

Posted in IKANHAZFIZMA | 1 Comment »
Tags:

Federal Computer Week and S.773

Posted September 20th, 2009 by

A phenomenal cartoon that reflects the true depth of discussion on S.773.  You may now return to your regularly-scheduled hacking.

Hat tip to Dan Philpott.



Similar Posts:

Posted in Uncategorized | No Comments »
Tags:

« Previous Entries Next Entries »


Visitor Geolocationing Widget: