Research

Attacks keep happening. Breaches keep happening. Senior management keeps wondering what the security team is doing. The lack of demonstrable progress [in stopping malware] comes down to two intertwined causes. First, devices are built using software that has defects attackers can exploit. Nothing is perfect, especially not software, so every line of code presents an attack surface. Second, employees can be fooled into taking action (such as installing software or clicking a link) that enables attacks to succeed. Application Control technology can have a significant impact on the security posture of protected devices, but has long been much maligned. There was no doubt of its value in stopping attacks, especially those using sophisticated malware. Being able to block the execution of unauthorized executables takes many common attacks out of play. But there is a user experience cost for that protection.   In Reducing Attack Surface with Application Control, we look at the double-edged sword of application control, detail a number of use cases where it fits well, and define selection criteria to consider for the technology. Keep in mind that no one control or tactic fits every scenario. Not for every company, nor for every device within a company. If you are looking for a panacea you are in the wrong business. If you are looking for a technology that can lock down devices in appropriate circumstances, check out this paper. Conclusion: Application control can be useful – particularly for stopping advanced attackers and securing unsupported operating systems. There are trade-offs as with any security control, but with proper planning and selection of which use cases to address, application control resists device compromise and protects enterprise data. We would like to thank AppSense for licensing the paper and supporting our research. We make this point frequently, but without security companies understanding and getting behind our Totally Transparent Research model you wouldn’t be able to enjoy our research. Get the paper via our permanent landing page or download the paper directly (PDF). Share:

Rich here, As technology professionals we always place bets with our careers. There is no way to really know, for certain, which sets of skills will be most in demand down the road. Yet, as with financial investments, we only have so many resources (time and brain cells) to allocate at any given time. Invest too much too early and your nifty new skills won’t be in demand. Too late and you miss the best opportunities, and are stuck playing catch-up if that’s even possible. Sometimes we make deliberate decisions, and sometimes we just sort of luck out. This week I am excited to announce my involvement as an Advisory Board member of DevOps.com. It’s something I basically fell into when I mentioned to Alan Shimmel, who founded it, that I was spending a ton of research time on DevOps and security. I never really intended to revert to my roots and start writing code and managing systems again – never mind realizing I was hooked into what may be one of the most important operational framework changes to hit IT in a long time. For me it was a series of chained intellectual and professional challenges that self-organized into a logical progression. I would love to say I planned it, but really I mostly tripped into it. It all started when Jim Reavis of the Cloud Security Alliance asked if I would be interested in building a training class for the CCSK exam. I said sure, but only if we could build some hands-on labs so security pros would learn how the cloud really works, and weren’t merely looking at architectural diagrams. I had launched some things in Amazon before, but I had never needed to create packaged, reproducible environments (the labs). Never mind ones that could hide complexity from students while still allowing them to create complete application stacks almost completely automatically. At the time I was solving problems to make labs and teach a few cloud security essentials. In the process, I was learning the foundation of techniques that underlie many DevOps processes. Total. Blind. Luck. This was before DevOps was a hot term – I just worked from problem to problem to meet my own needs. Then I refined the labs. Then I decided to create some proof of concept demonstrations of Software Defined Security techniques. Solving, in the process, some core DevOps problems that weren’t well documented anywhere. I wasn’t the first to hit the problem or come up with a solution, but no one else seemed to write it down, so I had to work my way through it from scratch. Then I started hearing more about DevOps. And as I dug in, I realized I was solving many of the same problems with many of the same tools. This is why I think DevOps is so important. I didn’t set out to “learn DevOps” – I set out to solve a set of practical implementation problems I was experiencing in the cloud, and in the process found myself smack in the middle of the DevOps ‘movement’ (whatever that is). Anyone who wants to operate in that environment needs the same basic skills, and any organizations deploying applications into the cloud will find themselves using the same techniques, to one degree or another. It is early days still, but I am not doubling down on cloud and DevOps because I think they are overhyped analyst fads. Spend some time in the trenches and you will realize there really isn’t any other way to get the job done, once you start down a certain road. On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences Rich quoted in Macworld UK on Apple security. To be honest, I think this is from an old blog post, but I’ll take it. Dave Lewis on Apple TV password disclosure. Favorite Securosis Posts Adrian Lane: Firestarter: RSA Postmortem. Mike Rothman: New Paper: Leveraging TI in Security Monitoring. Yeah, it’s my work. But there is a lot of noise about threat intelligence out there now, and much less about how to actually use it effectively. This paper looks at TI in terms of security monitoring. Rich: New Paper: Leveraging TI in Security Monitoring. Threat Intelligence was all over RSA, and Mike has been working on this research for far longer than those marketing departments. He really nails it, bringing TI from buzzwords to actionable advice. Nice. Other Securosis Posts Incite 3/12/2014: Digging Out. Advanced Endpoint and Server Protection: Quick Wins. Advanced Endpoint and Server Protection: Detection/Investigation. Favorite Outside Posts Mike Rothman: The cost of doing business at the RSA Conference. Big money. Big money. No whammies. Check out these numbers and maybe you will understand why some companies opt for a suite at the W to do meetings. Adrian Lane: To Wash It All Away. And epic rant that includes such gems as “For the uninitiated, Cascading Style Sheets are a cryptic language developed by the Freemasons to obscure the visual nature of reality and encourage people to depict things using ASCII art.” and “Here’s a life tip: when you’re confused about what something is, DON’T EXECUTE IT TO DISCOVER MORE CLUES!” Rich: Does devops leave security out in the cold? I will be writing more on this in coming days, but I think it’s safe to say this article misses the target. I guarantee you security can effectively integrate with DevOps, but not using some of the techniques mentioned in this article. Security has to fully integrate into the process. Gunnar Peterson: Ultimate Cheat Sheet for Dealing with Haters. Research Reports and Presentations Leveraging Threat Intelligence in Security Monitoring. The Future of Security: The Trends and Technologies Transforming Security. Security Analytics with Big Data. Security Management 2.5: Replacing Your SIEM Yet? Defending Data on iOS 7. Eliminate Surprises with Security Assurance and Testing. What CISOs Need to Know about Cloud Computing. Defending Against Application Denial of Service Attacks. Executive Guide to Pragmatic Network Security Management. Security Awareness Training Evolution. Top News and Posts Target Didn’t Follow Up After Hackers Tripped Its Security System. We still

