In, short, an organization can build its “gold image” desktop, with all necessary apps, and run the automatic rule creator to identify all the applications that will be on the whitelist of things that can run on the desktop. If you are mature enough to have a real good “gold image”, that shouldn’t be very hard to do.

The issue that I can see is with patches and updates. However, the automatic rule creation can work with the Publisher information when the binaries are signed, making it easier to accept new versions for those files. I think I’ll try that in a lab to see how effective that is.

Another interesting thing is that you can enable it in a “Audit only” mode. I have a personal view for whitelist based controls that is deploying them to generate logs only and monitor using a SIEM or similar system. On that way the risk to disrupt the environment is reduced and the exception can be managed on two levels (changing the whitelist, ignoring speficic alerts from the controls). It is one of the best ways to do security without breaking everything and also getting more value from a SIEM deployment. Be aware, however, that the SIEM system alone will not perform any miracles, this concept can only work when you have people and processes in place to deal with the generated alerts and to constantly tune the rules. That’s the price to pay for more flexible security.

Even if the initial SQL injection was in a SSL connection (my assumption is there was no initial reaction due to lack of detection), the rest of the attack should still be easy to detect. What are these companies doing about network security monitoring and intrusion detection? Seems to me that this is a point where current PCI-DSS requirements might not be sufficient. Requirements 10, 11.4 and 11.5 are good candidates to be improved.

I like to say that SIEMs are for security what ERP systems are for enterprise management. There is a huge value on deploying those systems, but you need to be aware that the implementation process is not easy, it takes time and requires a lot of commitment from the organization. It’s not just “pay software, pay hardware, a bunch of consultants, done”. Most of the times you need to create or adapt a lot of process to start working with the new tool. You need to understand the data that you will be working with. Just like for ERPs, when you need to have total control over how your books work in order to automate and improve them, you also need to understand how your network and systems work in order to get any value from SIEMs.

IDSes suffered a lot when they were deployed without the necessary services and (right) people to manage and operate them. SIEMs are not different on this aspect, and they may be even more sensitive about it, because they rely on receiving data from lots of different sources. If those who are responsible for those sources are not in the same boat as you and are not aware of the value of the tool, they have the power to make that SIEM a nightmare to manage. In order to get some value from SIEMs, you need to be able to get the data from the systems you identify as necessary and keep that data flowing! How many places you know where the biggest SIEM related activity is troubleshooting why the logs are not coming? If you cannot feed the beast, it won’t fly.

Mike also mentioned, again, the need to REACT FASTER (have I said how nice his “Pragmatic CSO” stuff is?) and linked it to the application security world. As I’m working a lot with log management these days I noticed that I’m not seeing people talking about what to do with their Web and application server logs. A lot of attacks against web applications can be identified in the logs, and yet we don’t see people collecting and analyzing them. Is there anybody out there with good results on “web log” correlation? I’d like to see how evolved this is and how can it help as an early warning system for attacks against web applications.

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?

Well, I’m an old advocate of analyzing outbound traffic to detect suspect behaviour. Mogull mentions DLP tools and Rothman reminds us about netflow.

They are all valid options and they are quite right on their opinions. I just want to add some thoughts on how to deploy those technologies in a way that they can really do the job. By mentioning specific technologies we may reinforce the perception that tools can solve the problem. Again, that’s not about the tools. This is about monitoring. You should have something (i.e. a process) in place to monitor your outbound traffic and also an understanding of what should be flowing from and to each part of your network. If we think about Heartland, hey, there was a communication from cardholder data environment (PCI lingo) to a highly suspect network location (sorry Russia), should it really be allowed? If yes, wasn’t it something so different from standard flows that would be easily spotted by a anomaly detection system?

(by the way, cardholder data is a very good example of a case where honeytokens can be deployed.)

Organizations should start thinking more seriously about security monitoring. Today it is basically done with IDSes, Antimalware (AV, etc) and basic event correlation rules (basic = almost stupid), things that will trigger an alert if something bad is spotted. They should also invest on having people looking at uncommon stuff, like unusual destinations, protocols and traffic volumes. You can easily detect (and block) some bad stuff by the old methods, but you need to go forward if you want to detect more dangerous stuff, elaborated and targeted attacks.

Good places to start thinking about how to do that: Argus, Netwitness, Arbor, Richard Bejtlich books and blog. Maybe it’s time to have some “Network security monitoring analysts” working and producing network security intelligence.

Now it’s just a matter of time for the first worms and bots. I’m already seeing some emergency patch management processes being fired to deal with that, but it’s important to ensure that detection and reaction capabilities are also up-to-date. Keep an eye on the sources for IDS signatures and be sure to check if your SIEM/Log analysis systems are able to identify abnormal traffic related to the Server service (139/445 TCP). Do a quick review of your incident management procedures to ensure that people will know what to do if the bell rings. For instance, if you catch signs of infection in your internal network, how will you act to identify and clean the infected computers?

May the Force be with you!

Have anybody tried to integrate DLP and/or e-Discovery products with NAC? Can you imagine the possibilities? You can build a policy where workstations with protected/sensitive information stored have their connectivity restricted to reduce the chances of data loss. Your computer is free from protected information, you can browse the Internet with more freedom than that guy with sensitive files in his hard disk. I wonder if anyone from Symantec is trying to do that with Vontu and their Endpoint Protection suite.

There are so many low hanging fruits that someone that is completely unaware of vulnerabilities and attack techniques from the past 5 years will still be able to do a lot of bad stuff on a ‘vanilla’ corporate network.

Ask yourself these 5 questions. If you can’t say yes to all of them, don’t sign the check for that new-miracle-black-box you are buying and do your homework to fix the basics:

• Can you promptly identify someone guessing passwords for administrative accounts on all your servers?
• Can you say for sure that there are no weak passwords for all administrative accounts on all your servers?
• Can you say for sure that you don’t have a user/password on a test box that also exists on a production server?
• Can you say for sure that there are no shared folders on your servers with sensitive information and weak permissions settings?
• Do you know who knows the password for (and use) the root or Administrator account?

Maybe after that you can start thinking about some cool stuff from Black Hat