Research

I had a long chat with Josh Corman yesterday afternoon about Rugged, especially as it applies to software development. I know this will be a continuing topic at the RSA conference, and we are both looking forward to a series of brainstorming sessions on the subject. One aspect that intrigues both of us is the overlap between Agile and Rugged as conceptual frameworks for guding developer decisions. I though this was important enough to blog up prior to the conference. The discussion went something like this: Agile – as a concept – is successful because when the principles behind the Agile Manifesto are put into practice, they make software development easier and faster. Agile development – embodied as one of many different process enhancements – is successful because they promote Agile principles. When creating Rugged, mirroring Agile Manifesto was a great approach because both strive to adjust development’s approach to creating software. But the Agile Manifesto illustrates – through its 12 principles – how you should prioritize preferences and make tradeoffs when molding software. Rugged has yet to define the principles that, when put into practice, promote Rugged software. Rugged is missing embodiments – examples to guide practitioners – that describe and promote Rugged principles. Rugged denotes a problem set (software is fragile, insecure, and feature-focused to the exclusion of all else) but lacks principles and a roadmap for fixing it. That’s the bad part, and the gist of my Twitter rant earlier this week. The good news is that the overlap between the two concepts provides plenty of examples of what Rugged could be. The more I think about it, the more I think the parallels between Agile and Rugged are important and serve as an example of how to approach Rugged development. There is sufficient overlap that several of the Agile principles can be directly adopted by Rugged with no loss of meaning or intent. Specifically, stealing from the Agile Principles: Welcoming changing requirements, even late in development …: Threats evolve rapidly, as do use cases and deployment models (Cloud? Anyone?). The fact that new security issues pop up like whack-a-moles is no different than new feature requests in web application development. The agility to respond to new requests and reprioritize on customer importance is no different that being agile enough to respond to risks. This principle applies equally well to Rugged as to Agile. Working software is the primary measure of progress: If your software does not compile, or is filled with logic errors, development efforts have not been totally successful. If your code is filled with security bugs, your software has variable functionality, then your development efforts have not been totally successful. When it comes to secure code development, I look at security as just another vector to manage on. It’s one of many factors that must be accounted for during the development process. Security is not your only goal, and usually not even the most important goal, but something important to account for. You can choose to ignore it, but if so there will likely be some major issue down the road. We are at that uncomfortable junction in the history of software development where we are seeing some firms have businesses disrupted by failing to manage risks posed by new code. Ruggedness should be a metric for progress. Continuous attention to technical excellence and good design enhances agility: I do threat modelling when building new software. I do it after the architecture phase and sometime during the design phase, because threat modelling finds weaknesses in my design choices. Sometimes they are logic flaws, sometimes communication protocol flaws, and sometimes it’s simply that the platform I was considering does support adequate security. Regardless, examining code with a jaundiced eye – looking for issues before they become serious problems – is all part of the design process. The scrutiny enhances product quality and Ruggedness. I have avoided problems before they became serious, because they were exposed during design, and those problems were easier to fix than ones I found later. That is only one example of the overlap. Build projects around motivated individuals: Coders are competitive. Developers have egos. Most developers want to write quality code, and to be recognized as experts who pay attention to detail. Most I have worked with are highly motivated to practice, to learn, and to get better. When there is a coding standard, they work hard to make sure their code meets it. They don’t want the code they checked in to crash the nightly build because everyone on the team will hear about it. If Ruggedness is part of the coding standard, and security checks are part of daily regression tests, there is no reason to expect the development team to do anything other than raise their game and meet the challenge. Simplicity – the art of maximizing the amount of work done – is essential: Developers are creative. Agile as a concept is intended to allow developers to think of creative solutions. Group discussions and open dialog, combined with rapid prototyping proofs of concept, all help find simple solutions to complex problems. Security problems fall to the same blade if you allow them to be addressed in the same way. Unfortunately much of what I am proposing here is a heck of a lot easier when building new code, as opposed to retrofitting old code. I have lugged the burden of legacy software many times, and the restrictions imposed by some old glob of misbehaving garbage crushes inspiration and ingenuity. Bubble gum and duct tape are fun up to a point, but sooner or later it becomes just fixing someone else’s crap over and over again. With new code I contend that Rugged is simply good programming practices – and if incorporated efficiently it will make software designers, coders, and quality assurance teams better. To some of you I am simply playing security jazz, this is all BS, and it really does not help you get your jobs

My wife says to me, “I seem to be getting your junk mail. Somebody just sent me Data Security Quiz results.” I have no idea what she means, so she forwarded me the email from the National Information Security Assocation (NISA). I confess that I had never heard of this organization before, and I really don’t know what they do. Apparently they quizzed a number of real estate agents and brokers around the country to find out how much they knew about data security. The results were emailed as a way of educating real estate professionals at large. Color me shocked. Actually, I thought the questions were pretty good to be asking for sales people. The Q&A was as follows: According to industry standard practices, when is it safe to leave sensitive client information in your car (either in electronic form, such as a laptop or in paper form)? Answer: d) Never. Which tool is most important once a network breach has been discovered? Answer: c) Access Log For most workplace computers when is it possible to be infected with malicious software? Answer: a) Anytime the computer is on. If I only collect client data for a short sale processing company, I am not responsible for data leaks? Answer: False What are the only actions that can guaranty the security of client data? Answer: c) There is no way to guaranty data security. What is the one sure method to determine if your computer contains malicious software? Answer: b) There is no way to be 100 percent sure. Question three actually cracked me up because it is so true! I think there is a little bit of FUD going on here to get people to attend a seminar, because the email talks about blended threats and Stuxnet. I know real estate agents are pretty pissed about the state of the economy, but I am pretty sure plutonium enrichment is not a general concern. Regardless, it is very interesting to see how much security awareness training and security bullitens are being distributed to real estate professionals. Like Rich’s mention a few weeks ago that the owner of the local coffee shop was aware of PCI-DSS. The times they are a-changin’. One final note: It appears we have SOLD OUT the Cloud Security Training course we are offering February 13th. If you are still interested, let us know and we will see if we can find a bigger room. Probably not, but we will see what we can do. Given the interest in the material, we are looking at providing more classes in the coming months so it helps us if you let us know if you are interested in cloud security certification. On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences Adrian’s Dark Reading article on Database Security in the Cloud. First in a series. Securosis Mentioned in PF newsletter. Adrian’s podcast on Agile Development, Security Fail for RSA. More NRF quotes from Adrian on security in the retail vertical. Rich quoted on 10 Risks in Public Cloud Computing. Favorite Securosis Posts Mike Rothman: Good Programming Practices vs. Rugged Development. We can always learn from similar initiatives and try not to make the same mistakes. Interesting post here from Adrian comparing Rugged to Agile. Adrian Lane: You Made Your Bed, Now Sleep in It. Ego and bravado have a funny way of coming back to crush security pros. Have I mentioned I suck lately? Other Securosis Posts Incite 2/2/2011: The End of Anonymity. Favorite Outside Posts Mike Rothman: Everyone has a plan until they get hit. I’m glad Gunnar is our team. Great quote from Tyson. Great post. Adrian Lane: Why terror alert codes never made sense. Actually every airport I have been to has been ‘Orange’ for three years. Too bad there are no free market forces to punish this type of stupidity. Project Quant Posts NSO Quant: Index of Posts. NSO Quant: Health Metrics–Device Health. NSO Quant: Manage Metrics–Monitor Issues/Tune IDS/IPS. NSO Quant: Manage Metrics–Deploy and Audit/Validate. Research Reports and Presentations The Securosis 2010 Data Security Survey. Monitoring up the Stack: Adding Value to SIEM. Network Security Operations Quant Metrics Model. Network Security Operations Quant Report. Understanding and Selecting a DLP Solution. White Paper: Understanding and Selecting an Enterprise Firewall. Understanding and Selecting a Tokenization Solution. Security + Agile = FAIL Presentation. Top News and Posts Microsoft accuses Google of Clickjacking. Abusing HTTP Status Codes to Expose Private Information. Plentyofhack, er, Plentyoffish Hack. Skimmers That Never Touch ATM. Mark Anderson says China’s IP Theft Unprecedented. Egypt shuts down their Internet. NRO to announce IPV6. The NRO might want to have someone pen test their site as I am getting error codes straight from the database, but that’s a different subject. Blog Comment of the Week Remember, for every comment selected, Securosis makes a $25 donation to Hackers for Charity. This week’s best comment goes to Joshua Corman, in response to Good Programming Practices vs. Rugged Development. @securityninja Rugged is a Value. A characteristic. An Attribute. A Quality. A State. Rugged in its simplest sense is an affirmative, non-security-executive desirable. Security is a negative – a Cost/Tax and usually an inhibitor to what a CIO wants. Rugged encapsulates things like: Availability Survivability Supportability Longevity Security* Scalability …that the CIO already wants. For your eCommerce, do you want a flimsy Hosting Site? or a Rugged Hosting site? Communities like OWASP can help developers to affect more Rugged outcomes. Jeff is involved in Rugged. Rugged is on the overlooked People level more heavily than on the process and tech level. We have a lot of great tools and technology and frameworks (sure we could use more and better ones). What’s most been lacking is Mainstream awareness and demand for the value of Rugged. In my 11/12 months, I’ve seen the most traction for Rugged on those buying software. on Demand. If we can drive sufficient Demand, Supply will often follow. I’m still looking to connect with you 1 on 1. For

Twitter exploded last night with news that the self-proclaimed world’s #1 hacker’s email and Twitter accounts were compromised. Personally, the amount of time that good people spend feeding that troll annoys me. Which is why I’m not mentioning his name. Why give him any more SEO points for acting poorly? Since the beginning of time there have been charlatans, shysters, and frauds; this guy is no different. Major media outlets are too dumb and lazy to do the work required to vet their experts, so they respond to his consistent PR efforts. Whatever. But let’s deal with the situation at hand because it’s important. First off, if you bait a lion, you shouldn’t be surprised when you get eaten. Tell me you were surprised when Roy got mauled by his white tiger. I was more surprised it took that long. In other words, live by the sword, die by the sword. And clearly that is the case here. Now there are 4gb of email and other sensitive files in the wild, and this guy’s closet will be opened for all to see. And there are skeletons in there. To be clear, this is wrong. The attackers are breaking the law, but it’s hard to feel bad for the victim. His sophomoric threats, frivolous lawsuits, and intimidation games probably worked OK in the schoolyard, but in the real world – not so much. It’s your bed, now you get to sleep in it. Second, if you know you are a target, why would you leave a huge amount of sensitive documents in an email store on a publicly accessible server? I read a Tweet that said his email was at GoDaddy. Really? And isn’t the first rule of email that it’s not a file store? I know we all probably violate that dictum from time to time, but to have financial records, account numbers, and legal filings in your email box? Come on, now! Basically, I suspect there is stuff there that could put our victim in the big house for a long time. Again, you made the bed, now sleep in it. We take ridiculous security precautions for a 3-person company. It’s actually a huge pain in the ass. And we are fully cognizant that at some point we will likely be breached. Crap, if it can happen to Kaminsky it can happen to us. So we don’t do stupid things. Too often. And that really is the lesson here. Everyone can be breached, even the world’s #1 hacker. Share:

“Hi Mike, how are you this morning?” When I heard those words I instinctively checked over my shoulder, since no one really calls me by name in any of the coffee and bagel shops I frequent. And that is intentional. I like to be the nondescript guy who may look familiar, but you don’t know from where. I don’t do small talk, and if I’m in a very good mood, maybe you’ll get a smirk. Other than that, I’m just the guy with his head down, inhaling coffee, and banging away at his Mac. Part of this is the security mindset. I vary my patterns and try to blend in. You never know when that hit team will be after you, so I don’t want to be a soft target. I’m also mostly anti-social. Sure, I turn it on for a few events a year, but truth be told, I’m like most of you. Introverted and happy to do my thing and not engage in small talk about stuff I mostly don’t care about. Unless I’m talking to you, then I’m very interested. Really. So once I realize the gig is up and they know who I am, my mind goes into response mode. I start thinking about extraction of the threat and how to eliminate any forensics trail. I’m sure the CSI team in my city is top notch. I’m evaluating locations for my Dexter-style kill room. I’m thinking of where I can get those rolls of plastic, and it’s time for a new reciprocating saw anyway, so my old trusty saw will do just fine. But then I realize being friendly isn’t a capital offense, so I’ll have to let it slide. This time. It turns out the staff at the bagel shop aren’t the only folks recognizing me. I had a guy come up to me in Starbucks and basically introduce himself because he’s seen me a number of times over the past few weeks. Another one who has to disappear? Of course, I recognized him too, since I pay attention to stuff like that. He rotates the stores he goes to as well. Not because he’s a paranoid security guy or socially inept, he just has various meetings around town and it’s convenient. So I guess the gig is up. I guess after living in ATL over six years and being in coffee shops 3-4 times per week, I can no longer slip entirely under the rader. Is it time for a change in behavior? Maybe smile a bit and even make conversation? Yeah, not so much. I can get comfortable with some level of recognition, but being friendly? Homey don’t play that. Mike Photo credits: “Anonymous is Friendly?” originally uploaded by liryon CCSK Training @ RSA Going to RSA? Interested in proving your cloud competency? Then you may be interested in the CCSK (Certificate of Cloud Security Knowledge), offered by the Cloud Security Alliance. We have partnered with the CSA to build a full-day training session to make sure you are ready to pass the test. The maiden voyage of this course will be Feb 13, the day before RSA. The training program costs $400, which includes a token to take the test (which costs $295 otherwise). So basically, you can spend a day with the Securosis team for $100. Let’s just say that’s a fair bit below our normal rates. And we are cutting off registration at 30, so you’ll get personal attention, whether you want it or not. We have a handful of slots left, so sign up now. Incite 4 U Groundhog Security Day: Love this obvious observation from Julie Starr on the reality that the more things change, the more they stay the same. Wait, a persistent attacker? Yes, we’ve seen this movie before and as Rich says, we aren’t going to change human behavior. Bad guys will find ways to do bad things. N00bs will continue to think they can win. One step above n00bs, folks will think they can protect something a persistent attacker wants. And the rest of us need to continue reminding these folks of the reality of our predicament. To answer Julie’s question on whether we’ve made progress, I’d say we have. Security is top of mind for most. That doesn’t mean it’s easy, or that we get what we want, or all our users any smarter. It just means organizations are now making conscious decisions to ignore security. And most are no longer blissfully unaware. No, it’s not where we want to be, but it’s still progress from where we were. – MR Open sourced: Apparently the source code of the KLAVA AV engine created by Kaspersky Labs was leaked to the Internet. Kaspersky is downplaying the report, saying it’s only a fragment of code, and it’s from 2008. But when you are talking about the core of a processing engine, 2,000 lines of C++ code is a lot and it’s pretty important. It’s very unlikely, given Big AV’s focus on adding features and researching new signatures, that the current engine has been fundamentally altered from the leaked version. To say it another way, there is a reasonable likelihood this is close to current production code. Will it affect the business? No. Existing customers pay for the signatures and all the other crap that goes along with an endpoint suite nowadays. The bulk of development costs go into research, so this is likely to have no effect on the business. Knowing how the processing engine works shouldn’t help attackers circumvent AV, so it’s pretty much “no harm, no foul”. – AL Getting real doesn’t make crap products work: I’m a big fan of MacGyver, so when I saw an article on a MacGuyer approach to security, I was intrigued. Some aspects of Richard Rushing’s approach are good. Especially the idea of “faster ways to detect and seal the vulnerabilities”, say the React Faster and Better guys. But the idea of “real” AV, IDS/IPS, and firewalls

It’s time for a good old fashion beatdown. Personally I’m working hard on not overreacting to stuff and letting most annoyances (which would normally set me off) pass on by. But sometimes, you know, a purge is required. It kind of reminds me of that great scene in 48 Hours, where Nick Nolte tells Eddie Murphy to be cool when they enter a bar to question someone. Nolte then proceeds to tear the place apart and when Murphy says “I thought you said to be cool,” the response is “That was cool.” Sometimes it’s cool to swing the clue bat. The target of my Louisville Slugger is this nonsense from Justin Rattner of Intel about a new technology that will be able to stop 0-day attacks. There are lots of smart people at Intel, who very well may have come up with something novel. But don’t waste our time until you can talk about it. Why? Because it’s useless to dangle yet another carrot in front of a disillusioned and frustrated security community. You don’t look smart – you look like an ass to us security folks. You read the article and thought the same thing: Another damn vendor is going to ride in on yet another horse and make our problems go away. Let’s just say security folks have heard this story before. Pretty much every year there is a new shiny object positioned as the answer to all our problems. There is a whole lot of security technology roadkill, now swept under the carpets, that made the same claim. Sorry, Intel. Your technology is not the answer. Unless it involves disconnecting all those PCs or phones or tablets or smart TVs from the network. Your suppositions and empty claims are insulting to all the folks who work their asses off every day to keep the attackers out of the crap that you and Microsoft have been shoving up our asses for the last twenty years. And one other thing, Intel: you are in the process of trying to acquire McAfee. One widespread concern is that an Intel + McAfee combination would provide an unfair advantage in the security market by bundling security into chips. So to go out and say you’ve got some new technology that you can’t talk about, which may or may not involve McAfee’s stuff, a few months before the deal closes, seems pretty stupid to me. Good thing I’m not an EU anti-trust official, eh? Let’s just say that if the deal closes, I hope our friends at McAfee teach you Intel folks a little bit about the security mindset. We security folks don’t believe you. Show us, don’t tell us. Prove that it can stop 0-day attacks. Let smart folks try to break it. Until then, you are just the latest in a long line of posers that have promised the world and ultimately delivered nothing. Share:

At Cal, even though my major was software, I had to take several electronics courses. When I got to college I had programming experience, but not the first clue about electronics. Resistors, LEDs, logic gates, karnaugh maps, and EPROMs were well outside my understanding. But within the first few weeks of classes they had us building digital alarm clocks and television remote controls from scatch. The first iterations were all resistors on breadboards, then we moved to chips and EEPROMs… which certainly made the breadboards neater. Things got much more complex a couple semesters in, when we had to design and implement CPUs – and the design not only had to work, but it actually had to meet design specifications for low power, low chip count, and high clock rates. Regardless, I loved the hardware classes, and I gave serious consideration to changing my major from software to hardware. But that pretty well died when I left college. Over the last couple months I have been picking up some basic projects for fun. Little stuff like replacing light bulbs with LEDs in an old stereo receiver, putting automated light switches into some of the wall plates, and making my own interconnect cables. A new multimeter and soldering iron, and I was off to the races. Pretty simple stuff, but then I wanted to do something a little more complex. I had a couple ideas but wanted to see if other people had already done something similar. As with most projects, I consulted The Google, and that’s when I stumbled on the world of Arduino. This little device keeps coming up on chat boards for all the projects I was looking at. I start doing my research I found the Arduino documentary which resulted in one of those “Oh, holy $#^!” moments. As long as I have been around software and participated in open source software projects, I had never considered the possibility of open source hardware. About 1/3 of the way into the documentary, they talk about physically creating objects from open source plans, using Arduino as the controller, and creating complex electronic control systems by assembling simple circuits other people have posted on the net. There are all sorts of how-tos on digital audio converters and, since Arduino offers the basic infrastructure to communicate with the computer through a USB port, it provides a common controller interface. Technically I have been aware of Arduino for a couple years now, as I see them at DEFCON, but I never really thought about owning one. My impression was that it was a toy for instructional purposes. That assessment is way off the mark. I mean, screwdrivers and hammers are incredibly simple tools, but essential when working on your home improvement/car/whatever. This thing is a simple-to-use but very powerful tool for interfacing computers and other logic controllers with just about any electronic device. I am sure those of you who have been playing with these for a few years are saying “Well, duh!”, so I acknowledge I am late to the party. But if you are not aware of this little device, it’s a cool tool with hundreds of easy examples for learning about electronics. So I just placed my order for a starter set, and am now looking for plans to build my own DAC for my iMac. I am hopeful it will sound better than the standard ones you can buy. Playing with malicious USB drives sounds interesting as well. And don’t forget our Cloud Security Alliance training February 13th in San Francisco! On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences Mike Rothman: Firewalls are Evolving. Adrian’s DB2 Security Overview white paper. Nice mention by Schwartz Communications. Favorite Securosis Posts Mike Rothman: The Greenfield Project. I know it’s lame to vote for yourself. But this is a great thought experiment. Rich: Microsoft, Oracle, or Other. Not really about security, but Adrian does a great job explaining the current database market drivers. Adrian Lane & David Mortman: Intel’s Red Herring. Other Securosis Posts React Faster and Better: Organizing for Response. Register for Our Cloud Security Training Class at RSA. Incite 1/25/2011: The Real-Time Peanut Gallery. Rich at Macworld. Friday Summary: January 21, 2010. Favorite Outside Posts Mike Rothman: He Who is Not Busy Being Born is Busy Dying. What Gunnar said. Yes, we do security, but we need to get smarter about the business. Period. Rich: The New School on the Ponemon data breach study. While Larry’s methodology has improved significantly, I think the cost-per-record-lost metric is one of the most misleading in our industry. There is no way it will accurately reflect your own losses with such wide variation between organizations. Adrian Lane: Russell eviscerates the Ponemon study. Pepper: Android Trojan details. Multiple very clever and very naughty bits combine to ‘hear’ and exfiltrate spoken or punched-in credit card data. David Mortman: Seven Dirty Words of Cloud Security. Project Quant Posts NSO Quant: Index of Posts. NSO Quant: Health Metrics–Device Health. NSO Quant: Manage Metrics–Monitor Issues/Tune IDS/IPS. NSO Quant: Manage Metrics–Deploy and Audit/Validate. NSO Quant: Manage Metrics–Process Change Request and Test/Approve. Research Reports and Presentations The Securosis 2010 Data Security Survey. Monitoring up the Stack: Adding Value to SIEM. Network Security Operations Quant Metrics Model. Network Security Operations Quant Report. Understanding and Selecting a DLP Solution. Top News and Posts Apple Taps Former Navy Information Warrior David Rice for Global Director of Security. Five men arrested on a charge of launcing pro-WikiLeaks DDoS attacks. Facebook hack apparently an API bug. Accounts were not hijacked. Exclusive: Q&A with hacker “srblche srblchez”. Android Trojan Collects Credit Card Details. “White Space” tracking database. Not security news, but an interesting look at some of behind-the-scene details on reuse of TV spectrum and Google’s thirst for data. Opera Security Flaw Fixed. Goatse Security Site Hacked. DHS to End Color-Coded ‘Threat Level’ Advisories. I know many of you are crying in a corner, asking how you can conduct yourselves without the big colorful fear-o-meter.

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