The ritual is largely the same. I do my morning stuff (usually consisting of some meditation and some exercise), I grab a quick bite, and then I consult my list of things that need to get done. It is long, and seems to be getting longer. The more I work, the more I have to do. It’s a good problem to have, but it’s still a problem. And going to RSA two weeks ago exacerbated it. I had a lot of great conversations with lots of folks who want to license our research, have us speak at their events, and have us advise them on all sorts of things. It’s awesome, but it’s still a problem.   Of course you probably think we should expand and add a bunch of folks to keep up with demand. We have thought about that. And decided against it. It takes a unique skill set to do what we do, the way we do it. The folks who understand research tend to be locked up by big research non-competes. The folks who understand how to develop business tend not to understand research. And the very few who can do both generally aren’t a cultural fit for us. Such is life… But that’s not even the biggest obstacle. It’s that after 4+ years of working together (Rich and Adrian a bit more), we enjoy a drama-free environment. The very few times we had some measure of disagreement or conflict, it was resolved with a quick email or phone call, in a few minutes. Adding people adds drama. And I’m sure none of us wants more drama. So we put our heads down and go to work. We build the pipeline, push the work over the finish line, and try to keep pace. We accept that sometimes we need to decide not to take a project or see how flexible the client is on delivery or scheduling. As with everything, you make choices and live with them. And while it may sound like I’m whining about how great our business is, I’m not. I am grateful to have to make trade-offs. That I have a choice of which projects I work on, for which clients. Not that I can’t find work or deal with slow demand. The three of us all realize how fortunate we are to be in this position: lots of demand and very low overhead. That is not a problem. We want to keep it that way. Which is basically my way of saying, where is that shovel again? Time to get back to digging. –Mike Photo credit: “Digging out auto” originally uploaded by Boston Public Library Securosis Firestarter Have you checked out our new video podcast? Rich, Adrian, and Mike get into a Google Hangout and well hang out. We talk a bit about security as well. We try to keep these to less than 15 minutes and usually fail. March 11 – RSA Postmortem Feb 21 – Happy Hour – RSA 2014 Feb 17 – Payment Madness Feb 10 – Mass Media Abuse Feb 03 – Inevitable Doom Jan 27 – Government Influence Jan 20 – Target and Antivirus Jan 13 – Crisis Communications 2014 RSA Conference Guide In case any of you missed it, we published our fifth RSA Conference Guide. Yes, we do mention the conference a bit, but it’s really our ideas about how security will shake out in 2014. You can get the full guide with all the memes you can eat. Heavy Research We are back at work on a variety of blog series, so here is a list of the research currently underway. Remember you can get our Heavy Feed via RSS, where you can get all our content in its unabridged glory. And you can get all our research papers too. Advanced Endpoint and Server Protection Quick Wins Detection/Investigation Prevention Assessment Introduction Newly Published Papers Leveraging Threat Intelligence in Security Monitoring The Future of Security Security Management 2.5: Replacing Your SIEM Yet? Defending Data on iOS 7 Eliminating Surprises with Security Assurance and Testing What CISOs Need to Know about Cloud Computing Incite 4 U Incentives drive organizational behavior: I am not sure why Gunnar tweeted a link to something he posted back in October, but it gave me an opportunity to revisit a totally awesome post. In Security Engineering and Incentives he goes through the key aspects of security engineering, and incentives are one of the four cornerstones (along with security policy, security mechanism, and assurance). Probably the most important of the cornerstones, because without proper incentives no one does anything. If you have ever been in sales you know the compensation plan drives behavior. It is that way in every functional part of the business. In the not-so-real world you have folks who do what they are supposed to because they do. And in the real world, those behaviors are driven by incentives, not risk (as GP points out). So when you wonder why the Ops team ignores the security policy and developers couldn’t give less of a crap about your security rules, look at what they are incented to do. Odds are be secure isn’t really on that list. – MR Persona non grata: The Mozilla Wiki does not really capture the essence of what’s going on with Mozilla’s Persona project, but the gist is that their effort to offer third party identity federation has failed. There is some debate about whether technical or financial derailed the project and prevented it from reaching “critical mass”, but I think the statement “We looked at Facebook Connect as our main competitor, but we can’t offer the same incentives (access to user data)” pretty much nails it. If you wonder why Yahoo is ditching Facebook and Google federation services in lieu of their own offering, understand that identity is the next generation’s “owning the user”, and a key means for data providers (advertising networks) to differentiate their value to advertisers. The goal of federated identity was to offer easier and better identity management across web applications, doing away with user names and passwords. But identity providers have seen the greatest benefit, through enrichment of the data

We are all rested and recovered from RSA (yeah, right) and it’s time to review the week and what we think. Did we mention security is back, baby?! That’s right – it is clear budgets are now free, and the stink of desperation is fading. Here’s the video: And the audio-only version is up – we should be available for subscription in iTunes next week. Thanks, and see you next week… Share:

We have covered the main aspects of the threat management cycle, in terms of the endpoint and server contexts, in our last few posts. Now let’s apply these concepts to a scenario to see how it plays out. In this scenario you work for a high-tech company which provides classified technology to a number of governments, and has a lot of valuable intellectual property. You know you are targeted by state-sponsored adversaries for the classified information and intellectual property on your networks. So you have plenty of senior management support and significant resources to invest in dealing with advanced threats. You bought into reimagined threat management, and have deployed a combination of controls on your endpoints and servers. These include advanced heuristics on valuable endpoints, application control on servers with access to key intellectual property stores, and broad deployment of device activity monitoring technology – all because you know it is a matter of when rather than if you will be compromised. You supplement endpoint and server protections with network-based malware detection and full packet capture. So resources are not an issue and you have controls in place to deal with advanced adversaries. Of course that and $4 will get you a coffee, so you need to build these controls into a strong process to ensure you can react faster and better to the attacks you know are coming. But not every organization can make such extensive investments, so you may not have the full complement of controls at your disposal. The Attack: Take 1 This attack starts as many do, with an adversary sending a phishing email with a malicious MS Office attachment to an employee in the finance department. The employee’s device has an agent that uses advanced heuristics, which identifies the malicious behavior when the file attempts to turn off the traditional AV product and install what looks like a dropper on the device. The agent runs at the kernel level so it manages to block the attack and administrators alerted, and no harm is done… this time. These are the kinds of quick wins you are looking for, and even with proper security awareness training, employees are still very likely to be duped by advanced attackers. So additional layers of defense, beyond the traditional endpoint protection suite, are critical. The Attack: Take 2 The advanced adversary is not going to give up after their blocked initial foray. This time they target the administrative assistant of the CEO. They pull out a big gun, and use a true 0-day to exploit an unknown flaw in the operating system to compromise the device. They deliver the exploit via another phishing email and get the admin to click on the link to a dedicated server never used for anything else. A drive-by download exploits the OS using the 0-day, and from there they escalate privileges on the admin’s device, steal credentials (including the CEO’s logins) and begin reconnaissance within the organization to find the data they were tasked to steal. As the adversary is moving laterally throughout the organization they compromise additional devices and get closer to their goal, a CAD system with schematics and reports on classified technology. As mentioned above, your organization deployed network-based malware detection to look for callbacks, and since a number of devices have used similar patterns of DNS searches (which seem to be driven by a domain-generating algorithm), alarms go off regarding a possible compromise. While you are undertaking the initial validation and triage of this potential attack, the adversaries have found the CAD system and are attempting to penetrate the server and steal the data. But the server has application controls, and will not run any unauthorized executables. So the attack is blocked and the security team is alerted to a bunch of unauthorized activity on that server. This is another quick win – attackers found their target but can’t get the data they want directly. Between the endpoint compromise calling back to the botnet, and attempts on the server, you have definitive proof of an adversary in your midst. At this point the incident response process kicks in. Respond and Contain As we described in our incident response fundamentals series, you start the response process after confirming the attack by escalating the incident based on what’s at risk and the likelihood of data loss. Then you size up the incident by determining the scope of the attack, the attacker’s tactics, and who the attacker is, to get a feel for intent. With that information you can decide what kind of response you need to undertake, and its urgency. Your next step is to contain the attack and make sure you have the potential damage under control. This can take a variety of forms, but normally it involves quarantining the affected device (endpoint or server) and starting the forensics investigation. But in this scenario – working with senior management, general counsel, and external forensic investigators – the decision has been made to leave the compromised devices on the network. You might do this for a couple reasons: You don’t want to tip off the adversary that you know they are there. If they know they have been detected they may burrow in deeper, hiding in nooks and crannies and making it much harder to really get rid of them. Given an advanced attacker is targeting your environment, you can gather a bunch of intelligence about their tactics and techniques by watching them in action. Obviously you start by making sure the affected devices can’t get to sensitive information, but this gives you an opportunity to get to know the adversary. A key part of this watching and waiting approach is continuing to collect detailed telemetry from the devices, and starting to capture full network traffic to and from affected devices. This provides a full picture of exactly what the adversary is doing (if anything) on the devices. Investigate The good news is that the investigation team has access to extensive telemetry from device activity monitoring and network packet capture. Analyzing the first compromised

As we continue our research into the practical uses of threat intelligence (TI), we have documented how TI should change existing security monitoring (SM) processes. In our Leveraging Threat Intelligence in Security Monitoring paper, we go into depth on how to update your security monitoring process to integrate malware analysis and threat intelligence. Updating our process maps demonstrates that we don’t consider TI a flash in the pan – it is a key aspect of detecting advanced adversaries as we move forward. Here is our updated process map for TI+SM.:   As much as you probably dislike thinking about other organizations being compromised, this provides a learning opportunity. An excerpt from the paper explains in more detail: There are many different types of threat intelligence feeds and many ways to apply the technology – both to increase the effectiveness of alerting and to implement preemptive workarounds based on likely attacks observed on other networks. That’s why we say threat intelligence enables you to benefit from the misfortune of others. By understanding attack patterns and other nuggets of information gleaned from attacks on other organizations, you can be better prepared when they come for you. And they will be coming for you – let’s be clear about that. So check out the paper and figure out how your processes need to evolve, both to keep pace with your adversaries, and to take advantage of all the resources now available to keep your defenses current. We would like to thank Norse Corporation for licensing this paper. Without support from our clients, you wouldn’t be able to use our research without paying for it. You can check out the permanent landing page for the paper, or download it directly (PDF). Share:

Our last AESP post covered a number of approaches to preventing attacks on endpoints and servers. Of course prevention remains the shiny object most practitioners hope to achieve. If they can stop the attack before the device is compromised there need be no clean-up. We continue to remind everyone that hope is not a strategy, and counting on blocking every attack before it reaches your devices always ends badly. As we detailed in the introduction, you need to plan for compromise because it will happen. Adversaries have gotten much better, attack surface has increased dramatically, and you aren’t going to prevent every attack. So pwnage will happen, and what you do next is critical, both to protecting the critical information in your environment and to your success as a security professional. So let’s reiterate one of our core security philosophies: Once the device is compromised, you need to shorten the window between compromise and when you know the device has been owned. Simple to say but very hard to do. The way to get there is to change your focus from prevention to a more inclusive process, including detection and investigation… Detection Our introduction described detection: You cannot prevent every attack, so you need a way to detect attacks after they get through your defenses. There are a number of different options for detection – most based on watching for patterns that indicate a compromised device. The key is to shorten the time between when the device is compromised and when you discover it has been compromised. To be fair, there is a gray area between detection and prevention, at least from an endpoint and server standpoint. With the exception of application control, the prevention techniques described in the last post depend on actually detecting the bad activity first. If you are looking at controls using advanced heuristics, you detect the malicious behavior first – then you block it. In an isolation context you run executables in the walled garden, but you don’t really do anything until you detect bad activity – then you kill the virtual machine or process under attack. But there is more to detection than just figuring out what to block. Detection in the broader sense needs to include finding attacks you missed during execution because: You didn’t know it was malware at the time, which happens frequently – especially given how quickly attackers innovate. Advanced attackers have stockpiles of unknown exploits (0-days) they use as needed. So your prevention technology could be working as designed, but still not recognize the attack. There is no shame in that. Alternatively, the prevention technology may have missed the attack. This is common as well because advanced adversaries specialize in evading known preventative controls. So how can you detect after compromise? Monitor other data sources for indicators that a device has been compromised. This series is focused on protecting endpoints and servers, but looking at devices is insufficient. You also need to monitor the network for a full perspective on what’s really happening, using a couple techniques: Network-based malware detection: One of the most reliable ways to identify compromised devices is to watch for communications with known botnets. You can look for specific traffic patterns, or for communications to known botnet IP addresses. We covered these concepts in both the NBMD 2.0 and TI+SM series. Egress/Content Filtering: You can also look for content that should not be leaving the confines of your network. This may involve a broad DLP deployment – or possibly looking for sensitive content on your web filters, email security gateways, and next generation firewalls. Keep in mind that every endpoint and server device has a network stack of some sort. Thus a subset of this monitoring can be performed within the device, by looking at traffic that enters and leaves the stack. As mentioned above, threat intelligence (TI) is making detection much more effective, facilitated by information sharing between vendors and organizations. With TI you can become aware of new attacks, emerging botnets, websites serving malware, and a variety of other things you haven’t seen yet and therefore don’t know are bad. Basically you leverage TI to look for attacks even after they enter your network and possibly compromise your devices. We call this retrospective searching. This works by either a) using file trajectory – tracking all file activity on all devices, looking for malware files/droppers as they appear and move through your network; or b) looking for attack indicators on devices with detailed activity searching on endpoints – assuming you collect sufficient endpoint data. Even though it may seem like it, you aren’t really getting ahead of the threat. Instead you are looking for likely attacks – the reuse of tactics and malware against different organizations gives you a good chance to see malware which has hit others before long. Once you identify a suspicious device you need to verify whether the device is really compromised. This verification involves scrutinizing what the endpoint has done recently for indicators of compromise or other such activity that would confirm a successful attack. We’ll describe how to capture that information later in this post. Investigation Once you validate the endpoint has been compromised, you go into incident response/containment mode. We described the investigation process in the introduction as: Once you detect an attack you need to verify the compromise and understand what it actually did. This typically involves a formal investigation, including a structured process to gather forensic data from devices, triage to determine the root cause of the attack, and searching to determine how broadly the attack has spread within your environment. As we described in React Faster and Better, there are a number of steps in a formal investigation. We won’t rehash them here, but to investigate a compromised endpoint and/or server you need to capture a bunch of forensic information from the device, including: Memory contents Process lists Disk images (to capture the state of the file system) Registry values Executables (to support malware analysis and reverse engineering) Network activity logs As part of the investigation you also need to understand the attack timeline. This enables you

I don’t code much. In fact over the last 10 years or so I have been actively discouraged from coding, with at least one employer threatening to fire me if I was discovered. I have helped firms architect new products, I have done code reviews, I have done some threat modeling, and even a few small Java utilities to weave together a couple other apps. But there has been very, very little development in the last decade. Now I have a small project I want to do so I jumped in with both feet, and it feels like I was dumped into the deep end of the pool. I forgot how much bigger a problem space application development is, compared to simple coding. In the last couple of days I have learned the basics of Ruby, Node.js, Chef, and even Cucumber. I have figured out how to bounce between environments with RVM. I brushed up on some Python and Java. And honestly, it’s not very difficult. Learning languages and tools are trivial matters. A few hours with a good book or web site, some dev tools, and you’re running. But when you are going to create something more than a utility, everything changes. The real difficulty is all the different layers of questions about the big picture: architecture, deployment, UI, and development methodologies. How do you want to orchestrate activities and functions? How do you want to architect the system? How do you allow for customization? Do I want to do a quick prototype with the intention of rewriting once I have the basic proof of concept, or do I want to stub out the system and then use a test-driven approach? State management? Security? Portability? The list goes on. I had forgotten a lot of these tasks, and those brain cells have not been exercised in a long time. I forgot how much prep work you need to do before you write a line of code. I forgot how easy it is to get sucked into the programming vortex, and totally lose track of time. I forgot the stacks of coffee-stained notes and hundreds of browser tabs with all the references I am reviewing. I forgot the need to keep libraries of error handling, input validation, and various other methods so I don’t need to recode them over and over. I forgot how much I eat when developing – when my brain is working at capacity I consume twice as much food. And twice as much caffeine. I forgot the awkwardness of an “Aha!” moment when you figure out how to do something, a millisecond before your wife realizes you haven’t heard a word she said for the last ten minutes. It’s all that. And it’s good. On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences Mort quoted in Network World. Rich quoted in Building the security bridge to the Millennials. Adrian quoted on Database Denial of Service. David Mortman and Adrian Lane will be presenting at Secure360. Mike and JJ podcast about the Neuro-Hacking talk at RSA. Favorite Securosis Posts Adrian Lane: Research Revisited: The Data Breach Triangle. This magical concept from Rich has aged very very well. I also use this frequently, basically because it’s awesome. Mike Rothman: Research Revisited: Off Topic: A Little Perspective. Rich brought me back to the beginning of this strange journey since I largely left the corporate world. 2006 was so long ago, yet it seems like yesterday. Other Securosis Posts Incite 3/5/2014: Reentry. Research Revisited: FireStarter: Agile Development and Security. Research Revisited: POPE analysis on the new Securosis. Research Revisited: Apple, Security, and Trust. Research Revisited: Hammers vs. Homomorphic Encryption. Research Revisited: Security Snakeoil. New Paper: The Future of Security The Trends and Technologies Transforming Security. Research Revisited: RSA/NetWitness Deal Analysis. Research Revisited: 2006 Incites. Research Revisited: The 3 Dirty Little Secrets of Disclosure No One Wants to Talk About. Favorite Outside Posts Adrian Lane: Charlie Munger on Governance. Charlie Munger is a favorite of mine, and about as pragmatic as it gets. Good read from Gunnar’s blog. Gal Shpantzer: Bloodletting the Arms Race: Using Attacker’s Techniques for Defense. Ryan Barnett, web app security and WAF expert, writes about banking trojans’ functionality and how to use it against attackers. David Mortman: Use of the term “Intelligence” in the RSA 2014 Expo. Mike Rothman: How Khan Academy is using design to pave the way for the future of education. I’m fascinated by design, or more often by very bad design. Which we see a lot of in security. This is a good story of how Khan Academy focuses on simplification to teach more effectively. Research Reports and Presentations The Future of Security: The Trends and Technologies Transforming Security. Security Analytics with Big Data. Security Management 2.5: Replacing Your SIEM Yet? Defending Data on iOS 7. Eliminate Surprises with Security Assurance and Testing. What CISOs Need to Know about Cloud Computing. Defending Against Application Denial of Service Attacks. Executive Guide to Pragmatic Network Security Management. Security Awareness Training Evolution. Firewall Management Essentials. Top News and Posts Behind iPhone’s Critical Security Bug, a Single Bad ‘Goto’. We Are All Intelligence Officers Now. A week old – we’re catching up on our reading. Marcus Ranum at RSA (audio). Hacking Team’s Foreign Espionage Infrastructure Located in U.S. The Face Behind Bitcoin Uroburos Rootkit Fix it tool available to block Internet Explorer attacks leveraging CVE-2014-0322 Blog Comment of the Week This week’s best comment goes to Marco Tietz, in response to Research Revisited: FireStarter: Agile Development and Security, and you’ll have to watch the video to get it. @Adrian: good video on Agile vs Security. But why did you have the Flying Spaghetti Monster in there and didn’t even give it credit! 🙂 rAmen Share:

