Research

As we previously mentioned, we will teach the very first CSA Cloud Computing Security Knowledge (Enhanced) class the Sunday before RSA. We finally have some more details and the registration link. The class costs $400 and include a voucher worth $295 to take the Cloud Computing Security Knowledge (CCSK) exam. We are working with the CSA and this is our test class to check out the material before it is sent to other training organizations. Basically, you get a full day of training with most of the Securosis team for $105. Not bad, unless you don’t like us. The class will be in Moscone and includes a mix of lecture and practical exercises. You can register online and we hope to see you there! (Yes, that means it’s a long week. I’ll buy anyone in the class their first beer to make up for it). Share:

I ran across Robin Harris’s analysis of the Hyder transaction database research project, and his subsequent analysis on how Microsoft could threaten Oracle in the data center on his ZDNet blog. Mr. Harris is raising the issue of disruption in the database market, a topic I have covered in my Dark Reading posts, but he is also pointing out how he thinks this could erode Oracle’s position in the data center. I think looking at Hyder and like databases as disruptive is spot on, but I think the effects Mr. Harris outlines are off the mark. They both miss the current trends I am witnessing and seem to be couched in the traditional enterprise datacenter mind set. To sketch out what I mean, I first offer a little background. From my perspective, during the Internet boom of the late 90’s, Oracle grew at a phenomenal rate because every new development project or web site selected Oracle. Oracle did a really smart thing in that they made training widely available so every DBA I knew had some Oracle knowledge. You could actually find people to architect and manage Oracle, unlike DB2, Sybase and Informix (SQL Server was considered a ‘toy’ at the time). What’s more, the ODBC/JDBC connectors actually worked. This combination made development teams comfortable with choosing Oracle, and the Oracle RDBMS seemed ubiqitous as small firms grew out of nothing. Mid-sized firms chose databases based upon DBA analysis of requirements, and they tended to skew the results to the platforms they knew. But this time it’s different. This latest generation of developers, especially web app developers, are not looking for transactional consistancy. They don’t want to be constrained by the back end. And most don’t want to be burdened by learning about a platform that does not enhance the user experience or usability of their applications. Further, basic application behavior is changing in the wake of fast, cheap and elastic cloud services. Developers conceptualize services based upon the ability ot leverage these resources. Strapping a clunky relational contraption on the back of their cheap/fast/simple/agile services is incongrous. It’s clear to me that growth in databases is there, but the choice is non-relational databases or NoSQL variants. Hyder could fill the bill, but only if it was a real live service, and only if transactional consistancy was a requirement. Ease of use, cheap storage, throughput and elasticity are the principle requirements. The question is not if Oracle will lose marketshare to Microsoft because because of Hyder – nobody is going to rip out an entrenched Oracle RDBMS as migration costs and instability far outweigh Hyder’s percieved benefits. This issue is developers of new applications are losing interest in relational databases. The choice is not ‘Hyder vs. Oracle’, it’s ‘can I do everything with flat files/NoSQL or do I need a supporting instance of MySQL/Postgres/Derby for transactional consistency’? The architectural discussion for non-enterprise applications has fundamentally shifted. I am not saying relational databases are dead. Far from it. I am saying that they are not the first – or even second – choice for web application developers, especially those looking to run on cloud services. With the current app development surge relational technologies are an afterthought. And that’s important as this is where a lot of the growth is happening. I have not gone into what this means for database security as that is the subject for future posts. But I will say that monitoring, auditing and assessment all change, as does the application of encryption and masking technologies. Share:

Now that we have a sense of what data to focus on at the beginning of an incident, it’s time to start digging into the response and investigations process itself and talk specifically about what they entail. In larger enterprises, organizing the response process and teams can be extremely complex, due both to the volume of incidents and the complexity of the organizational structure (politics). Some teams align with business units, others with tools, and yet others are centralized. Leading organizations we speak with consistently display a range of established best practices for responding to threats. Each is a little different on specifics, but they all have tiered escalation plans, optimized to specific threat types, planned out in advace. Occasionally we see a radical re-architecting of these structures and incident response processes due to significant changes in the nature of security risks, regulatory changes, or volume of incidents. Support tools and technology also evolve to support changing processes. We start the process once an alert has triggered and front-line personnel are initiating the response process. This involves multiple teams and tiers, depending on the nature of the incident. Before detailing the organizational structure, there are a few points to keep in mind: There is no ‘right’ organization: Team organization is influenced by the overall organizational layout and nature of the business. We describe a hierarchical and centralized structure, but we have talked with organizations which spread these functions across different teams to align with business units. That said, nearly every organization has a top-tier team or individual responsible for major incidents and those crossing business or agency lines. Organize for longevity: Organize around skills and responsibilities rather than tools. Tools come and go, and it’s important that the team utilize platform-specific skills without devolving to a focus on specifici tools. Communicate early, even if you don’t have answers yet: It’s important to communicate the basic nature of incidents up the chain early, but not necessarily the details. Higher-level tiers need to know that an incident is occurring and the basics, even if they won’t be directly involved. This helps them prepare resources early and identify incidents with broad scope, even if the early responder doesn’t realize the full impact. Not every incident needs to be passed on, especially as many low-level incidents are handled pretty much immediately, but anything with broader potential should result in a ‘heads-up’ notification. Carefully define containment policies: Advanced attacks, as well as those potentially involving law enforcement, require different handling than a simple external intrusion attempt. Cutting off malware or instantly cleaning systems could trigger an attacker response and result in a deeper and more complex infection. Our instinct is to cut all attacks off when we detect them, but this may result in more and longer term damage; sometimes partial containment, monitoring, or other action (or even inaction) is more appropriate. Plan containment scenarios for major attack types early, communicate them, and make sure junior personnel are trained to react properly. Clearly define roles and responsibilities: Every team member should know when to escalate, as well as who to notify and when. All too often, a crisis occurs because junior folks tried to manage risk which they lacked the scope, authority, or ability to handle. The key to managing incidents in large environments is to focus on people and process. The right foundation optimizes incident response and enables nimble and graceful escalation. Making incident response look easy is actually very very hard, and take a lot of work and practice. But the benefits are there. The faster and more effectively you can engage the right resources, the less time the attacker has to wreak havoc in your environment. In our next posts we will walk through the response tiers and talk about types of incidents, tools, and skills involved at each level. Share:

