Having spent eight years of my life at LogMatrix (which had been called OpenService until it was renamed in 2009) helping develop its security business, I am glad to see it in the hands of the fast-growing NitroSecurity.
We brought to market several innovative concepts to improve the effectiveness of SIEM solutions including a risk-based quantitative algorithm that worked on both network and application logs, and a user-based behavioral anomaly algorithm.
I wish my friends at LogMatrix who moved over to NitroSecurity all the best.
Excellent summary of Stuxnet. Separates facts from conjecture. Points out some of the erroneous descriptions you may have read, e.g. SCADA is incorrect.
Block .LNK and .PIF files coming from the Internet to a private network
Disable RPC application traffic from the Internet to a private network
Deploy vulnerability protection profiles using the specific Palo Alto vulnerability signatures they developed to detect all four of the Windows vulnerabilities Stuxnet exploits.
This week Palo Alto Networks is releasing two new signatures which protect against the last of the four vulnerabilities, CVE-2010-2772. Microsoft does not have a patch for this one yet.
What the sophistication of Stuxnet shows is a level of professionalism and seriousness that normally is attributed to governments and their intelligence agencies. They have the motive, the means and the opportunity to create a piece of malware of the magnitude of Stuxnet and pinning this on the government of Israel is perhaps a logical conclusion, given some of the evidence. There’s a hidden reference in the worm’s code to a date on which an Iranian Jew was executed, as well as some vague Biblical connections. Iran and Israel have a hostile, complicated history, and Israel also is thought to have elite offensive information security capabilities. And Iran had a huge number of Stuxnet infections, including at its Bushehr nuclear plant, which Israel presumably has a vested interest in damaging. Add that all together and you get a seemingly solid case for Israel having unleashed Stuxnet on Iran.
However:
There are no clear benefits that would accrue to Stuxnet’s creators if they made it easy for people to identify them. In fact, there are some major deterrents, including possible retaliation from the target.
In other words, if the Israelis were smart enough to build Stuxnet, why would they be so stupid as to leave clues that lead directly back to them?
Going forward I am going to avoid any posts tied to politics.
London: A cheap mobile phone application that can track the precise location of passenger aircraft in the sky can be a serious terrorist threat, security experts have claimed and called for its immediate ban.
The Plane Finder AR application, developed by a British firm for the Apple iPhone and Google’s Android, allows users to point their phone at the sky and see the position, height and speed of nearby aircraft.
The new application works by intercepting the so-called Automatic Dependent Surveillance-Broadcasts (ADS-B) transmitted by most passenger aircraft to a new satellite tracking system that supplements or, in some countries, replaces radar.
Apparently the ADS-B transmits all this information in clear text. If this information can be used to aid terrorists, why is it not encrypted? Don’t blame the developer. Blame the people who built the ADS-B system!!
Dark Reading recently published an article about the problems that plague Security Information and Event Management deployments, Five Reasons SIEM Deployments Fail. First, I would say that you could use these five reasons to explain why almost any “enterprise” information technology project fails. Having said that, I would like to address each of the five points individually:
1. SIEM is too hard to use.
The nut of it really comes down to the fact that SIEM is not an easy technology to use. Part of that rests squarely at the feet of SIEM vendors, who still have not done enough to simplify their products — particularly for small and midsize enterprises, says Mike Rothman, analyst and president of Securosis.
There is no doubt that some SIEM products are harder than others to use. Ease-of-use must surely be one of the criteria you use when evaluating SIEM solutions. On the other hand, too hard to use may be code for not having the resources needed to deploy and operate a SIEM solution. For those organizations, there is an alternative to buying a SIEM solution. Use a Managed Security Service Provider (MSSP) to provide the service. This is a particularly appropriate approach for small and midsize enterprises.
“I think that we need to see more of a set of deployment models [that] make it easier for folks that aren’t necessarily experts on this stuff to use it. In order for this market to continue to grow and to continue to drive value to customers, it has to be easier to use, and it has to be much more applicable to the midmarket customer,” Rothman says. “Right now the technology is still way too complicated for that.”
There is an alternate deployment model which Mike seems to be ignoring. Incident detection and response is complicated. If you don’t have skilled resources or the budget to hire and train people, you need to go with a MSSP. A good MSSP will have multiple deployment models to support different customer needs.
A more correct statement might be that an organization has to decide whether it has the resources to select, deploy, and operate a SIEM.
2. Log management lacks standardization.
In order to truly automate the collection of data from different devices and automate the parsing of all that data, organizations need standardization within their logged events, says Scott Crawford, analyst for Enterprise Management Associates. “This is one of the biggest issues of event management,” Crawford says. “A whole range of point products can produce a very wide variety of ways to characterize events.”
There is no doubt that there is no standardization in logs. That’s like saying there is no standardization in operating systems, firewalls, or any of the other products for which you need to collect logs. Even if there were to be a standard, there would still be ways for manufacturers to differentiate themselves. Just take a look at SNMP. It represents one of the most used industry standards. Yet manufacturers always add proprietary functions for which systems management products must account. So logs may get somewhat more standardized if, for example, Mitre’s CEE were to become a standard. But the SIEM manufacturers and MSSPs will always be dealing with integrating custom logs.
3. IT can’t rise above organizational power struggles.
“One of the key challenges our customers face is really getting all parts of the company to work together to actually make the connections to get the right scope of monitoring,” says Joe Gottlieb, president and CEO of SenSage. “And the things you want to monitor sit in different places within the organization and are controlled by different parts of the organization.”
Yes, by definition SIEM cuts across departmental lines when the goal is to provide organization-wide security posture and incident visibility. As with most “enterprise” solutions, you need senior management support in order to have any hope of success.
4. Security managers see SIEM as magic.
SIEM expectations frequently don’t jibe with reality because many IT managers believe SIEM is about as powerful as Merlin’s wand.
“A lot of people look at SIEM like it’s this magical box — I get a SIEM and it’s going to do all my work for me,” says Eric Knapp, vice president of technology marketing for NitroSecurity. “SIEM has different levels of ease of use, but they all come back to looking at information and drawing conclusions. Unless you’re looking at it in the correct context for your specific environment, it’s not going to help you as much as it should.”
SIEM has been around for ten years now. Is it really possible that SIEM still has some kind of magical mystique about it? SIEM vendors that let their sales people sell this way don’t last because the resources the vendor has to commit to alleviate customer dissatisfaction is huge and profit-sapping. On the other hand, caveat emptor. Any organization buying SIEM without understanding how it works and what resources they need to make it successful, have only themselves to blame. Again, if you are not sure what you are getting yourself into, consider a MSSP as an alternative buying a SIEM solution.
5. Scalability nightmares continue to reign.
There is no doubt that scalability is a particularly important attribute of a SIEM solution. And there are SIEM products out there that do not scale well. If the vendor tells you, (1) We store log data in a traditional relational database, or (2) You only need to save the “relevant” logs, RUN. These statements are sure signs of lack of scalability. On the other hand, you do need to know or estimate how many events per second and per day you will actually generate in order to configure the underlying hardware to get reasonable performance.
There are SIEM solutions that do scale well. They don’t use traditional relational databases to store log data. As to which log events are unimportant? It’s practically impossible to determine. If you are in doubt, there is no doubt. Collect them.
One of the lesser known facts about Stuxnet is that it used two stolen digital certificates to bypass anti-malware systems.
“…many antimalware products and other security applications will whitelist binaries and files that are digitally signed. These components are simply trusted and passed along in most cases. The creators of Stuxnet obviously knew this and used it to their advantage. In the wake of the Stuxnet attack, security experts said that they expected other malware authors to follow the lead of Stuxnet and begin using digial signatures to evade security software, and that prediction is already being fulfilled.“
Now that there is a new version of Zeus that’s digitally signed, it’s clear that digitally signed binaries can no longer be trusted. Will digital certificate black lists be added to anti-malware products?
Via Lenny Zelster, Richard Bejtlich, a well known Computer Incident Response Team (CIRT) person has an interesting view of IT Security pictured here:
What is normally considered the major functions of IT Security, are simply the first two phases of Bejtlich’s Incident Response cycle – Plan and Resist.
Note the use of the word, “Resist” rather than “Prevent,” thus forcing the recognition that incidents will happen. In other words, if you are not detecting incidents, it’s because you don’t have the right tools in place.
Well worth reading the whole post. Also there is a link to the Bejtlich’s complete presentation.
