Posted April 9th, 2007 by
rybolov
I was downtown teaching at the City Club of Washington. It was my favorite day of the series: Security Test and Evaluation and Risk Management (SPs 800-42, 800-53A, and 800-30).
Earl Crane of ISM-Community fame came jumped in at the last minute (I called him the day before) and gave a good hour worth of presentation on Google hacking and the government.
One thing about the Potomac Forum FISMA Fellows program that is very important to understand: It’s only for government employees. The only contractors present are the instructors. That means two things:
- We can teach at a very surprising level of depth because we’re not training our competitors. It leaves the instructors with a bit of a bad aftertaste when you’ve trained somebody to “eat your lunch”. By restricting the participants to government only, I can teach people exactly how I do things and give them examples to take home in a binder.
- Students can talk about particular scenarios in their agency without worrying that the information will go anywhere that it’s not supposed to. There isn’t any press allowed, and no contractors trying to profit from your misfortune (I’m the world’s worst salesman).
Notice the need in there? Each government agency is siloed into their own little information security management world and there isn’t really a community of peers among the practitioners. That’s the niche that the FISMA Fellows program is addressing.
Secretly (Maybe not so secretly because it’s now public knowledge), I love it when people come to my classes and then go back to their agency where they become the “this is how you do it right” gadfly. From time to time I wonder how many people hate me, even though they haven’t met me, simply because I taught their employees how to be a royal PITA. The smart ones don’t hate me–they keep sending more people to be trained.
Similar Posts:
Posted in FISMA, NIST, Risk Management, Speaking, Technical | No Comments »
Posted April 3rd, 2007 by
rybolov
It’s a little-known secret that will get out fairly quickly: I hate security policy. I hate writing it. I hate having to live with other people’s security policy that is just a rehash of the NIST guidance in new packaging.
In light of this, I’m offering up to the world “Mike’s Guide to Information Security Policy”.
First, policy only works when it’s grounded in reality. That’s why, just like Ludwig Mies van der Rohe, I believe that “less is more”. Something big and theoretical is OK, but what the server team manager needs is a “how-to” process and checklist for firing an employee without creating an incident.
My policy framework looks roughly like this:
- Overview: We like information, it helps us do our job. The CISO is responsible for creating policy. Senior Management signs the policy.
- Risk Management: We will make cost/benefit/risk comparisons.
The rest is details, and it’s easy to have a skeleton for each control family from whatever framework you want–PCI, 800-53, SoX, 7799, etc. I use 2 frameworks: 800-53 and ITIL, although sometimes I run into other areas that are normally QA. I’m not the ITIL policy person, but I realize that if I want to succeed at the information security approval at the Change Control board, I need a Technical Review Board and an Engineering Review Board. That keeps me from denying changes at the last minute because if I do that, I hurt the business end. I would rather shape the change further upstream so that it becomes easy to approve at the end of the process.
My rule of thumb on policy is that if I have to make a decision on something 3 times, then it needs to be written down in a policy because there are more people that need to ask but haven’t.
Similar Posts:
Posted in FISMA, NIST, Rants, What Works | No Comments »
Posted March 23rd, 2007 by
rybolov
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.
Similar Posts:
Posted in FISMA, NIST, Risk Management, Technical, What Works | No Comments »
Posted March 23rd, 2007 by
rybolov
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.
Similar Posts:
Posted in FISMA, NIST, What Works | No Comments »
Posted March 15th, 2007 by
rybolov
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.
Similar Posts:
Posted in FISMA, NIST, Risk Management, What Works | No Comments »
Posted March 9th, 2007 by
rybolov
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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- (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.
Similar Posts:
Posted in FISMA, NIST, Outsourcing, What Works | No Comments »