There’s an article on The Global Flyfisher about rag worms.  These things freak me out for some reason.  But then again, so do catfish and eels. =)

• Falling Springs Branch
• Skip’s Dad
• Friday Flyfish Picture #4
• Friday Flyfishing Post–Kiwi Camo
• Friday Flyfishing Post–Trout Bums and Fish Porn

In a news article at The Register, the US Government is going to have a standard hardened set of settings of Windows OS’s that they will require vendors to install.

From TFA:

“The purchasing power attached to the $65bn federal IT spending budget means that suppliers will have no choice but to take notice.”

Right on!  I’ve been waiting for this for a long time.  You have the 8000-lb gorilla of IT budgets sitting back, buying all this junk from people and then not doing anything about the poor quality of it.  About a year ago, I started teaching government employees in my classes that they had the power to ask for better software, and I think the idea is starting to sink in.

Now they have to do me proud and not make the settings a watered-down weak version of what they should be.  My one fear is that this will be hardening by committee, where you have all these people who show up out of nowhere to complain that one hardening setting or another breaks the functionality they absolutely need to not harden that part of the OS.  The problem with that is you end up with hardening holes.

• Do You Know What FISMA Is?
• Rebuilding C&A
• Power Outages Do Happen
• And Now for Something Completely Different…
• SCAP for Dummies

I talk lots about building a security program.  Like I tell my friends, put 3 squirrels up on a bench and I’ll give them a lecture about building viable security programs and what Certification and Accreditation really means, with some risk management thrown in there to fill it out.

Now while the people at NIST have created some fine guidelines on  what a security program does (800-12 is rock-solid), there isn’t any good source on a staffing model.  This is intentional–as soon as NIST makes an official stance on how to organize a security program, then the very next day I’m going to be asked by somebody if my staffing structure is “NIST-compliant”.

Inside the US Government, the organization should  roughly be organized along these roles or areas of responsibility:

• CISO/ISSO/ISSM/Security PM
• Policy and Procedures
• Risk Management
• Certification, Accreditation, and Compliance
• Contingency Planning/Continuity of Operations/Disaster Recovery
• Awareness and Training
• Security Architecture
• Security Engineering
• Security Monitoring
• Incident Response

You can take these roles and staff them however you want.  In other words, $one_role !== “one person”.  You can combine, say, Risk Management and C&A into one group.  Or you can put the architecture and engineering roles together.  The key is to know what strengths your security program has and working around the weaknesses.

It’s approximately a 1-day exercise to sit down with this list and slice it up however you want.  I can almost see an ISM-Community project on this, where we build a generic staffing template with responsibilities and recommended staffing levels for each of these roles, but I don’t have the time to get on it right now.  If anybody desperately wants to do this as a project, please get in touch with me and I can give you a start.

• The Accreditation Decision and the Authorizing Official
• NIST’S FISMA Pase II–Who Certifies Those who Certify the Certifiers?
• How Much Security Should the Outsourcer Do?
• A Niche to a Niche is Still Hard to Staff
• Remembering Accreditation

How do you dictate common sense?  That’s the real heart of the problem that people who build compliance frameworks have to struggle with.  You can’t force people to do the right thing when the right thing is not easily definable.

This is why I’m convinced that compliance just doesn’t work for what we are trying to get it to do in the information security world.  You run the risks of either leaving too many loopholes that people can get through too easily, or you end up dictating the solution for people with no flexibility.

About the only way where compliance makes sense is in a very limited scope in much the same way you would use a SLA with an external vendor.  In this case, the compliance rules or a similar SLA are a compensating control for the risk to the buyer.

• The Vendors are Already Jumping on the 07-11 Bandwagon
• In Search of a Better Catalog of Controls
• Core Belief #4 — Compliance is a Dead-End
• Workin’ for the ‘Counters: an Analysis of my Love-Hate Relationship with the CPAs
• Cloud Computing and the Government

8 Bit Peoples:  comfort music for geeks who grew up in the 80’s.  It’s simple and Street-Fighter-sounding, yet oddly addicting.  And oh yeah, creative commons licensing.  It makes me want to download the entire set and use that as music to work by.

When I’m elected Dictator of the World, one of my first acts will be to commission a global anthem from one of the 8 Bit Peoples. =)

• Blame it all on John Hughes….
• Hello World
• Making Press Releases
• Radio Nigel
• Famous Quotes: George H

In the operations world, if something dies and doesn’t make a ticket, did it really die?

The answer is, of course, “yes”, but there is a caveat:  if it doesn’t make a ticket, it doesn’t get looked at.

This is a simple fact of life in the operations world.  Yes, we have the large screens with network monitoring system dashboards available 24/7, but a red light on a dashboard is not as instantaneous as a trouble ticket.  It’s because people can only do a handful of things at the same time.  They can’t field user calls and at the same time investigate potential problems shown on the big screen because they need undivided attention on the task at hand.

What does this have to do with security?  That’s an interesting question, and an explanation follows.

I’m half toying with the idea of making trouble tickets for vulnerabilities and audit findings, and here’s why:

• Tickets get assigned to the tier-3/4 administrators to fix
• Tickets are unavoidable for the most part
• The ticketing system provides metrics on what is fixed and not fixed
• The operations guys are already accustomed to having tickets introduced as a stimulus
• Our operational staff is rated on the number of tickets that they close
• Ticketing systems support the operational work flow

Notice what I didn’t explicitly say here?  I’m adapting my security mindset to the operational mindset because that is my environment.  It’s strange because I’ve always been more in the engineering world, so I have to wrap my brain around the operations way of doing things.

• Compensating Controls
• Combatting Tool Creep
• Ed Bellis’s Little SCAP Project
• Federated Vulnerability Management
• Guerilla CISO Tip: Get Inside the Data Center