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

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

Our government hasn’t had a ton of time to get their act together.  It’s only been 225 years, give or take, and in that time, we might have learned a thing or two.

So why is it that it took us this long before we could get one agency to recognize the clearances from another agency?  Even though OMB keeps trying to unify the clearance management systems, as a managed service provider I still have to convince every new client that I’m trustworthy because I have a DoD Top Secret.
So what’s the benefit?  Well, from my angle, one unified clearance system means economy of scale simply by avoiding a “Not Invented Here” attitude.  If I have 5 clients, 100 employees, and $5000 per person for a clearance, the savings add up really quickly if I just have to clear people once.

Now the strange thing is that by agencies having their own individual clearance system, we are creating an artificial scarcity of cleared people.  For somebody with a TS/SCI, starting salary in the DC area is around $80K/year, simply because of lack of supply.  That’s an indirect cost that we could avoid.

• Tangling with the Clearance Monsters
• Lines of Business, Relationships, and Trustability
• Feds to Embrace SaaS, End is Nigh for Security!
• Compensating Controls
• The Guerilla’s Guide to Piggybacking

Want me to take a stab at what the information security management world will look like in 5 years?  I think I’m starting to see the start of it, and I’ll tell you about it if you sit for awhile and listen.

The US government does some things right.  Yes, you heard me correctly.

You probably think by now that all I do now is whine about huge levels of gross incompetence I see on a daily basis and how I could singlehandedly run the government all while sitting at home, sipping on a coke, and crunching data on my own personal cluster of beowulf clusters.

But really, the government does some things right.  The folks at the NIST FISMA project do some very amazing things, and I’m not just saying that to suck up to Ron and Marianne.

One thing that the government does right is to make their guidelines available for free to anyone over the internet.  And some of them beat the pants off what you would find in the commercial world.  Inside ISM-Community, when we started the Risk Assessment Methodology Project, I personally found it hard to ignore the fact that Special Publication 800-30 was staring me in the face.  How really do you improve on it?  Well, for starters you take 800-30 as a base process and then add more specific guidelines, examples, and templates, which is pretty much what our methodology started out as.
One of the things that NIST does really well is to provide you with a framework.  It’s extensible to include various standards (PCI, 7799, and the government’s home-grown 800-53), tailorable, and is designed to hook security into the system development life cycle (SDLC).  It’s entirely free as in beer and free as in you have the ability to import into your own processes.

Would you be surprised if I told you the framework was certification and accreditation?

Yes, I’ve criticized certification and accreditation a bazillion times.  Well, I haven’t really criticized the process–personally I think it’s really strong.  Instead, I criticize the implementation of the process and how the people who are tasked with C&A usually do not have the technical skills to accomplish what they are trying to do.

I’ve seen 2 RFPs out on the street in the past couple of months for C&A services for local governments.
This is driven by auditors and practitioners coming from the federal government who are making recommendations on joint systems, like RealID will end up if the states don’t rebel like it seems they are starting to do.

The future will bring along C&A, and it might even turn out to be the vehicle for needs determination and risk assessment, but C&A has to adapt and lose some of it’s heavy baggage along the way.

• FISMA Fellows Spring Cohort
• What the Government Looks for in a Product
• NIST’S FISMA Pase II–Who Certifies Those who Certify the Certifiers?
• Build a Security Program
• Remembering Accreditation

I’ve fried 2 processors in the past 2 weeks.  That’s not a good track record.  Maybe I overheated them with one too many FPS games, but I think the culprit was a bad motherboard.  Since I was running on some older technology, most of it wouldn’t work in any of the newer hardware (I had a socket 478 Pentium 4 with DDR 1 RAM and ATA-166 drives), I knew I was headed for a “forklift upgrade”.

I got a clearance workstation for $400.  Not bad for something with a dual-core (Pentium-D so it’s one generation behind) CPU, 2 GB  RAM, 2 250 GB SATA drives and an Nvidia graphics card.  I probably couldn’t buy the components for that much.

Right now I’m taking the OS (Debian with some special sources) and putting it on the new drives.  Even if you hate software raid, it does give you a solid amount of portability from one drive technology to another, like I am here with the transition from raid on IDE drives to raid on SATA drives.  The operations dweeb in me likes that flexibility.

The point here is that flexibility ~= availability.  That’s why you have a security architecture.  That’s why things such as load balancers, DNS, and redundant SAN fibre switches make sense.

• My System Environment
• Server Upgrades
• Clearances and Economy of Scale
• It’s Still not Too Late
• Lions, Tigers, and VLANs Oh MY!

While I’m still on an outsourcing kick, let me go through what I call the keys to the wonderful kingdom of outsourcing.

In true ISM-Community form, let me give you a “Top 10 Keys to Outsourcing” list.

1. Know Thyself:  Like the Oracle at Delphi, the most important thing you can do before outsourcing is to know where your weaknesses are and to sculpt the contract to your needs.  More on this subject.
2. Bottom Line up Front:  It works for newspaper editors, it can also for you.  Being as explicit with security categorization and must-have requirements as you can without defining the solution will allow the contractor to determine a solid security model and staffing to support the outsourcing effort.  More on this subject.
3. Use Compensating Controls:  You can’t control the vendor’s infrastructure, so use compensating controls where you have to sacrifice control for economy of scale.  More on this subject.
4. Retain Authority to Make Decisions:  This is why the contractor shouldn’t be the system owner.  If you lose the authority to make decisions, you will be “worked over” by the vendor.  More on this subject.
5. Understand the Added Complexity of Outsourcing:  Things sometimes get slower when you outsource them because there is the added layer of abstraction in the contracting officers.  More on this subject.
6. Have Requirements-Driven Roles and Responsibilities:  Start with what your security requirements, roles, and responsibilities and then divide them up between government and contractor.  More on this subject.
7. Tie into the Existing Security Organization:  Create a dotted line on the organization chart between your organization and the contractor’s.  More on this subject.
8. Get a Gap Analysis:  Bring in a third party to assess you for areas that need fixing, both pre-outsourcing and during outsourcing.  More on this subject.
9. Hedge Your Bets:  By having a minimum of one security representative on either side of the contracting fence, you have a parallel path other than through contracting officers.  More on this subject.
10. 2 Is Sometimes better than 1:  If you have IT services outsourced through one contractor, you can have a second contractor provide security support.  It sometimes adds more complexity at reducing conflict-of-interest.  More on this subject.
11. (The Freebie) It’s all About Transparency:  Be wary of vendors and contractors that withhold information.  In a partnership, you share information.  More on this subject.

• You Didn’t Outsource Your Responsibilities
• How Much Security Should the Outsourcer Do?
• Introduction to Outsourcing in the US Government
• What the Government Looks for in a Product
• Compensating Controls