For those of you who are not American Football fans, we’re in the middle of the playoffs over here. Teams work all year to get into the tournament and secure a high seeding. And of course the best laid plans sometimes end up at the wrong end of a blowout (yes, ATL Falcons, I’m talking about you). This past week’s NFC Championship provided a lot more drama than in the past, and not because it was a competitive, exciting game. Instead it was the reaction from all sorts of folks when Chicago’s QB, Jay Cutler, was taken out the game with an alleged knee injury. It did seem kind of strange, with Cutler walking around on the sideline. How hurt could he be? In years past, the commentators and analysts would weigh in and focus on the game. But the game has clearly changed. Lots of folks chimed in on Twitter and in blogs about how hurt (or not) Cutler was. Some NFL players called him a wimp. Some questioned his heart. All in real time. And even better, without any real information from which to judge. You don’t need no stinking proof. Guys in testosterone overload talked smack about needing to be taken off the field on a stretcher before they’d leave a championship game. The chatter around the news has actually become the news, which is rather weird. The past 48 hours haven’t been about how Chicago played the game or even the Packers trip to the Super Bowl after sliding into the tournament as #6 seed. It was about Cutler. Now he’s got to defend whether he should have been playing on a Level 2 MCL sprain (which is really a tear). Welcome to the Real Time generation. Who needs proof? There’s tweeting to do! We see this in security as well. You have folks live tweeting conference presentations, and half the time in meetings during their work days. I hear about stupid clients and funny jokes, in real time. This is both good and bad. I used to judge my pitches based on heads nodding and how many folks came up after the session and chatted. At least now I know where I stand. If I suck, someone in the crowd has tweeted it. Why have an off-day with 100 folks, when you can be laid bare to the entire Twitterverse? Likewise, if I’m killing it, I get that feedback right when I step off the stage. Fortunately I haven’t gotten so wrapped up around this real time feedback that once I’m done I defer real life conversation to re-tweet flattering comments. Though Rich has been known to use Twitter for Q&A when he moderates panels. I’m still trying to calibrate the true effect of this real-time communication, but I have time. Real time isn’t going away anytime soon. -Mike Photo credits: “Pile of Peanuts” originally uploaded by falcon1961 Last Call. Vote for Me. Is it too late to grovel? I think you can still vote for the Social Security Blogger Awards. The Incite has been nominated in the Most Entertaining Security Blog Category. My fellow nominees are Jack Daniel’s Uncommon Sense, the Naked Sophos folks, and some Symantec bunker dwellers from the UK. All very entertaining and worthy competition. Help a brother out with a vote. If I win, Swedish pumps for all! Yeah, baby! Incite 4 U Trojan opens the malware umbrella: It seems the Trojan man has upped the ante in the latest round of malware punch/counter-punch. Cloud AV helps leverage reputation and a much broader library of bad stuff to detect, and dramatically improves effectiveness to still pretty crappy. So it’s not surprising that bad guys would just block calls to any external service from the AV client. It’s no different than when some malware uninstalled other root kits. Once a machine is owned, why wouldn’t they install the software they want and disable stuff they don’t? Even worse, it’s not clear how the AV vendors can block this behavior. Any ideas? – MR A little security theater on the way out: Back in 2005 when the FFIEC told banks they had to start using two-factor authentication, the industry responded with one of the most impressive acts of security theater I’ve ever seen. Instead of giving us all tokens or linking our accounts to text messages on our phone, they used these idiotic browser/system detection technologies that are effectively worthless. But according to my former colleague Avivah Litan in this NetworkWorld article, the FFIEC might be correcting their mistake. Get ready for the screaming from both banks and consumers, but this one could tighten the window the bad guys have to drain your account once they grab your credentials. – RM Scratching Bottom: When I used to develop software, prior to release I would do a sanity check of the publicly exposed methods in my code to determine my “threat surface”. More to the point, what interfaces would attackers target, and which methods in particular could expose functions or data critical to the system? It’s a rather myopic programmer’s view of attack surface, but addressed the parts I was most interested in and the components under my control. When Microsoft announced the Attack Surface Analyzer last week I was somewhat non-plussed, as their tool focuses on “classes of security weaknesses as applications are installed on the Windows operating system”. As a developer my responsibility was the top of the stack, not the bottom. Sure, I might be responsible for Apache `httpd` and the database, but not the platform nor other supporting applications. But security of the platform matters – even if attack surface analysis of the OS is not part of your SDL/release management process. Tools like Threat Surface Analyzer would be handy to `diff` revisions over time so you could confirm applications and OS configurations are what you expect. Most IT admins have tools that verify application sets, and others to verify configuration and patch settings, but this is a different