Research

There’s something I have always struggled with as an analyst. Because of the, shall we say, ‘aggressiveness’ of today’s markets and marketers, most of us in the analyst world are extremely cautious about ever saying anything positive about any vendors. This frequently extends to entire classes of technology, because we worry it will be misused or taken out of context to promote a particular product or company. Or, as every technology is complex and no blanket statement can possibly account for everyone’s individual circumstances, that someone will misinterpret what we say and get pissed it doesn’t work for them. What complicates this situation is that we do take money from vendors, both as advisory clients and as sponsors for papers/speaking/etc. They don’t get to influence the content – not even the stuff they pay to put their logos on – but we’re not stupid. If we endorse a technology and a vendor who offers it has their logo on that paper, plenty of people will think we pulled a pay for play. That’s why one of our hard rules is that we will never specifically mention a vendor in any research that’s sponsored by any vendor. If we are going to mention a vendor, we won’t sell any sponsorship on it. But Mike and I had a conversation today where we realized that we were holding ourselves back on a certain project because we were worried it might come too close to endorsing the potential sponsor, even though it doesn’t mention them. We were writing bad content in order to protect objectivity. Which is stupid. Objectivity means having the freedom to say when you like something. Just crapping on everything all the time is merely being contrarian, and doesn’t necessarily lead to good advice. So we have decided to take off our self-imposed handcuffs. Sometimes we can’t fully dance around endorsing a technology/approach without it ending up tied to a vendor, but that’s fine. They still never get to pay us to say nice things about them, and if some people misinterpret that there really isn’t anything we can do about it. We have more objectivity controls in place here than any other analyst firm we’ve seen, including our Totally Transparent Research policy. We think that gives us the freedom to say what we like. And, to be honest, we can’t publish good research without that freedom. Share:

Everyone’s process is a bit different, but through our research we have found that the best teams tend to gear themselves through three general levels of response, each staffed with increasing expertise. Once the alert triggers, your goal is to filter out the day-to-day crud junior staffers are fully capable of handling, while escalating the most serious incidents through the response levels as quickly as possible. Having a killer investigation team doesn’t do any good if an incident never reaches them, or if their time is wasted on the daily detritus that can be easily handled by junior folks. As mentioned in our last post, Organizing for Response, these tiers should be organized by skills and responsibilities, with clear guidelines and processes for moving incidents up (and sometimes down) the ladder. Using a tiered structure allows you to more quickly and seamlessly funnel incidents to the right handlers – keeping those with the most experience and skills from being distracted by lower-level events. An incident might be handled completely at any given level, so we won’t repeat the usual incident response fundamentals, but instead focus on what to do at each level, who staffs it, and when to escalate. Tier 1: Validate and filter After an incident triggers, the first step is to validate and filter. This means performing a rapid analysis of the alert and either handling it on the spot or passing it up the chain of command. While incidents might trigger off the help desk or from another non-security source, the initial analysis is always performed by a dedicated security analyst or incident responder. The analyst receives the alert and it’s his or her job to figure out whether the incident is real or not, and if it is real, how severe it might be. These folks are typically in your Security Operations Center and focus on “desk analysis”. In other words they handle everything right then and there, and aren’t running into data centers or around hallways. The alert comes in, they perform a quick analysis, and either close it out or pass it on. For simple or common alerts they might handle the incident themselves, depending on your team’s guidelines. The team These are initial incident handlers, who may be dedicated to incident response or, more frequently, carry other security responsibilities (e.g., network security analyst) as well. They tend to be focused on one or a collection of tools in their coverage areas (network vs. endpoint) and are the team monitoring the SIEM and network monitors. Higher tiers focus more on investigation, while this tier focuses more on initial identification. Primary responsibilities: Their main responsibility is initial incident identification, information gathering, and classification. They are the first human filter, and handle smaller incidents and identify problems that need greater attention. It is far more important that they pass information up the chain quickly than try to play Top Gun and handle things over their heads on their own. Good junior analysts are extremely important for quickly identifying more serious incidents for rapid response. Incidents they handle themselves: Basic network/SIEM alerts, password lockouts/failures on critical systems, standard virus/malware. Typically limited to a single area – e.g., network analyst. When they escalate: Activity requiring HR/legal involvement, incidents which require further investigation, alerts that could indicate a larger problem, etc. The tools The goal at this level is triage, so these tools focus on collecting and presenting alerts, and providing the basic investigative information we discussed in the fundamentals series. SIEM: SIEMs aren’t always very useful for full investigations, but do a good job of collecting and presenting top-level alerts and factoring in data from a variety of sources. Many teams use the SIEM as their main tool for initial reduction and scoping of alerts from other tools and filtering out the low-level crud, including obvious false positives. Central management of alerts from other tools helps to identify what’s really happening, even though the rest of the investigation and response will be handled at the original source. This reduces the number of eyeballs needed to monitor everything and makes the team more efficient. Network monitoring: A variety of network monitoring tools are in common use. They tend to be pretty cheap (and there are a few good open source options) and provide good bang for the buck, so you can get a feel for what’s really happening on your network. Network monitoring typically includes NetFlow, collected device logs, and perhaps even your IDS. Many organizations use these monitoring tools either as an extension of their SIEM environment or as a first step toward deeper network monitoring. Full packet network capture (forensics): If network monitoring represents baby steps, full packet capture is your first bike. A large percentage of incidents involves the network, so capturing what happens on the wire is the linchpin of any analysis and response. Any type of external attack, and most internal attacks, eventually involve the network. The more heavily you monitor, the greater your ability to characterize incidents quickly, because you have the data to reconstruct exactly what happened. Unlike endpoints, databases, or applications; you can monitor a network deeply, passively and securely, using tools that (hopefully) aren’t involved in the successful compromise (less chance of the bad guys erasing your network logs). You’ll use the information from your network forensics infrastructure to scope the incident and identify “touch points” for deeper investigation. At this level you need a full packet capture tool with good analysis capabilities – especially given the massive amount of data involved – even if you feed alerts to a SIEM. Just having the packets to look it, without some sort of analysis of them, isn’t as useful. Getting back to our locomotion example, deep analysis of full packet capture data is akin to jumping in the car. Endpoint Protection Platform (EPP) management console: This is often your first source for incidents involving endpoints. It should provide up-to-date information on the endpoint as well as activity logs. Data Loss Prevention

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: