Power Outages Do Happen

Posted July 10th, 2007 by

Finally had one today. It was great. The generators kicked on. The building-wide UPS worked. The NOC and SOC still had power. The other working areas ran out of AC, power, and people before I got there.  No problem, the engineers can go elsewhere to work as long as the operations people still have what they need.

Before you ask, no I didn’t create the problem as a BOFH DR test, and the outage did not occur immediately after a line like “so, what does this big, shiny, red button labeled ‘EPO’ really do?”.  =)



Similar Posts:

Posted in Risk Management, The Guerilla CISO | 5 Comments »

Another Day, Another Vendor

Posted July 10th, 2007 by

So I got “roped into” another vendor presentation yesterday. I should have done a little bit of research beforehand because then I would know that the product they pitch is Yet Another Technical Policy Compliance Tool (YATPCT)(tm) and I could have safely skipped it.

From my standpoint, this market is getting crowded, but the nature of the beast is that it’s low sales volume but high cost. Ie, it’s a market that will forever be make-or-break. Not a good place to be as a vendor, and I have a feeling that the majority of them will die a horrendous death but to the business leadership one sale looks pretty good.

One thing that I did see is that the typical YATPCT has now evolved. Most of them have incorporated workflow now so they’re aiming for “security team in a box”.

Now for people who know what they are doing, the people that I refer to as “clueful”, these tools are pretty good at keeping you on track. The problem is that there is a shortage of clueful people, so they’re buying tools to compensate for the lack of skill. The end result of this game is that you end up broke with no adequate security–not exactly what I would call “effective security”.

One of these days I’ll find a vendor who “gets it” and is worth my time to teach them how to do the last 5% of what they need to work for me. God knows I’ve taken hours to explain it to anyone that wanted to hear. This is what I want to see:

  • Grouping assets together
  • Determining a criticality for the group based on the Business Reference Model (SP 800-60)
  • Yes, a baseline of controls from 800-53 but the ability to add my own controls and do tailoring because I have to distill the control into an exact requirement that people can build to
  • The ability to extract a complete System Security Plan to hand to an auditor
  • An engine to build a test plan and record results
  • Workflow for Plan of Action and Milestones so I can get funding from Congress and actually get things fixed. Exhibit 300 format would be highly superb.

The problem is that a tool adds to the effort involved, not detracts from it–you still have to use the thing in addition to all the people-power. If you still need the people with the wetware to use the tool, what has the tool effectively saved you? Probably not much. In fact, I ask the basic question: what does automation really provide for something that is perpetually a one-off system? You only get efficiency when you optimize the parts of a process that are repeated–ask any programmer about it. Yet at the same time, if you have a set of systems that habitually have a large amount of shared controls between them, why aren’t they lumped together into the same system already?

In the meantime, all I see are SoX technical compliance solutions kluged into FISMA compliance solutions. We think differently here inside the beltway. I don’t assign dollar values to individual servers, and I don’t care about ALE calculations. To be bluntfully honest, I don’t really care about compliance, I care about risk management (both security risk and project risk), so at the end of this exercise, no matter what the scope of it is, I want to know what the residual risk is and if we should do one of the following:

  • Leave it as-is
  • Pump more money into it
  • Kill it or at least investigate feasible alternatives
  • Beat people about the head with the giant foam cluebat until they fix a small subset of problems
  • Fire the staff
  • Fire the evaluation staff
  • Go fishing (trick answer, I was going to do that anyway) =)


Similar Posts:

Posted in FISMA, NIST, Risk Management | 5 Comments »

Open Letter to New Security Manager

Posted June 27th, 2007 by

Let me be one of the first to congratulate you. Whether your title is CISO, ISSO, Manager, or Consultant, being a security manager is an accomplishment.

Now for the bad news:   You need to go into the job knowing that you will always be short on people, time, and money.  Good people are hard to come by, and as soon as you get them trained up, they’ll change jobs because they outgrew what you hired them to do.  Time is critical because effective security requires cooperation with all the other business disciplines which takes time and effort.  Security is seen as a cost center, so any good business will try to limit security spending in order to maximize their profit.

My friends at ISM-Community have developed an Information Security Management Top 10 document with some very solid practical advice for how to survive in today’s security environment.  Think of it as a list of meta-themes that all successful security managers and programs have in common.

The ISM Top 10 doesn’t solve all of your people, time, and money problems, but it can help you to recognize trends and set a long-term strategy to winning.



Similar Posts:

Posted in ISM-Community, Risk Management, What Works | 2 Comments »

The Long Tail and Security Posture

Posted June 26th, 2007 by

If you haven’t heard of The Long Tail by now, you’re either not a student of Web x.0, only read the mainstream mass media, or you live under a rock. Or all 3. I was going to do some “esspraining”, but wikipedia does it way better than I can.

Here, this is the picture from Wikipedia:

The Long Tail, Picture by Hay Kranen/PD

In this picture, the part in green represents the high-demand, high-sales products/services and the yellow represents “The Long Tail” or low-demand, low-sales products/services that actually constitute the majority of sales. So in other words, if you’re a Netflix, you rent more movies simply by having all the obscure titles that a brick-and-mortar video store can’t afford the shelf space for.

This concept has also been used to explain blogs, where blogs represent The Long Tail and are free to talk about the niche subjects that the mainstream mass media ignores because the mainstreamers are constrained by time and applicability to their readership.

As with just about everything I write, by now you’re thinking “What does this have to do with information security?” Yes, I hear this quite a bit, so don’t be worried if it’s not immediately transparent.

Imagine the same drawring with “Level of Effort” (LOE) as the X-Axis and “Return on Investment” (ROI) (what I really want to say is “payoff” but I’m trying to be pseudo-scientific, so humor me) as the Y-Axis. It would look something like this:

The Long Tail as Risk Management

Anything that is green represents “high-payoff activities” or “common sense security”–the easy controls that provide a high level of security or other benefits. In this group, we have change control, automated patching, and testing backup tapes. You probably have a handful of similar controls that come to mind.

Anything in yellow represents “excessive spending” or “you must be out of your mind”. In other words, the amount of resources that you would have to expend to build the control outweigh the benefits that you would get.

But there’s one catch: what we are trying to do in deciding if/how to implement a security control is to make a decision based on cost, benefit, and risk. We have cost and benefit, how do we account for risk?

If you take a look at where the division is between green and yellow, that line represents what we would call “acceptable risk”–it’s a sliding scale along the X-Axis.  Where that tipping point lies depends on the nature of the system, the mission that it supports, and the types of data that it stores, processes, or forwards.

For high-critical systems, you move the line to the right and you actually become more inefficient at the types of security controls that you build–you’re into The Long Tail for all it’s worth.

But for low-criticality systems, all you really have to focus on is the high-payoff activities because your level of acceptable risk is lower.

Now when you’re in a compliance information security management model, what’s happening is somebody is setting that level of acceptable risk for you. I think this is the reason that there is such a backlash on most compliance frameworks. What is low LOE for somebody else might be high LOE for me because of the technology I have in play or due to other externalities, and if you hold me to that pre-determined level of risk acceptance, then I’m back to spending inefficiently.  As a business, I hate it when people tell me to spend inefficiently “for my own good”.

What do I expect you to do with this model? Not much, I ‘m just building on the ideas from Jacquith, Earl Crane, and other people that I know. I just figured it would help somebody explain acceptable risk and compliance in a format that was easier to understand.



Similar Posts:

Posted in Risk Management | 5 Comments »

My Analysis of the DHS Congressional Testimony

Posted June 25th, 2007 by

Disclaimer up front: I’ve worked with DHS as a contractor. I have friends in DHS. I have DHS as a client agency. I’ve felt some of their growing pains. I’m also a taxpayer and a wannabe civil libertarian when it suits me. =)

Background: Last week, Scott Charbo, DHS CIO, was given a pretty good grilling by the House Committee on Homeland Security. Responses have ranged anywhere from apathy to outrage, with the mainstream media wondering why DHS is doing so poorly at security of their systems.

The testimony is online at the following url: http://homeland.house.gov/hearings/index.asp?ID=65

First of all, at the bottom there is a link that takes you to the movie. You have to watch this before you read the transcripts. Caution: this is a good 1.5 hours of viewing. http://boss.streamos.com/wmedia/homeland/chs/cyberjune.wvx

My first comment is something along the lines of what the public is saying. If you’re responsibly for cybersecurity (not my preferred title, btw) for the nation, how can you honestly stand in front of us as the Government’s cybersecurity leader when you’re failing at securing your own house?

Scott Charbo gave an excellent answer, one that the public needs to seriously think about. There are 2 information security groups inside DHS. One is the Assistant Secretary for Cybersecurity and Telecommunications who works with the rest of the government and industry to help secure the infrastructure. The other is the DHS Chief Information Security Officer who works under the CIO to security DHS-internal systems. What this means is that the 2 topics are divorced both on an organizational chart and in funding sources. It’s still a PR problem, but there is a specific reason why this problem exists.

The Q&A Session Led by Chairman Langevin:

  • Titan Rain–Everybody doing IT in the government should know about Titan Rain. As a CIO to say that you haven’t heard about it, it’s a red flag. This doesn’t bode well for the agency that has been charged with cybersecurity for the rest of the agencies.
  • Ingress and Egress filtering on workstations–This is usually too noisy, so what you do is filtering on the aggregate data flow from multiple machines. Otherwise, you end up with a NMCI problem where every workstation had a HID on it. It’s expensive and probably rates lower on the scale of priorities than other security spending. Maybe in the future when endpoint security is an all-in-one, it will make much more sense, and the technology is starting to get to that point.
  • Nationwide Risk Assessment–yes, it’s a fantastic idea. The question is, how do you eat this elephant? Really it takes an ongoing campaign of assessing individual parts (bite-sized pieces, pun intended) and then addressing and prioritizing them as a whole. Some of that is taken care of ala GAO reporting. Some of that (SCADA systems, commercial telecoms, anything we have a dependency on) needs to be discovered and assessed. You have to be careful when trying to boil the ocean.
  • Classified Spillage–it’s one of the “dirty little secrets” (pun intended) of the classified world. Short of context-filtering on the non-classified side (cheap pitch for Verdasys here), there is nothing that you can do technically to prevent a user from manually typing classified data into a non-classified system. But then again, you can’t prevent a user from talking about classified data on a metro train.
  • Contractor Laptops–note to self: if you are testifying in front of congress, never answer a question with only a “No.” Are contractors plugging into government IT systems? Yes, and DHS isn’t the only one. It depends on the facility. If you go into a classified facility, then plugging into a classified network is bad. If you go into a development environment to upload code that you built on your laptop, then most people would say that’s OK. Somewhere in there is a spectrum of activity that needs to be decided on whether it’s allowed or not.
  • Budgeting–The role of CIO pretty much is in an advisory role when it comes to budget. Inside DHS (and all the other agencies), Congress manages the budget down to the sub-agency level. Mr Charbo can request funds (and if he got the message, he should request more security funding next year), but holding him responsible for the budget that is given to him by Congress hardly seems fair or really what I would call responsible governing. However, a good point was made by Mr Etheridge about the fact that DHS is a very young organizations and that they most likely need to be spending more than the average on security. But then again, they are spending quite a bit of money on building IT systems, so a smaller percentage is to be expected (ie, the size of the pot got bigger, so you have a smaller percent of that pot).
  • Auditing Telcos–You cannot audit the carrier clouds. You use compensating controls to limit your risk. I’ve talked about this before. However, why is the telco managing the agency’s firewall? It sounds like somebody was doing routing on the firewall or doing some kind of logical segregation on their switches (ie, untrusted and trusted on the same switch using VLANs), which shouldn’t be happening for your main edge. Here, GAO is pointing at one system where they were allowed to audit a MPLS cloud and saying that they should be able to audit a DHS MPLS cloud. It just doesn’t work that way. You might be able to do a partial edit or you pay the vendor more to implement specific controls that you need, but that’s the extent of it.
  • Einstein–Link for those of you who are interested, and a blog post from Richard Bejtlich about it. It’s a monitoring system used by quite a few agencies.
  • Interconnectivity Between Classified and Non-Classified Systems: GAO points to the fact that DHS did not have a valid system inventory or established interconnects. While I agree with some of the concept, I guess I just don’t like the presentation layer of that statement, like we’re confusing security and compliance again.

I still contend that if another agency the size of DHS is not reporting as many incidents as DHS is, then they’re either not monitoring or they don’t have the same criteria as to what an incident is. I think DHS got banged on first because they provided transparency and fairly valid metrics on what is going on with their networks. Playing the role of “Armchair CIO”, I would turn it back on the other agencies and ask why they didn’t have the same level of incidents to report.

I give DHS quite a bit of credit for avoiding the urge to present a “zero defects” picture to GAO, OMB, Congress, and the public.

Best quote of the day is from Keith A. Rhodes who is the Chief Technologist and Director of the Center for Technology and Engineering at the Government Accountability Office.

“The risk assessment that you’re talking about, risk is a function of threat, vulnerability, and impact, so all three pieces have to be done. Yes, there has to be a threat assessment. There also has to be a realization of vulnerability, and there has to be an understanding of impact. No one, certainly not I, certainly not my colleague, Mr Wilshusen, is going to say ‘Secure everything, lock everything down.’ That’s impossible. It’s also impossible to have perfect security, but we have to drive toward zero tolerance on key systems.”

By this time, you’re all thinking “What will it take to get DHS to winning in IT security?”

There are some people who believe that DHS will never make it. “It’s too large, the Department is too new.”

Realistically, I think the earliest realistic timeframe for DHS is 5-10 years and 3 CIOs down the road. Scott Charbo will build as much as he can until he meets serious resistance, then it’s time to bring in a new face to push the ball forward just because the newness can get things done.

Once again leading me to my point that security is all about personnel management.

While DHS has overcome quite a few hurdles, I think it’s amazing that they managed to score any more than an “F”.

What I didn’t hear in this hearing is something along the lines of “Mr Chairman, we only have a limited amount of personnel, time, and budget. As an agency, we are forced to make decisions on what is more important to us: to migrate all the organizational elements to OneNet and build a NOC, SOC, and redundant data centers, or to maintain legacy major applications and put HIDs on all of our workstations. While you might disagree somewhat with our priorities, I doubt that anybody would chose a path that is radically different from where we have gone and are going.” That’s the message that the country needs to hear in order to understand the conflicts between operations, budget, and security that today’s CIO has to manage, and why the indicators at times might provide the impression that the government is not concerned about security.

But then again, I’m a little bit more confrontational because I can afford to be, not being in charge of the IT assets for a huge agency. =)



Similar Posts:

Posted in FISMA, Risk Management | 2 Comments »

Call for Volunteers

Posted June 21st, 2007 by

I’m once again the pusher for the ISM-Community Risk Assessment Methodology and I’m looking for a few good geeks.

I figured I would send out the call here, too, since if I don’t advertise enough for volunteers, the whole thing falls on my shoulders. =)



Similar Posts:

Posted in ISM-Community, Risk Management, What Works | No Comments »

« Previous Entries Next Entries »


Visitor Geolocationing Widget: