As everybody in the field had predicted, malware targetting SCADA system has finally come true. The lucky thing is this one is looking for information to steal only, not actually doing anything. I wonder what outcome could we have if this nasty little thing was designed to force systems to fail.

SCADA systems are one of the most critical blind spots in organizations Today. Few people have access to then and know how they work, so there is a false perception of security about them. Specialized systems, such as SCADA and ATMs, often rely on obscurity as their main security strategy. It’s not even something done intentionally, but as result of a neverending vicious cycle. Internal security resources don’t know about security on those systems and the specialists in that technology don’t understand security. You can think about hiring external consultants to check the systems, but the consultants also don’t have much contact with that technology. Of course they won’t tell you that, they will run their off-the-shelf tools anyway. The results will tell you nothing, what you will interpret as “secure”, perpetuating the notion that there are no security issues with that technology. As there are no security concerns there, the security team won’t spend time learning that technology and the specialists will keep saying that this security thing is for those Internet-web-2.0-cloud-stuff guys. Until the next Black Hat briefings or sexy malware.

I wonder when this is going to hit the old mainframe. I must say it will be fun to watch.

I can see two reasons why they are still not doing that:

• The malware developers are not closely related to the “money criminals” – They are building software to be used by different “clients”, and the best way to implement that portability is to sell credentials only.
• Stealing credentials just work and can be used multiple times, and people just understand the model.

If any of those conditions change, more sophisticated versions of the attack will probably start to detected too. By now, it is important to note that fighting the “stolen credentials” threat doesn’t necessarily mean you are also solving the MitB threat. For that, transaction authentication is necessary.

But you know what? I think that my current depressed state has changed my way of thinking about security (or changing my way of thinking about security is making me depressed…). I agree with him that the source of the problems is bad security from the deep of the systems we rely on Today, bad (or no) security design in general. But I just think this is a problem we cannot solve. We can see the same issue on several other disciplines, old design and decisions being perpetuated in a way that causes issues to current stuff. However, revolutionary approaches are not (or are almost never) possible due to the way that economy and society works. The technology evolution is also so fast that it would require too many revolutionary processes to solve the recurrent problem of old decisions based on premises no longer valid causing problems to the current state. We simply cannot afford burning everything to ground and start fresh again. All these things are competing for resources and it would be naive to believe we could just choose to build everything with the perfect design.

Gunnar uses the example of the Chicago reconstruction after the great fire. I think it is a great example, but it doesn’t fit exactly his intention. It shows that once something out of your control happens and puts everything to the ground, you have the choice to start fresh and with a better design. Now, how many times have you got the opportunity to start something from scratch in IT? Hey, wouldn’t it be nice to build an OS with no backward compatibility concerns? Ask Microsoft if they don’t dream with that every night!

Gunnar is asking for something right that is just not practical. Maybe I’m being too cynic and conformist, and I believe we need people who push us to take those revolutionary roads, but when someone does that is usually the exception and not the norm. Those who are dealing with real life issues need to be pragmatic. Yes, we need to protect our straw houses.

What I think is more important from Gunnar’s post is this line:

“The boring stuff is what’s important”

That’s different from trying to re-design everything. There are lot’s of boring stuff that we need to do to protect the straw house My first and main example is access control. IMHO there isn’t anything more boring in Infosec than Access Control – access reviews, entitlement reporting, fire IDs, privileged accounts tracking, wow, those things kill me. But I must say that doing those things properly will probably reduce a lot more risk than buying the last pretty-pizza-box-with-blinking-lights. The problem will be finding smart people who enjoy that enough to that properly.

 Today’s biggest challenge in Information Security is to find smart people willing to work with boring stuff.

That’s my last line from my “back to blogging post”. Wow, I’ve just noticed how much I miss doing. Ok, I’m back

It is, and I’m trying to see how these two different approaches can co-exist. One option, and can see how cool that could become, is to create that big standard as a framework that would allow different implementations of the same process, but all following specifications for inputs and outputs. That would create a big standard with “sub-standard plugins”, suggested implementations for specific processes. Each of those plugins would consider information from those threat modeling components I mentioned before, in a way that you could choose an implementation of a process that is more aligned to your organization profile, technology and characteristics.

That would avoid excessive standardization and also ensure that the basic necessary processes are in place. Now the two posts are not that incompatible anymore and I can go to sleep without that bugging me

Honestly, I remember when I first read that 2006 article from Donn Parker that I was somewhat disapointed by his suggestion of doing things based on compliance. It was the old security sin “checklist based security”. All the recent discussions about PCI DSS are great sources of opinions and insights about the subject, and I’m seeing that there’s an overall perception from the security industry that it end up being good for security. Is the checklist based security working?

If PCI DSS is working, it’s certainly not because of those approaching it with a checklist based mind. It is because it is a quite good prescriptive standard. It is clear about what the organizations need to do. But is has limitations.

PCI DSS has a very clear goal, to protect card and cardholder data. The standard allows a quick and dirty approach for those that don’t want to bother with all those requirements. Reducing scope. Think about all those requirements about wireless networks. You have two choices, doing everything required by the standard or removing that network from the scope. With PCI, as long as you can prove that the cardholder data environment is protected, the rest can be hell, it doesn’t matter, you are good to go. Is it wrong? Well, the standard has a clear goal and it makes sense to define the scope around it, but it is kind of naive on assuming that it’s possible to isolate network environments inside the same organization without considering that the payment process (that uses card data) is usually very close to other core business processes. So, PCI DSS is a good standard but it is limited for overall information security purposes.

With this in mind, one could say that creating a “generic PCI DSS” would be the solution for risk-less security. I think it is part of the solution, for sure. The problem is that the scope for that standard is considerably bigger, in a way that it would have to include some less prescriptive requirements. Is there a way of doing that without creating a new ISO27002? Don’t get me wrong, I think ISO27002 is a great standard, but it is so open to interpretation that it can almost any beast can become a certified ISMS. Also, it has on its base the risk management process, that is exactly what we are trying to avoid. The new standard would have to include requirements to solve one of the biggest challenges on information security: prioritization.

Prioritization is the achilles heel of any attempt of doing security without risk management. After all, everybody knows that we cannot protect everything and during the long implementation phases the bigger pains need to be addressed first. How can we do that without using that wizardry to “guess-timate risks”?

My take is that it should be done based on two sources of information: benchmarking and threat modeling. Threat models can be generated based on geographic aspects, organization and business profiles, technology in use. Threats for banks in the same context (same country, for example) are probably very similar. Organizations using the same basic software package on its workstations will share the same threats for that technology too. We should also consider that a lot of the current threats organizations face are pervasive and ubiquotous, they affect almost any organization out there. Except for very few cases, malware issues are a common problem. Sure, the impact from malware issues will be different for each organization, but it seems to me that those characteristics will probably be those considered for many other threats too.

How would an organization “risk-less” work to define its security strategy and the controls to implement? Most important, how it would check its own security status? Is it ok? Should it spend more? What needs to be improved?

That’s where the fun is. And no, I don’t have those answers. But building the processes and tools to do that is definitely the most cool thing to do on this field.

If you look at the incident characteristics it’s easy to relate that only to multy-tenancy environments, but this can also be seen as a sign of higher impacts (and rewards to attackers) when leveraging components to multiple users, users being not only multiple organizations but also multiple applications, guest OSes, networks or anything else that can share a common resource base. Sharing an (elastic, on demand, whatever) common resource base is probably one of they concepts of cloud computing, so yes, we should connect that incident to cloud security. It’s not a “one to one” relationship, but it makes sense to look into the causes and effects of that fact under “cloud glasses” (WOW, I’ve just created a cloud-hype-term!). And that’s also why I think that Schneier is not completely wrong when he says that we have been there before. We have been sharing computing resources from some time, let’s look into the old stuff without prejudice and see what lessons learned at that time can be applied to the new context. I’m sure we can use a few.

Some interesting aspects that can be highlighted from this incident is how the security dependencies can sharply increase when you start to leverage cloud based services. Suddenly, the security of your data starts to depend not only on the security of the software and hardware that you own, but also on the security of software and hardware of the several service providers that are part of that offering. So, you are using Saas from X? Ok, and they are running their application over PaaS from Y, who operates over IaaS from Z. You are seeing X, but your security now depends on X, Y and Z. How can we do risk assessment for that?  I’m not saying that it’s god or bad, just that it has interesting implications about risk management and trust.

Yes Alan, cloud security matters and LxLabs is a very good example to use.

A lot of people will say that this is not true, as they’ve already completed successfully several assessments. For those I would ask, do you think that just by delivering a methodology you can ensure that the results would be the same for any other (competent) security professional? Until we can answer that with a sounding “YES”, I don’t think we’ve developed a good enough methodology for risk assessments. In short, I want to see a methodology that brings results that can used to:

• Compare the risk from different organizations (benchmarking!)
• Compare the risk for the same organization in different points of time
• Identify a comfortable level of risk that will be pursued by the implementation of security measures
• Identify the results of applying security measures (answering the basic question, “was it helpful/worth doing?”)
• Compare the risk from two or more different business processes, components or approaches
• Protect against “black swans” (this one is extremely hard)

It should also:

• Include “blind spots” from the organization into the risk calculation
• Consider the interdependency of different business and technology processes and components (how much risk are your production systems inheriting from your development systems?)
• Be resilient to the fact that almost all medium/big organizations have very high levels of uncertainty on the different variables usually necessary for a meaningful risk calculation

That’s not easy and most of the current methodologies cannot address all these issues. That’s the fun part in our job today, we need to find how to do it.

Until then they were including the controller location inside the bot code, so it was easy to find to identify it and block/take it down. Updates could be used to turn existing bots to a new controller, but new infections wouldn’t be able to find the original controller to get the updates. We predicted (and we really nailed it!) that pseudo-random algorithms would be the natural choice to avoid including URLs (or other location-type info) in the malware code.

The difference from our original work and what is happening today is that most botnet authors are implementing that to generate DNS names. The problem (for them) on that they create the need to register the names that will be created.  There are usually costs and a process to be followed to register new domain names, so I really don’t think they are being very effective. We envisioned that they would use one (or some) of those new applications like P2P protocols, Skype, and general Web 2.0 stuff that includes search capabilities to drop information from the controller to the bots anonymously on the web and just let them search for it. We presented a proof of concept based on Skype at that time. We went far enough to say that they could even eliminate the need for a centralized command and control host by directly dropping the commands to the bots instead of the C&C location. Digital signatures would be used to reduce the risk of someone hijacking their botnet.

Since then I’ve seen a lot of new possibilites to implement those concepts. Twitter, Wikipedia, Facebook, there are lots of new applications than can be used as reliable communication channels between the controller and his bots. There’s not doubt that botnet creators are skilled programmers, but I think they still lack some creativity on the design part. As we said on our 2007 preso, things are not half as nasty as they can be. I can see that in a very short time we may see botnets that have their C&C entirely “Cloud based”. Yet, we haven’t evolved at all in our detection capabilities. How should we react to new threats if they get a boost on design?

We need to start to think about how to design a next generation world-wide distributed monitoring solution, an “in the cloud behaviour anomaly intrusion detection system”. Is there anybody out there working on something like this?

I’ve got the tip for this very interesting Burton Group discussion from Anton Chuvakin’s post (who also has an overflowing ”2blog” queue .

There is a way to summarize that discussion. The key issue on deperimeterization is the control over the endpoint. If you are pushing the defenses to the endpoint, you better control it. So, if you are allowing endpoints that you don’t control to access your data, it’s not your data anymore.

Think for a moment, how a data-centric security approach would work? It would be something like agents that run on every endpoint or that go together with data, encapsulating it. Either way, it will run on the endpoint. If the user is controlling the endpoint ring-0 by having admin rights on the box, he will be able to modify/trick the security agent into doing things with the data that it shouldn’t be supposed to do. Now, quick answer, how can you avoid users from having admin rights over their own devices? You can’t!

Imagine that you have printed some very sensitive document in a very, very bleeding edge technology paper. It can’t be copied by any photocopy machine, and it will destroy the data on it if someone tries to put it through one of those machines. If you allow someone to get that paper to anywhere where you can’t see them, they will copy it like the XII century monks used to do it! 

So, what can be done to avoid it? First, the user can NEVER control the device. How can you avoid that if he owns it? Well, I don’t like it, but the only alternative is something like a very broad adoption of the TPM. However, I doubt that those devices will become popular, and if that happens also will be the ways to hack it.

The other alternative is not that cool, but I believe it’s closer to reality. Things will still be like what they are today. I mean, we’ll still have to put some restrictions over which devices can be used, we’ll still have to have some control over the physical and network environments, will still have to deal will ACCESS CONTROL. That’s not as sexy as virtualization, deperimeterization and any other ation, but it’s the root of information security. We’ll still have to choose carefully who can access the information and under which circunstances it will happen.

Did you really think that, with all these new variables, security would be that simple?