After I got off the plane Friday night, picked my bag up off the carousel, took the train up to the northern Atlanta suburbs, got picked up by the Boss, said hello to the kids, and then finally took a breath – my first thought was that RSA isn’t real. But it is quite real, just not sustainable. That makes reentry into my day to day existence a challenge for a few days.   It’s not that I was upset to be home. It’s not that I didn’t want to see my family and learn about what they have been up to. My 5 minute calls two or three times a day, while running between meetings, didn’t give me much information. So I wanted to hear all about things. But first I needed some quiet. I needed to decompress – if I rose to the surface too quickly I would have gotten the bends. For me the RSA Conference is a nonstop whirlwind of activity. From breakfast to the wee hours closing down the bar at the W or the Thirsty Bear, I am going at all times. I’m socializing. I’m doing business. I’m connecting with old friends and making new ones. What I’m not doing is thinking. Or recharging. Or anything besides looking at my calendar to figure out the next place I need to be. For an introvert, it’s hard. The RSA Conference is not the place to be introverted – not if you work for yourself and need to keep it that way. I mean where else is it normal that dinner is a protein bar and shot of 5-hour energy, topped off with countless pints of Guinness? Last week that was not the exception, it was the norm. I was thankful we were able to afford a much better spread at the Security Blogger’s Meetup (due to the generosity of our sponsors), so I had a decent meal at least one night. As I mentioned last week, I am not about to complain about the craziness, and I’m thankful the Boss understands my need to wind down on reentry. I make it a point to not travel the week after RSA, both to recharge, get my quiet time, and reconnect with the family. The conference was great. Security is booming and I am not about to take that for granted. There are many new companies, a ton of investment coming into the sector, really cool innovative stuff hitting the market, and a general awareness that the status quo is no good. Folks are confused and that’s good for our business. The leading edge of practitioners are rethinking security and have been very receptive to research we have been doing to flesh out what that means in a clear, pragmatic fashion. This is a great time to be in security. I don’t know how long it will last, but the macro trends seem to be moving in our direction. So I’ll file another RSA Conference into the memory banks and be grateful for the close friends I got to see, the fantastic clients who want to keep working with us, and the new companies I look forward to working with over the next year (even if you don’t know you’ll be working with us yet). Even better, next year’s RSA Conference has been moved back to April 2015. So that gives me another two months for my liver to recover and my brain cells to regenerate. –Mike PS: This year we once again owe huge thanks to MSLGROUP and Kulesa Faul, who made our annual Disaster Recovery Breakfast possible. We had over 300 people there and it was really great. Until we got the bill, that is… Photo credit: “Reentry” originally uploaded by Evan Leeson Securosis Firestarter Have you checked out our new video podcast? Rich, Adrian, and Mike get into a Google Hangout and, well, hang out. We talk a bit about security as well. We try to keep these less than 15 minutes, and usually fail. Feb 21 – Happy Hour – RSA 2014 Feb 17 – Payment Madness Feb 10 – Mass Media Abuse Feb 03 – Inevitable Doom Jan 27 – Government Influence Jan 20 – Target and Antivirus Jan 13 – Crisis Communications 2014 RSA Conference Guide In case any of you missed it, we published our fifth RSA Conference Guide. Yes, we do mention the conference a bit, but it’s really our ideas about how security will shake out in 2014. You can get the full guide with all the memes you can eat. Heavy Research We are back at work on a variety of blog series, so here is a list of the research currently underway. Remember you can get our Heavy Feed via RSS, where you can get all our content in its unabridged glory. And you can get all our research papers too. Leveraging Threat Intelligence In Security Monitoring Quick Wins with TISM The Threat Intelligence + Security Monitoring Process Revisiting Security Monitoring Benefiting from the Misfortune of Others Advanced Endpoint and Server Protection Prevention Assessment Introduction Newly Published Papers The Future of Security Security Management 2.5: Replacing Your SIEM Yet? Defending Data on iOS 7 Eliminating Surprises with Security Assurance and Testing What CISOs Need to Know about Cloud Computing Defending Against Application Denial of Service Security Awareness Training Evolution Firewall Management Essentials Incite 4 U TI is whatever you want it to mean: Interesting experiment from FireEye/Mandiant’s David Bianco, who went around the RSA show floor and asked vendors what threat intelligence (TI) meant to vendors who used the term prominently in their booths. Most folks just use the buzzword, and mean some of the less sophisticated data sources. I definitely understand David’s perspective, but he is applying the wrong filter. It’s like of like having a Ph.D. candidate go into a third grade classroom and wonder why the students don’t understand differential equations. Security is a big problem, and the kinds of things David is comfortable with at the top of his Pyramid of Pain would be lost on 98% of the world. If even 40% of the broad market would use

I have had many conversations over the last few months with firms about to take their first plunge into Agile development methodologies. Each time they ask how to map secure software development processes into an Agile framework. So I picked this Firestarter for today’s retrospective on Agile Development and Security (see the original post with comments). I am a big fan of the Agile project development methodology, especially Agile with Scrum. I love the granularity and focus it requires. I love that at any given point in time you are working on the most important feature or function. I love the derivative value of communication and subtle peer pressure that Scrum meetings produce. I love that if mistakes are made, you do not go far in the wrong direction – resulting in higher productivity and few total disasters. I think Agile is the biggest advancement in code development in the last decade because it addresses issues of complexity, scalability, focus, and bureaucratic overhead. But it comes with one huge caveat: Agile hurts secure code development. There, I said it. Someone had to. The Agile process, and even the scrum leadership model, hamstrings development in terms of building secure products. Security is not a freakin’ task card. Logic flaws are not well-documented and discreet tasks to be assigned. Project managers (and unfortunately most ScrumMasters) learned security by skimming a “For Dummies” book at Barnes & Noble while waiting for lattes, but they are the folks making the choices as to what security should make it into iterations. Just like general IT security, we end up wrapping the Agile process in a security blanket or bolting on security after the code is complete, because the process itself is not suited to secure development. I know several of you will be saying “Prove it! Show us a study or research evidence that supports your theory.” I can’t. I don’t have meaningful statistical data to back up my claim. But that does not mean it isn’t true, and there is ample anecdotal evidence to support what I am saying. For example: The average Sprint duration of two weeks is simply too short for meaningful security testing. Fuzzing & black box testing are infeasible in the context of nightly builds or pre-release sanity checks. Trust assumptions, between code modules or system functions where multiple modules process requests, cannot be fully exercised and tested within the Agile timeline. White box testing can be effective, but security assessments simply don’t fit into neat 4-8 hour windows. In the same way Agile products deviate from design and architecture specifications, they deviate from systemic analysis of trust and code dependencies. It is a classic forest for the trees problem: efficiency and focus gained by skipping over big picture details necessarily come at the expense of understanding how the system and data are used as a whole. Agile is great for dividing and conquering what you know, but not so great for dealing with the abstract. Secure code development is not like fixing bugs where you have a stack trace to follow. Secure code development is more about coding principles that lead to better security. In the same way Agile cannot help enforce code ‘style’, it doesn’t help with secure coding guidelines. (Secure) style verification is an advantage of peer programming and inherent to code review, but not intrinsic to Agile. The person on the Scrum team with the least knowledge of security, the Product Manager, prioritizes what gets done. Project managers generally do not track security testing, and they are not incented to get security right. They are incented to get the software over the finish line. If they track bugs on the product backlog, they probably have a task card buried somewhere but do not understand the threats. Security personnel are chickens in the project, and do not gate code acceptance the way they traditionally were able in waterfall testing; they may also have limited exposure to developers. The fact that major software development organizations are modifying or wrapping Agile with other frameworks to compensate provide security is evidence of the difficulties in applying security practices directly. The forms of testing that fit Agile development are more likely to get done. If they don’t fit they are typically skipped (especially at crunch time), or they need to be scheduled outside the development cycle. It’s not just that the granular focus on tasks makes it harder to verify security at the code and system levels. It’s not just that features are the focus, or that the wrong person is making security decisions. It’s not just that the quick turnaround in code production precludes effective forms of testing for security. It’s not just that it’s hard to bucket security into discreet tasks. It is all that and more. We are not about to see a study comparing Waterfall with Agile for security benefits. Putting together similar development teams to create similar products under two development methodologies to prove this point is infeasible. I have run Agile and Waterfall projects of similar natures in parallel, and while Agile had overwhelming advantages in a number of areas, security was not one of them. If you are moving to Agile, great – but you will need to evolve your Agile process to accommodate security. What do you think? How have you successfully integrated secure coding practices with Agile? Share: